From: Vladimir D. <vo...@mi...> - 2005-02-19 01:07:18
|
I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. best Vladimir Dergachev |
From: Vladimir D. <vo...@mi...> - 2005-02-19 01:10:14
|
On Fri, 18 Feb 2005, Vladimir Dergachev wrote: > > I think I found the cause of lockups in VB mode - they were due to cursor > updating function in radeon_mergedfb.c calling OUTREGP() which in turn called > INREG. Forgot to add: 1. the fix is in X.org CVS, if you are running R300 + merged fb I recommend to update the driver 2. VB mode also needs the fix from Nicolai Haehnle that was committed to R300 CVS earlier. I tested with glxgears and quake3a - no lockups so far, even on crossing window boundaries. best Vladimir Dergachev |
From: Adam K K. <ad...@vo...> - 2005-02-19 02:06:11
|
Vladimir Dergachev wrote: > > > On Fri, 18 Feb 2005, Vladimir Dergachev wrote: > >> >> I think I found the cause of lockups in VB mode - they were due to >> cursor updating function in radeon_mergedfb.c calling OUTREGP() which >> in turn called INREG. > > > Forgot to add: > > 1. the fix is in X.org CVS, if you are running R300 + merged fb I > recommend to update the driver > > 2. VB mode also needs the fix from Nicolai Haehnle that was > committed > to R300 CVS earlier. > > I tested with glxgears and quake3a - no lockups so far, even on > crossing window boundaries. > > best > > Vladimir Dergachev Well that would definitely explain my lockups... I'll give it a shot later this weekend. Adam |
From: Alex D. <ale...@gm...> - 2005-02-19 08:57:19
|
On Fri, 18 Feb 2005 20:06:53 -0500 (EST), Vladimir Dergachev <vo...@mi...> wrote: > > I think I found the cause of lockups in VB mode - they were due to cursor > updating function in radeon_mergedfb.c calling OUTREGP() which in turn > called INREG. > > When silken mouse is enabled this function could be called at any time > which would do *bad* things when CP engine is active. > > The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. > > I have *no* idea why this worked with immediate mode at all and why no > issues were reported by R200 and Radeon users (well, I only looked through > the mailing lists, perhaps there is something on bugzilla but I don't know > how to use that efficiently) I've never had any reports of this kind that I can think of for radeon or r200. > > Also, I have no idea why the code in radeon_cursor.c that writes images > directly into framebuffer memory works - according to the manual any > writes into framebuffer while GUI is active should cause a hard lock. > > However, I could not produce any lockups with it, and so left it as is. > Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Alex |
From: Philipp K. K. <pk...@sp...> - 2005-02-19 10:23:57
|
Vladimir Dergachev schrieb: > > I think I found the cause of lockups in VB mode - they were due to > cursor updating function in radeon_mergedfb.c calling OUTREGP() which in > turn called INREG. > > When silken mouse is enabled this function could be called at any time > which would do *bad* things when CP engine is active. > > The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. > > I have *no* idea why this worked with immediate mode at all and why no > issues were reported by R200 and Radeon users (well, I only looked > through the mailing lists, perhaps there is something on bugzilla but I > don't know how to use that efficiently) Well my rv250 lockups occour only during mouse movement in fullscreen applications. But for month ago there were no lockups. The situation was slowly getting worse since. With current DRM and Mesa driver I get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. Philipp |
From: Vladimir D. <vo...@mi...> - 2005-02-19 14:58:21
|
>> >> The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. >> >> I have *no* idea why this worked with immediate mode at all and why no >> issues were reported by R200 and Radeon users (well, I only looked through >> the mailing lists, perhaps there is something on bugzilla but I don't know >> how to use that efficiently) > > Well my rv250 lockups occour only during mouse movement in fullscreen > applications. But for month ago there were no lockups. The situation > was slowly getting worse since. With current DRM and Mesa driver I > get an immediate lockup in gl-117 when moving the mouse. If I use > current DRM with an older Mesa it locks up after about a minute of mouse > movement. Interesting :) Could you try this with latest X.org source ? Also, what is gl-117 ? thank you Vladimir Dergachev > > Philipp > |
From: Philipp K. K. <pk...@sp...> - 2005-02-19 15:12:08
|
Vladimir Dergachev schrieb: > > Interesting :) Could you try this with latest X.org source ? Sorry, but I probably won't find much time. I'll be away from the rv250 during the next week. Next month I'll have to write some exams, while at the beginning of april there are oral exams. I hope to find more time for DRI testing at the beginning of the next term. > > Also, what is gl-117 ? It's a free flight simulator, included in Debian. Philipp |
From: Benjamin H. <be...@ke...> - 2005-02-20 01:00:28
|
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote: > Vladimir Dergachev schrieb: > > > > I think I found the cause of lockups in VB mode - they were due to > > cursor updating function in radeon_mergedfb.c calling OUTREGP() which in > > turn called INREG. > > > > When silken mouse is enabled this function could be called at any time > > which would do *bad* things when CP engine is active. > > > > The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. > > > > I have *no* idea why this worked with immediate mode at all and why no > > issues were reported by R200 and Radeon users (well, I only looked > > through the mailing lists, perhaps there is something on bugzilla but I > > don't know how to use that efficiently) > > Well my rv250 lockups occour only during mouse movement in fullscreen > applications. But for month ago there were no lockups. The situation > was slowly getting worse since. With current DRM and Mesa driver I > get an immediate lockup in gl-117 when moving the mouse. If I use > current DRM with an older Mesa it locks up after about a minute of mouse > movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). I can kill X tho, that works, so the chip/bus isn't totally dead (or it recovers with an engine reset). Ben. |
From: Philip A. <phi...@ka...> - 2005-02-20 14:19:56
|
On Sun, Feb 20, 2005 at 12:00:10PM +1100, Benjamin Herrenschmidt wrote: > On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote: > > Well my rv250 lockups occour only during mouse movement in fullscreen > > applications. But for month ago there were no lockups. The situation > > was slowly getting worse since. With current DRM and Mesa driver I > > get an immediate lockup in gl-117 when moving the mouse. If I use > > current DRM with an older Mesa it locks up after about a minute of mouse > > movement. > > rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel > (well, actually, all of the above are about 5 days old, doesn't have > Vladimir latest fixes), I get very jerky display with g117 and broken > textures, ultimately it locks up after moving the mouse a little bit (at > the meny screen). > > I can kill X tho, that works, so the chip/bus isn't totally dead (or it > recovers with an engine reset). Fwiw, gl-117 locks up almost immediately (goes fullscreen, puts "Please wait" {or something like that} up, then hangs) for me on my rv280 (Radeon 9200SE). This is with the nixnuts Debian dri packages, so dri CVS from 2005-02-08 or so. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt |
From: Philip A. <ph...@ka...> - 2005-02-20 14:07:33
|
On Sun, Feb 20, 2005 at 12:00:10PM +1100, Benjamin Herrenschmidt wrote: > On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote: > > Well my rv250 lockups occour only during mouse movement in fullscreen > > applications. But for month ago there were no lockups. The situation > > was slowly getting worse since. With current DRM and Mesa driver I > > get an immediate lockup in gl-117 when moving the mouse. If I use > > current DRM with an older Mesa it locks up after about a minute of mouse > > movement. > > rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel > (well, actually, all of the above are about 5 days old, doesn't have > Vladimir latest fixes), I get very jerky display with g117 and broken > textures, ultimately it locks up after moving the mouse a little bit (at > the meny screen). > > I can kill X tho, that works, so the chip/bus isn't totally dead (or it > recovers with an engine reset). Fwiw, gl-117 locks up almost immediately (goes fullscreen, puts "Please wait" {or something like that} up, then hangs) for me on my rv280 (Radeon 9200SE). This is with the nixnuts Debian dri packages, so dri CVS from 2005-02-08 or so. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt |
From: Vladimir D. <vo...@mi...> - 2005-02-19 14:57:01
|
>> >> Also, I have no idea why the code in radeon_cursor.c that writes images >> directly into framebuffer memory works - according to the manual any >> writes into framebuffer while GUI is active should cause a hard lock. >> >> However, I could not produce any lockups with it, and so left it as is. >> > > Does using the overlay also cause a lockup? there are some non-idled > INREGs in there as well. I've never had a problem with them on r100 > or r200 though. Not anymore, I think I fixed all of those when importing GATOS code a while back. best Vladimir Dergachev > > Alex > |
From: Alex D. <ale...@gm...> - 2005-02-19 15:48:42
|
On Sat, 19 Feb 2005 09:56:33 -0500 (EST), Vladimir Dergachev <vo...@mi...> wrote: > >> > >> Also, I have no idea why the code in radeon_cursor.c that writes images > >> directly into framebuffer memory works - according to the manual any > >> writes into framebuffer while GUI is active should cause a hard lock. > >> > >> However, I could not produce any lockups with it, and so left it as is. > >> > > > > Does using the overlay also cause a lockup? there are some non-idled > > INREGs in there as well. I've never had a problem with them on r100 > > or r200 though. > > Not anymore, I think I fixed all of those when importing GATOS code a > while back. there's still one is the overlay gamma setup function, and I think another one further down. I can add the idle calls at some point this weekend unless someone beats me to it. Alex > > best > > Vladimir Dergachev > > > > > Alex > > > |
From: Vladimir D. <vo...@mi...> - 2005-02-19 16:06:03
|
On Sat, 19 Feb 2005, Alex Deucher wrote: > On Sat, 19 Feb 2005 09:56:33 -0500 (EST), Vladimir Dergachev > <vo...@mi...> wrote: >>>> >>>> Also, I have no idea why the code in radeon_cursor.c that writes images >>>> directly into framebuffer memory works - according to the manual any >>>> writes into framebuffer while GUI is active should cause a hard lock. >>>> >>>> However, I could not produce any lockups with it, and so left it as is. >>>> >>> >>> Does using the overlay also cause a lockup? there are some non-idled >>> INREGs in there as well. I've never had a problem with them on r100 >>> or r200 though. >> >> Not anymore, I think I fixed all of those when importing GATOS code a >> while back. > > there's still one is the overlay gamma setup function, and I think > another one further down. I can add the idle calls at some point this > weekend unless someone beats me to it. Ohh I see - these are triggerred only by changing Xv attributes and I don't think many people do this simultaneously with running 3d. I fixed it, no problem. best Vladimir Dergachev |
From: Nicolai H. <pre...@gm...> - 2005-02-20 02:29:55
|
On Saturday 19 February 2005 02:06, Vladimir Dergachev wrote: > I think I found the cause of lockups in VB mode - they were due to cursor= =20 > updating function in radeon_mergedfb.c calling OUTREGP() which in turn=20 > called INREG. >=20 > When silken mouse is enabled this function could be called at any time=20 > which would do *bad* things when CP engine is active. >=20 > The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. >=20 > I have *no* idea why this worked with immediate mode at all and why no=20 > issues were reported by R200 and Radeon users (well, I only looked throug= h=20 > the mailing lists, perhaps there is something on bugzilla but I don't kno= w=20 > how to use that efficiently) >=20 > Also, I have no idea why the code in radeon_cursor.c that writes images=20 > directly into framebuffer memory works - according to the manual any=20 > writes into framebuffer while GUI is active should cause a hard lock. >=20 > However, I could not produce any lockups with it, and so left it as is. I can see no difference at all with this latest change, i.e. no regressions= ,=20 but the lockup is still there. cu, Nicolai > best >=20 > Vladimir Dergachev |
From: Vladimir D. <vo...@mi...> - 2005-02-20 04:23:00
|
>> Also, I have no idea why the code in radeon_cursor.c that writes images >> directly into framebuffer memory works - according to the manual any >> writes into framebuffer while GUI is active should cause a hard lock. >> >> However, I could not produce any lockups with it, and so left it as is. > > I can see no difference at all with this latest change, i.e. no regressions, > but the lockup is still there. I think we can safely assume that there is more than one issue. For example, I am often seeing about 2-sec delay upon the start of a GL app (all 2d updates are frozen). The delay always happens upon the first GL context after a cold reboot, and it is often not present on successive launches of GL apps. I just tried to check for "partly covered window lockup" bug - glxgears appears to be entirely indifferent to whether anything is covering it. As for gl-117 - I just tried it and it segfaults due to undefined functions to handle vertex buffers. best Vladimir Dergachev |
From: Vladimir D. <vo...@mi...> - 2005-02-20 04:25:36
|
>> get an immediate lockup in gl-117 when moving the mouse. If I use >> current DRM with an older Mesa it locks up after about a minute of mouse >> movement. > > rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel > (well, actually, all of the above are about 5 days old, doesn't have > Vladimir latest fixes), I get very jerky display with g117 and broken > textures, ultimately it locks up after moving the mouse a little bit (at > the meny screen). Is it a hard lockup ? With R300 it segfaults when I move a mouse due to vertex arrays code not written yet, however it is strange this happens only after a mouse movement. It could be that it tramples over some Mesa driver memory (or there is a bug in Mesa driver/library). best Vladimir Dergachev > > I can kill X tho, that works, so the chip/bus isn't totally dead (or it > recovers with an engine reset). > > Ben. > > |
From: Vladimir D. <vo...@mi...> - 2005-02-20 04:31:01
|
On Sat, 19 Feb 2005, Vladimir Dergachev wrote: >>> get an immediate lockup in gl-117 when moving the mouse. If I use >>> current DRM with an older Mesa it locks up after about a minute of mouse >>> movement. >> >> rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel >> (well, actually, all of the above are about 5 days old, doesn't have >> Vladimir latest fixes), I get very jerky display with g117 and broken >> textures, ultimately it locks up after moving the mouse a little bit (at >> the meny screen). > > Is it a hard lockup ? With R300 it segfaults when I move a mouse due to > vertex arrays code not written yet, however it is strange this happens only > after a mouse movement. One more thing: go to ~/.gl-117 and edit the file "conf" to turn off full screen mode. Reduce the resolution to something small (like 640x480). Now you would be able to run it under debugger and see where it segfaults. I am curious to see where the problem is in rv250 driver. best Vladimir Dergachev |
From: Benjamin H. <be...@ke...> - 2005-02-20 05:26:58
|
On Sat, 2005-02-19 at 23:25 -0500, Vladimir Dergachev wrote: > >> get an immediate lockup in gl-117 when moving the mouse. If I use > >> current DRM with an older Mesa it locks up after about a minute of mouse > >> movement. > > > > rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel > > (well, actually, all of the above are about 5 days old, doesn't have > > Vladimir latest fixes), I get very jerky display with g117 and broken > > textures, ultimately it locks up after moving the mouse a little bit (at > > the meny screen). > > Is it a hard lockup ? With R300 it segfaults when I move a mouse due to > vertex arrays code not written yet, however it is strange this happens > only after a mouse movement. > > It could be that it tramples over some Mesa driver memory (or there is a > bug in Mesa driver/library). Well, difficult to say, I didn't manage to get back to X, but I managed to kill X and radeonfb managed to restore the display, at which point I could re-launch X... > best > > Vladimir Dergachev > > > > > I can kill X tho, that works, so the chip/bus isn't totally dead (or it > > recovers with an engine reset). > > > > Ben. > > > > -- Benjamin Herrenschmidt <be...@ke...> |
From: Eric A. <et...@lc...> - 2005-02-20 04:29:04
|
On Sat, 2005-02-19 at 23:22 -0500, Vladimir Dergachev wrote: [...] > For example, I am often seeing about 2-sec delay upon the start of a GL > app (all 2d updates are frozen). The delay always happens upon the first > GL context after a cold reboot, and it is often not present on successive > launches of GL apps. I see this on my R200 on amd64, as well. -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |
From: Vladimir D. <vo...@mi...> - 2005-02-20 04:32:53
|
On Sat, 19 Feb 2005, Eric Anholt wrote: > On Sat, 2005-02-19 at 23:22 -0500, Vladimir Dergachev wrote: > [...] >> For example, I am often seeing about 2-sec delay upon the start of a GL >> app (all 2d updates are frozen). The delay always happens upon the first >> GL context after a cold reboot, and it is often not present on successive >> launches of GL apps. > > I see this on my R200 on amd64, as well. Really ? Do you have DynamicClocks on ? Do you have ACPI in the kernel ? I have no idea what could have caused such a delay, as microcode has long been loaded by then. best Vladimir Dergachev > > -- > Eric Anholt et...@lc... > http://people.freebsd.org/~anholt/ anholt@FreeBSD.org > |
From: Roland M. <rol...@nr...> - 2005-02-21 00:36:26
|
Vladimir Dergachev wrote: [snip] > Interesting :) Could you try this with latest X.org source ? > > Also, what is gl-117 ? OpenGL flight simulator. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) |