From: Benjamin H. <be...@ke...> - 2006-01-25 23:43:28
|
Ok, so finally here is a new version of the patch. This time, it's against modular and it comes with a DRM patch. The X driver and the DRM patch should both work with the unpatched counterpart though you'll only get the full benefit of the fixes with both patches applied. As I had to shuffle a lot of code around in the X driver, there may still be bugs lurking around. Especially look for regressions around Xinerama and MergedFB as I haven't yet had a chance to test with those (especially Xinerama is doing a lot of very dodgy stuffs in the radeon driver). Please, try to test all sort of combinations of color tiling on/off, dri enabled/disabled, bit depth, hw/sw cursor etc... Patches are available at: Xorg driver patch: http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff DRM patch: http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff Please, report any problem, thanks, Ben. |
From: Roland S. <rsc...@hi...> - 2006-01-26 00:42:30
|
Benjamin Herrenschmidt wrote: > Ok, so finally here is a new version of the patch. This time, it's > against modular and it comes with a DRM patch. The X driver and the DRM > patch should both work with the unpatched counterpart though you'll only > get the full benefit of the fixes with both patches applied. > > As I had to shuffle a lot of code around in the X driver, there may > still be bugs lurking around. Especially look for regressions around > Xinerama and MergedFB as I haven't yet had a chance to test with those > (especially Xinerama is doing a lot of very dodgy stuffs in the radeon > driver). > > Please, try to test all sort of combinations of color tiling on/off, dri > enabled/disabled, bit depth, hw/sw cursor etc... Not tested yet, but I see you now no longer set the HDP_APER_CNTL which didn't work for me at all. However, does that mean some cards which map their memory as for instance 2x64MB have to live with 64MB because of that? Do you have any information why this setting doesn't work for some cards? Roland |
From: Benjamin H. <be...@ke...> - 2006-01-26 01:49:22
|
On Thu, 2006-01-26 at 01:42 +0100, Roland Scheidegger wrote: > Not tested yet, but I see you now no longer set the HDP_APER_CNTL which > didn't work for me at all. However, does that mean some cards which map > their memory as for instance 2x64MB have to live with 64MB because of > that? Do you have any information why this setting doesn't work for some > cards? Unless I screwed up, I keep the original code from Hui that sets it on some cards (r300 typically). My previous patch set it on all cards but that caused some cards (including an rv250 I have here) to completely stop responding on PCI accesses to the aperture :( Note also that I don't clear it neither ... Thus if the firmware sets it, it will work. I do read the bit to decide wether to expose half or not of memory in those cases. I'm still waiting for somebody from ATI to reply to my request asking for more infos about what's going on with that bit ... Ben |
From: Benjamin H. <be...@ke...> - 2006-01-26 01:50:45
|
On Thu, 2006-01-26 at 10:43 +1100, Benjamin Herrenschmidt wrote: > Ok, so finally here is a new version of the patch. This time, it's > against modular and it comes with a DRM patch. The X driver and the DRM > patch should both work with the unpatched counterpart though you'll only > get the full benefit of the fixes with both patches applied. > > As I had to shuffle a lot of code around in the X driver, there may > still be bugs lurking around. Especially look for regressions around > Xinerama and MergedFB as I haven't yet had a chance to test with those > (especially Xinerama is doing a lot of very dodgy stuffs in the radeon > driver). > > Please, try to test all sort of combinations of color tiling on/off, dri > enabled/disabled, bit depth, hw/sw cursor etc... BTW. If you get segfaults with the patch, please look into rebuilding your server with http://cvs.freedesktop.org/xorg/xserver/xorg/include/xorg-config.h.in?r1=1.12&r2=1.13 To enable backtrace support, it was broken in stock 7.0 Ben. |
From: Benjamin H. <be...@ke...> - 2006-01-26 07:30:35
|
> Xorg driver patch: > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff > > DRM patch: > http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff Ok, DRM patch is busted, it breaks an assumption done by the DRM that AGP is always appended to the framebuffer in card space which is no longer the case. I'll need to do a bit more fixing there. New patch soon hopefully. Ben. |
From: Benjamin H. <be...@ke...> - 2006-01-27 01:15:33
|
On Thu, 2006-01-26 at 10:43 +1100, Benjamin Herrenschmidt wrote: > Xorg driver patch: > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff > > DRM patch: > http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff The DRM patch had issues. Here's a new version that fixes them though it would be useful to test it with earlier userland DRI (for the DRM patch to have any effect, though, it must be run with a patches X driver as well). A reminder too: If you experience X segfaults with the patch, please try a server rebuilt with the fix for backtraces I mentioned in a previous email. AFAIK, Gentoo latest has it, other distros still have to catch up. Thanks ! http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff Ben. |
From: Michel <mi...@da...> - 2006-01-31 15:48:44
|
On Fri, 2006-01-27 at 12:15 +1100, Benjamin Herrenschmidt wrote: > On Thu, 2006-01-26 at 10:43 +1100, Benjamin Herrenschmidt wrote: >=20 > > Xorg driver patch: > > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff Just noticed something else: this seems to only read OV0_SCALE_CNTL but not write it back with RADEON_SCALER_ENABLE disabled. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Will D. <wil...@gm...> - 2006-02-02 00:04:05
|
On 1/26/06, Benjamin Herrenschmidt <be...@ke...> wrote: > On Thu, 2006-01-26 at 10:43 +1100, Benjamin Herrenschmidt wrote: > > > Xorg driver patch: > > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff > > > > DRM patch: > > http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff > > The DRM patch had issues. Here's a new version that fixes them though > it would be useful to test it with earlier userland DRI (for the DRM > patch to have any effect, though, it must be run with a patches X driver > as well). > > http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff I tested this patch on my amd64 debian box w/ x.org 6.9 (unpatched). No problems at all (as expected). I'll try to test the X driver patch soon, but I'm not sure exactly when I'll have time. -- Will Dyson |
From: Michel <mi...@da...> - 2006-01-27 11:52:35
|
Hi Ben, haven't got around to testing the patches, but they basically look good to me. Some comments: On Fri, 2006-01-27 at 12:15 +1100, Benjamin Herrenschmidt wrote: >=20 > > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff There should be no need to check for info->cursor_offset =3D=3D 0 in the cursor functions. Longer term, I think we should just reserve a static FB region for the cursor upfront instead of going through all these hoops with EXA. Also, unless I'm missing something, you're removing the code that forces the display priority to high for Radeon 7200. > http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff The way you handle backwards compatibility here is brilliant, thanks. The only minor issue I see is that the setparam ioctl can be called by unprivileged clients, but that applies to the existing colour tiling part as well, and it may not be a problem thanks to the offset fixups. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Michel <mi...@da...> - 2006-01-27 11:54:28
|
On Fri, 2006-01-27 at 12:52 +0100, Michel D=C3=A4nzer wrote: >=20 > On Fri, 2006-01-27 at 12:15 +1100, Benjamin Herrenschmidt wrote: > >=20 > > > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff >=20 > There should be no need to check for info->cursor_offset =3D=3D 0 in the > cursor functions. ... with current xserver/xorg CVS. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Benjamin H. <be...@ke...> - 2006-01-27 16:22:54
|
> There should be no need to check for info->cursor_offset == 0 in the > cursor functions. Longer term, I think we should just reserve a static > FB region for the cursor upfront instead of going through all these > hoops with EXA. I had some dodgy stuff happening at things like shutdown/entervt/leavevt, so I preferred being extra-safe there, though they might indeed not be necessary. > Also, unless I'm missing something, you're removing the code that forces > the display priority to high for Radeon 7200. Oops ? Where did I miss that ? (which bit of code specifically ? If it's the hack that was in SetFBLocation, it's now in the bandwidth calc) > > > http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff > > The way you handle backwards compatibility here is brilliant, thanks. > The only minor issue I see is that the setparam ioctl can be called by > unprivileged clients, but that applies to the existing colour tiling > part as well, and it may not be a problem thanks to the offset fixups. I'm not 100% sure yet of whta the clients may or may not do here, I'd be very happy if you could double check that part :) Ben. |
From: Michel <mi...@da...> - 2006-01-30 10:56:42
|
On Sat, 2006-01-28 at 03:22 +1100, Benjamin Herrenschmidt wrote: >=20 > > Also, unless I'm missing something, you're removing the code that force= s > > the display priority to high for Radeon 7200. >=20 > Oops ? Where did I miss that ? (which bit of code specifically ? If it's > the hack that was in SetFBLocation, it's now in the bandwidth calc) I mean /* old AIW Radeon has some BIOS initialization problem * with display buffer underflow, only occurs to DFP */ if (!info->HasCRTC2) OUTREG(RADEON_GRPH_BUFFER_CNTL, INREG(RADEON_GRPH_BUFFER_CNTL) & ~0x7f0000); from RADEONRestoreFPRegisters(). > > > http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff > >=20 > > The way you handle backwards compatibility here is brilliant, thanks. > > The only minor issue I see is that the setparam ioctl can be called by > > unprivileged clients, but that applies to the existing colour tiling > > part as well, and it may not be a problem thanks to the offset fixups. >=20 > I'm not 100% sure yet of whta the clients may or may not do here, I'd be > very happy if you could double check that part :) I can't think of any case that this patch wouldn't cover offhand. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Kevin S. <kms...@di...> - 2006-01-28 23:36:37
Attachments:
Xorg.0.log.vtswitch
Xorg.0.log.swcursor
|
On Thu, Jan 26, 2006 at 10:43:39AM +1100, Benjamin Herrenschmidt wrote: > Ok, so finally here is a new version of the patch. This time, it's > against modular and it comes with a DRM patch. The X driver and the DRM > patch should both work with the unpatched counterpart though you'll only > get the full benefit of the fixes with both patches applied. Hi Ben, Testing with Linux 2.6.15, Debian xorg 6.9 with your new patch applied (just edited the paths in the diff) and dri cvs with your patch. This is an x86 (Transmeta) laptop, with a Radeon Mobility M6 LY (PCI). As with your last patch, this fixes the startup problems I was having with the 6.8.2 -> 6.9 upgrade (http://bugs.debian.org/345729). However, with this version the server crashes when I switch to a VT and back again. Log with backtrace attached. Otherwise it works well, including DRI / 3D apps. > As I had to shuffle a lot of code around in the X driver, there may > still be bugs lurking around. Especially look for regressions around > Xinerama and MergedFB as I haven't yet had a chance to test with those > (especially Xinerama is doing a lot of very dodgy stuffs in the radeon > driver). I never used Xinerama or MergedFB, so I couldn't tell you about any regressions there. > Please, try to test all sort of combinations of color tiling on/off, dri > enabled/disabled, bit depth, hw/sw cursor etc... Okay; color tiling and dri on/off didn't show any obvious changes. For bit depth I used 16-bit only (required for DRI on 8MB chip). When I enabled sw cursor, the server crashed - a log for that is attached. I also tested on my desktop with Radeon 9800 Pro (R350), but no miracle improvements there. It still locks up after about 1 minute of glquake, but no problems if not using 3d apps. I'm using xorg 6.9 packages there but with libgl1-mesa-dri (6.3.2-2) instead of xlibmesa-dri. Regards, Kevin. |
From: Benjamin H. <be...@ke...> - 2006-01-29 05:04:59
|
On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote: > Testing with Linux 2.6.15, Debian xorg 6.9 with your new patch applied > (just edited the paths in the diff) and dri cvs with your patch. This > is an x86 (Transmeta) laptop, with a Radeon Mobility M6 LY (PCI). Thanks ! .../... > Okay; color tiling and dri on/off didn't show any obvious changes. For > bit depth I used 16-bit only (required for DRI on 8MB chip). When I > enabled sw cursor, the server crashed - a log for that is attached. Ok, I think I know what's wrong with that one. I'll try to make a new patch soon. I'm a bit distracted at the moment as we just had a baby :) > I also tested on my desktop with Radeon 9800 Pro (R350), but no > miracle improvements there. It still locks up after about 1 minute of > glquake, but no problems if not using 3d apps. I'm using xorg 6.9 > packages there but with libgl1-mesa-dri (6.3.2-2) instead of > xlibmesa-dri. With both the DRM and the server patch ? Ok, so it seems that my patch fix some lockups on some 9800's but not all of them... bummer. Ben. |
From: Kevin S. <kms...@di...> - 2006-01-29 23:11:43
|
On Sun, Jan 29, 2006 at 04:04:50PM +1100, Benjamin Herrenschmidt wrote: > On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote: > > Okay; color tiling and dri on/off didn't show any obvious changes. For > > bit depth I used 16-bit only (required for DRI on 8MB chip). When I > > enabled sw cursor, the server crashed - a log for that is attached. > > Ok, I think I know what's wrong with that one. I'll try to make a new > patch soon. I'm a bit distracted at the moment as we just had a baby :) Hey, congrats! I can understand. > > I also tested on my desktop with Radeon 9800 Pro (R350), but no > > miracle improvements there. It still locks up after about 1 minute of > > glquake, but no problems if not using 3d apps. I'm using xorg 6.9 > > packages there but with libgl1-mesa-dri (6.3.2-2) instead of > > xlibmesa-dri. > > With both the DRM and the server patch ? Ok, so it seems that my patch > fix some lockups on some 9800's but not all of them... bummer. Yes, I patched both. Maybe there were some lockups solved in Mesa 6.4, but I'll wait until Debian packages are available to test that. Cheers, Kevin. |
From: Kevin S. <kms...@di...> - 2006-02-01 20:38:57
|
On Mon, Jan 30, 2006 at 09:41:30AM +1030, Kevin Shanahan wrote: > On Sun, Jan 29, 2006 at 04:04:50PM +1100, Benjamin Herrenschmidt wrote: > > On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote: > > > I also tested on my desktop with Radeon 9800 Pro (R350), but no > > > miracle improvements there. It still locks up after about 1 minute of > > > glquake, but no problems if not using 3d apps. I'm using xorg 6.9 > > > packages there but with libgl1-mesa-dri (6.3.2-2) instead of > > > xlibmesa-dri. > > > > With both the DRM and the server patch ? Ok, so it seems that my patch > > fix some lockups on some 9800's but not all of them... bummer. > > Yes, I patched both. Maybe there were some lockups solved in Mesa 6.4, > but I'll wait until Debian packages are available to test that. Okay, I've now updated to Mesa 6.4.1 but unfortunately it still locks up. Possibly this is just a typical lockup, but I'll describe what I'm seeing: - Start GLQuake - I notice one warning is printed from libGL: *********************************WARN_ONCE********************************* File r300_render.c function r300_get_num_verts line 193 user error: 227 is not a valid number of vertices for primitive T ! *************************************************************************** - GLQuake runs perfectly for a minute or so - Then, all windows on the screen stop updating - Mouse cursor can still be moved around - The keyboard is not responsive at all - Networking still works, I can log in with ssh - GLQuake executable is still running, hogging the cpu - It appears to be stuck in glXSwapBuffers #0 0xb7db7cc4 in ioctl () from /lib/tls/libc.so.6 #1 0xb7cd5fb5 in drmCommandWriteRead () from /usr/lib/libdrm.so.2 #2 0xb6af5673 in radeonUnbindContext () from /usr/lib/dri/r300_dri.so #3 0xb6af58d4 in radeonUnbindContext () from /usr/lib/dri/r300_dri.so #4 0xb6af5a36 in radeonCopyBuffer () from /usr/lib/dri/r300_dri.so #5 0xb6af540b in radeonSwapBuffers () from /usr/lib/dri/r300_dri.so #6 0xb6af0baf in __driUtilUpdateDrawableInfo () from /usr/lib/dri/r300_dri.so #7 0xb7e6038e in glXSwapBuffers () from /usr/lib/libGL.so.1 #8 0x08097b53 in GL_EndRendering () at ../common/gl_vidlinuxglx.c:641 #9 0x08092e8a in SCR_UpdateScreen () at gl_screen.c:909 #10 0x0805583c in _Host_Frame (time=0.0147500001) at host.c:730 #11 0x080559a9 in Host_Frame (time=0.0147500001) at host.c:765 #12 0x080969a1 in main (c=8, v=0xbfdc0d24) at sys_linux.c:404 Detaching from program: /home/kmshanah/quake/tyr-glquake, process 17191 This is my video card: 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] (prog-if 00 [VGA]) Subsystem: Giga-byte Technology: Unknown device 4026 Flags: bus master, stepping, 66MHz, medium devsel, latency 32, IRQ 18 Memory at d8000000 (32-bit, prefetchable) [size=128M] I/O ports at a000 [size=256] Memory at e9000000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at e8000000 [disabled] [size=128K] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 Let me know if there's any other information I can provide which might help, but I suspect not. Anyway, I'll keep testing these patches as they come. Cheers, Kevin. |
From: Benjamin H. <be...@ke...> - 2006-02-01 23:00:54
|
On Thu, 2006-02-02 at 07:08 +1030, Kevin Shanahan wrote: > On Mon, Jan 30, 2006 at 09:41:30AM +1030, Kevin Shanahan wrote: > > On Sun, Jan 29, 2006 at 04:04:50PM +1100, Benjamin Herrenschmidt wrote: > > > On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote: > > > > I also tested on my desktop with Radeon 9800 Pro (R350), but no > > > > miracle improvements there. It still locks up after about 1 minute of > > > > glquake, but no problems if not using 3d apps. I'm using xorg 6.9 > > > > packages there but with libgl1-mesa-dri (6.3.2-2) instead of > > > > xlibmesa-dri. > > > > > > With both the DRM and the server patch ? Ok, so it seems that my patch > > > fix some lockups on some 9800's but not all of them... bummer. > > > > Yes, I patched both. Maybe there were some lockups solved in Mesa 6.4, > > but I'll wait until Debian packages are available to test that. > > Okay, I've now updated to Mesa 6.4.1 but unfortunately it still locks > up. Possibly this is just a typical lockup, but I'll describe what I'm > seeing: What happens if you try (serparately): - With the X patch but not the DRM patch - Modify RADEONInitMemoryMap() in radeon_driver.c (X driver) to change that line: mem_size = INREG(RADEON_CONFIG_MEMSIZE); to: mem_size = INREG(RADEON_CONFIG_MEMSIZE) / 2; And tell me if any of those makes a difference... Ben. |
From: Kevin S. <kms...@di...> - 2006-02-03 23:29:39
|
On Thu, Feb 02, 2006 at 10:01:12AM +1100, Benjamin Herrenschmidt wrote: > What happens if you try (serparately): > > - With the X patch but not the DRM patch Tried with 2.6.15.2 kernel drm and drm cvs - no change. > - Modify RADEONInitMemoryMap() in radeon_driver.c (X driver) to change > that line: > > mem_size = INREG(RADEON_CONFIG_MEMSIZE); > > to: > > mem_size = INREG(RADEON_CONFIG_MEMSIZE) / 2; On the first run, it did take a little longer to lock up (got well into the second demo), but after a reboot I tried again and it locked up just as quickly as usual. I tested this with your patched drm, which I think is what you intended. Cheers, Kevin. |
From: Michel <mi...@da...> - 2006-01-30 10:28:05
|
On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote: >=20 > As with your last patch, this fixes the startup problems I was having > with the 6.8.2 -> 6.9 upgrade > (http://bugs.debian.org/345729). However, with this version the server > crashes when I switch to a VT and back again. Log with backtrace > attached. FWIW, there's a good chance that this wouldn't happen with current xserver/xorg CVS. There's no question that the radeon cursor code could use a good cleanup though. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Benjamin H. <be...@ke...> - 2006-02-10 07:13:49
|
Here's a 3rd set of patches. Please report regressions ASAP as I intend to merge those in the various CVS trees real soon now. I fixed a couple of possible segfaults I found due to initialisation issues (places relying on pScrn->pScreen from within ScreenInit() and incorrect ordering of colormap vs. cursor inits for example). Also, I fixed a potential issue in the DRM with machines where AGP writeback doesn't work (we would still rely on AGP writeback for the ring read ptr instead of reading it from a register). Patches are at: Xorg driver patch: http://gate.crashing.org/~benh/radeon-memmap-7.0-3.diff DRM patch: http://gate.crashing.org/~benh/radeon-memmap-drm-4.diff Cheers, Ben. |
From: Kevin S. <kms...@di...> - 2006-02-10 22:34:56
|
On Fri, Feb 10, 2006 at 06:12:24PM +1100, Benjamin Herrenschmidt wrote: > Here's a 3rd set of patches. Please report regressions ASAP as I intend > to merge those in the various CVS trees real soon now. Thanks Ben, compiling now - I just thought I'd mention while I remember that there's a small problem with this (and previous) patch: radeon_cursor.c:35: error: syntax error before '/' token radeon_cursor.c:35: error: stray '#' in program radeon_cursor.c: In function 'RADEONCursorAllocEXA': radeon_cursor.c:138: warning: too many arguments for format radeon_cursor.c: In function 'RADEONUseHWCursorARGB': radeon_cursor.c:361: warning: unused variable 'info' Looks to be cause by the C++ style // comment. $ gcc --version gcc (GCC) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8) Not sure if the fact I'm using 6.9 has any bearing on that. Anyway, I'll report back with the testing results shortly. Cheers, Kevin. |
From: Benjamin H. <be...@ke...> - 2006-02-10 22:39:01
|
On Sat, 2006-02-11 at 09:04 +1030, Kevin Shanahan wrote: > On Fri, Feb 10, 2006 at 06:12:24PM +1100, Benjamin Herrenschmidt wrote: > > Here's a 3rd set of patches. Please report regressions ASAP as I intend > > to merge those in the various CVS trees real soon now. > > Thanks Ben, compiling now - I just thought I'd mention while I > remember that there's a small problem with this (and previous) patch: > > radeon_cursor.c:35: error: syntax error before '/' token > radeon_cursor.c:35: error: stray '#' in program > radeon_cursor.c: In function 'RADEONCursorAllocEXA': > radeon_cursor.c:138: warning: too many arguments for format > radeon_cursor.c: In function 'RADEONUseHWCursorARGB': > radeon_cursor.c:361: warning: unused variable 'info' > > Looks to be cause by the C++ style // comment. Will have a look, thanks. Ben. |
From: Kevin S. <kms...@di...> - 2006-02-11 01:30:47
|
On Sat, Feb 11, 2006 at 09:04:43AM +1030, Kevin Shanahan wrote: > On Fri, Feb 10, 2006 at 06:12:24PM +1100, Benjamin Herrenschmidt wrote: > > Here's a 3rd set of patches. Please report regressions ASAP as I intend > > to merge those in the various CVS trees real soon now. ... > Anyway, I'll report back with the testing results shortly. All seems good. No regressions on my Radeon Mobility M6 LY and Radeon 64MB DDR (7200). VT switch problems from #2 now fixed. Radeon 9800 Pro still locks up with 3D, but that's not a regression. > Cheers, > Kevin. |
From: Tilman S. <ti...@co...> - 2006-02-12 12:39:32
|
Benjamin Herrenschmidt [2006-02-10 18:12]: > Here's a 3rd set of patches. Please report regressions ASAP as I intend > to merge those in the various CVS trees real soon now. >=20 > [...] > =20 > Also, I fixed a potential issue in the DRM with machines where AGP > writeback doesn't work (we would still rely on AGP writeback for the > ring read ptr instead of reading it from a register). I believe these 2 patches introduce a hardware lockup problem in 3D mode for me. It's not reliably reproduced though, so I'm not sure whether this is a regression wrt to patch set #2 or a another problem. However, I never had that problem with the second patch set. The symptom is that my LCD turns off ("no signal") and the machine locks up. I don't know enough about the DRM code to say whether it's even possible that the diff between drm-3.diff and drm-4.diff could introduce such problems. The AGP writeback stuff seems to work just fine on my machine. dmesg says: [drm] writeback test succeeded, tmp=3D1. The graphics card is a ATI Technologies Inc R420 JI [Radeon X800PRO] / X800 GTO. Regards, Tilman --=20 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? |
From: Tilman S. <ti...@co...> - 2006-02-12 18:25:45
|
Tilman Sauerbeck [2006-02-12 13:39]: > Benjamin Herrenschmidt [2006-02-10 18:12]: > > Here's a 3rd set of patches. Please report regressions ASAP as I intend > > to merge those in the various CVS trees real soon now. > >=20 > > [...] > > =20 > > Also, I fixed a potential issue in the DRM with machines where AGP > > writeback doesn't work (we would still rely on AGP writeback for the > > ring read ptr instead of reading it from a register). >=20 > I believe these 2 patches introduce a hardware lockup problem in 3D > mode for me. It's not reliably reproduced though, so I'm not sure n/m, I just reproduced it with patch set #2, so it's not a regression. Regards, Tilman --=20 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? |