few more minutes before it locked up, but it still locked up
rather quickly.
I think I remember that there's some way to increase debugging
output from the drm module, but can't remember how. I have a
serial console, and these lockups rarely take down the whole
machine, so I can debug this furth
Felix Kühling a écrit :
I haven't changed anything in the Savage DRM in a while. Must be some
change in the generic drm module. I won't be able to look into this.
Does the oops below ring a bell, anyone?
I think that's the same issue I have
(https://bugs.freedesktop.org/show_bug.cgi?id=2418)
May 22 17:26:33 hypercube kernel: Unable to handle kernel NULL pointer
dereference at virtual
address 0080
May 22 17:26:33 hypercube kernel: printing eip:
May 22 17:26:33 hypercube kernel: dab62bc5
May 22 17:26:33 hypercube kernel: *pde = 0fafd067
May 22 17:26:33 hypercube kernel: *pte =
On Sun, 2005-05-22 at 21:00 +0200, Jerome Glisse wrote:
> Hi,
>
> I setup a x86 with radeon 9800 pro or xt, trying to find
> why it locks. I see little improvement with option no silken
> mouse can you test and tell me if it dones anythings for
> you (X -nosilk).
>
Sorry, that didn't do any good
On Sun, 2005-05-22 at 21:00 +0200, Jerome Glisse wrote:
>
> I setup a x86 with radeon 9800 pro or xt, trying to find
> why it locks. I see little improvement with option no silken
> mouse can you test and tell me if it dones anythings for
> you (X -nosilk).
>
> My thought on this lockups is that
Hi,
I setup a x86 with radeon 9800 pro or xt, trying to find
why it locks. I see little improvement with option no silken
mouse can you test and tell me if it dones anythings for
you (X -nosilk).
My thought on this lockups is that it's similar to the one
r200 users report, X taking 100% of CPU wa
Jerome Glisse wrote:
Okay i finaly came over a stupid bug (as all bugs are...).
Thus i commited the table to r300 and here is what look
like swizzle & modified emit_arithm (there is some debug
code to test swizzling)...
Note that i changed pfs_reg_t thus swizzling is done
in emit arith and note
On 5/22/05, Ben Skeggs <[EMAIL PROTECTED]> wrote:
> The reason I was doing swizzling in t_src is that some ARB_f_p opcodes
> aren't
> native on r300 and we need to emit multiple instuctions to emulate them
> (see LRP).
> If one of the sources used a non-native swizzle, we'd waste alu
> instructions
Okay i finaly came over a stupid bug (as all bugs are...).
Thus i commited the table to r300 and here is what look
like swizzle & modified emit_arithm (there is some debug
code to test swizzling)...
Note that i changed pfs_reg_t thus swizzling is done
in emit arith and note in t_src. This way we c
