Hide Forgot
Dell Dimension 4600 with a Radeon 9800 128MB ram During installation, tries to start radeon, fails, falls back to vesa. After install, using radeon driver works if I tweak the XF86Config with a new Chip Id. The device is seen as: 01:00.0 Class 0300: 1002:4e48 Subsystem: 1002:3002 Flags: stepping, 66Mhz, medium devsel, IRQ 16 Memory at f0000000 (32-bit, prefetchable) [size=128M] I/O ports at de00 [size=256] Memory at fe9e0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at fea00000 [disabled] [size=128K] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 01:00.1 Class 0380: 1002:4e68 Subsystem: 1002:3003 Flags: bus master, stepping, 66Mhz, medium devsel, latency 64 Memory at e8000000 (32-bit, prefetchable) [size=128M] Memory at fe9f0000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350 [Radeon 9800] 01:00.1 Display controller: ATI Technologies Inc Radeon R350 [Radeon 9800] (Secondary) The problem is that, although the radeon driver works with this chipset, it doesn't recognize its ID because the 9800 chipset isn't on the whitelist of supported hardware. If I put: ChipId 0x4e45 in XF86Config (which according to Google is a Chip ID for a 9700) then it works....
I've just backported the latest support from CVS for all XFree86.org known ATI Radeon/FireGL hardware. The latest updates are provided by the following two patches in XFree86 4.3.0-36, and will appear in rawhide soon. XFree86-4.3.0-Xserver-xf86PciInfo-updates.patch XFree86-4.3.0-radeon-support-backport-from-CVS.patch Yet to be done, is to take the latest PCI ID list from ATI, plus their Catalyst drivers Windows .INF file PCI ID's, then apply a couple new patches for new hardware coming out, then verify the billion locations where these all show up in the driver/Xserver/pcitable/yadayada. ;o) Please test 4.3.0-36 and let me know if it works for you, and if it is autodetected by r-c-x properly. Thanks Chris
*** Bug 105962 has been marked as a duplicate of this bug. ***
Chris is out of town this week, so I'll test this out and report.
Thanks Dax. RPMS are on my people.redhat.com ftp space under testing/unstable 4.3.0-36
I tried out -37. The Xserver would start without having to add the ChipId line. Cool! Problem I saw though, the console (whole machine maybe??) locked up while the GNOME desktop was still loading. I couldn't do a CTL-ALT-F1 to get a text terminal. That was with a fully up2date (I subscribed the machine to the beta updates channel) with the exception of the kernel. Anyways, I did this testing 10 mins before I had to leave to catch a 18 hour plane ride to Australia to teach a class. Sorry I didn't have a chance to chase down the lockup. I won't be back until next week, but Chris will be back this week (starting Monday). Speaking of which I'm +16 hours from my normal time zone (MST), so my Monday is almost done.
I also am seeing this lockup (though in -40), both on AMD64 and i386 RHEL3 final, running the Fedora XFree86 RPMs.
I'm closing this, since it works w/o Chip Id now....