Re: [Dri-users] r300 question
I know it's quite silly to reply to own posts I don't know if this problem: > 3. Second dri problem: glxinfo says $ glxinfo > name of display: :0.0 > libGL warning: 3D driver claims to not support visual 0x23 > libGL warning: 3D driver claims to not support visual 0x24 > libGL warning: 3D driver claims to not support visual 0x25 > libGL warning: 3D driver claims to not support visual 0x26 > libGL warning: 3D driver claims to not support visual 0x27 > libGL warning: 3D driver claims to not support visual 0x28 > libGL warning: 3D driver claims to not support visual 0x29 > libGL warning: 3D driver claims to not support visual 0x2a > libGL warning: 3D driver claims to not support visual 0x2b > libGL warning: 3D driver claims to not support visual 0x2c > libGL warning: 3D driver claims to not support visual 0x2d > libGL warning: 3D driver claims to not support visual 0x2e > libGL warning: 3D driver claims to not support visual 0x2f > libGL warning: 3D driver claims to not support visual 0x30 > libGL warning: 3D driver claims to not support visual 0x31 > libGL warning: 3D driver claims to not support visual 0x32 > Error: couldn't find RGB GLX visual > >visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > -- > 0x23 16 tc 0 16 0 r . . 6 5 0 0 0 16 0 0 0 0 0 0 0 None > 0x24 16 tc 0 16 0 r . . 6 5 0 0 0 16 8 0 0 0 0 0 0 Slow > 0x25 16 tc 0 16 0 r . . 6 5 0 0 0 16 0 16 16 16 0 0 0 Slow > 0x26 16 tc 0 16 0 r . . 6 5 0 0 0 16 8 16 16 16 0 0 0 Slow > 0x27 16 tc 0 16 0 r y . 6 5 0 0 0 16 0 0 0 0 0 0 0 None > 0x28 16 tc 0 16 0 r y . 6 5 0 0 0 16 8 0 0 0 0 0 0 Slow > 0x29 16 tc 0 16 0 r y . 6 5 0 0 0 16 0 16 16 16 0 0 0 Slow > 0x2a 16 tc 0 16 0 r y . 6 5 0 0 0 16 8 16 16 16 0 0 0 Slow > 0x2b 16 dc 0 16 0 r . . 6 5 0 0 0 16 0 0 0 0 0 0 0 None > 0x2c 16 dc 0 16 0 r . . 6 5 0 0 0 16 8 0 0 0 0 0 0 Slow > 0x2d 16 dc 0 16 0 r . . 6 5 0 0 0 16 0 16 16 16 0 0 0 Slow > 0x2e 16 dc 0 16 0 r . . 6 5 0 0 0 16 8 16 16 16 0 0 0 Slow > 0x2f 16 dc 0 16 0 r y . 6 5 0 0 0 16 0 0 0 0 0 0 0 None > 0x30 16 dc 0 16 0 r y . 6 5 0 0 0 16 8 0 0 0 0 0 0 Slow > 0x31 16 dc 0 16 0 r y . 6 5 0 0 0 16 0 16 16 16 0 0 0 Slow > 0x32 16 dc 0 16 0 r y . 6 5 0 0 0 16 8 16 16 16 0 0 0 Slow > was gentoo-specific http://bugs.gentoo.org/show_bug.cgi?id=122140 , however it seems fixed now (with new ebuild for xorg). Michał --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On Mon, Feb 13, 2006 at 07:34:45PM +0100, Adrian Bunk wrote: > On Mon, Feb 13, 2006 at 10:16:59AM -0800, Linus Torvalds wrote: > > > > > > On Mon, 13 Feb 2006, Linus Torvalds wrote: > > > > > > DaveA, I'll apply this for now. Comments? > > > > Btw, the fact that Mauro has the same exact PCI ID (well, lspci stupidly > > suppresses the ID entirely, but the string seems to match the one that > > Dave Jones reports) may be unrelated. > > Dave's patch removes the entry for the card with the 0x5b60. > According to his bug report, Mauro has a Radeon X300SE that should > have the 0x5b70 according to pci.ids from pciutils and that doesn't seem > to be claimed by the DRM driver (and the dmesg from the bug report > confirms that the radeon DRM driver didn't claim to be responsible for > this card). The X300SE (mine at least) is a dual head card, with a 0x5b60 _and_ a 0x5b70 Dave --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On Mon, 13 Feb 2006, Adrian Bunk wrote: > > Dave's patch removes the entry for the card with the 0x5b60. > > According to his bug report, Mauro has a Radeon X300SE that should > have the 0x5b70 according to pci.ids from pciutils No. Look closer: 04:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] (prog-if 00 [VGA]) Subsystem: ASUSTeK Computer Inc. Extreme AX300SE-X That's the 5b60 chip too (yeah, the lspci doesn't show numbers when it has an ascii string, but in this case the ascii string happily has at least that part of the number in it: ".. RV370 5B60 ..", where the 5B60 is just the PCI ID number). So it _is_ the same chip. I just worry whether (a) the other added PCI ID's are any good for that core and (b) whether the bug was really introduced with some of the other changes. I admit that (b) is pretty unlikely, but it would be good to test. > and that doesn't seem to be claimed by the DRM driver (and the dmesg > from the bug report confirms that the radeon DRM driver didn't claim to > be responsible for this card). Sadly, that module loading is done by X. So the bootup dmesg stuff wouldn't have had the message. It might be interesting to see if the hang can be reproduced without starting X at all, by just going a "modprobe radeon" or something. Unlikely, though - while loading the drm modules does _some_ things to the card, it's usually only when X actually starts sending commands to them that things really go downhill.. Linus --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On 2/13/06, Dave Jones <[EMAIL PROTECTED]> wrote: > On Mon, Feb 13, 2006 at 07:34:45PM +0100, Adrian Bunk wrote: > > On Mon, Feb 13, 2006 at 10:16:59AM -0800, Linus Torvalds wrote: > > > > > > > > > On Mon, 13 Feb 2006, Linus Torvalds wrote: > > > > > > > > DaveA, I'll apply this for now. Comments? > > > > > > Btw, the fact that Mauro has the same exact PCI ID (well, lspci stupidly > > > suppresses the ID entirely, but the string seems to match the one that > > > Dave Jones reports) may be unrelated. > > > > Dave's patch removes the entry for the card with the 0x5b60. > > According to his bug report, Mauro has a Radeon X300SE that should > > have the 0x5b70 according to pci.ids from pciutils and that doesn't seem > > to be claimed by the DRM driver (and the dmesg from the bug report > > confirms that the radeon DRM driver didn't claim to be responsible for > > this card). > > The X300SE (mine at least) is a dual head card, with a 0x5b60 _and_ a 0x5b70 > > Dave > The secondary id is just a place holder for the windows driver so dualhead will work on windows 2000. Neither the drm nor the xorg DDX uses the secondary id. Alex --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On Mon, 13 Feb 2006, Adrian Bunk wrote: > > The one thing I have not yet been proven wrong for is that this PCI id > is the only one we have in this driver for an RV370. It definitely is an RV370, you're right in that. I'm too lazy to actually see if the other entries that claim to be RV350's really are RV350's. So I decided to just remove it. Even if there is some other bug that could make it work again, we can always just re-add it at that time. In the meantime, this should fix both DaveJs and Mauros problems, and is clearly no worse than 2.6.15 (which also didn't recognize the card), so... Linus --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] r300 question
Michał Pytasz wrote: > was gentoo-specific > http://bugs.gentoo.org/show_bug.cgi?id=122140 , however it seems fixed now > (with new ebuild for xorg). Indeed it wasn't Gentoo-specific at all, we just fixed it in our packages. See https://bugs.freedesktop.org/show_bug.cgi?id=5835. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: 2.6.16-rc3: more regressions
On Mon, 13 Feb 2006, Linus Torvalds wrote: > > So I decided to just remove it. Even if there is some other bug that could > make it work again, we can always just re-add it at that time. In the > meantime, this should fix both DaveJs and Mauros problems, and is clearly > no worse than 2.6.15 (which also didn't recognize the card), so... Btw, on a totally unrelated tangent, I just wanted to say how much I appreciate people looking for regressions like this, and trying to track them. Andrew does it, but this is absolutely something that should be possible to get more people to do, and it would be a huge boon for kernel development if we had a more aggressive regression tracking system. Right now it all very easily gets lost in the noise - either on the mailing list or even on bugzilla (where following up on regressions and trying to get details and prodding people to perhaps try to narrow things down a bit more often ends up falling on the floor, because it's a big job). Linus --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-13 09:20]: > On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote: > > Tilman Sauerbeck [2006-02-12 13:39]: > > > Benjamin Herrenschmidt [2006-02-10 18:12]: > > > > Here's a 3rd set of patches. Please report regressions ASAP as I intend > > > > to merge those in the various CVS trees real soon now. > > > > > > > > [...] > > > > > > > > Also, I fixed a potential issue in the DRM with machines where AGP > > > > writeback doesn't work (we would still rely on AGP writeback for the > > > > ring read ptr instead of reading it from a register). > > > > > > I believe these 2 patches introduce a hardware lockup problem in 3D > > > mode for me. It's not reliably reproduced though, so I'm not sure > > > > n/m, I just reproduced it with patch set #2, so it's not a regression. > > What if you only apply the X patch and not the DRM patch ? Current DRM CVS HEAD doesn't work for me. However it does work with a small patch applied: https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 Does it make sense to test that DRM code with the new X patch? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpaVumFHj6yo.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Kevin Shanahan wrote: > All seems good. No regressions on my Radeon Mobility M6 LY and Radeon > 64MB DDR (7200). VT switch problems from #2 now fixed. Radeon 9800 Pro > still locks up with 3D, but that's not a regression. I just had some trouble with VT switching -- when switching back to X, I lost my cursor and a small black "minify" box appeared near the lower right of my screen (perhaps where the cursor was when I switched VTs?). Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: 2.6.16-rc3: more regressions
On Mon, Feb 13, 2006 at 10:16:59AM -0800, Linus Torvalds wrote: > > > On Mon, 13 Feb 2006, Linus Torvalds wrote: > > > > DaveA, I'll apply this for now. Comments? > > Btw, the fact that Mauro has the same exact PCI ID (well, lspci stupidly > suppresses the ID entirely, but the string seems to match the one that > Dave Jones reports) may be unrelated. Dave's patch removes the entry for the card with the 0x5b60. According to his bug report, Mauro has a Radeon X300SE that should have the 0x5b70 according to pci.ids from pciutils and that doesn't seem to be claimed by the DRM driver (and the dmesg from the bug report confirms that the radeon DRM driver didn't claim to be responsible for this card). > DaveJ (or Mauro): since you can test this, can you test having that ID > there but _without_ the other changes to drm in -rc1? > > Ie was it the addition of that particular ID, or are the other radeon > driver changes (which haven't had as much testing) perhaps the culprit? > > I realize that without the ID, that card would never have been tested > anyway, but the point being that plain 2.6.15 with _just_ that ID added > has at least gotten more testing on other (similar) chips. So before I > revert that particular ID, it would be nice to know that it was broken > even with the previous radeon driver state. The ID removed by Dave's patch is the only ID listed for an RV370 chips (the other RV370's aren't listed in the radeon DRM driver). I suspect Dave and Mauro having unrelated problems. > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On Mon, Feb 13, 2006 at 01:42:09PM -0500, Dave Jones wrote: > On Mon, Feb 13, 2006 at 07:34:45PM +0100, Adrian Bunk wrote: > > On Mon, Feb 13, 2006 at 10:16:59AM -0800, Linus Torvalds wrote: > > > > > > > > > On Mon, 13 Feb 2006, Linus Torvalds wrote: > > > > > > > > DaveA, I'll apply this for now. Comments? > > > > > > Btw, the fact that Mauro has the same exact PCI ID (well, lspci stupidly > > > suppresses the ID entirely, but the string seems to match the one that > > > Dave Jones reports) may be unrelated. > > > > Dave's patch removes the entry for the card with the 0x5b60. > > According to his bug report, Mauro has a Radeon X300SE that should > > have the 0x5b70 according to pci.ids from pciutils and that doesn't seem > > to be claimed by the DRM driver (and the dmesg from the bug report > > confirms that the radeon DRM driver didn't claim to be responsible for > > this card). > > The X300SE (mine at least) is a dual head card, with a 0x5b60 _and_ a 0x5b70 OK, this might explain it. Then your patch could indeed fix Mauro's problem. > Dave cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On Mon, Feb 13, 2006 at 10:50:52AM -0800, Linus Torvalds wrote: >... > I just worry whether (a) the other added PCI ID's are any good for that > core and (b) whether the bug was really introduced with some of the other > changes. I admit that (b) is pretty unlikely, but it would be good to > test. >... The one thing I have not yet been proven wrong for is that this PCI id is the only one we have in this driver for an RV370. Perhaps someone will be able to prove this wrong, too, ;-) but otherwise it would be a good explanation why exactly this one is causing problems. > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
Hi Donnie! Monday 13, at 11:53:35 AM you wrote: > Kevin Shanahan wrote: > > All seems good. No regressions on my Radeon Mobility M6 LY and Radeon > > 64MB DDR (7200). VT switch problems from #2 now fixed. Radeon 9800 Pro > > still locks up with 3D, but that's not a regression. > > I just had some trouble with VT switching -- when switching back to X, I > lost my cursor and a small black "minify" box appeared near the lower > right of my screen (perhaps where the cursor was when I switched VTs?). In my case, this patch fix "black box" issue: after suspend/resume I see message "Hardware cursor temporarily disabled due to insufficient offscreen memory" and black (or white) box in a place of cursor. But before patch black box doesn't disappear until I restart X server, and after patch I see only warning message but cursor stay normal. PS I'm using 128 DDR 9200PRO board and DRM/Mesa from last saturday. -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov,speak to ==>JID: [EMAIL PROTECTED] aka L.A. Kostis write to ==>mailto:[EMAIL PROTECTED] ...The information is like the bank...(c) EC8OR --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-13 09:20]: > On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote: > > Tilman Sauerbeck [2006-02-12 13:39]: > > > Benjamin Herrenschmidt [2006-02-10 18:12]: > > > > Here's a 3rd set of patches. Please report regressions ASAP as I intend > > > > to merge those in the various CVS trees real soon now. > > > > > > > > [...] > > > > > > > > Also, I fixed a potential issue in the DRM with machines where AGP > > > > writeback doesn't work (we would still rely on AGP writeback for the > > > > ring read ptr instead of reading it from a register). > > > > > > I believe these 2 patches introduce a hardware lockup problem in 3D > > > mode for me. It's not reliably reproduced though, so I'm not sure > > > > n/m, I just reproduced it with patch set #2, so it's not a regression. > > What if you only apply the X patch and not the DRM patch ? It's possible that the crash that I'm seeing was introduced by a change to the r300 DRI driver, so it's not DRMs fault necessarily. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpPonvV6Wj8t.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
> Current DRM CVS HEAD doesn't work for me. However it does work with a > small patch applied: > https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 > > Does it make sense to test that DRM code with the new X patch? You mean the DRM without my old patch doesn't work ? What was the symptom ? lockups ? So it worked in the short period of time when my old patch was in and broke when it was backed off right ? That's interesting... In that case I would have expected my new patch to work but you say you still have lockups. Can you try all combinations of my old patch, new patch, X patch & !X patch and let me know what the results are ? Thanks, Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
On Mon, 2006-02-13 at 11:53 -0800, Donnie Berkholz wrote: > Kevin Shanahan wrote: > > All seems good. No regressions on my Radeon Mobility M6 LY and Radeon > > 64MB DDR (7200). VT switch problems from #2 now fixed. Radeon 9800 Pro > > still locks up with 3D, but that's not a regression. > > I just had some trouble with VT switching -- when switching back to X, I > lost my cursor and a small black "minify" box appeared near the lower > right of my screen (perhaps where the cursor was when I switched VTs?). XAA or EXA ? Is this reproduceable ? Will the cursor go back to normal when changed again by a program ? Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5883] New: "Unable to reserve mem region" on $modprobe r128 (Open GL apps crash)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5883 Summary: "Unable to reserve mem region" on $modprobe r128 (Open GL apps crash) Product: DRI Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Overview: dmesg reports "Unable to reserve mem region" for ATI Rage 128 Pro. OpenGL Apps crash or freeze. To Reproduce: 1) modprobe r128 2) startx 3) Start one of various OpenGL apps Actual Results (all reproducible everytime): 1) Module loads, but dmesg reports error - see below. 2) Works. 3) App crashes (example a) or freezes (b) or works (c) a) game gltron: exits on selection of new game, output: Rage 128 timed out... b) game Privateer Gemini Gold: Whole system freezes c) glxgears: runs with ~1000fps Expected Results: 3a,b) should run, as it does without DRI. My Software: Linux Mandriva 2006 kernel 2.6.11 xorg 6.9.0 DRI snapshot 06-Feb-2006 My Hardware: PC, ATI Rage 128 Pro AGP 4x Diagnostical output: dmesg: [drm] Initialized drm 1.0.1 20051102 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 [drm] Initialized r128 2.5.0 20030725 on minor 0: [drm] Used old pci detect: framebuffer loaded agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 1x mode agpgart: Putting AGP V2 device at :01:00.0 into 1x mode -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-14 09:37]: > > > Current DRM CVS HEAD doesn't work for me. However it does work with a > > small patch applied: > > https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 > > > > Does it make sense to test that DRM code with the new X patch? > > You mean the DRM without my old patch doesn't work ? What was the > symptom ? lockups ? So it worked in the short period of time when my old > patch was in and broke when it was backed off right ? If revision 1.71 of radeon_cp.c was the only change that was backed off, then yes, in worked with your old patch. When the single radeon_cp.c change was backed off, my screen got garbled on X startup and the machine locked up hard. > That's interesting... In that case I would have expected my new patch to > work but you say you still have lockups. As I said in my other mail, it's quite likely that the lock up was introduced by bad Mesa code. > Can you try all combinations of my old patch, new patch, X patch & !X > patch and let me know what the results are ? If it's perfectly stable with your latest patch and without that one bad Mesa patch, would that convince you it's not a bug in DRM/DDX? :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgppYIKlwVPwa.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
> > Can you try all combinations of my old patch, new patch, X patch & !X > > patch and let me know what the results are ? > > If it's perfectly stable with your latest patch and without that one bad > Mesa patch, would that convince you it's not a bug in DRM/DDX? :) Well, I'm navigating between lots of conflicting reports so yes, any "solid" data like that would be very useful. Also, is it stable if not using 3d ? Thanks, Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On 2/13/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Mon, 13 Feb 2006, Adrian Bunk wrote: > > > > The one thing I have not yet been proven wrong for is that this PCI id > > is the only one we have in this driver for an RV370. > > It definitely is an RV370, you're right in that. I'm too lazy to actually > see if the other entries that claim to be RV350's really are RV350's. > Well a while back, I hacked in the pci id for my Xpress 200M (5955), which is basically an RV370 with no dedicated vram. I did the same thing and claimed an RV350, which is the closest model. This allowed the radeon module to load. When I startx'ed and DRI was allowed to load on it, it locked up. So I never sent in the patch. I believe the person who sent this one in originally seemed to indicate that it worked, and I believed it if he had an X300 and my problem was having the IGP version. But now having this reported, I'm pretty sure it is the same problem. RV370 doesn't seem to work as an RV350. Jesse --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
Am Montag, den 13.02.2006, 16:27 -0700 schrieb Jesse Allen: > On 2/13/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, 13 Feb 2006, Adrian Bunk wrote: > > > > > > The one thing I have not yet been proven wrong for is that this PCI id > > > is the only one we have in this driver for an RV370. > > > > It definitely is an RV370, you're right in that. I'm too lazy to actually > > see if the other entries that claim to be RV350's really are RV350's. > > > > Well a while back, I hacked in the pci id for my Xpress 200M (5955), > which is basically an RV370 with no dedicated vram. I did the same > thing and claimed an RV350, which is the closest model. This allowed > the radeon module to load. When I startx'ed and DRI was allowed to > load on it, it locked up. So I never sent in the patch. I believe > the person who sent this one in originally seemed to indicate that it > worked, and I believed it if he had an X300 and my problem was having > the IGP version. But now having this reported, I'm pretty sure it is > the same problem. RV370 doesn't seem to work as an RV350. The Xpress200 chips have a completely different GART implementation. Thus the driver can't even send commands to the command processor and that's why X locked up on you when DRI was enabled. This has nothing to do with the Xpress200 being (almost) an RV370 or not. Regards, Felix -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
