Re: 2.6.16-rc3: more regressions
Module Size Used by appletalk 27696 2 ax25 45784 2 ipx21164 2 radeon 94112 0 this of course on 2.6.15, since 2.6.16 completely hangs, and no other info can be gathered. BTW, modprobe-ing radeon.ko (no Xorg started), 2.6.16-rc1 stays up and this is dmesg: ... snip ... ACPI: PCI Interrupt :04:00.0[A] - GSI 16 (level, low) - IRQ 16 [drm] Initialized radeon 1.21.0 20051229 on minor 0 ... snip ... then, as soon as Xorg is started, the system hangs. Mauro --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On Mon, 13 Feb 2006, Adrian Bunk wrote: Date: Mon, 13 Feb 2006 19:34:45 +0100 From: Adrian Bunk [EMAIL PROTECTED] To: Linus Torvalds [EMAIL PROTECTED] Cc: Dave Jones [EMAIL PROTECTED], Andrew Morton [EMAIL PROTECTED], Linux Kernel Mailing List linux-kernel@vger.kernel.org, Mauro Tassinari [EMAIL PROTECTED], [EMAIL PROTECTED], dri-devel@lists.sourceforge.net Subject: 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 The X300 has two pci ids: :05:00.0 0300: 1002:5b60 :05:00.1 0380: 1002:5b70 :05:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] :05:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
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 The X300 has two pci ids: :05:00.0 0300: 1002:5b60 :05:00.1 0380: 1002:5b70 :05:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] :05:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] Gerhard This particular pci express card is commercialized as ASUS EXTREME AX 300 SE-X/TD/128 MB DDR TV OUT DVI has the following: 04:00.0 Class 0300: 1002:5b60 04:00.1 Class 0380: 1002:5b70 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 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, cache line size 04 Interrupt: pin A routed to IRQ 0 Region 0: Memory at d800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at e000 [size=256] Region 2: Memory at d7fe (32-bit, non-prefetchable) [size=64K] Expansion ROM at d7fc [disabled] [size=128K] 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- Capabilities: [58] #10 [0001] Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: Data: 04:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] Subsystem: ASUSTeK Computer Inc.: Unknown device 002b Flags: bus master, fast devsel, latency 0 Memory at d7ff (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Capabilities: [58] #10 [0001] It does indeed work with dri disabled in xorg.conf, as explained by Dave Airlie in previous post. the only modules loaded starting xorg are: Module Size Used by appletalk 27696 2 ax25 45784 2 ipx21164 2 radeon 94112 0 this of course on 2.6.15, since 2.6.16 completely hangs, and no other info can be gathered. Mauro --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On 2/13/06, Felix Kühling [EMAIL PROTECTED] wrote: Am Montag, den 13.02.2006, 16:27 -0700 schrieb Jesse Allen: 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. Well, I did not know about the GART problem. So this means that RV370s and XPRESS will be listed both separately in the driver in the future? They certainly don't function as an RV350 and of course they aren't quite compatable then. 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=lnkkid3432bid#0486dat1642 -- ___ 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=lnkkid=103432bid=230486dat=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=lnkkid=103432bid=230486dat=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=lnkkid3432bid#0486dat1642 -- ___ 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=lnkkid=103432bid=230486dat=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, 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=lnkkid=103432bid=230486dat=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: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=lnkkid=103432bid=230486dat=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=lnkkid=103432bid=230486dat=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=lnkkid=103432bid=230486dat=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=lnkkid3432bid#0486dat1642 -- ___ 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=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
