Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-14 10:06]: Can you try all combinations of my old patch, new patch, X patch !X patch and let me know what the results are ? If it's perfectly stable with your latest patch and without that one bad Mesa patch, would that convince you it's not a bug in DRM/DDX? :) Well, I'm navigating between lots of conflicting reports so yes, any solid data like that would be very useful. Also, is it stable if not using 3d ? Yes, it is. FYI, this is with an ATI R420 JI [Radeon X800PRO] (that's what lspci says, I think the box says it's an x800 GTO). Regards, Tilman -- 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? pgpAq983QxHJV.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-13 09:20]: On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote: 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. [...] 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 n/m, I just reproduced it with patch set #2, so it's not a regression. What if you only apply the X patch and not the DRM patch ? Current DRM CVS HEAD doesn't work for me. However it does work with a small patch applied: https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 Does it make sense to test that DRM code with the new X patch? Regards, Tilman -- 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? pgpaVumFHj6yo.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Kevin Shanahan wrote: 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. I just had some trouble with VT switching -- when switching back to X, I lost my cursor and a small black minify box appeared near the lower right of my screen (perhaps where the cursor was when I switched VTs?). Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [PATCH] new radeon memory map fixes (#3)
Hi Donnie! Monday 13, at 11:53:35 AM you wrote: Kevin Shanahan wrote: 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. I just had some trouble with VT switching -- when switching back to X, I lost my cursor and a small black minify box appeared near the lower right of my screen (perhaps where the cursor was when I switched VTs?). In my case, this patch fix black box issue: after suspend/resume I see message Hardware cursor temporarily disabled due to insufficient offscreen memory and black (or white) box in a place of cursor. But before patch black box doesn't disappear until I restart X server, and after patch I see only warning message but cursor stay normal. PS I'm using 128 DDR 9200PRO board and DRM/Mesa from last saturday. -- WBR, Konstantin chat with ==ICQ: 109916175 Lepikhov,speak to ==JID: [EMAIL PROTECTED] aka L.A. Kostis write to ==mailto:[EMAIL PROTECTED] ...The information is like the bank...(c) EC8OR --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-13 09:20]: On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote: 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. [...] 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 n/m, I just reproduced it with patch set #2, so it's not a regression. What if you only apply the X patch and not the DRM patch ? It's possible that the crash that I'm seeing was introduced by a change to the r300 DRI driver, so it's not DRMs fault necessarily. Regards, Tilman -- 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? pgpPonvV6Wj8t.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Current DRM CVS HEAD doesn't work for me. However it does work with a small patch applied: https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 Does it make sense to test that DRM code with the new X patch? You mean the DRM without my old patch doesn't work ? What was the symptom ? lockups ? So it worked in the short period of time when my old patch was in and broke when it was backed off right ? That's interesting... In that case I would have expected my new patch to work but you say you still have lockups. Can you try all combinations of my old patch, new patch, X patch !X patch and let me know what the results are ? Thanks, Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
On Mon, 2006-02-13 at 11:53 -0800, Donnie Berkholz wrote: Kevin Shanahan wrote: 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. I just had some trouble with VT switching -- when switching back to X, I lost my cursor and a small black minify box appeared near the lower right of my screen (perhaps where the cursor was when I switched VTs?). XAA or EXA ? Is this reproduceable ? Will the cursor go back to normal when changed again by a program ? Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-14 09:37]: Current DRM CVS HEAD doesn't work for me. However it does work with a small patch applied: https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 Does it make sense to test that DRM code with the new X patch? You mean the DRM without my old patch doesn't work ? What was the symptom ? lockups ? So it worked in the short period of time when my old patch was in and broke when it was backed off right ? If revision 1.71 of radeon_cp.c was the only change that was backed off, then yes, in worked with your old patch. When the single radeon_cp.c change was backed off, my screen got garbled on X startup and the machine locked up hard. That's interesting... In that case I would have expected my new patch to work but you say you still have lockups. As I said in my other mail, it's quite likely that the lock up was introduced by bad Mesa code. Can you try all combinations of my old patch, new patch, X patch !X patch and let me know what the results are ? If it's perfectly stable with your latest patch and without that one bad Mesa patch, would that convince you it's not a bug in DRM/DDX? :) Regards, Tilman -- 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? pgppYIKlwVPwa.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Can you try all combinations of my old patch, new patch, X patch !X patch and let me know what the results are ? If it's perfectly stable with your latest patch and without that one bad Mesa patch, would that convince you it's not a bug in DRM/DDX? :) Well, I'm navigating between lots of conflicting reports so yes, any solid data like that would be very useful. Also, is it stable if not using 3d ? Thanks, Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
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. [...] 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=1. The graphics card is a ATI Technologies Inc R420 JI [Radeon X800PRO] / X800 GTO. Regards, Tilman -- 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? pgpaXI55DXFo2.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
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. [...] 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 n/m, I just reproduced it with patch set #2, so it's not a regression. Regards, Tilman -- 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? pgpkVuHLhIJXr.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Tilman Sauerbeck wrote: 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. [...] 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 n/m, I just reproduced it with patch set #2, so it's not a regression. I've been having the same problem since at least #2, but haven't had a lockup yet with #3. Donnie signature.asc Description: OpenPGP digital signature
Re: [PATCH] new radeon memory map fixes (#3)
On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote: 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. [...] 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 n/m, I just reproduced it with patch set #2, so it's not a regression. What if you only apply the X patch and not the DRM patch ? Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] new radeon memory map fixes (#3)
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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.014751) at host.c:730 #11 0x080559a9 in Host_Frame (time=0.014751) 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: :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 d800 (32-bit, prefetchable) [size=128M] I/O ports at a000 [size=256] Memory at e900 (32-bit, non-prefetchable) [size=64K] Expansion ROM at e800 [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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On 1/26/06, Benjamin Herrenschmidt [EMAIL PROTECTED] 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 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On Fri, 2006-01-27 at 12:15 +1100, Benjamin Herrenschmidt 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 Just noticed something else: this seems to only read OV0_SCALE_CNTL but not write it back with RADEON_SCALER_ENABLE disabled. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote: 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. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On Sat, 2006-01-28 at 03:22 +1100, Benjamin Herrenschmidt wrote: 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) 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) ~0x7f); from RADEONRestoreFPRegisters(). 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 :) I can't think of any case that this patch wouldn't cover offhand. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On Fri, 2006-01-27 at 12:52 +0100, Michel Dänzer wrote: On Fri, 2006-01-27 at 12:15 +1100, Benjamin Herrenschmidt wrote: http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff There should be no need to check for info-cursor_offset == 0 in the cursor functions. ... with current xserver/xorg CVS. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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: http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff 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. 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. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] new radeon memory map fixes
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. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
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 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (if you segfault)
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.12r2=1.13 To enable backtrace support, it was broken in stock 7.0 Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
