| Summary: | Unable to use radeon driver with ATI Radeon xPRESS 200M | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Samuele Kaplun <kaplun> | ||||
| Component: | Driver/Radeon | Assignee: | Eric Anholt <eric> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | lowest | CC: | alexdeucher, dulles, eric, hyu, johnp, jthorn, manlix, michel, tavisbarr, vd | ||||
| Version: | 6.8.99.15 | Keywords: | have-backtrace | ||||
| Hardware: | x86 (IA32) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 1690 | ||||||
| Attachments: |
|
||||||
|
Description
Samuele Kaplun
2005-07-26 02:04:31 UTC
Please try again with the version of the radeon driver from cvs. It turns out XPRESS chips are more like RV3xx chips than RS3xx. I've had several users confirm the driver now works. Alternatively you can try adding this line to your existing driver config to force the driver to use an RV370 chip id. chipid 0x5B60 I'm not able to try CVS due to a compilation failure because I had to mix up Gentoo host.def with the one indicated on X.org site. (Gentoo makes heavy personalisation and I run an amd64 with mutlilib on, so by now I had to stick with their config) So I'm going to compile the Gentoo provided package which is version 6.8.99.15 and I'll try with the line you indicated. I've tried the latest snapshot with the ChipID indicated by you. Drm don't work (Radeon kernel module doesn't recognize my card). X eventually start, but with a black screen. *** Bug 3291 has been marked as a duplicate of this bug. *** My laptop has similar problems. With a Radeon XPRESS 200M, X loads "gdm" good and well, but the system freezes completely (no mouse, keyboard, screen frozen) when it tries to load either gnome or kde. A "gnome failsafe session" works fine. I'm running Debian Unstable's xserver-xorg-6.8.2.dfsg.1-6 package. Please advise if I ought to file a seperate bug report, or for log data. (I'm new to bug tracking systems) --dulles I ought to mention: vesa doesn't cause this crash. fglrx has problems of its own for me (locks out my keyboard!). The crash is /hard/ - i can't ssh in to fix it. (In reply to comment #5) > My laptop has similar problems. With a Radeon XPRESS 200M, X loads "gdm" good > and well, but the system freezes completely (no mouse, keyboard, screen frozen) > when it tries to load either gnome or kde. A "gnome failsafe session" works fine. > > I'm running Debian Unstable's xserver-xorg-6.8.2.dfsg.1-6 package. > > Please advise if I ought to file a seperate bug report, or for log data. (I'm > new to bug tracking systems) > --dulles You need to use Xorg from cvs. My originial patch (which is probably what debian picked up if they support your chip out of the box) set the chips up incorrectly. You can also try adding the following line to your device config to force the chipid: chipid 0x5B60 You might also try other rv3xx chipids. Thanks, using the provided ChipID lets me now start the server on this Xpress200M 5955 on a Compaq Presario V2000Z (V2311US), before problem was as described by the reporter of this bug. *** Bug 3227 has been marked as a duplicate of this bug. *** FYI Ubuntu applies this patch:
--- xc/programs/Xserver/hw/xfree86/drivers/ati.orig/radeon_driver.c
2005-09-20 17:41:44.000000000 +1000
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2005-09-20
17:45:14.000000000 +1000
@@ -4062,8 +4062,21 @@
{
#ifdef XFree86LOADER
RADEONInfoPtr info = RADEONPTR(pScrn);
+ int noaccel = FALSE;
- if (!xf86ReturnOptValBool(info->Options, OPTION_NOACCEL, FALSE)) {
+ /* Screen-to-screen copies and solid fills lock up badly on these chipsets
+ * at least, so disable acceleration there by default since XAA doesn't
+ * really buy anything else useful except a lot of framebuffer reads.
+ * -daniels, 2005-09-20 */
+ if ((info->Chipset == PCI_CHIP_RS400_5A42 ||
+ info->Chipset == PCI_CHIP_RC410_5A62 ||
+ info->Chipset == PCI_CHIP_RS480_5955 ||
+ info->Chipset == PCI_CHIP_RS482_5975) &&
+ info->IsMobility) {
+ noaccel = TRUE;
+ }
+
+ if (!xf86ReturnOptValBool(info->Options, OPTION_NOACCEL, noaccel)) {
int errmaj = 0, errmin = 0;
info->xaaReq.majorversion = 1;
*** Bug 3227 has been marked as a duplicate of this bug. *** (In reply to comment #10) > FYI Ubuntu applies this patch: > > --- xc/programs/Xserver/hw/xfree86/drivers/ati.orig/radeon_driver.c > 2005-09-20 17:41:44.000000000 +1000 > +++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2005-09-20 > 17:45:14.000000000 +1000 > @@ -4062,8 +4062,21 @@ > { > #ifdef XFree86LOADER > RADEONInfoPtr info = RADEONPTR(pScrn); > + int noaccel = FALSE; > > - if (!xf86ReturnOptValBool(info->Options, OPTION_NOACCEL, FALSE)) { > + /* Screen-to-screen copies and solid fills lock up badly on these chipsets > + * at least, so disable acceleration there by default since XAA doesn't > + * really buy anything else useful except a lot of framebuffer reads. > + * -daniels, 2005-09-20 */ > + if ((info->Chipset == PCI_CHIP_RS400_5A42 || > + info->Chipset == PCI_CHIP_RC410_5A62 || > + info->Chipset == PCI_CHIP_RS480_5955 || > + info->Chipset == PCI_CHIP_RS482_5975) && > + info->IsMobility) { > + noaccel = TRUE; > + } > + > + if (!xf86ReturnOptValBool(info->Options, OPTION_NOACCEL, noaccel)) { > int errmaj = 0, errmin = 0; > > info->xaaReq.majorversion = 1; I haven't looked at ubuntu's xorg source, but this may be a work around for that fact that I initially added the xpress chips as IGP variants which was wrong. CVS should just work. I've got at least one user confirming the original segfault with RC2. With the latest rc version, X still segfaults for me. *** Bug 5234 has been marked as a duplicate of this bug. *** Also, backing the ATI driver out through 20050915 hasn't affected the problem, which is new to me between then and now I'm pretty sure. Caveat: I'm using a modular server, which makes me uneasy. However, other reports have been monolithic. (In reply to comment #16) > Also, backing the ATI driver out through 20050915 hasn't affected the problem, > which is new to me between then and now I'm pretty sure. Caveat: I'm using a > modular server, which makes me uneasy. However, other reports have been monolithic. > I suspect ati may have changed their bios format at some point. Unforunately, we have no documentation as to what may be different. possibly they just added a new monitor type (maybe component TV-out), or perhaps they re-arranged the order. I've seen several other reports of users of newer ati chips (newer r3xx and r4xx) having problems with monitor detection detecting either the wrong monitor type or no monitor. Created attachment 4017 [details] [review] radeon-ddctype-sanity.diff My previous debugging which was based on "does it crash or not?" was basically bogus because it was compiler/CFLAGS/phase-of-moon dependent. Remember, kids, reading past the end of an array is undefined. Attaching a patch to avoid using a DDC value from the BIOS that we don't understand. This is taken from a previous DDCType read from BIOS for a different case (line 243). I suspect the value is actually legit, since it happens to be 1 past the values we know about. The laptop has a VGA out and RCA out port, if anyone finds that relevant. While in the area, I noticed DDCType sometimes getting set to DDC_NONE -- an enum from vbe/vbe.h -- when it looks like DDC_NONE_DETECTED from radeon_probe.h is what was wanted. DDC_NONE is the same value as radeon's DDC_MONID. This is also fixed in the patch. Nominate as blocker, since it's clearly hurting a lot of people. *** This bug has been marked as a duplicate of 1690 *** Oops. I can use bugzilla, honestly. Looks good to me. Hui, can you take a look as well? Comment on attachment 4017 [details] [review] radeon-ddctype-sanity.diff approved, pending me testing it. i'll take checking this in. applied, thanks |
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.