Menu
▾
▴
dri-devel
|
From: Alexander S. <Ale...@at...> - 2002-04-25 12:27:56
|
> Please do the following tasks via telnet and report > back to the list: > - See if there is any application consuming all processor (top). > - Copy the Xfree86.0.log to a safe place and post it here. > - Check if X is still running or not (ps -A | grep X) and > point down > it's pid, and if it is do: > - do "gdb </path/to/your/X> <pid>" > - get a backtrace with "bt" and paste to somewhere > - quit "q" > - Do the same steps as above with your opengl application. > > Before attempt to do the above get debug info from the DRM, > doing from a X > console as root: > - rmmod mach64 > - insmod mach64 drm_opts=debug > - cat /proc/kmsg > kmsg.txt > > After the computer has crashed send that kmsg. So far that i know you can only restart kernel modules if their usage count is zero. This means as long as you are running X or some application (even when X is already down) it wont work. if it looks like the console is responsive, it still can prevent your machine from shutting down because the kernel module wont unload due to some module internal inconsistency or fault. successfully restarting X in such a case is unlikely as well. If i dont have remote access to the box i would just try to issu a "vga_reset" to et least get a workable screen and analyze the state. Sometimes console switching helps a tiny bit or restarting X (even if it doesnt work) but dont expect much to work, the system is already screwed. |
|
From: Leif D. <lde...@re...> - 2002-04-28 17:48:40
|
On Sun, 28 Apr 2002, Peter Andersson wrote: > Leif Delgass wrote: >=20 > >On Sun, 28 Apr 2002, Peter Andersson wrote: > > > >>>Well, it looks like the _dispatch_clear completes without a > >>>problem. Could you run ksymoops on the syslog? That will decode th= e back > >>>trace from the oops (it's best to run it right after the oops before= you > >>>reboot, so you use the symbol table from the modules installed at th= e time > >>>of the error). =20 > >>> > >>It is included in this email. > >> > > > >I didn't get an attachment, could you send it again? > >=20 > > >=20 > Sorry, wrong attatchment. I don=B4t know whats wrong with me, didn=B4t = get=20 > much sleep last night. Here is the right attatchment. I know the feeling. ;) Well, it looks like you're probably getting the oops at the same point=20 that I am when I run without agpgart. Next time you get an oops, try to=20 run ksymoops before rebooting, you'll get fewer warnings and a more=20 accurate trace. Anyway, I think this is enough info for now. I'll try t= o=20 track down and fix the oops I'm seeing on x86 and then we'll see if that=20 fixes your problem. From your other email, it looks like the bus master=20 test is working, so that's good news. --=20 Leif Delgass=20 http://www.retinalburn.net |
|
From: Leif D. <lde...@re...> - 2002-04-28 18:52:29
|
On Sun, 28 Apr 2002, Leif Delgass wrote: > On Sun, 28 Apr 2002, Peter Andersson wrote: >=20 > > Leif Delgass wrote: > >=20 > > >On Sun, 28 Apr 2002, Peter Andersson wrote: > > > > > >>>Well, it looks like the _dispatch_clear completes without a > > >>>problem. Could you run ksymoops on the syslog? That will decode = the back > > >>>trace from the oops (it's best to run it right after the oops befo= re you > > >>>reboot, so you use the symbol table from the modules installed at = the time > > >>>of the error). =20 > > >>> > > >>It is included in this email. > > >> > > > > > >I didn't get an attachment, could you send it again? > > >=20 > > > > >=20 > > Sorry, wrong attatchment. I don=B4t know whats wrong with me, didn=B4= t get=20 > > much sleep last night. Here is the right attatchment. >=20 > I know the feeling. ;) >=20 > Well, it looks like you're probably getting the oops at the same point=20 > that I am when I run without agpgart. Next time you get an oops, try t= o=20 > run ksymoops before rebooting, you'll get fewer warnings and a more=20 > accurate trace. Anyway, I think this is enough info for now. I'll try= to=20 > track down and fix the oops I'm seeing on x86 and then we'll see if tha= t=20 > fixes your problem. From your other email, it looks like the bus maste= r=20 > test is working, so that's good news. OK, I found out what was causing the oops, but I'm not sure why yet. It=20 was in mach64_dma_vertex: buf_priv->prim =3D vertex.prim; buf_priv->discard =3D vertex.discard; I've disabled these lines until I can figure out what's wrong. Peter can= =20 you update cvs and try it again? --=20 Leif Delgass=20 http://www.retinalburn.net |
|
From: Peter A. <pe...@da...> - 2002-04-28 22:50:01
|
> > >OK, I found out what was causing the oops, but I'm not sure why yet. It= =20 >was in mach64_dma_vertex: > >buf_priv->prim =3D vertex.prim; >buf_priv->discard =3D vertex.discard; > >I've disabled these lines until I can figure out what's wrong. Peter ca= n=20 >you update cvs and try it again? > Now i have re-compiled the entire dri-tree, and yes something has=20 happened. When i run glxgears i do get the glxgears displayed, this has=20 never happened before! The problem is that as soon as the window is=20 displayed the computer hangs and the only way to shut it down is via=20 control+alt+delete, and i am not very happy about that. I can=B4t see any= =20 error messages in the system log, please get back to me on how you wish=20 me to proceed. Peter |
|
From: Leif D. <lde...@re...> - 2002-04-28 23:24:19
|
On Mon, 29 Apr 2002, Peter Andersson wrote: > > > > > >OK, I found out what was causing the oops, but I'm not sure why yet. = It=20 > >was in mach64_dma_vertex: > > > >buf_priv->prim =3D vertex.prim; > >buf_priv->discard =3D vertex.discard; > > > >I've disabled these lines until I can figure out what's wrong. Peter = can=20 > >you update cvs and try it again? > > > Now i have re-compiled the entire dri-tree, and yes something has=20 > happened. When i run glxgears i do get the glxgears displayed, this has= =20 > never happened before! The problem is that as soon as the window is=20 > displayed the computer hangs and the only way to shut it down is via=20 > control+alt+delete, and i am not very happy about that. I can=B4t see a= ny=20 > error messages in the system log, please get back to me on how you wish= =20 > me to proceed. hmmm.. OK, here are some questions for you: Did you actually see the gears being drawn, or just the window with a black background? If you sa= w them being drawn, did you see them moving before the lockup? When the lockup happened, did the screen blank or did it just freeze? --=20 Leif Delgass=20 http://www.retinalburn.net |
|
From: Peter A. <pe...@da...> - 2002-04-28 23:33:37
|
> > >hmmm.. OK, here are some questions for you: Did you actually see the >gears being drawn, or just the window with a black background? > I saw the gears. Previously when it crashed to xmon i only saw the window with the black background. So this is the first time for me when the gears actually get drawn. >If you saw them being drawn, did you see them moving before the lockup? > No motion the system hung as soon as it drew the first frame. >When the lockup happened, did the screen blank or did it just freeze? > It just froze. Peter |
|
From: José F. <j_r...@ya...> - 2002-04-29 00:04:42
|
On 2002.04.29 00:33 Peter Andersson wrote: >> >> >> hmmm.. OK, here are some questions for you: Did you actually see the >> gears being drawn, or just the window with a black background? > I saw the gears. Previously when it crashed to xmon i only saw the > window with the black background. So this is the first time for me when > the gears actually get drawn. > >> If you saw them being drawn, did you see them moving before the lockup? > No motion the system hung as soon as it drew the first frame. This is strange. It seams that it drawed a full frame and copied the back to the front buffer. It's not clear where the fault happened, as it should be able to repeat this cicle over and over. > >> When the lockup happened, did the screen blank or did it just freeze? >> > It just froze. I said that u had to make ctrl-alt-del. This in PowerPC means what? Can u still ssh? If yes a backtrace from glxgears would be great. If not running DRI_MACH64_DEBUG=all glxgears > dump.txt 2>&1 would have to do. José Fonseca |
|
From: Leif D. <lde...@re...> - 2002-04-29 00:16:57
|
On Mon, 29 Apr 2002, Jos=E9 Fonseca wrote: > On 2002.04.29 00:33 Peter Andersson wrote: > >>=20 > >>=20 > >> hmmm.. OK, here are some questions for you: Did you actually see th= e > >> gears being drawn, or just the window with a black background? > > I saw the gears. Previously when it crashed to xmon i only saw the=20 > > window with the black background. So this is the first time for me wh= en=20 > > the gears actually get drawn. > >=20 > >> If you saw them being drawn, did you see them moving before the lock= up? > > No motion the system hung as soon as it drew the first frame. >=20 > This is strange. It seams that it drawed a full frame and copied the ba= ck=20 > to the front buffer. It's not clear where the fault happened, as it sho= uld=20 > be able to repeat this cicle over and over. >=20 > >=20 > >> When the lockup happened, did the screen blank or did it just freeze= ? > >>=20 > > It just froze. >=20 > I said that u had to make ctrl-alt-del. This in PowerPC means what? Can= u=20 > still ssh? If yes a backtrace from glxgears would be great. If not runn= ing >=20 > DRI_MACH64_DEBUG=3Dall glxgears > dump.txt 2>&1 >=20 > would have to do. > Actually turning on all the debugging options when you're not stepping through in a debugger will probably __cause__ a lockup. Setting a breakpoint at the SwapBuffers would let you get a frame of output at a time, but you'd need to compile gears from the Mesa source with debugging= =20 symbols. =20 --=20 Leif Delgass=20 http://www.retinalburn.net |
|
From: Leif D. <lde...@re...> - 2002-04-29 00:22:20
|
On Sun, 28 Apr 2002, Leif Delgass wrote: > On Mon, 29 Apr 2002, Jos=E9 Fonseca wrote: >=20 > > On 2002.04.29 00:33 Peter Andersson wrote: > > >>=20 > > >>=20 > > >> hmmm.. OK, here are some questions for you: Did you actually see = the > > >> gears being drawn, or just the window with a black background? > > > I saw the gears. Previously when it crashed to xmon i only saw the=20 > > > window with the black background. So this is the first time for me = when=20 > > > the gears actually get drawn. > > >=20 > > >> If you saw them being drawn, did you see them moving before the lo= ckup? > > > No motion the system hung as soon as it drew the first frame. > >=20 > > This is strange. It seams that it drawed a full frame and copied the = back=20 > > to the front buffer. It's not clear where the fault happened, as it s= hould=20 > > be able to repeat this cicle over and over. > >=20 > > >=20 > > >> When the lockup happened, did the screen blank or did it just free= ze? > > >>=20 > > > It just froze. > >=20 > > I said that u had to make ctrl-alt-del. This in PowerPC means what? C= an u=20 > > still ssh? If yes a backtrace from glxgears would be great. If not ru= nning > >=20 > > DRI_MACH64_DEBUG=3Dall glxgears > dump.txt 2>&1 > >=20 > > would have to do. > > >=20 > Actually turning on all the debugging options when you're not stepping > through in a debugger will probably __cause__ a lockup. Setting a > breakpoint at the SwapBuffers would let you get a frame of output at a > time, but you'd need to compile gears from the Mesa source with debuggi= ng=20 > symbols. OK, scratch that. I forgot that all implies sync, which will wait for=20 idle after each frame, so you should be OK. You probably don't need all=20 the output for primitives though, so I'd use: DRI_MACH64_DEBUG=3Dsync,api,msg,ioctl glxgears > dump.txt 2>&1 --=20 Leif Delgass=20 http://www.retinalburn.net |
|
From: Peter A. <pe...@da...> - 2002-04-29 00:29:19
|
> I said that u had to make ctrl-alt-del. This in PowerPC means what?=20 > Can u still ssh? If yes a backtrace from glxgears would be great.=20 I can in no way connect to the computer at all, not via telnet or any=20 other remote terminal. Ctrl-alt-del (actually its=20 ctrl-"apple-button"-"powerbutton") in PPC means the same thing as in=20 x86, its as close to pulling the power plug as you can get. > If not running DRI_MACH64_DEBUG=3Dall glxgears > dump.txt 2>&1 would= =20 > have to do.=20 This was also impossible i=B4m afraid. I can=B4t find the dump.txt after = the=20 reboot. Peter |
|
From: José F. <j_r...@ya...> - 2002-04-29 00:38:10
|
On 2002.04.29 01:29 Peter Andersson wrote: >> I said that u had to make ctrl-alt-del. This in PowerPC means what? Can >> u still ssh? If yes a backtrace from glxgears would be great. > > > I can in no way connect to the computer at all, not via telnet or any > other remote terminal. Ctrl-alt-del (actually its > ctrl-"apple-button"-"powerbutton") in PPC means the same thing as in > x86, its as close to pulling the power plug as you can get. > >> If not running DRI_MACH64_DEBUG=all glxgears > dump.txt 2>&1 would >> have to do. > > This was also impossible i´m afraid. I can´t find the dump.txt after the > reboot. mmm.. don't see why it didn't work. Well, from a ssh session do: export DISPLAY=:0.0 DRI_MACH64_DEBUG=sync,api,msg,ioctl glxgears With some luck (and not too much buffering) you may be able to see something before the computer locks. And since you're at it, also load the kernel module with debug option and redirect it to a file (as specified in a previous email), to see if there is anything unusual there. José Fonseca |
|
From: Peter A. <pe...@da...> - 2002-04-29 01:01:22
Attachments:
kmsg.txt
|
> mmm.. don't see why it didn't work. Well, from a ssh session do:
>
> export DISPLAY=3D:0.0
> DRI_MACH64_DEBUG=3Dsync,api,msg,ioctl glxgears
Here is the output from the telnet session. Unfortunatley my telnet=20
client doesn=B4t have any scrollbar (do you know of any windows compatibl=
e=20
that do?). This means that some of the debug messages got lost. I am=20
sorry about this.
mach64DDUpdateHWState: (0x200)=20
context, =
=20
FLUSH_BATCH in=20
mach64DDShadeModel =
=20
mach64EmitHwStateLocked: (0xff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width,=20
setup_cntl, =20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64DDUpdateHWState: (0x200)=20
context, =
=20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64EmitHwStateLocked: (0xff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width,=20
setup_cntl, mach64DDUpdateHWState: (0x200)=20
context, =
=20
FLUSH_BATCH in=20
mach64DDShadeModel =
=20
mach64EmitHwStateLocked: (0xff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width,=20
setup_cntl, =20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64DDUpdateHWState: (0x200)=20
context, =
=20
FLUSH_BATCH in=20
mach64DDShadeModel =
=20
mach64EmitHwStateLocked: (0x10ff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width, setup_cntl,=20
cliprects, =20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64DDUpdateHWState: (0x200)=20
context, =
=20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64EmitHwStateLocked: (0xff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width,=20
setup_cntl, mach64DDUpdateHWState: (0x200)=20
context, =
=20
FLUSH_BATCH in=20
mach64DDShadeModel =
=20
mach64EmitHwStateLocked: (0xff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width,=20
setup_cntl, =20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64DDUpdateHWState: (0x200)=20
context, =
=
=
=20
******************************** =
=
=
=
=20
mach64CopyBuffer( 0x10017b90=20
) =
=
=
=20
FLUSH_BATCH in=20
mach64CopyBuffer =
=20
mach64EmitHwStateLocked: (0xff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width,=20
setup_cntl, mach64DDClear: all=3D1 0,0=20
300x300 =
=20
FLUSH_BATCH in=20
mach64DDClear =
=20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64DDUpdateHWState: (0x200)=20
context, =
=20
mach64EmitHwStateLocked: (0x11ff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width, setup_cntl,=20
misc, cliprects, drmMach64Clear: flag 0x6 color 0 depth ffff=20
nbox=20
1 =
=20
FLUSH_BATCH in=20
mach64DDShadeModel =
=20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64EmitHwStateLocked: (0x11ff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width, setup_cntl,=20
misc, cliprects, mach64DDUpdateHWState: (0x200)=20
context, =
=20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64EmitHwStateLocked: (0xff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width,=20
setup_cntl, mach64DDUpdateHWState: (0x200)=20
context, =
=20
FLUSH_BATCH in=20
mach64DDShadeModel =
=20
mach64EmitHwStateLocked: (0xff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width,=20
setup_cntl, =20
mach64DDUpdateHWState: =
=
=20
FLUSH_BATCH in=20
mach64DDUpdateHWState =
=20
mach64DDUpdateHWState: (0x200)=20
context, =
=20
FLUSH_BATCH in=20
mach64DDShadeModel =
=20
mach64EmitHwStateLocked: (0x10ff) dst_off_pitch, z_alpha_cntl,=20
scale_3d_cntl, dp_fog_clr, dp_write_mask, dp_pix_width, setup_cntl,=20
cliprects, =20
> also load the kernel module with debug option and redirect it to a=20
> file (as specified in a previous email), to see if there is anything=20
> unusual there.
The kmsg is included as an attatchment...
Peter
|
|
From: José F. <j_r...@ya...> - 2002-04-29 09:50:02
|
On 2002.04.29 02:01 Peter Andersson wrote:
>> mmm.. don't see why it didn't work. Well, from a ssh session do:
>>
>> export DISPLAY=:0.0
>> DRI_MACH64_DEBUG=sync,api,msg,ioctl glxgears
>
>
> Here is the output from the telnet session. Unfortunatley my telnet
> client doesn´t have any scrollbar (do you know of any windows compatible
> that do?). This means that some of the debug messages got lost. I am
> sorry about this.
>
> ...
>
>> also load the kernel module with debug option and redirect it to a
>> file (as specified in a previous email), to see if there is anything
>> unusual there.
>
> The kmsg is included as an attatchment...
>
> Peter
I didn't noticed anything unusual in the logs. The last lines showed
nothing new relative to the previous lines. Let's try narrow this down.
On xc/lib/GL/mesa/src/drv/mach64:150-156 you'll find this:
/* HACK!!! This is evil shit...
*/
if ( mmesa->dirty ) {
mach64EmitHwStateLocked( mmesa );
}
drmMach64FlushVertexBuffer( fd, prim, buffer->idx, buffer->used, 1 );
First, comment out the line as:
/* drmMach64FlushVertexBuffer( fd, prim, buffer->idx, buffer->used, 1
); */
and test it. If it still locks, then comment out the line as:
/* mach64EmitHwStateLocked( mmesa ); */
and test it again.
Before testing you have to build and install in both cases. Just do on the
same dir:
make
su -c "make install"
You do not to worry about debug logging. If it doesn't lock the program
should exit with an error message like
"Error: Could not get new VB... exiting",
which is fine as we are always asking more vertex buffers but never return
any.
Depending on which cases it locks we should know where to search further &
deeper.
José Fonseca
|
|
From: Peter A. <pe...@da...> - 2002-04-29 14:37:50
|
I did as you asked and commented out the line: drmMach64FlushVertexBuffer( fd, prim, buffer->idx, buffer->used, 1 ); in xc/lib/GL/mesa/src/drv/mach64/mach64_ioctl.c And as you predicted i got the error message: "Error: Could not get new VB... exiting", Peter |
|
From: José F. <j_r...@ya...> - 2002-04-29 16:43:29
|
On 2002.04.29 15:37 Peter Andersson wrote: > I did as you asked and commented out the line: > > drmMach64FlushVertexBuffer( fd, prim, buffer->idx, buffer->used, 1 ); > > in xc/lib/GL/mesa/src/drv/mach64/mach64_ioctl.c > > And as you predicted i got the error message: > > "Error: Could not get new VB... exiting", > > Peter > I'm getting suspicious that it could be related with the FIFO, i.e., we are flooding your chip (which may be more picky) with requests. One thing that we can do to check that is in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64_drv.h enable DMA my making #define MACH64_USE_DMA 1 as I believe that Leif already made the necessary changes to DMA works in PowerPC too (Isn't Leif?). Also change #define MACH64_VERBOSE 1 and redirect /proc/kmsg to a file. You need to build and install the kernel module, and remove the previous from memory. Don't forget to undo the changes in mach64_ioctl.c. If this still doesn't work, then try to put "#if 0" ... "#endif" around "#if MACH64_USE_DMA"... "#endif /* MACH64_USE_DMA */" in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64_state.c like: #if 0 #if MACH64_USE_DMA ... #endif /* MACH64_USE_DMA */ #endif to disable all that section. Well, Peter, although the bissection algorithm can take some interations, if the initial conditions are met, it's guaranteed that it converges! ;-) José Fonseca |
|
From: Leif D. <lde...@re...> - 2002-04-29 16:53:46
|
On Mon, 29 Apr 2002, Jos=E9 Fonseca wrote: > On 2002.04.29 15:37 Peter Andersson wrote: > > I did as you asked and commented out the line: > >=20 > > drmMach64FlushVertexBuffer( fd, prim, buffer->idx, buffer->used, 1 ); > >=20 > > in xc/lib/GL/mesa/src/drv/mach64/mach64_ioctl.c > >=20 > > And as you predicted i got the error message: > >=20 > > "Error: Could not get new VB... exiting", > >=20 > > Peter > >=20 >=20 > I'm getting suspicious that it could be related with the FIFO, i.e., we= =20 > are flooding your chip (which may be more picky) with requests. >=20 > One thing that we can do to check that is in=20 > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64_drv.h= =20 > enable DMA my making >=20 > #define MACH64_USE_DMA 1 >=20 > as I believe that Leif already made the necessary changes to DMA works = in=20 > PowerPC too (Isn't Leif?). Also change Yes, this should work, though I haven't been able to test it. The bus=20 master test works on ppc, and we know the vertex buffers are OK, since=20 glxgears draws correctly with MMIO, so as long as the virt_to_bus()=20 produces a valid physical address for the buffer, DMA should work. =20 > #define MACH64_VERBOSE 1 >=20 > and redirect /proc/kmsg to a file.=20 Note that the DMA debug output currently uses DRM_INFO, so this will go t= o=20 the system log. Perhaps I should change this to DRM_DEBUG. For that=20 matter, the bus master test could use DRM_DEBUG statements as well. > You need to build and install the=20 > kernel module, and remove the previous from memory. Don't forget to und= o=20 > the changes in mach64_ioctl.c. >=20 > If this still doesn't work, then try to put "#if 0" ... "#endif" around= =20 > "#if MACH64_USE_DMA"... "#endif /* MACH64_USE_DMA */" in=20 > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64_state= .c=20 > like: >=20 > #if 0 > #if MACH64_USE_DMA >=20 > ... >=20 > #endif /* MACH64_USE_DMA */ > #endif >=20 > to disable all that section. >=20 > Well, Peter, although the bissection algorithm can take some interation= s,=20 > if the initial conditions are met, it's guaranteed that it converges! ;= -) >=20 > Jos=E9 Fonseca >=20 --=20 Leif Delgass=20 http://www.retinalburn.net |
|
From: Peter A. <pe...@da...> - 2002-04-29 18:30:49
Attachments:
kmsg.txt
|
> > >>One thing that we can do to check that is in >>xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64_drv.h >>enable DMA my making >> >> #define MACH64_USE_DMA 1 >> >> #define MACH64_VERBOSE 1 >> >>and redirect /proc/kmsg to a file. >> It works!!! This is so cool :-) . I can run glxgears without a computer crash or hang. It runs a bit jerky though, the gears spin for about a second then the computer hangs for a second then the gears start spinning again for a second etc. I attatched a small part of the kmsg.txt to this email (the original one was about 6 mb in size). If you are interested i can send the whole file to you but it looked like it contained the same messages over and over. Regards Peter |
|
From: José F. <j_r...@ya...> - 2002-04-29 18:58:01
|
On 2002.04.29 19:30 Peter Andersson wrote: > ... > It works!!! This is so cool :-) . I can run glxgears without a computer Great! > crash or hang. It runs a bit jerky though, the gears spin for about a > second then the computer hangs for a second then the gears start > spinning again for a second etc. I attatched a small part of the This is probably due to the huge amount of debug output info. Please try again without MACH64_VERBOSE and without the debug option in the kernel module. If everything runs smoothly then also try running more demanding applications. > kmsg.txt to this email (the original one was about 6 mb in size). If you > are interested i can send the whole file to you but it looked like it > contained the same messages over and over. No. Thanks! ;o) Since it worked, that's no longer necessary. > > Regards > > Peter So this means that there should be some problem with the FIFO in your card. We will need to get to the bottom of that eventually (I shall give you a patch to force a longer wait or something similar to try), but not right now since we are really focusing on DMA. I advise you to keep your eyes on dri-devel and dri-patches and keep using an updated CVS, so that if things ever get broken for PowerPC it's more easy to pin-point and fix them. Regards, José Fonseca |
|
From: Leif D. <lde...@re...> - 2002-04-29 18:58:02
|
On Mon, 29 Apr 2002, Peter Andersson wrote: > >>One thing that we can do to check that is in > >>xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64_drv.h > >>enable DMA my making > >> > >> #define MACH64_USE_DMA 1 > >> > >> #define MACH64_VERBOSE 1 > >> > >>and redirect /proc/kmsg to a file. > >> > It works!!! This is so cool :-) . I can run glxgears without a computer > crash or hang. It runs a bit jerky though, the gears spin for about a > second then the computer hangs for a second then the gears start > spinning again for a second etc. I attatched a small part of the > kmsg.txt to this email (the original one was about 6 mb in size). If you > are interested i can send the whole file to you but it looked like it > contained the same messages over and over. Try setting MACH64_VERBOSE back to zero in mach64_drv.h: #define MACH64_VERBOSE 0 ...and see if the jerkiness goes away. Also, could you try this: set MACH64_USE_DMA back to zero in mach64_drv.h, then change line 539 of mach64_state.c from: if ( mach64_do_wait_for_fifo( dev_priv, 16 ) < 0 ) to: if ( mach64_do_wait_for_idle( dev_priv ) < 0 ) ...and see if you still get a lockup. -- Leif Delgass http://www.retinalburn.net |
|
From: Peter A. <pe...@da...> - 2002-04-29 19:27:43
|
> > >Try setting MACH64_VERBOSE back to zero in mach64_drv.h: > >#define MACH64_VERBOSE 0 > >...and see if the jerkiness goes away. > >Also, could you try this: > >set MACH64_USE_DMA back to zero in mach64_drv.h, then change line 539 of >mach64_state.c from: > >if ( mach64_do_wait_for_fifo( dev_priv, 16 ) < 0 ) > >to: > >if ( mach64_do_wait_for_idle( dev_priv ) < 0 ) > >...and see if you still get a lockup. > This works like a charm! And i never thought the graphics board would be this fast, i get about 120 fps on glxgears when i used software rendering i only got about 35-40. I get really smooth working open gl, but there are some kind of error in the rendering perhaps i could drop you a screenshot or something... Thanks for all the help! And please get back to me if you want me to continue to test the driver on the ppc platform. Regards Peter |
|
From: Leif D. <lde...@re...> - 2002-04-29 19:47:20
|
On Mon, 29 Apr 2002, Peter Andersson wrote: > >Try setting MACH64_VERBOSE back to zero in mach64_drv.h: > > > >#define MACH64_VERBOSE 0 > > > >...and see if the jerkiness goes away. > > > >Also, could you try this: > > > >set MACH64_USE_DMA back to zero in mach64_drv.h, then change line 539 of > >mach64_state.c from: > > > >if ( mach64_do_wait_for_fifo( dev_priv, 16 ) < 0 ) > > > >to: > > > >if ( mach64_do_wait_for_idle( dev_priv ) < 0 ) > > > >...and see if you still get a lockup. > > > This works like a charm! Just to clarify, do you mean both things worked? If changing the _wait_for_fifo to _wait_for_idle worked, I think we should keep it that way so we have stable MMIO to fall back on as we move ahead with DMA testing. > And i never thought the graphics board would be > this fast, i get about 120 fps on glxgears when i used software > rendering i only got about 35-40. I get really smooth working open gl, > but there are some kind of error in the rendering perhaps i could drop > you a screenshot or something... Sure, a screenshot would help. Can you describe the problems you see? What apps are you testing with? > Thanks for all the help! And please get back to me if you want me to > continue to test the driver on the ppc platform. Sure, the more testers the better! And it would be good to make sure that ppc and PCI are still working as we continue with DMA. > Regards > > Peter > > > -- Leif Delgass http://www.retinalburn.net |
|
From: José F. <j_r...@ya...> - 2002-04-29 20:27:10
|
On 2002.04.29 21:22 Peter Andersson wrote: > Leif Delgass wrote: > >> On Mon, 29 Apr 2002, Peter Andersson wrote: >> >>> ... >> >> Just to clarify, do you mean both things worked? If changing the >> _wait_for_fifo to _wait_for_idle worked, I think we should keep it that >> way so we have stable MMIO to fall back on as we move ahead with DMA >> testing. >> > Both things worked great, it was when i changed _wait_for_fifo to > _wait_for_idle i got a decent framerate, just changing the verbose did > not help at all. > This is very strange... something is not going well with the reading the fifo... >> >>> And i never thought the graphics board would be this fast, i get about >>> 120 fps on glxgears when i used software rendering i only got about >>> 35-40. I get really smooth working open gl, but there are some kind of >>> error in the rendering perhaps i could drop you a screenshot or >>> something... >>> > > Sure, a screenshot would help. Can you describe the problems you see? > >> What apps are you testing with? > > Actually i only have one working opengl app, and that is prboom an open > source Doom clone with open gl rendering, of course i will try other > applications as well, especially since i am working alot with 3D > modelling and animation. To describe my problem with the open gl > rendering every other vertical "pixel row" is jagged. It looks similar > to the fields in a frozen video frame if you know what i mean, only > these fields are horiziotal. Perhaps the screenshot will speak more > clearly. Nice effect! ;-) It's probably the textures that must be byte swapped too. > >> >> Sure, the more testers the better! And it would be good to make sure >> that ppc and PCI are still working as we continue with DMA. >> > Just drop me a line when you want me to re-compile DRI and i should have > it done in a couple of hours, depending on if i am at work or not. > > Peter > José Fonseca |
|
From: Peter A. <pe...@da...> - 2002-04-30 08:32:42
|
> To describe my problem with the open gl rendering every other > vertical "pixel row" is jagged. It looks similar to the fields in a > frozen video frame if you know what i mean, only these fields are > horiziotal. Perhaps the screenshot will speak more clearly. > > Nice effect! ;-) > > It's probably the textures that must be byte swapped too. Do you mean the "texture mapping drivers" in DRI or in the program (prboom)? If i run the program with indirect rendering the textures work ok. I had the same problems when running quake. Peter |
|
From: José F. <j_r...@ya...> - 2002-04-30 08:46:40
|
On 2002.04.30 09:36 Peter Andersson wrote: >> To describe my problem with the open gl rendering every other vertical >> "pixel row" is jagged. It looks similar to the fields in a frozen video >> frame if you know what i mean, only these fields are horiziotal. >> Perhaps the screenshot will speak more clearly. >> >> Nice effect! ;-) >> >> It's probably the textures that must be byte swapped too. > > Do you mean the "texture mapping drivers" in DRI or in the program > (prboom)? If i run the program with indirect rendering the textures work > ok. I had the same problems when running quake. > > Peter > I meant in the drivers. This is still not very clear - yesterday we discussed this in the IRC meeting -, because the colors are ok. Looking careful to the picture is seems that we have to word swap and not byte swap. Perhaps because within a pixel, the color disposition isn't changed across little/big endian architectures. Another thing that was suggested was to put memory barriers to avoid processor memory cache when accessing the memory-maped IO registers, which could be causing the noticed behaviour without DMA. I'll come back to you again when these things are commited to CVS. José Fonseca |
|
From: Michel <mi...@da...> - 2002-04-30 13:17:07
|
On Tue, 2002-04-30 at 10:45, Jos=E9 Fonseca wrote: > On 2002.04.30 09:36 Peter Andersson wrote: > >> To describe my problem with the open gl rendering every other vertica= l=20 > >> "pixel row" is jagged. It looks similar to the fields in a frozen vide= o=20 > >> frame if you know what i mean, only these fields are horiziotal.=20 > >> Perhaps the screenshot will speak more clearly. > >>=20 > >> Nice effect! ;-) > >>=20 > >> It's probably the textures that must be byte swapped too. > >=20 > > Do you mean the "texture mapping drivers" in DRI or in the program=20 > > (prboom)? If i run the program with indirect rendering the textures wor= k=20 > > ok. I had the same problems when running quake. >=20 > I meant in the drivers. This is still not very clear - yesterday we=20 > discussed this in the IRC meeting -, because the colors are ok. Looking=20 > careful to the picture is seems that we have to word swap and not byte=20 > swap. Perhaps because within a pixel, the color disposition isn't changed= =20 > across little/big endian architectures. I was going to explain this is due to 32 bit swapping exchanging 16 bit texels, but on second thought it should work if both the texture and framebuffer use the same bpp. Where can I see that screenshot? :) --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
Thanks for helping keep SourceForge clean.
X