| Summary: | fglrx should blacklist the radeon kernel module | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Carl Roth <roth> |
| Component: | fglrx-kmod | Assignee: | Stewart Adam <s.adam> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | fedora, kwizart |
| Priority: | P5 | ||
| Version: | 10 | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| namespace: | |||
|
Description
Carl Roth
2009-02-18 19:09:11 CET
That's exactly how I could have worded things, and why I've forked my own fglrx version. Installing fglrx shouldn't keep compatibly with radeon while this will affect how fgrlx is easy or not to install. Actually, r-c-d will regenerate this blacklist script already (along with the udev creation rule), but while coming from a radeon detected hardware, you cannot have it to work without regenerating the kernel image twice: -One for removing radeon, -Reboot to have fglrx been able to load, then -a second time to add the 40 udev script in the kernel image in order to have fglrx to work. BTW which card do you have ? Can you check that /etc/udev/makedev.d/40-fglrx-dri.nodes is present ? (In reply to comment #1) > Actually, r-c-d will regenerate this blacklist script already (along with the > udev creation rule), but while coming from a radeon detected hardware, you > cannot have it to work without regenerating the kernel image twice: > -One for removing radeon, > -Reboot to have fglrx been able to load, then > -a second time to add the 40 udev script in the kernel image in order to have > fglrx to work. What's this about udev? > BTW which card do you have ? from Xorg.0.log: ATI Technologies Inc R520 [Radeon X1800] (II) fglrx(0): VESA BIOS detected (II) fglrx(0): VESA VBE Version 3.0 (II) fglrx(0): VESA VBE Total Mem: 16384 kB (II) fglrx(0): VESA VBE OEM: ATI ATOMBIOS (II) fglrx(0): VESA VBE OEM Software Rev: 9.12 (II) fglrx(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc. (II) fglrx(0): VESA VBE OEM Product: R520 (II) fglrx(0): VESA VBE OEM Product Rev: 01.00 (II) fglrx(0): ATI Video BIOS revision 9 or later detected > Can you check that /etc/udev/makedev.d/40-fglrx-dri.nodes is present ? > No such file. I forgot about that tweak too, I should have included it in my initial report. I don't know any better at this point so I ended up adding a script into /etc/sysconfig/modules to run MAKEDEV. What driver version do you have installed? Both the udev and blacklist files should be present: $ rpm -ql xorg-x11-drv-fglrx | grep -e modprobe -e udev /etc/modprobe.d/blacklist-radeon /etc/udev/makedev.d/40-fglrx-dri.nodes (In reply to comment #3) > What driver version do you have installed? Both the udev and blacklist files > should be present: > $ rpm -ql xorg-x11-drv-fglrx | grep -e modprobe -e udev > /etc/modprobe.d/blacklist-radeon > /etc/udev/makedev.d/40-fglrx-dri.nodes > xorg-x11-drv-fglrx-8.573-1.9.1.fc9.x86_64 methinks my version may be too old for those files. I only see 8.573-1.9.1 on in the rpmfusion channels (testing, development). I have the same version... Those files should be there on your system: $ wget http://download1.rpmfusion.org/nonfree/fedora/updates/10/x86_64/xorg-x11-drv-fglrx-8.573-1.9.1.fc10.x86_64.rpm $ rpm -qpl xorg-x11-drv-fglrx-8.573-1.9.1.fc10.x86_64.rpm | grep -e modprobe -e udev /etc/modprobe.d/blacklist-radeon /etc/udev/makedev.d/40-fglrx-dri.nodes neat! I hope I never have to go through that again. Here is the chain of events: 1. test out new fglrx on an F9 system. It works, yay! 2. upgrade system in-place to to F10. full install, overwrite the root filesystem, but save /home, /local/spool/yum/cache partitions (hey, why let the yum cache clutter up the root filesystem) 3. install fglrx on the F10 system (the F9 version, still in the yum cache) So yes, the F10 fglrx RPM does have the files I need, thanks. |