[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #9 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:16:28 --- Hi, Michel. On Fri, May 20, 2011 at 12:11, bugzilla-dae...@bugzilla.kernel.org wrote: --- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-05-20 12:11:38 --- (In reply to comment #1) Anyway, things are *way* better with 2.6.38 than with 2.6.39, as with 2.6.39 the kernel doesn't even get the colors correctly---everything that should be red becomes blue and so forth (any kind of endianness problem?). That's probably nothing to do with the kernel directly but endianness bugs in the X driver when acceleration is not available. OK, then that's a separate issue. Good to know. It would be interesting if you could bisect what broke acceleration with radeon.agpmode=-1. Oooh, I guess that I made some mess in your head here, taking into account the other messages of us. To clear things up: When I use 2.6.38, it works mostly OK if I use radeon.agpmode=-1. It is sufficiently stable to the point that I told you that this setting was OK. But, in fact, if I play a video with mplayer, then it always (so far, 100% reproducible) causes those GPU lockups, but the computer is still accessible via the network, so that I can take the logs etc. If, instead, I use 1 instead of -1, then, even with kernel 2.6.38, I get those lysergide-like :-) pictures that I put on my homepage (but, for documentation purposes, I am thinking of uploading here as attachments, as I am quite short of space there). With kernel 2.6.39, I have not been able to get anything working, whether or not I pass any option to the kernel. Summary: * 2.6.38 with KMS and agpmode=-1: OK, up to me trying to play some video, then GPU lockups. * 2.6.38 with KMS and agpmode=1: GPU lockups a few seconds after X loads (it *does* show up, but locks up a few seconds latter). * 2.6.39 with KMS and agpmode=-1: Not OK, even if I don't use anything accelerated (problems with colors and software rendering). So, I am not quite sure if it would be the case of bisecting or, at least, what would be a good starting point. I can, though, try to boot with many other kernels to see if I can (provided that udev doesn't stop me). Note that you should boot with radeon.no_wb=1 as well for OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. this, as CP writeback was only fixed during the 2.6.39 cycle (in commit dc66b325f161bb651493c7d96ad44876b629cf6a). Right. Thanks for that fix of yours (just read the commit). Regards, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #10 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:23:27 --- Hi there. On Sat, May 21, 2011 at 09:16, bugzilla-dae...@bugzilla.kernel.org wrote: OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still locks up the GPU when I play a video with mplayer. I will try with 2.6.39 with the same settings. Thanks, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #11 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:34:20 --- Another test. On Sat, May 21, 2011 at 09:23, bugzilla-dae...@bugzilla.kernel.org wrote: On Sat, May 21, 2011 at 09:16, bugzilla-dae...@bugzilla.kernel.org wrote: OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still locks up the GPU when I play a video with mplayer. Just for the record #2, 2.6.38 with KMS + agpmode=-1 + no_wb=1 + dynclks=1 still locks up the GPU when I play a video with mplayer. Besides that, like Andreas, with dynclks=1 the resolution is reduced to be 800x600. I didn't have the opportunity to read the X logs regarding the S-Video port, but, at least for the user, iBooks (differently from PowerBooks) don't have user-accessible S-Video ports (but this doesn't prevent Apple from having inutilized them somehow). Thanks, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #12 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:42:12 --- On Sat, May 21, 2011 at 09:34, bugzilla-dae...@bugzilla.kernel.org wrote: On Sat, May 21, 2011 at 09:23, bugzilla-dae...@bugzilla.kernel.org wrote: On Sat, May 21, 2011 at 09:16, bugzilla-dae...@bugzilla.kernel.org wrote: OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still locks up the GPU when I play a video with mplayer. Wooow! Oopsen galore with 2.6.39 with KMS + agpmode=-1 + no_wb=1... Five in a row. OK, probably only the first one matters. Then, it stays there and doesn't load the system... Actually, as I am writing this thing, after about 180 seconds, the boot process is continuing and X is being loaded, but with the wrong colors (the endianness issue). I will try to see if the network is available and attach here what I get from dmesg. BTW, I hope that you don't mind me providing copious amounts of testing here (and their results) in the hope to get this fixed... :-) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #13 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:47:45 --- Created an attachment (id=58892) -- (https://bugzilla.kernel.org/attachment.cgi?id=58892) dmesg log with 2.6.39-rc7 with KMS + agpmode=-1 + no_wb=1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #14 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:50:35 --- Created an attachment (id=58902) -- (https://bugzilla.kernel.org/attachment.cgi?id=58902) X log with 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #15 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:56:33 --- With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1: * I don't get the Oopsen. * the resolution is restricted to 800x600. * XV is not available to mplayer or other applications. I think the XV extension not working is something that has always happened with 2.6.39 kernels. Thanks, Rogério Brito. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #16 from Michel Dänzer mic...@daenzer.net 2011-05-21 14:54:25 --- (In reply to comment #15) With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1: * XV is not available to mplayer or other applications. When the kernel radeon driver fails to initialize acceleration, there's no point in trying any functionality that needs acceleration, such as XVideo. I don't think there's any point doing any more tests with 2.6.39-rc7, as it's obviously suffering from additional issues which only occurred intermittently during the 2.6.39 cycle. (In reply to comment #12) BTW, I hope that you don't mind me providing copious amounts of testing here (and their results) in the hope to get this fixed... :-) Well, I'm afraid less quantity but more quality would be better... It's becoming rather difficult and time-consuming to find the relevant pieces of information in this mass. (In reply to comment #11) Just for the record #2, 2.6.38 with KMS + agpmode=-1 + no_wb=1 + dynclks=1 still locks up the GPU when I play a video with mplayer. Has either of you tried agpmode=1 dynclks=1? Does that increase stability at all? Besides that, like Andreas, with dynclks=1 the resolution is reduced to be 800x600. I didn't have the opportunity to read the X logs regarding the S-Video port, but, at least for the user, iBooks (differently from PowerBooks) don't have user-accessible S-Video ports (but this doesn't prevent Apple from having inutilized them somehow). I thought there was some kind of multimedia adapter for the external output. Anyway, it should be possible to override the incorrect output detection, either on the kernel command line with something like video=S-video-1:d or later in xorg.conf or during X runtime with something like xrandr. But really, we need to focus on one problem per bug report as much as possible, or things are getting out of hand. (In reply to comment #9) So, I am not quite sure if it would be the case of bisecting or, at least, what would be a good starting point. No, there's no point in bisecting, as that problem should be gone with 2.6.39 final. Note that you should boot with radeon.no_wb=1 as well for OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. no_wb=1 would only have been important for bisecting, to avoid the writeback endianness bug interfering. P.S. beware of Debian package udev version 169-1: IME an initrd generated with that installed prevents the radeon module from being loaded automatically, and when trying to load it manually, it fails to load the CP microcode and consequently fails to initialize acceleration. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #17 from Rogério Brito rbr...@ime.usp.br 2011-05-21 15:34:37 --- Hi, Michel. Thank you very much for the attention. (In reply to comment #16) When the kernel radeon driver fails to initialize acceleration, there's no point in trying any functionality that needs acceleration, such as XVideo. OK. I don't think there's any point doing any more tests with 2.6.39-rc7, as it's obviously suffering from additional issues which only occurred intermittently during the 2.6.39 cycle. Right. Well, I'm afraid less quantity but more quality would be better... It's becoming rather difficult and time-consuming to find the relevant pieces of information in this mass. Indeed, it is getting out of hand pretty quickly. Do you want me to give you some SSH access to this notebook? Or, if that's not feasible/useful, what would you like me to test as the next step, so that I avoid flooding you with so much data? Has either of you tried agpmode=1 dynclks=1? Does that increase stability at all? I will try those. But with which kernel? I have been avoiding compiling a kernel nowadays, since they take ages on this notebook, but I can set up a cross-compilation environment, if necessary. BTW, would you mind sharing your .config? I thought there was some kind of multimedia adapter for the external output. The only external adapter is one to a VGA port. No traces of S-video here. But really, we need to focus on one problem per bug report as much as possible, or things are getting out of hand. OK, I can file a separate bug for this S-Video issue, then. Thank you so much for your patience, Rogério Brito. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #18 from Alex Deucher alexdeuc...@gmail.com 2011-05-21 15:38:57 --- apples sells VGA to s-video adapters, so we list both connectors in the driver. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #19 from Rogério Brito rbr...@ime.usp.br 2011-05-21 15:42:21 --- (In reply to comment #18) apples sells VGA to s-video adapters, so we list both connectors in the driver. Oh, sorry for the ignorance. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #20 from Michel Dänzer mic...@daenzer.net 2011-05-21 16:47:10 --- Created an attachment (id=58922) -- (https://bugzilla.kernel.org/attachment.cgi?id=58922) Allow forcing on all GPU clocks (In reply to comment #17) Has either of you tried agpmode=1 dynclks=1? Does that increase stability at all? I will try those. But with which kernel? 2.6.38 should be fine for this test. But at some point it'll probably be useful for you to be able to try kernel patches. Once you've built a kernel, building the radeon module with a patch shouldn't take long. E.g., you guys could try this patch, and booting with radeon.dynclks=0, which should force on all GPU clocks. Does that increase stability with agpmode=1 or agpmode=-1? BTW, would you mind sharing your .config? My .config still takes 1-2 hours to build on this 1.6 GHz PowerBook. If that could help you, please ask for it on the debian-powerpc list. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #21 from Michel Dänzer mic...@daenzer.net 2011-05-21 16:58:59 --- Would also be interesting if one of you guys could attach dmesg with agpmode=1. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-05-20 12:11:38 --- (In reply to comment #1) Anyway, things are *way* better with 2.6.38 than with 2.6.39, as with 2.6.39 the kernel doesn't even get the colors correctly---everything that should be red becomes blue and so forth (any kind of endianness problem?). That's probably nothing to do with the kernel directly but endianness bugs in the X driver when acceleration is not available. It would be interesting if you could bisect what broke acceleration with radeon.agpmode=-1. Note that you should boot with radeon.no_wb=1 as well for this, as CP writeback was only fixed during the 2.6.39 cycle (in commit dc66b325f161bb651493c7d96ad44876b629cf6a). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #7 from Michel Dänzer mic...@daenzer.net 2011-05-20 14:31:00 --- I was able to reproduce the acceleration initialization failure with the Debian 2.6.39-rc7-powerpc kernel, but not with a self-built 2.6.39 kernel. So this was probably just an intermittent problem during the 2.6.39 cycle, e.g. due to the intermittent broken usage of the DMA API by TTM. As for the GPU lockups, does radeon.dynclks=1 help for those? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #8 from Andreas Schwab sch...@linux-m68k.org 2011-05-20 20:58:03 --- radeon.dynclks=1 causes the wrong resolution to be selected. It thinks something is conncted to the S-video port with a max resolution of 800x600, so it selects this instead of the native resolution (1024x768). -6Console: switching to colour frame buffer device 128x48 +6[drm] crtc 1 is connected to a TV +6Console: switching to colour frame buffer device 100x37 +(II) RADEON(0): Printing probed modes for output S-video +(II) RADEON(0): Modeline 800x600x59.9 38.25 800 832 912 1024 600 603 607 624 -hsync +vsync (37.4 kHz) +(II) RADEON(0): Modeline 640x480x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) +(II) RADEON(0): Modeline 320x240x60.1 12.59 320 328 376 400 240 245 246 262 doublescan -hsync -vsync (31.5 kHz) (II) RADEON(0): Output LVDS connected (II) RADEON(0): Output VGA-0 disconnected -(II) RADEON(0): Output S-video disconnected +(II) RADEON(0): Output S-video connected (II) RADEON(0): Using exact sizes for initial modes -(II) RADEON(0): Output LVDS using initial mode 1024x768 +(II) RADEON(0): Output LVDS using initial mode 800x600 +(II) RADEON(0): Output S-video using initial mode 800x600 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #1 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:34:40 --- Just for the record, I can provide further messages of these: this is as reproducible as I like. In fact, I am now able to reproduce it with kernel 2.6.38 if I boot the iBook G4 with the options: video=radeonfb:off radeon.agpmode=-1 radeon.modeset=1 and play a video with mplayer. If, OTOH, I leave off the KMS, then I don't get the GPU lockups that I reported. Anyway, things are *way* better with 2.6.38 than with 2.6.39, as with 2.6.39 the kernel doesn't even get the colors correctly---everything that should be red becomes blue and so forth (any kind of endianness problem?). I am attaching here another stacktrace, in case it helps. Regards, Rogério Brito. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #2 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:36:24 --- Created an attachment (id=58602) -- (https://bugzilla.kernel.org/attachment.cgi?id=58602) A dmesg log from 2.6.39-rc7 showing problems. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #3 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:37:08 --- Created an attachment (id=58612) -- (https://bugzilla.kernel.org/attachment.cgi?id=58612) The log of X with the 2.6.39-rc7 kernel -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #4 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:38:14 --- Created an attachment (id=58622) -- (https://bugzilla.kernel.org/attachment.cgi?id=58622) A dmesg log with 2.6.38 kernel Please, notice the GPU hang with kernel 2.6.38. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #5 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:38:56 --- Created an attachment (id=58632) -- (https://bugzilla.kernel.org/attachment.cgi?id=58632) Log from X with the kernel 2.6.38 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] New: [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772
Summary: [radeon] [R300] GPU lockups with when KMS is enabled
Product: Drivers
Version: 2.5
Kernel Version: 2.6.38
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: rbr...@ime.usp.br
Regression: No
Created an attachment (id=57062)
-- (https://bugzilla.kernel.org/attachment.cgi?id=57062)
dmesg output right after the lock up, obtained via the network
Hi there.
I have been getting some Oopses/stack traces when I try to use my iBook G4
(with an ATI Technologies Inc M11 NV/FireGL Mobility T2e card) and I enable
KMS.
The userland here is Debian unstable with the DRM from experimental, but I am
willing to test anything that you would like me to.
For example, attached is the last of a series of such Oopses that I got when I
tried to test if a video was playing or not with mplayer.
I tried to use 2.6.39-rc{5,6}, but upon boot I get messages telling me that
there were failures and that hardware acceleration will be disabled and I that
I get is a desktop with colors distorted like if there were some endianness
issues.
This is, BTW, part of my attempts to get Linux running well on PowerPC, with
some of my logs (with photos) present at my homepage:
http://www.ime.usp.br/~rbrito/linux/debug-r300/
Please, if there is anything that I can provide to fix this, let me know and I
will do my best.
Thanks, Rogério Brito.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On Wed, 2005-06-22 at 18:36 +1000, Benjamin Herrenschmidt wrote: The problem is simple: when setting up the AGP aperture, it's putting it after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy, CONFIG_APER_SIZE might only be _half_ of the mapped vram space (as the card can be setup for 2 contiguous apertures). We need to make sure the DRM uses what is in MC_FB_LOCATION top, and that itself should be set ideally to max(CONFIG_APER_SIZE*2,CONFIG_MEMSIZE) to avoid any possible kind of overlap. Has this been changed by now? i.e. should I try again? johannes signature.asc Description: This is a digitally signed message part
Re: [r300/ppc] lockups
On Thu, 2005-08-25 at 23:26 +0200, Johannes Berg wrote: On Wed, 2005-06-22 at 18:36 +1000, Benjamin Herrenschmidt wrote: The problem is simple: when setting up the AGP aperture, it's putting it after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy, CONFIG_APER_SIZE might only be _half_ of the mapped vram space (as the card can be setup for 2 contiguous apertures). We need to make sure the DRM uses what is in MC_FB_LOCATION top, and that itself should be set ideally to max(CONFIG_APER_SIZE*2,CONFIG_MEMSIZE) to avoid any possible kind of overlap. Has this been changed by now? i.e. should I try again? Not sure my patch got merged, I'll have to dig into that again. Ben. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On Thu, 2005-08-25 at 23:42 +0200, Jerome Glisse wrote: IIRC there have been a patch to xorg for that and to DRM too. Give it a try :) For whatever reason, I can't seem to build xorg right now. I'll have a try another time, but thanks for the heads-up. johannes signature.asc Description: This is a digitally signed message part
Re: [r300/ppc] lockups
On Tue, 2005-06-21 at 16:44 +0200, Johannes Berg wrote: Jerome Glisse wrote: I can remember from the top of my head but there is maybe some patch that could be revealent for ppc not included in this snapshot. Thus i think you should consider trying building xorg from cvs. Anyway with a g4 it will compiles a lot faster than on dumb x86 ;) Ok, I'll have a try. But I doubt I can before the weekend though. Nicolai: If you want to take a look first-hand, I can take the pb to university (assuming you are prefect at upb dot de which I have reason to believe) next week. Can't do it this week due to a talk I have to give on Friday. The problem is simple: when setting up the AGP aperture, it's putting it after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy, CONFIG_APER_SIZE might only be _half_ of the mapped vram space (as the card can be setup for 2 contiguous apertures). We need to make sure the DRM uses what is in MC_FB_LOCATION top, and that itself should be set ideally to max(CONFIG_APER_SIZE*2,CONFIG_MEMSIZE) to avoid any possible kind of overlap. Ben. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 18 Jun 2005, Johannes Berg wrote: Any idea where I should start looking for the source of the lockups or what else to do? The problem is likely either due to the radeon memory controller - in particular registers like MC_FB_LOCATION MC_AGP_LOCATION - or some sort of AGP issue with ring buffer not working properly. IIRC Paul has a similar problem with his powerbook and Ben provided patch against xorg drm for correcting the way this reg are setup. But this patch were for normal drm. Maybe once we get time we should look at that an program properly this reg in r300... Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On Tuesday 21 June 2005 10:54, Jerome Glisse wrote: On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 18 Jun 2005, Johannes Berg wrote: Any idea where I should start looking for the source of the lockups or what else to do? The problem is likely either due to the radeon memory controller - in particular registers like MC_FB_LOCATION MC_AGP_LOCATION - or some sort of AGP issue with ring buffer not working properly. IIRC Paul has a similar problem with his powerbook and Ben provided patch against xorg drm for correcting the way this reg are setup. But this patch were for normal drm. Maybe once we get time we should look at that an program properly this reg in r300... Not knowing this particular patch or whether anybody has tried our driver on PPC, what about endianness issues? I know it's obvious, but who knows... cu, Nicolai pgpi0g7Vngt13.pgp Description: PGP signature
Re: [r300/ppc] lockups
On 6/21/05, Johannes Berg [EMAIL PROTECTED] wrote: Hi, I mainly used r300 on ppc so far thus yes it works. Good to know. I am using it on x86 for the 9800 lockup. But as i used a g5 i don't know if there is an issue with the agp of g4, don't think so... And IIRC someone told me that it worked on a powerbook which is, i presume, what Johannes got. Yes, the latest model. Btw Johannes you compile everythings yourself ? You use snapshot of what mesa, xorg, ... ? I used mesa cvs, r300 cvs and xorg cvs snapshot from http://xorg.freedesktop.org/snapshots/xorg-x11-6.8.99.11.tar.bz2 Kernel 2.6.12-rc5 (I think), only major patchset in it is suspend2. You should better build xorg from cvs on your platform. If i can steal the pb of a friend i will give it a try... Do you really think it makes a difference? I can give it a try though. I can remember from the top of my head but there is maybe some patch that could be revealent for ppc not included in this snapshot. Thus i think you should consider trying building xorg from cvs. Anyway with a g4 it will compiles a lot faster than on dumb x86 ;) Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
Hi, I mainly used r300 on ppc so far thus yes it works. Good to know. I am using it on x86 for the 9800 lockup. But as i used a g5 i don't know if there is an issue with the agp of g4, don't think so... And IIRC someone told me that it worked on a powerbook which is, i presume, what Johannes got. Yes, the latest model. Btw Johannes you compile everythings yourself ? You use snapshot of what mesa, xorg, ... ? I used mesa cvs, r300 cvs and xorg cvs snapshot from http://xorg.freedesktop.org/snapshots/xorg-x11-6.8.99.11.tar.bz2 Kernel 2.6.12-rc5 (I think), only major patchset in it is suspend2. You should better build xorg from cvs on your platform. If i can steal the pb of a friend i will give it a try... Do you really think it makes a difference? I can give it a try though. johannes --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On 6/21/05, Nicolai Haehnle [EMAIL PROTECTED] wrote: On Tuesday 21 June 2005 10:54, Jerome Glisse wrote: On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 18 Jun 2005, Johannes Berg wrote: Any idea where I should start looking for the source of the lockups or what else to do? The problem is likely either due to the radeon memory controller - in particular registers like MC_FB_LOCATION MC_AGP_LOCATION - or some sort of AGP issue with ring buffer not working properly. IIRC Paul has a similar problem with his powerbook and Ben provided patch against xorg drm for correcting the way this reg are setup. But this patch were for normal drm. Maybe once we get time we should look at that an program properly this reg in r300... Not knowing this particular patch or whether anybody has tried our driver on PPC, what about endianness issues? I know it's obvious, but who knows... I mainly used r300 on ppc so far thus yes it works. I am using it on x86 for the 9800 lockup. But as i used a g5 i don't know if there is an issue with the agp of g4, don't think so... And IIRC someone told me that it worked on a powerbook which is, i presume, what Johannes got. Btw Johannes you compile everythings yourself ? You use snapshot of what mesa, xorg, ... ? You should better build xorg from cvs on your platform. If i can steal the pb of a friend i will give it a try... Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
Jerome Glisse wrote: I can remember from the top of my head but there is maybe some patch that could be revealent for ppc not included in this snapshot. Thus i think you should consider trying building xorg from cvs. Anyway with a g4 it will compiles a lot faster than on dumb x86 ;) Ok, I'll have a try. But I doubt I can before the weekend though. Nicolai: If you want to take a look first-hand, I can take the pb to university (assuming you are prefect at upb dot de which I have reason to believe) next week. Can't do it this week due to a talk I have to give on Friday. johannes --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On Sat, 18 Jun 2005, Johannes Berg wrote: Hi, I just tried the latest r300 cvs code (with current mesa cvs, latest Xorg snapshot) but all I get is a lockup as soon as the X server starts. If I have debugging enabled, I get a loop of radeon_do_cp_idle calls. Hardware is: :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 (2000ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 48 Region 0: Memory at b800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 802400 [size=256] Region 2: Memory at b000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at f100 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=none Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Any idea where I should start looking for the source of the lockups or what else to do? The problem is likely either due to the radeon memory controller - in particular registers like MC_FB_LOCATION MC_AGP_LOCATION - or some sort of AGP issue with ring buffer not working properly. The 2d support should work - the fact that it does not indicates a screw up someplace obvious. Check that the registers mentioned above are programmed to what Xserver and drm driver think they are. In particular look for endianness errors, though this might not be it.. To avoid lockups you can modify Xserver code to put exit(0) just after those are set - you will need a separate box to ssh in as the monitor will not be in a usable state. best Vladimir Dergachev Thanks, johannes --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300/ppc] lockups
Hi, I just tried the latest r300 cvs code (with current mesa cvs, latest Xorg snapshot) but all I get is a lockup as soon as the X server starts. If I have debugging enabled, I get a loop of radeon_do_cp_idle calls. Hardware is: :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 (2000ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 48 Region 0: Memory at b800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 802400 [size=256] Region 2: Memory at b000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at f100 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=none Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Any idea where I should start looking for the source of the lockups or what else to do? Thanks, johannes signature.asc Description: This is a digitally signed message part
Re: [R300] on lockups
On Sat, 4 Jun 2005, Nicolai Haehnle wrote: The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. It could be that AGP GART can still decode addresses for writes to system memory, I guess this depends on a particular architecture. One of the reasons to look forward to PCI Express is that it is bi-directional, unlike AGP. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). What's the meaning of RADEON_AGP_BASE, by the way? It is programmed to dev-agp-base, which is AFAIK an address from the kernel's address space. That doesn't make much sense to me. It could be anything. However, the recommended way to program the memory controller is to set the BASE of video memory to its physical PCI address and to put AGP memory where it is mirrored by the AGP GART, as, presumably, this does not overlap with system RAM or any of other sensitive areas. My understanding is that dev-agp-base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Of course, these are somewhat bogus on 64 bit system. The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. However, the size of video RAM is usually much smaller than the size of system RAM. So if the scratch registers image in system memory had small physical address you might get a lockup and if it was high you don't. You also would be more likely to get a lockup when load on system memory increased. Hmm. The way RADEON_MC_(FB|AGP)_LOCATION are programmed, it seems to be like they actually consist of two 16 bit fields, one indicating the start of the FB/AGP area, the other indicating the end. They are always programmed in rather large memory units. Do you know what happens when the programmed size of the FB area is larger than the physical size of video RAM? What happens when the programmed size of the AGP area is larger than the size of the AGP aperture? This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. How did that fix work? Eventually the DRM driver was able to reprogram memory controller on request. So by default it used the usual setup (DISPLAY_BASE at 0) and it switched to reasonable setup when requested. The reasons for such behaviour are: * older mesa drivers did not know about reprogramming (and drm is separate from Mesa) * framebuffer does not know about reprogramming * *all* video BIOSes that I have seen always set DISPLAY_BASE to 0. so this is a safe mode (which completely precludes DMA from/to the first N megabytes of system memory where N is the size of video aperture). best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. Yup, and that is not recommended. We program it differently on r200 but for some reason, X still does that hack to put it down at 0 on r300. I wonder why. I always assumed that r300 should behave similarly to r200 - at least I can't see where the switch is. I certainly have not put any switches to change the behaviour (unless it was a mistake). Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. The most puzzling thing is that lockup is not immediate (as I would have expected) and that it works on some chips.. best Vladimir Dergachev Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Vladimir Dergachev schrieb: My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. AGP can do both. Every AGP compliant device has to support the System RAM - video RAM part. The other one is optional. Optional not only in the graphics card but in the northbridge, so there are some cheap chipsets that don't support it. This lead to many card manufacturers not supporting it in their cards and drivers. Highend graphics cards like the Wildcat support it. Philipp --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sun, 5 Jun 2005, Jerome Glisse wrote: Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. Was wondering were this stuff is setup, drm ? Xorg driver ? dri driver ? Or is there a simple option to fallback :) I think this is inside DRM driver. Search for string Writeback doesn't seem to work everywhere, test it first inside the file radeon_cp.c best Vladimir Dergachev Jerome --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sunday 05 June 2005 15:55, Vladimir Dergachev wrote: On Sat, 4 Jun 2005, Nicolai Haehnle wrote: The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. You mean system RAM - graphics card, right? Does this mean that the graphics card cannot always write into memory that falls within RADEON_MC_AGP_LOCATION? It could be that AGP GART can still decode addresses for writes to system memory, I guess this depends on a particular architecture. One of the reasons to look forward to PCI Express is that it is bi-directional, unlike AGP. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). What's the meaning of RADEON_AGP_BASE, by the way? It is programmed to dev-agp-base, which is AFAIK an address from the kernel's address space. That doesn't make much sense to me. It could be anything. However, the recommended way to program the memory controller is to set the BASE of video memory to its physical PCI address and to put AGP memory where it is mirrored by the AGP GART, as, presumably, this does not overlap with system RAM or any of other sensitive areas. My understanding is that dev-agp-base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Yes, that's my understanding, too. But what is the Radeon's business knowing that address? Why does it need to know this address? I thought this was CPU address space, not card address space. cu, Nicolai pgpmw9nGNctUV.pgp Description: PGP signature
Re: [R300] on lockups
This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. You mean system RAM - graphics card, right? Does this mean that the graphics card cannot always write into memory that falls within RADEON_MC_AGP_LOCATION? I don't think we can rely on this. My understanding is that dev-agp-base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Yes, that's my understanding, too. But what is the Radeon's business knowing that address? Why does it need to know this address? I thought this was CPU address space, not card address space. Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sunday 05 June 2005 20:07, Vladimir Dergachev wrote: My understanding is that dev-agp-base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Yes, that's my understanding, too. But what is the Radeon's business knowing that address? Why does it need to know this address? I thought this was CPU address space, not card address space. Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. I understand that part, but it's not what I meant. What I mean is this: You said, RADEON_MC_AGP_LOCATION is used to program where AGP is in the card's address space, and that's all fine and makes sense. However, we are *also* programming dev-agp-base into a register called RADEON_AGP_BASE. What is the meaning of that register? cu, Nicolai pgpmkn1hvrepD.pgp Description: PGP signature
Re: [R300] on lockups
Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. I understand that part, but it's not what I meant. What I mean is this: You said, RADEON_MC_AGP_LOCATION is used to program where AGP is in the card's address space, and that's all fine and makes sense. However, we are *also* programming dev-agp-base into a register called RADEON_AGP_BASE. What is the meaning of that register? AFAIK this offset is used by PCI GART. When PCI GART is on this offset specifies location of AGP-like space. best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sun, 2005-06-05 at 09:58 -0400, Vladimir Dergachev wrote: Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. Yup, and that is not recommended. We program it differently on r200 but for some reason, X still does that hack to put it down at 0 on r300. I wonder why. I always assumed that r300 should behave similarly to r200 - at least I can't see where the switch is. I certainly have not put any switches to change the behaviour (unless it was a mistake). I think people originally had problems with the r200 code on r300, which might be related to the use of tiled mode by the firmware on some r300 based setups (at least on macs). It seems that just mucking around MC_FB_* etc... without actually disabling or reconfiguring tiling properly locks up the card. I think we need to be smarter here. We probably need to change MC_FB_LOCATION etc... in the actual mode set sequence (and thus save/restore them on console switch). We should probably make sure nothing is accessing memory while doing the change (that is set the proper bits to disable access to MC by the CRTC, which should be easy in the mode setting which is already wrapped in blanks). Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. The most puzzling thing is that lockup is not immediate (as I would have expected) and that it works on some chips.. best Vladimir Dergachev Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. You mean system RAM - graphics card, right? Does this mean that the graphics card cannot always write into memory that falls within RADEON_MC_AGP_LOCATION? Actually, that depends on the chipset. Some chipsets do support it, some don't. I don't think this capability is currently exposed by our AGP infrastructure. It could be anything. However, the recommended way to program the memory controller is to set the BASE of video memory to its physical PCI address and to put AGP memory where it is mirrored by the AGP GART, as, presumably, this does not overlap with system RAM or any of other sensitive areas. My understanding is that dev-agp-base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Yes, that's my understanding, too. But what is the Radeon's business knowing that address? Why does it need to know this address? I thought this was CPU address space, not card address space. No, the AGP aperture base is known to the radeon since the AGP cycles issued by the radeon must land in the proper area. However, it's programmed once for all in the card. But it can't be set to the same value as the CPU view of it neither. The reason is that there may not be any valid CPU view of it. On some chipsets, the AGP aperture is not accessible at all by the CPU. On those platforms, the aperture is made visible by remapping all pages that are bound to it into a single linear virtual mapping (using the MMU), not by mapping in the physical AGP aperture. In fact, on some chipsets, the AGP base has to be 0 (without however conflicting with PCI accesses as these chipsets, afaik, only go through the GART for pure AGP transactions). Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. It will overlap it on all PowerMac's (where it will be 0) Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sun, 2005-06-05 at 14:45 -0400, Vladimir Dergachev wrote: Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. I understand that part, but it's not what I meant. What I mean is this: You said, RADEON_MC_AGP_LOCATION is used to program where AGP is in the card's address space, and that's all fine and makes sense. However, we are *also* programming dev-agp-base into a register called RADEON_AGP_BASE. What is the meaning of that register? AFAIK this offset is used by PCI GART. When PCI GART is on this offset specifies location of AGP-like space. No, it's the address of the AGP aperture on the _bus_, (the value you were talking about earlier) though it's sometimes just 0. Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] on lockups
I just wanted to contribute the following piece of information that might help with R300 lockups. I do not know whether it applies or not in this case, but just something to be aware about. Radeon has a memory controller which translates internal address space of the chip into accesses of different memory - framebuffer, agp, system ram. So from the point of view of Radeon chip there is a single flat 32 bit address space which contains everything. This is nice because you can simply set texture offset to a particular number and the chip will pull it from appropriate memory - be it video memory, agp or system ram. (albeit system ram access is done via PCI, not AGP commands and thus is much slower). It used to be that Radeon DRM driver had two modes for usage of scratch registers - a mode when it polled Radeon chip directly and a mode when the contents of the registers were mirrored in the system RAM. The driver would try mirroring during startup and if it fails uses polling method. The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. However, the size of video RAM is usually much smaller than the size of system RAM. So if the scratch registers image in system memory had small physical address you might get a lockup and if it was high you don't. You also would be more likely to get a lockup when load on system memory increased. This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. On the other hand, all of this might not be relevant at all.. best Vladimir Dergachev --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Saturday 04 June 2005 15:01, Vladimir Dergachev wrote: I just wanted to contribute the following piece of information that might help with R300 lockups. I do not know whether it applies or not in this case, but just something to be aware about. Radeon has a memory controller which translates internal address space of the chip into accesses of different memory - framebuffer, agp, system ram. So from the point of view of Radeon chip there is a single flat 32 bit address space which contains everything. This is nice because you can simply set texture offset to a particular number and the chip will pull it from appropriate memory - be it video memory, agp or system ram. (albeit system ram access is done via PCI, not AGP commands and thus is much slower). It used to be that Radeon DRM driver had two modes for usage of scratch registers - a mode when it polled Radeon chip directly and a mode when the contents of the registers were mirrored in the system RAM. The driver would try mirroring during startup and if it fails uses polling method. The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). What's the meaning of RADEON_AGP_BASE, by the way? It is programmed to dev-agp-base, which is AFAIK an address from the kernel's address space. That doesn't make much sense to me. The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. However, the size of video RAM is usually much smaller than the size of system RAM. So if the scratch registers image in system memory had small physical address you might get a lockup and if it was high you don't. You also would be more likely to get a lockup when load on system memory increased. Hmm. The way RADEON_MC_(FB|AGP)_LOCATION are programmed, it seems to be like they actually consist of two 16 bit fields, one indicating the start of the FB/AGP area, the other indicating the end. Do you know what happens when the programmed size of the FB area is larger than the physical size of video RAM? What happens when the programmed size of the AGP area is larger than the size of the AGP aperture? This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. How did that fix work? cu, Nicolai pgpNmZIBoEWgy.pgp Description: PGP signature
Re: [R300] on lockups
Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. Ok, then that leads to another issue ... some AGP bridges simply don't support writes to AGP memory (or seem to support it but screw up). Hmm. The way RADEON_MC_(FB|AGP)_LOCATION are programmed, it seems to be like they actually consist of two 16 bit fields, one indicating the start of the FB/AGP area, the other indicating the end. Yup. Do you know what happens when the programmed size of the FB area is larger than the physical size of video RAM? What happens when the programmed size of the AGP area is larger than the size of the AGP aperture? I don't know for sure, probably harmless though. What I know however is that we don't program it properly since we use CONFIG_APER_SIZE, which is the aperture size on PCI and has nothing to do with the actual amount of video memory on r100/200. I don't remember what we do on r300 except that we put it down to 0 which is wrong too. This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. How did that fix work? Well, the recommended practice is to set MC_FB_LOCATION such that the framebuffer is at the same address in card's space as it's bus address from CPU viw, that is to whatever is in the BAR. (CONFIG_APER_BASE I suppose). Then to put AGP just after that (or before that if that doesn't fit). I think we do some of that for r100/r200 (though with the issue I describe above of using the wrong information for the size) and we just put the FB down at 0 for r300. Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. Goood old discussion :) Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. Yup, and that is not recommended. We program it differently on r200 but for some reason, X still does that hack to put it down at 0 on r300. However, the size of video RAM is usually much smaller than the size of system RAM. So if the scratch registers image in system memory had small physical address you might get a lockup and if it was high you don't. You also would be more likely to get a lockup when load on system memory increased. This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. Yup, look at X.org side, it's still getting wrong. Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
Vladimir Dergachev wrote: This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4 appear stable 1-3 appear unstable. With the latest CVS I once managed to run the lesson for 3 sec. before it locked up . All other times I got a lockup before it showed the first frame. Does the same happen if you load them in a different order ? What is the difference between these textures ? the first and last texture are the only textures that work properly. If I change the order it is still the first and last texture. To me it smells like an texture allocation/management bug. Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
On Sun, 30 Jan 2005, Rune Petersen wrote: Vladimir Dergachev wrote: This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4 appear stable 1-3 appear unstable. With the latest CVS I once managed to run the lesson for 3 sec. before it locked up . All other times I got a lockup before it showed the first frame. Does the same happen if you load them in a different order ? What is the difference between these textures ? the first and last texture are the only textures that work properly. If I change the order it is still the first and last texture. To me it smells like an texture allocation/management bug. Since we get a lockup it is reasonable to assume that the texture offset is screwed up. This is strange as the texture management code was pulled straight from r200 driver - I would have expected it to work. best Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
Vladimir Dergachev wrote: On Sun, 30 Jan 2005, Rune Petersen wrote: Vladimir Dergachev wrote: This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4 appear stable 1-3 appear unstable. With the latest CVS I once managed to run the lesson for 3 sec. before it locked up . All other times I got a lockup before it showed the first frame. Does the same happen if you load them in a different order ? What is the difference between these textures ? the first and last texture are the only textures that work properly. If I change the order it is still the first and last texture. To me it smells like an texture allocation/management bug. Since we get a lockup it is reasonable to assume that the texture offset is screwed up. This is strange as the texture management code was pulled straight from r200 driver - I would have expected it to work. Can you tell me how to get at these offsets? it will be easier to debug compared to lockups :) Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
Does the same happen if you load them in a different order ? What is the difference between these textures ? the first and last texture are the only textures that work properly. If I change the order it is still the first and last texture. To me it smells like an texture allocation/management bug. Since we get a lockup it is reasonable to assume that the texture offset is screwed up. This is strange as the texture management code was pulled straight from r200 driver - I would have expected it to work. Can you tell me how to get at these offsets? it will be easier to debug compared to lockups :) I started looking for the code to point you to and could not resist to experiment a little. Turns out offsets are not at fault, rather the issue is with HOSTDATA_BLT (again !). If you comment out the code in r300_texmem.c in the end of the function uploadSubImage (starting with LOCK_HARDWARE) then lesson20 works without a lockup. What this code does is upload textures to the hardware - so you'll see some random patterns instead of what it is supposed to look like. I think this is the same problem that causes Quake or tuxracer to lockup as well - both are certainly trying to upload a ton of textures at the start of the game. The fix needs to be made someplace inside DRM driver.. It would be interesting to find out why some HOSTDATA_BLT calls succeed and some don't - maybe it is as simple as calling HOSTDATA_BLT in sequence (without any 3d commands in between) locks up. best Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
This is strange as the texture management code was pulled straight from r200 driver - I would have expected it to work. Can you tell me how to get at these offsets? it will be easier to debug compared to lockups :) I started looking for the code to point you to and could not resist to experiment a little. Turns out offsets are not at fault, rather the issue is with HOSTDATA_BLT (again !). If you comment out the code in r300_texmem.c in the end of the function uploadSubImage (starting with LOCK_HARDWARE) then lesson20 works without a lockup. What this code does is upload textures to the hardware - so you'll see some random patterns instead of what it is supposed to look like. I think this is the same problem that causes Quake or tuxracer to lockup as well - both are certainly trying to upload a ton of textures at the start of the game. The fix needs to be made someplace inside DRM driver.. It would be interesting to find out why some HOSTDATA_BLT calls succeed and some don't - maybe it is as simple as calling HOSTDATA_BLT in sequence (without any 3d commands in between) locks up. Hi Rune, I think I fixed it - looks like the texture upload function in drm/shared-core/radeon_state.c needed a fix similar to cp_idle() function. Could you let me know how it work with your card ? You would need to update the DRM driver from CVS and recompile it. thank you ! Vladimir Dergachev PS Both q3demo and tuxracer still lock up, something to do with ClearBuffer code.. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
On Fri, 28 Jan 2005, Rune Petersen wrote: Vladimir Dergachev wrote: On Thu, 27 Jan 2005, Rune Petersen wrote: Hi, I get lockups running anything other than glxgears. I am running the 25 jan. snapshots of Xorg r300_driver. Are there any simple way to locate the functions that course lockups? I was thinking of something like simple programs or tutorials. Try NeHe tutorial - nehe.gamedev.net In particular, it would be interesting to find out whether you can run any programs that use textures. for now I have tried lessons up to lesson 20. only 2 give me problems Lesson 16 causes a segfault. Can you make the driver recover the original resolution after a segfault? Lesson 20 causes a hard lockup. Can you confirm if these Lessons work on R300? Hi Rune, I see the same problems on R300. I guess the segfault is possibly due to trying to access framebuffer directly (as using fog triggers a fallback). As for lesson20 I have no idea - try commenting out drawing code and checking which part creates a lockup. Btw, I am getting a partial lockup with lesson20 even without r300_dri.so (when it is absent the driver falls back to software rendering), so it might be due to mode switching. best Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
Vladimir Dergachev wrote: Hi, I get lockups running anything other than glxgears. I am running the 25 jan. snapshots of Xorg r300_driver. Are there any simple way to locate the functions that course lockups? I was thinking of something like simple programs or tutorials. Try NeHe tutorial - nehe.gamedev.net In particular, it would be interesting to find out whether you can run any programs that use textures. for now I have tried lessons up to lesson 20. only 2 give me problems Lesson 16 causes a segfault. Can you make the driver recover the original resolution after a segfault? Lesson 20 causes a hard lockup. Can you confirm if these Lessons work on R300? Hi Rune, I see the same problems on R300. I guess the segfault is possibly due to trying to access framebuffer directly (as using fog triggers a fallback). As for lesson20 I have no idea - try commenting out drawing code and checking which part creates a lockup. Btw, I am getting a partial lockup with lesson20 even without r300_dri.so (when it is absent the driver falls back to software rendering), so it might be due to mode switching. Lesson 20 have 3 points that causes lockups (maybe more). They are all related. the first is at line 258-259: glBindTexture(GL_TEXTURE_2D, texture[3]); glBegin(GL_QUADS); glBegin() is causing the lockup, but only when textures 1, 2, or 3. if you change it to texture 4: glBindTexture(GL_TEXTURE_2D, texture[4]); glBegin(GL_QUADS); The lesson will now run (until you press space). To me it sounds rather strange that a texture causes the lockup. Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
fallback). As for lesson20 I have no idea - try commenting out drawing code and checking which part creates a lockup. Btw, I am getting a partial lockup with lesson20 even without r300_dri.so (when it is absent the driver falls back to software rendering), so it might be due to mode switching. Lesson 20 have 3 points that causes lockups (maybe more). They are all related. the first is at line 258-259: glBindTexture(GL_TEXTURE_2D, texture[3]); glBegin(GL_QUADS); glBegin() is causing the lockup, but only when textures 1, 2, or 3. if you change it to texture 4: glBindTexture(GL_TEXTURE_2D, texture[4]); glBegin(GL_QUADS); The lesson will now run (until you press space). To me it sounds rather strange that a texture causes the lockup. This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? thank you ! Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
Vladimir Dergachev wrote: Lesson 20 have 3 points that causes lockups (maybe more). They are all related. the first is at line 258-259: glBindTexture(GL_TEXTURE_2D, texture[3]); glBegin(GL_QUADS); glBegin() is causing the lockup, but only when textures 1, 2, or 3. if you change it to texture 4: glBindTexture(GL_TEXTURE_2D, texture[4]); glBegin(GL_QUADS); The lesson will now run (until you press space). To me it sounds rather strange that a texture causes the lockup. This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4 appear stable 1-3 appear unstable. With the latest CVS I once managed to run the lesson for 3 sec. before it locked up . All other times I got a lockup before it showed the first frame. Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
On Sun, 30 Jan 2005, Rune Petersen wrote: Vladimir Dergachev wrote: Lesson 20 have 3 points that causes lockups (maybe more). They are all related. the first is at line 258-259: glBindTexture(GL_TEXTURE_2D, texture[3]); glBegin(GL_QUADS); glBegin() is causing the lockup, but only when textures 1, 2, or 3. if you change it to texture 4: glBindTexture(GL_TEXTURE_2D, texture[4]); glBegin(GL_QUADS); The lesson will now run (until you press space). To me it sounds rather strange that a texture causes the lockup. This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4 appear stable 1-3 appear unstable. With the latest CVS I once managed to run the lesson for 3 sec. before it locked up . All other times I got a lockup before it showed the first frame. Does the same happen if you load them in a different order ? What is the difference between these textures ? thank you Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] 3D lockups on R420
Hi, I get lockups running anything other than glxgears. I am running the 25 jan. snapshots of Xorg r300_driver. Are there any simple way to locate the functions that course lockups? I was thinking of something like simple programs or tutorials. Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
On Thu, 27 Jan 2005, Rune Petersen wrote: Hi, I get lockups running anything other than glxgears. I am running the 25 jan. snapshots of Xorg r300_driver. Are there any simple way to locate the functions that course lockups? I was thinking of something like simple programs or tutorials. Try NeHe tutorial - nehe.gamedev.net In particular, it would be interesting to find out whether you can run any programs that use textures. best Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
Vladimir Dergachev wrote: On Thu, 27 Jan 2005, Rune Petersen wrote: Hi, I get lockups running anything other than glxgears. I am running the 25 jan. snapshots of Xorg r300_driver. Are there any simple way to locate the functions that course lockups? I was thinking of something like simple programs or tutorials. Try NeHe tutorial - nehe.gamedev.net In particular, it would be interesting to find out whether you can run any programs that use textures. for now I have tried lessons up to lesson 20. only 2 give me problems Lesson 16 causes a segfault. Can you make the driver recover the original resolution after a segfault? Lesson 20 causes a hard lockup. Can you confirm if these Lessons work on R300? Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
