Summary: | 180 second hang on boot, DRM doesn't seem to initialize (firmware issue?) | ||||||
---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Owen Riddy <owen.riddy> | ||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | medium | CC: | jrnieder | ||||
Version: | unspecified | ||||||
Hardware: | x86 (IA32) | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
Owen Riddy
2011-02-18 14:01:20 UTC
Make sure you have the firmware in your initrd if you are using modules, or built into the kernel if you built radeon into the kernel rather than as a module. See the "Troubleshooting Extra Firmware" section of this page: http://wiki.x.org/wiki/radeonBuildHowTo Comparing the initrd of 2.6.37 and 2.6.32 show they are both the same, and neither of them have any firmware in them. They didn't actually have the radeon module at all. I compared /lib/firmware to the git repository http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git , everything matched (I checked with md5sum) except the newer BARTS/CAICOS/BTC/PALM/SUMO/TURKS firmware which I assume is all later than my card. I tried to force update-initramfs to include the radeon kernel modules by listing it in /etc/initramfs-tools/modules, but this caused the update-initramfs to hang when loading radeon.ko in. Rather than try to insert everything manually in my initrd, I blacklisted radeon in /etc/modeprobe.d and modprobe'd it in after a complete boot to a virtual terminal. On my old kernel, this worked swimmingly (no radeon in lsmod, module loaded nicely). On the debian stock kernel modprobe hangs, I stopped timing after ten minutes, the screen doesn't resize as usual for KMS, lsmod lists radeon/drm/drm_kms_helper. dmesg again shows only RS780 Microcode being loaded. :/ Sorry, my last paragraph was a little ambigous. On my old debian 2.6.32 kernel, this worked swimmingly (module loaded nearly instantly, screen resolution jumped up). On the debian 2.6.37 kernel modprobe hangs, I stopped timing after ten minutes, the screen doesn't resize as usual for KMS but lsmod lists radeon/drm/drm_kms_helper. dmesg again shows only RS780 Microcode being loaded. In each case, before starting, I checked with lsmod to make sure radeon was not loaded. Since my last comment, I also checked Ubuntu 10.10 (2.6.35), and it has graphics issues as well - it is much harder to see what is happening because plymouth gives me a blank screen, but it also has a modprobe timeout, apparently no KMS loading, and firmware seems to be available in /lib/firmware. (In reply to comment #4) > [ 4.414321] radeon 0000:01:05.0: WB enabled Does passing the parameter no_wb=1 to the radeon kernel module help? Alternatively, does disabling the integrated RS780 GPU work around the problem? > Does passing the parameter no_wb=1 to the radeon kernel module help? It doesn't seem to help. `dmesg | grep WB` shows it as Disabled, but modprobe still hangs on load at the RS780 firmware. > Alternatively, does disabling the integrated RS780 GPU work around the problem? Works. With the RS780 GPU disabled, everything functions. BIOS -> Advanced Chipset Features -> Surround View -> [Disabled], KMS works, no modprobe hang. I didn't know that that card could be switched on and off. Thanks :) Owen, can you bisect? Just trying a few intermediate versions from http://snapshot.debian.org/ would already be useful. For narrowing down the regression range beyond that, "git bisect" can help: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux git bisect start -- drivers/gpu/drm/radeon git checkout (bad version) make localmodconfig; # minimal configuration make -j2 deb-pkg dpkg -i ../(package).deb reboot # confirm that it is actually bad git bisect bad git checkout (good version) make silentoldconfig; # reuse configuration make -j2 deb-pkg dpkg -i ../(package).deb reboot # confirm that it is good git bisect good # now it checks out an intermediate version to test make silentoldconfig make -j2 deb-pkg dpkg -i ../(package).deb reboot git bisect bad; # if it hangs in the same way git bisect good; # if it boots correctly git bisect skip; # if some other problem makes it hard to test ... rinse and repeat ... git bisect visualize; # to watch the regression range narrowing git bisect log; # to summarize partial results if you get bored This problem was resolved a couple of kernel updates ago. |
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.