Red Hat Bugzilla – Bug 157665
Auto-loading of radeon module causes stall
Last modified: 2007-11-30 17:11:06 EST
Description of problem: When the X server is required to load the 'radeon' module by itself it stops dead shortly after a successful load. The machine only responds to Ctrl-Alt-Del. Logging into the machine via the network, killing X and resetting the hardware (video_post) gets things back to normal though. Problem did not exist in previous release. From xorg-x11-6.8.2-1.FC3.13: *snip* (II) RADEON(0): Dynamic Clock Scaling Disabled drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEON(0): [drm] loaded kernel module for "radeon" driver (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0b82000 (II) RADEON(0): [drm] mapped SAREA 0xe0b82000 to 0xb3ecd000 (II) RADEON(0): [drm] framebuffer handle = 0x98000000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000207 [AGP 0x8086/0x3340; Card 0x1002/0x4c66] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x00000001 (II) RADEON(0): [agp] ring handle = 0xb0000000 (II) RADEON(0): [agp] Ring mapped at 0xb3dcc000 (II) RADEON(0): [agp] ring read ptr handle = 0xb0101000 *snip* From xorg-x11-6.8.2-30: *snip* (II) RADEON(0): Dynamic Clock Scaling Disabled drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEON(0): [drm] loaded kernel module for "radeon" driver (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0b82000 (II) RADEON(0): [drm] mapped SAREA 0xe0b82000 to 0xb3ed0000 (II) RADEON(0): [drm] framebuffer handle = 0x98000000 (II) RADEON(0): [drm] added 1 reserved context for kernel It then stops here. How reproducible: Every time.
Please attach your complete X server log, config file, and /var/log/messages from after triggering this. Be sure to include all Xorg.*.log* files including the .old ones. Setting status to NEEDINFO.
Created attachment 114954 [details] Xorg.0.log Xorg log from when the server stops.
Created attachment 114955 [details] Xorg.0.log.old Xorg log from when the server functions fine (radeon loaded before start).
Created attachment 114956 [details] messages from the two runs above.
Created attachment 114957 [details] xorg.conf
The config file attached here shows unnecessary options present in the config file. In general, you should never specify the AGPMode in the config file, however if it is specified, it *must* match exactly, the AGP mode set in the BIOS CMOS settings. On many computers the CMOS does not permit changing the AGP mode, in which case you must not specify this option at all. Using this option incorrectly can result in system instability and lockups. In addition, the following 3 options are experimental, and should not generally be used: Option "EnablePageFlip" "True" Option "RenderAccel" "true" Option "backingstore" "true" It is highly recommended to use the default config file generated by "system-config-display --reconfig" as is for the highest level of system stability. Since this bugzilla report was filed, there have been several major updates to the X Window System, which may resolve this issue. Users who have experienced this problem are encouraged to upgrade to the latest Fedora Core xorg-x11 updates by running: yum update If this issue turns out to still be reproduceable in the latest version of Fedora Core with all updates applied, and the system fully rebooted, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to "ERRATA".