Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
Hi José, I got a similar error with your patch applied. On stdout I get the usual Error flushing vertex buffer: return = -11 but the log looks different: Jul 15 13:01:11 viking kernel: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xd000 64MB Jul 15 13:01:11 viking kernel: [drm] Initialized mach64 1.0.0 20020417 on minor 0 Jul 15 13:01:12 viking kernel: [drm] Creating pci pool Jul 15 13:01:12 viking kernel: [drm] Allocating descriptor table memory Jul 15 13:01:12 viking kernel: [drm] descriptor ring: cpu addr 0xc051c000, bus addr: 0x0051c000 Jul 15 13:01:12 viking kernel: [drm] Starting DMA test... Jul 15 13:01:12 viking kernel: [drm] starting DMA transfer... Jul 15 13:01:12 viking kernel: [drm] waiting for idle... Jul 15 13:01:12 viking kernel: [drm] waiting for idle...done Jul 15 13:01:12 viking kernel: [drm] DMA test succeeded, using asynchronous DMA mode Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] ring contents: Jul 15 13:04:02 viking kernel: [drm] head_addr: 0x0051d650 head: 1428 tail: 1944 Jul 15 13:04:02 viking kernel: Jul 15 13:04:02 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd001c000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051d620: 0x007ffe48 0xd0098000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d630: 0x007ffe48 0xd018 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d640: 0x007ffe48 0xd013 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d650: 0x007ffe48 0xd01b4000 0x4dd0 0x (head) Jul 15 13:04:02 viking kernel: [drm] 0x0051d660: 0x007ffe48 0xd0054000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d670: 0x007ffe48 0xd00bc000 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d680: 0x007ffe48 0xd0084000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051de30: 0x007ffe48 0xd008c000 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de40: 0x007ffe48 0xd018 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de50: 0x007ffe48 0xd0098000 0xc0d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de60: 0x007ffe48 0xd00dc000 0x4068 0x (tail) Jul 15 13:04:02 viking kernel: [drm] 0x0051de70: 0x007ffe48 0xd00d4000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de80: 0x007ffe48 0xd01ec000 0x4270 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de90: 0x007ffe48 0xd001c000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] buffer contents: Jul 15 13:04:02 viking kernel: [drm] d01b4000: 0x00060190 Jul 15 13:04:02 viking kernel: [drm] d01b4004:0x0240 = 0x3d806d0d Jul 15 13:04:02 viking kernel: [drm] d01b4008:0x0244 = 0xbcc71574 Jul 15 13:04:02 viking kernel: [drm] d01b400c:0x0248 = 0x3b9f445d Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4454:0x0840 = 0x3d9f677c Jul 15 13:04:02 viking kernel: [drm] d01b4458:0x0844 = 0xbc78d3d8 Jul 15 13:04:02 viking kernel: [drm] d01b445c:0x0848 = 0x3bc179a8 Jul 15 13:04:02 viking kernel: [drm] d01b4460:0x084c = 0xff10 Jul 15 13:04:02 viking kernel: [drm] d01b4464:0x0850 = 0xfee88000 Jul 15 13:04:02 viking kernel: [drm] d01b4468:0x0854 = 0xffcc Jul 15 13:04:02 viking kernel: [drm] d01b446c:0x0858 = 0x07a203ff Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4dc4:0x11b0 = 0x053d03df Jul 15 13:04:02 viking kernel: [drm] d01b4dc8:0x11b4 = 0x01c0 Jul 15 13:04:02 viking kernel: [drm] d01b4dcc:0x11b8 = 0xbb9a4b09 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm]BM_GUI_TABLE = 0x0051d660 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ffe48 Jul 15 13:04:02 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0xd01b4460 Jul 15 13:04:02 viking kernel: [drm] BM_COMMAND = 0x4970 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] BM_STATUS = 0x130060ca Jul 15 13:04:02 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:04:02 viking
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
I tried restarting torcs after the last problem and it locked up the Xserver. I got something in the log before I rebooted: Jul 15 13:16:48 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] ring contents: Jul 15 13:16:48 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:48 viking kernel: Jul 15 13:16:48 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:48 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:48 viking kernel: [drm] ... Jul 15 13:16:48 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:48 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_STATUS = 0x930860ca Jul 15 13:16:48 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:16:48 viking kernel: [drm] FIFO_STAT = 0x Jul 15 13:16:48 viking kernel: [drm]GUI_STAT = 0x0181 Jul 15 13:16:48 viking kernel: [drm]SRC_CNTL = 0x0f00 Jul 15 13:16:48 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle failed BM_GUI_TABLE=0x0051c000 tail: 4 Jul 15 13:16:50 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] ring contents: Jul 15 13:16:50 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:50 viking kernel: Jul 15 13:16:50 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:50 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:50 viking kernel: [drm] ... Jul 15 13:16:50 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:50 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 Jul 15 13:16:50 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] BM_STATUS = 0x930860ca Jul 15 13:16:50 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:16:50 viking kernel: [drm] FIFO_STAT = 0x Jul 15 13:16:50 viking kernel: [drm]GUI_STAT = 0x0181 Jul 15 13:16:50 viking kernel: [drm]SRC_CNTL = 0x0f00 Jul 15 13:16:50 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle failed BM_GUI_TABLE=0x0051c000 tail: 4 Jul 15 13:16:52 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:52 viking kernel: [drm] Jul 15 13:16:52 viking kernel: [drm] ring contents: Jul 15 13:16:52 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:52 viking kernel: Jul 15 13:16:52 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:52 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:52 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:52 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:52 viking kernel: [drm] ... Jul 15 13:16:52 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Mon, Jul 15, 2002 at 01:16:37PM +0200, Felix Kühling wrote: Hi José, I got a similar error with your patch applied. On stdout I get the usual Error flushing vertex buffer: return = -11 but the log looks different: Yes, it's a different problem this time - the engine locked hard. [...] Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] buffer contents: Jul 15 13:04:02 viking kernel: [drm] d01b4000: 0x00060190 Jul 15 13:04:02 viking kernel: [drm] d01b4004:0x0240 = 0x3d806d0d Jul 15 13:04:02 viking kernel: [drm] d01b4008:0x0244 = 0xbcc71574 Jul 15 13:04:02 viking kernel: [drm] d01b400c:0x0248 = 0x3b9f445d Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4454:0x0840 = 0x3d9f677c Jul 15 13:04:02 viking kernel: [drm] d01b4458:0x0844 = 0xbc78d3d8 Jul 15 13:04:02 viking kernel: [drm] d01b445c:0x0848 = 0x3bc179a8 Jul 15 13:04:02 viking kernel: [drm] d01b4460:0x084c = 0xff10 Jul 15 13:04:02 viking kernel: [drm] d01b4464:0x0850 = 0xfee88000 Jul 15 13:04:02 viking kernel: [drm] d01b4468:0x0854 = 0xffcc Jul 15 13:04:02 viking kernel: [drm] d01b446c:0x0858 = 0x07a203ff Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4dc4:0x11b0 = 0x053d03df Jul 15 13:04:02 viking kernel: [drm] d01b4dc8:0x11b4 = 0x01c0 Jul 15 13:04:02 viking kernel: [drm] d01b4dcc:0x11b8 = 0xbb9a4b09 These values on the left side are absurd - the DMA buffer is busted. This means that either invalid data was generated or it was overwritten. I vote for the former (attending the new vertex template code may be buggy somewhere). [...] I think its just a coincident that it happend so soon after the server start, since I tested it a lot last night and nothing happened. Yes. It's most definetly an unrelated problem. [...] One more thing, I'm going home for at least four weeks on wednesday, so I won't be able to do any more testing then. And when I get back I will most probably upgrade to a Xpert 2000 Pro. So if there is any other patch you want me to test, there is not much time left. Ok, I'll contact you if make any advances here. hmm.. ATI Xpert 2000 Pro? That's an R128... I'm sad we won't be able to count with you anymore for the Mach64 development, but I hope you still keep your insterest on the DRI development. Thanks for all the help you've given, Felix! José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Mon, Jul 15, 2002 at 01:26:58PM +0200, Felix Kühling wrote: I tried restarting torcs after the last problem and it locked up the Xserver. I got something in the log before I rebooted: Jul 15 13:16:48 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] ring contents: Jul 15 13:16:48 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:48 viking kernel: Jul 15 13:16:48 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x ^^ Jul 15 13:16:48 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:48 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:48 viking kernel: [drm] ... Jul 15 13:16:48 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:48 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 The engine locked while looping around the ring, reading the first entry. My guess is that the engine was already busted somehow... Jul 15 13:16:48 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:48 viking kernel: [drm] [...] José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Fw: Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
Oops, forgot to copy this one to the list... Begin forwarded message: Date: Mon, 15 Jul 2002 15:09:17 +0200 From: Felix Kühling [EMAIL PROTECTED] To: José Fonseca [EMAIL PROTECTED] Subject: Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11 On Mon, 15 Jul 2002 12:56:33 +0100 José Fonseca [EMAIL PROTECTED] wrote: On Mon, Jul 15, 2002 at 01:16:37PM +0200, Felix Kühling wrote: [...] One more thing, I'm going home for at least four weeks on wednesday, so I won't be able to do any more testing then. And when I get back I will most probably upgrade to a Xpert 2000 Pro. So if there is any other patch you want me to test, there is not much time left. Ok, I'll contact you if make any advances here. hmm.. ATI Xpert 2000 Pro? That's an R128... I'm sad we won't be able to count with you anymore for the Mach64 development, but I hope you still keep your insterest on the DRI development. Thanks for all the help you've given, Felix! I will definitely keep my interest in DRI development. And I have to thank you and Leif. José Fonseca Bye, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sat, Jul 13, 2002 at 08:12:26PM -0400, Leif Delgass wrote:
On Sat, 13 Jul 2002, Leif Delgass wrote:
On Sun, 14 Jul 2002, José Fonseca wrote:
But the fact remains that the reads from GUI_STAT aren't reliable. I
wonder if the chip creats some transient values...
I wonder if always reading FIFO_STAT before GUI_STAT would make a
difference. The register reference says that the GUI_ACTIVE bit in
GUI_STAT would be set if the FIFO is not empty, but all the sample code I
recall looking at waits for idle by reading FIFO_STAT to make sure the
last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed
like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT.
I looked at the idle function in the DDX, and it only reads FIFO_STAT for
chips earlier than the VTB. It relies on the GUI_FIFO bits of GUI_STAT
for all Rage Pro chips and above, so it seems unlikely that reading
FIFO_STAT would make a difference.
Ok. Let's try the following then: call do_wait_for_idle when the engine
is given as idle on ring_tick. (This basically consists of checking
FIFO_STAT and then GUI_STAT again).
If the chip generates transient idles during operation then this
should catch it (or at least it should be really unlikely to miss it). If
the chip generates transient busys while in idle (which somehow seems more
unlikely) then the error will happen again.
Felix, please try the patch attached. I'm also gonna see if I can
reproduce it (by the look of its webpages, TORCS seems a nice way to
spend sometime ;-). I'll also redo the other extra safety check that
was failing before on my system to see if it goes away too.
José Fonseca
Index: mach64_drv.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_drv.h,v
retrieving revision 1.1.6.3.2.26.2.3
diff -u -r1.1.6.3.2.26.2.3 mach64_drv.h
--- mach64_drv.h10 Jul 2002 04:43:49 - 1.1.6.3.2.26.2.3
+++ mach64_drv.h14 Jul 2002 18:47:07 -
-523,6 +523,9
*/
int gui_active = MACH64_READ(MACH64_GUI_STAT) MACH64_GUI_ACTIVE;
+ if( !gui_active )
+ mach64_do_wait_for_idle( dev_priv );
+
ring-head_addr = MACH64_READ(MACH64_BM_GUI_TABLE) 0xfff0;
if ( gui_active ) {
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sun, 14 Jul 2002 19:59:08 +0100 José Fonseca [EMAIL PROTECTED] wrote: On Sat, Jul 13, 2002 at 08:12:26PM -0400, Leif Delgass wrote: On Sat, 13 Jul 2002, Leif Delgass wrote: On Sun, 14 Jul 2002, José Fonseca wrote: But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... I wonder if always reading FIFO_STAT before GUI_STAT would make a difference. The register reference says that the GUI_ACTIVE bit in GUI_STAT would be set if the FIFO is not empty, but all the sample code I recall looking at waits for idle by reading FIFO_STAT to make sure the last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT. I looked at the idle function in the DDX, and it only reads FIFO_STAT for chips earlier than the VTB. It relies on the GUI_FIFO bits of GUI_STAT for all Rage Pro chips and above, so it seems unlikely that reading FIFO_STAT would make a difference. Ok. Let's try the following then: call do_wait_for_idle when the engine is given as idle on ring_tick. (This basically consists of checking FIFO_STAT and then GUI_STAT again). If the chip generates transient idles during operation then this should catch it (or at least it should be really unlikely to miss it). If the chip generates transient busys while in idle (which somehow seems more unlikely) then the error will happen again. Felix, please try the patch attached. I'm also gonna see if I can Ok, I will apply it. But since the errors were very rare, it will take some time to be sure. Is there a way to make a patch that can print a log message when a transient idle is generated in a situation when it shoudn't and try to recover from it the way your patch does? Then if one sees such a message and the programme didn't crash one could be sure. reproduce it (by the look of its webpages, TORCS seems a nice way to spend sometime ;-). I'll also redo the other extra safety check that was failing before on my system to see if it goes away too. Yeah, it's a nice programme, but I get only between 8 and 13 fps at 640x480. José Fonseca Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sun, Jul 14, 2002 at 10:09:44PM +0200, Felix Kühling wrote: On Sun, 14 Jul 2002 19:59:08 +0100 José Fonseca [EMAIL PROTECTED] wrote: [...] Felix, please try the patch attached. I'm also gonna see if I can Ok, I will apply it. But since the errors were very rare, it will take some time to be sure. Is there a way to make a patch that can print a I know... Have no hurry! log message when a transient idle is generated in a situation when it shoudn't and try to recover from it the way your patch does? Then if one sees such a message and the programme didn't crash one could be sure. As is now, not really.. unless one polls the value a little waiting for a transient value, but it's not very pratical. Just leave the patch in your tree - if nothing happens after some weeks of regular use is enough. Anyway, I think I can reproduce the problem on my testbox by letting the UT demo running alone some hours, so I hope to have a more definite answer soon. reproduce it (by the look of its webpages, TORCS seems a nice way to spend sometime ;-). I'll also redo the other extra safety check that was failing before on my system to see if it goes away too. Yeah, it's a nice programme, but I get only between 8 and 13 fps at 640x480. Hey! I didn't made the chip! I just helped on the drivers! ;-) José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: Error flushing vertex buffer: return = -11
Hi, I tried another game: Torcs. Occasionally (about once in 1 or 2 hours) it crashes with Error flushing vertex buffer: return = -11. This is the corresponding kernel log: Jul 13 23:04:30 viking kernel: [drm:mach64_freelist_get] *ERROR* Empty ring with non-idle engine! Jul 13 23:04:30 viking kernel: [drm] Jul 13 23:04:30 viking kernel: [drm] ring contents: Jul 13 23:04:30 viking kernel: [drm] head_addr: 0x0051e310 head: 2244 tail: 2244 Jul 13 23:04:30 viking kernel: Jul 13 23:04:30 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd00a4000 0x4048 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd01f8000 0x4068 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0198000 0x4048 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd00c8000 0x4068 0x Jul 13 23:04:30 viking kernel: [drm] ... Jul 13 23:04:30 viking kernel: [drm] 0x0051e2e0: 0x007ffe48 0xd00cc000 0x40d0 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051e2f0: 0x007ffe48 0xd0004000 0x4048 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051e300: 0x007ffe48 0xd0018000 0xc068 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051e310: 0x007ffe48 0xd00cc000 0x4048 0x (head) (tail) Jul 13 23:04:30 viking kernel: [drm] 0x0051e320: 0x007ffe48 0xd01a4000 0x4068 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051e330: 0x007ffe48 0xd01ac000 0x4068 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051e340: 0x007ffe48 0xd008c000 0x4138 0x Jul 13 23:04:30 viking kernel: [drm] ... Jul 13 23:04:30 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00d 0x4068 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd006c000 0x4068 0x Jul 13 23:04:30 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd018 0x4068 0x Jul 13 23:04:30 viking kernel: [drm] Jul 13 23:04:30 viking kernel: [drm] buffer contents: Jul 13 23:04:30 viking kernel: [drm] d00cc000: 0x00060190 Jul 13 23:04:30 viking kernel: [drm] d00cc004:0x0240 = 0x3f89dd39 Jul 13 23:04:30 viking kernel: [drm] d00cc008:0x0244 = 0x Jul 13 23:04:30 viking kernel: [drm] d00cc00c:0x0248 = 0x3c0d6ea3 Jul 13 23:04:30 viking kernel: [drm] ... Jul 13 23:04:30 viking kernel: [drm] d00cc0c4:0x0298 = 0x012a0473 Jul 13 23:04:30 viking kernel: [drm] d00cc0c8: 0x01c0 Jul 13 23:04:30 viking kernel: [drm] d00cc0cc:0x0300 = 0x7f80 Jul 13 23:04:30 viking kernel: [drm] Jul 13 23:04:30 viking kernel: [drm] Jul 13 23:04:30 viking kernel: [drm]BM_GUI_TABLE = 0x0051e310 Jul 13 23:04:30 viking kernel: [drm] Jul 13 23:04:30 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 13 23:04:30 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051e310 Jul 13 23:04:30 viking kernel: [drm] BM_COMMAND = 0xc000 Jul 13 23:04:30 viking kernel: [drm] Jul 13 23:04:30 viking kernel: [drm] BM_STATUS = 0x8b0820ca Jul 13 23:04:30 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 13 23:04:30 viking kernel: [drm] FIFO_STAT = 0x Jul 13 23:04:30 viking kernel: [drm]GUI_STAT = 0x01800100 Jul 13 23:04:30 viking kernel: [drm]SRC_CNTL = 0x0f00 Jul 13 23:04:30 viking kernel: [drm:mach64_emit_state] *ERROR* mach64_emit_state: couldn't get buffer in DMAGETPTR I can restart torcs after that without problems. Maybe other programmes have the same problem but I didn't test them that thoroughly ;) Bye, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sat, Jul 13, 2002 at 11:24:44PM +0200, Felix Kühling wrote: Hi, I tried another game: Torcs. Occasionally (about once in 1 or 2 hours) it crashes with Error flushing vertex buffer: return = -11. This is the corresponding kernel log: Jul 13 23:04:30 viking kernel: [drm:mach64_freelist_get] *ERROR* Empty ring with non-idle engine! Here it says the engine was idle [...] Jul 13 23:04:30 viking kernel: [drm] 0x0051e310: 0x007ffe48 0xd00cc000 0x4048 0x (head) (tail) ... but the engine here seems to be idle... [...] Jul 13 23:04:30 viking kernel: [drm]GUI_STAT = 0x01800100 ^ ... and here is the confirmation! I don't know how this can be but I already had to override another safety check like this one because of the same problem. The reads are made using the kernel 'readl' macro, which deals with the compiler ordering, and the memory barriers. Since it's a read there isn't caching on the PCI bus. But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... [...] I can restart torcs after that without problems. Maybe other programmes have the same problem but I didn't test them that thoroughly ;) BTW, I'm also trying to figure out a problem reported by David Willmore is always reproducible on gltestperf, which seems to happens due to excess rate of tris/sec. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sun, 14 Jul 2002, José Fonseca wrote: But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... I wonder if always reading FIFO_STAT before GUI_STAT would make a difference. The register reference says that the GUI_ACTIVE bit in GUI_STAT would be set if the FIFO is not empty, but all the sample code I recall looking at waits for idle by reading FIFO_STAT to make sure the last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sat, 13 Jul 2002, Leif Delgass wrote: On Sun, 14 Jul 2002, José Fonseca wrote: But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... I wonder if always reading FIFO_STAT before GUI_STAT would make a difference. The register reference says that the GUI_ACTIVE bit in GUI_STAT would be set if the FIFO is not empty, but all the sample code I recall looking at waits for idle by reading FIFO_STAT to make sure the last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT. I looked at the idle function in the DDX, and it only reads FIFO_STAT for chips earlier than the VTB. It relies on the GUI_FIFO bits of GUI_STAT for all Rage Pro chips and above, so it seems unlikely that reading FIFO_STAT would make a difference. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
