On 2002.04.21 17:43 Felix Kühling wrote:
> Yeah, I thought about that, too. But it is always hard to know how much
> time you need for your test. And in the end it might be faster to reboot
> the machine :). Thanks, anyway.
Take a look to /usr/src/linux-2.4/Documentation/sysrq.txt. I believe that
On 2002.04.21 17:41 Felix Kühling wrote:
> On Sun, 21 Apr 2002 09:36:35 +0100
> José Fonseca <[EMAIL PROTECTED]> wrote:
> > ...
>
> I had a look at the radeon and r128 drivers. They both don't lock when
> switching the mode. But in LeaveVT and EnterVT they do
> RADEONCP_STOP/R128CCE_STOP after DR
On Sun, 21 Apr 2002 09:36:35 +0100
José Fonseca <[EMAIL PROTECTED]> wrote:
> > Ok, I checked aticonsole.c. The existing locks seem to be in the right
> > places. If I understand the problem correctly I will have to make sure
> > that the hardware is in 2d state when the X-server has the lock. Thi
On 2002.04.21 02:31 Felix Kühling wrote:
> ...
>
> OK, I checked the mach64-0-0-4-branch out tonight and compiled it. It
> runs surprisingly usable. The only big difference to mach64-0-0-3 which I
> noticed is that all the CPU load is in the kernel now :)
>
Good. I guess that I can start making
On Thu, 18 Apr 2002 23:37:20 -0400 (EDT)
Leif Delgass <[EMAIL PROTECTED]> wrote:
> I can provide some background on this, since I played around with the
> locks back when Manuel was working on this. First off, it'll probably be
> most productive to work on this on the new branch, when all the
On Sunday 28 October 2001 03:33 pm, Manuel Teira wrote:
> is making WRITE access to the card without calling LOCK_HARDWARE. Perhaps
> this funcion is called from another place were the lock takes place, I
> don't know. Anyway, when the DMA work takes shape on the Mesa layer, the
> places where th
On Sun, 28 Oct 2001, Manuel Teira wrote:
> El Dom 28 Oct 2001 19:17, Leif Delgass escribió:
>
>
>
> > OK. I did test it out doing it in the way I suggested, but I'm still
> > getting a lockup. I was thinking of compiling with the debugging macros
> > turned on to get a better idea of where t
El Dom 28 Oct 2001 19:17, Leif Delgass escribió:
> OK. I did test it out doing it in the way I suggested, but I'm still
> getting a lockup. I was thinking of compiling with the debugging macros
> turned on to get a better idea of where the problem is. Since the problem
> doesn't seem to happ
On Sun, 28 Oct 2001, Manuel Teira wrote:
[snip]
> I still think that we should avoid more than one consecutive locks. It
> has nonsense from my point of view, at least in this case. The
> DRM_LOCK/DRM_UNLOCK macros are defined in:
> xc/programs/Xserver/hw/xfree86/os-support/xf86drm.h and a lot o
El Dom 28 Oct 2001 00:10, Leif Delgass escribió:
> On Sat, 27 Oct 2001, Manuel Teira wrote:
> > El Sáb 27 Oct 2001 21:40, Leif Delgass escribió:
> > > On Sat, 27 Oct 2001, Manuel Teira wrote:
> > > > El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
> > > > > Well, I just got my box to hang hard (l
El Dom 28 Oct 2001 00:10, Leif Delgass escribió:
> On Sat, 27 Oct 2001, Manuel Teira wrote:
> > El Sáb 27 Oct 2001 21:40, Leif Delgass escribió:
> > > On Sat, 27 Oct 2001, Manuel Teira wrote:
> > > > El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
> > > > > Well, I just got my box to hang hard (l
OK, I actually looked at the definition of DRILock/DRIUnlock
(programs/Xserver/GL/dri/dri.c), and it does reference counting, so
locking twice might not be an issue, it just increments the reference
count. What I haven't found yet is where the DRM_LOCK/DRM_UNLOCK macros
used in DRILock/DRIUnlock
On Sat, 27 Oct 2001, Manuel Teira wrote:
> El Sáb 27 Oct 2001 21:40, Leif Delgass escribió:
> > On Sat, 27 Oct 2001, Manuel Teira wrote:
> > > El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
> > > > Well, I just got my box to hang hard (like with the vt switching) when
> > > > running tuxracer a
El Sáb 27 Oct 2001 21:40, Leif Delgass escribió:
> On Sat, 27 Oct 2001, Manuel Teira wrote:
> > El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
> > > Well, I just got my box to hang hard (like with the vt switching) when
> > > running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
>
On Sat, 27 Oct 2001, Manuel Teira wrote:
> El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
> > Well, I just got my box to hang hard (like with the vt switching) when
> > running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
> > defined in my config and the hang happened when loopi
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
> Well, I just got my box to hang hard (like with the vt switching) when
> running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
> defined in my config and the hang happened when looping back to the
> original mode, i.e. the third swi
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
defined in my config and the hang happened when looping back to the
original mode, i.e. the third switch), so I think the
answer is yes, it needs locking.
El Sáb 27 Oct 2001 18:49, Leif Delgass escribió:
> First off, I messed up on the FIFO size defines in mach64_drv.h (drm
> kernel module), they should be:
>
> # define MACH64_CMDFIFO_SIZE_MASK 0x0003ul
> # define MACH64_CMDFIFO_SIZE_192 0xul
First off, I messed up on the FIFO size defines in mach64_drv.h (drm
kernel module), they should be:
# define MACH64_CMDFIFO_SIZE_MASK 0x0003ul
# define MACH64_CMDFIFO_SIZE_192 0xul
# define MACH64_CMDFIFO_SIZE_128
19 matches
Mail list logo
