| Summary: | x.org hangs with DRI and r300 | ||
|---|---|---|---|
| Product: | xorg | Reporter: | the_nihilant <the_nihilant> |
| Component: | Driver/Radeon | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | low | CC: | alexej.davidov, benh, christophe.choumert+fdobugs, daf, dmueller, erik-freedesktop-bugzilla, glisse, idr, ilbardo, kilian.cavalotti, mmacleod, sa, viorxus |
| Version: | 7.1 (2006.05) | Keywords: | regression |
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
the_nihilant
2005-10-23 03:53:55 UTC
Reassigning to mesa3d-dev as this appears to be a 3D driver problem. (In reply to comment #1) > Reassigning to mesa3d-dev as this appears to be a 3D driver problem. nope it a 2D driver issue, if X doesn't start its 2D... And if I had to guess I'd just call "ricer" and ask the user to turn off AGPFastWrite and see those the system work then.. (In reply to comment #0) > (II) RADEON(0): PLL parameters: rf=2700 rd=6 min=20000 max=46909632841912; > xclk=20000 Ricer indeed... Not that it matters much but that doesnt look too sane. FYI: What we are seeing at SuSE seems to be the same bug - or at least related: https://bugzilla.novell.com/show_bug.cgi?id=127757 So far we only see this on the ATI Radeon Mobility M10, however, on a couple of different subtypes as it seems. The reports on our side indicate that this bug is not related to acceleration or DRI. However, I have only been able to reproduce with both DRI and acceleration enabled. *** Bug 4486 has been marked as a duplicate of this bug. *** Could this be a dynamic clock gating related driver bug? Try commenting out the calls to RADEONSetDynamicClock(). I can confirm this behaviour. Running Gentoo on amd64 with Xorg7.0RC2 and the r300 drivers from last night's CVS. With this in my xorg.conf, KDM doesn't even appear (not even as far as showing the mouse cursor which is before it paints the wallpaper, etc) it just gives me a blank screen and I have to hit the power button. Section "Device" Identifier "RadeonDriver 0" Driver "radeon" Option "AGPFastWrite" "on" EndSection However, if I comment out FastWrite (since the default is "off") I can enable fancy things like DynamicClocks:on, AGPMode and AccelMethod:exa and glxgears etc all work without issue. Video card is an ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] according to lspci. (In reply to comment #7) > > However, if I comment out FastWrite (since the default is "off") I can enable > fancy things like DynamicClocks:on, AGPMode and AccelMethod:exa and glxgears > etc all work without issue. This is not a bug, certainly not the one this entry is about. You've merely discovered the reason AGP FastWrites are an option that defaults to off. Any progress on this? This bug keeps me from updating to xorg 6.9/7.0. I too have an ATI Radeon Mobility M10 on a Thinkpad T42p. The lock-up occurs regardless of the settings AGPMode, AGPFastWrite, RenderAccel, AccelMethod, or whether DRI is enabled or not. However, with DRI enabled the lock-up always occurs immediately when starting up X. With DRI disabled it will occur some arbitrary time later. The lock-up is complete: no response to keyboard sysrq, network. Not even the NMI watchdog gets activated. Also first starting with the ATI's fglrx driver and then with xorg's radeon driver doesn't help, so it doesn't seem to be an initialisation problem. Have you played with Option "DynamicClocks" and the suggestion from comment #6? I experienced the same issue on an IBM Thinkpad T42p (ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80)), complete lock occurs within seconds with DRI enabled, and within minutes without DRI, and regardless of the DynamicClocks setting. Moreover, a probably interesting experiment, which seems to tighten the problem in the radeon module area: I remarked that my computer locked even when X failed to load. So, I removed font definitions from my xorg.conf, then launched X from VT1, waited for it to fail, and get the "could not load fixed font" fatal error message. Then I waited a little, still in VT1, and the computer locked up all by itself. So it hanged even with X not running anymore, but after radeon module has been loaded. One sure way to speed up things is to use framebuffer device, after X failed (I used links with fb driver to browse the web while compiling X), it locks in a second. I just see Benjamin Herrenschmidt posts on xorg mailing list (http://lists.freedesktop.org/archives/xorg/2005-December/011678.html) about mem map fixes. I didn't try his patches yet. > I just see Benjamin Herrenschmidt posts on xorg mailing list
> (http://lists.freedesktop.org/archives/xorg/2005-December/011678.html) about
> mem map fixes. I didn't try his patches yet.
I tried, on a 2.6.15-rc6. And the lockups are gone. Using DRI, DynClocks,
everything runs smooth for 4 hours now.
Great work!
Just FYI, it seems that forcing "AGPMode" "4" in xorg.conf results in X locks in DRI applications. AGP 2x or 1x does not cause any hang. *** Bug 5997 has been marked as a duplicate of this bug. *** During the course of normal X usage, I'm not experiencing problems with my M10 (Thinkpad T42). $ lspci | grep Radeon 0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] $ glxinfo | grep direct *********************************WARN_ONCE********************************* File r300_state.c function r300Enable line 456 TODO - double side stencil ! *************************************************************************** No ctx->FragmentProgram._Current!! direct rendering: Yes However, I have experienced lockups with BZFlag (intermittent), Xgl (consistent) and the metacity composition manager (consistent). I'm using Xorg 7.0.0 on Ubuntu. I'm not using any fancy options:
Section "Device"
Identifier "ATI Technologies, Inc. Radeon Mobility 9600/9700
M10/M11 (RV350 NP)"
Driver "ati"
BusID "PCI:1:0:0"
EndSection
I think we still doesn't properly setup r3xx card. fglrx does somethings we doesn't. Could you try launch an xserver with fglrx (only 2D DDX no need for fglrx module) quit and then launch your regular xserver/r300 and try apps which usualy cause a lockup for you. You shouldn't experience anymore lockup. I hope to get back on this fglrx analysis soon and hopefuly find what we miss. Might be useful also if you could try the ati driver from CVS HEAD... Not sure if this is related to #4324 but modular CVS HEAD stopped my X from crashing. If you're still having this problem, please try current xf86-video-ati git with radeon DRM >= 1.23. This seems to have been solved for me on Ubuntu Edgy (xorg 7.1.1, I believe). I was able to launch and close glxgears 10-15 times with no problem. Feel free to close. Can the submitter confirm this is fixed? (In reply to comment #22) > Can the submitter confirm this is fixed? it seems fixed (thanks!) Closing the bug :) I've a Mobility Radeon 9700; using standard mesa dri from Ubuntu Edgy it works good... Btw, If I use a newer version of Mesa dri (recompiled from debian unstable or porting the cvs dri section to the ubuntu mesa, or using the cvs), I get the freeze when I load glxinfo/glxgears or any other 3d related app. Xorg.log is ok (exactly like when I run X using standard mesa dri)... Simply I get a blank screen loading any 3d app or a composite manager. (In reply to comment #25) > > Btw, If I use a newer version of Mesa dri (recompiled from debian unstable or > porting the cvs dri section to the ubuntu mesa, or using the cvs), I get the > freeze when I load glxinfo/glxgears or any other 3d related app. That's not the same problem as reported here. Please follow up to a bug that matches your symptoms (which would more likely be in the Mesa r300 driver or the radeon DRM) or file a new one. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.