Bug 13158 - X uses fbdev instead of radeon for rv200 unless modprobe radeon before starting X
Summary: X uses fbdev instead of radeon for rv200 unless modprobe radeon before starti...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-07 08:20 CEST by Felix Miata
Modified: 2014-07-30 08:41 CEST (History)
3 users (show)

See Also:
Source RPM: kernel-desktop-3.13.9-1.mga5
CVE:
Status comment:


Attachments
gfx hwinfo/lsmod/Xorg.0.log without modprobe radeon (36.21 KB, text/plain)
2014-04-07 08:20 CEST, Felix Miata
Details
Xorg.0.log after modprobe radeon (61.10 KB, text/plain)
2014-04-07 08:21 CEST, Felix Miata
Details
lspicdrake -v (3.15 KB, text/plain)
2014-04-13 20:23 CEST, Felix Miata
Details

Description Felix Miata 2014-04-07 08:20:05 CEST
Created attachment 5102 [details]
gfx hwinfo/lsmod/Xorg.0.log without modprobe radeon

Initial summary:
X uses fbdev instead of radeon for rv200 unless modprobe radeon before starting X

Also happens with kernel 3.12.8. openSUSE 13.1's 3.11.10 and Rawhide's 3.15.rc0 do not require manually modprobing the radeon kernel driver for X to use the radeon X driver for rv200. This manual intervention for Cauldron's X to use the optimal driver should not be required.
Comment 1 Felix Miata 2014-04-07 08:21:37 CEST
Created attachment 5103 [details]
Xorg.0.log after modprobe radeon

Note lspci -v and lsmod output have been prepended.
Manuel Hiebel 2014-04-08 17:51:15 CEST

CC: (none) => anssi.hannula, thierry.vignaud, tmb

Comment 2 Thomas Backlund 2014-04-13 19:20:10 CEST
Can you attach output of lspicdrake -v
Comment 3 Felix Miata 2014-04-13 20:23:46 CEST
Created attachment 5115 [details]
lspicdrake -v
Comment 4 Anssi Hannula 2014-04-13 20:40:45 CEST
Enable debugging of the display driver helper:
# sed -i "s,^# DEBUG,DEBUG," /sbin/display_driver_helper

then reboot, and when X loads up with the wrong driver, attach /dev/ddh_debug.
Comment 5 Felix Miata 2014-04-13 21:38:47 CEST
display_driver_helper was nowhere to be found on host m7ncd's Cauldron / filesystem. drakx-kbd-mouse-x11 was not installed. X uses radeon fully automatically since installing it.

Rawhide with 3.15.rc0 and openSUSE with 3.11.10 load radeon long before graphical.target is reached, and neither have display_driver_helper. Why does Cauldron need this? If it's truly needed, why didn't whatever depends on it have it pulled in automatically when it was installed?

cf. https://lists.fedoraproject.org/pipermail/devel/2014-April/197399.html
Comment 6 Anssi Hannula 2014-04-13 22:59:53 CEST
display_driver_helper is used to avoid loading radeon driver when a proprietary driver or a generic vesa driver is configured.

I guess we should
a) modify the udev rule to always load the driver so that if drakx stuff is not installed (and make sure the proprietary drivers depend on the drakx stuff if they don't already), or
b) move display_driver_helper to some package in basesystem.

To test (a), edit /lib/udev/rules.d/80-drivers.rules from:
SUBSYSTEM=="pci", ATTR{class}=="0x03*", DRIVER!="?*", TEST=="/initrd", RUN+="/sbin/display_driver_helper --load $env{MODALIAS}", GOTO="drivers_end"
to:
SUBSYSTEM=="pci", ATTR{class}=="0x03*", DRIVER!="?*", TEST=="/sbin/display_driver_helper", TEST=="/initrd", RUN+="/sbin/display_driver_helper --load $env{MODALIAS}", GOTO="drivers_end"

I'm not immediately sure whether (a) or (b) is the right way to go, though... Thomas, any opinion?
Comment 7 Felix Miata 2014-04-13 23:37:19 CEST
My 80-drivers.rules contains nothing I can spot that is like what you want to change from:

# do not edit this file, it will be overwritten on update

ACTION=="remove", GOTO="drivers_end"

ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}"
SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", RUN{builtin}="kmod load tifm_sd"
SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", RUN{builtin}="kmod load tifm_ms"
SUBSYSTEM=="memstick", RUN{builtin}="kmod load ms_block mspro_block"
SUBSYSTEM=="i2o", RUN{builtin}="kmod load i2o_block"
SUBSYSTEM=="module", KERNEL=="parport_pc", RUN{builtin}="kmod load ppdev"
KERNEL=="mtd*ro", ENV{MTD_FTL}=="smartmedia", RUN{builtin}="kmod load sm_ftl"

LABEL="drivers_end"
Comment 8 Anssi Hannula 2014-04-13 23:43:15 CEST
Are you sure you didn't accidentally check on a non-Mageia system?

There should be Mageia-specific stuff below the ACTION=="remove" line.

I've verified that systemd-208-14.mga5.x86_64 does contain the lines.
Comment 9 Felix Miata 2014-04-14 00:25:19 CEST
(In reply to Anssi Hannula from comment #8)
> Are you sure you didn't accidentally check on a non-Mageia system?

That is what I had done. :-p

I made the comment 6 edit, renamed display_driver_helper display_driver_helpeR, rebooted, and the radeon kernel driver automatically loaded @[25.480256] (on the 3.13.9-desktop-1.mga5 i686 system).
Comment 10 Felix Miata 2014-05-10 05:24:52 CEST
still a problem with 3.14.3 kernel and x11-driver-video-ati-7.3.0-1
Comment 11 Felix Miata 2014-07-30 08:41:05 CEST
Looks to be fixed on host m7ncd as of 3.15.6 kernel and 7.4.0 driver.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.