Hide Forgot
Description of problem: I have a Thinkpad T500 with switchable graphics. If the switchable graphics mode is enabled the kernel will crash while attempting to load. Version-Release number of selected component (if applicable): How reproducible: Everytime Steps to Reproduce: 1. Enter BIOS > Graphics 2. Set Graphics Mode to Switchable 3. Attempt to boot into Fedora 15 Actual results: Kernel Crashes and computer never loads Expected results: Fedora boots regularly Additional info: The system boots fine if you set the graphics to either Discrete or Integrated. Just setting it to Switchable causes it to crash. Did not occur in F-14
if the kernel crashes, it's not the fault of udev.
I have got the same problem on a Thinkpad T400. My internal graphics chip is the usual intel one and the descrete chip is a ATI Technologies Inc Mobility Radeon HD 3400 Series I addition the fan of the Notebook is very noisy if I boot it up with the descrete graphics chip activated in the BIOS. The system boots with the old Fedora 14 kernel.
I have got the same problem on my Thinkpad T400 with "Switchable" graphics enabled in the BIOS too. If I try to boot with "intel" or "radeon" driver the boot fails (when launching the xserver i think). Booting with "vesa" (in xorg.conf) is working. There is no splash screen while booting and after the boot hangs and you can still login by switching to "Ctrb+Alt+F2". There is also no "/sys/kernel/debug/vgaswitcheroo/" directory like it should be, since vga_switcheroo was added to the kernel 2.6.34.
I have a Lenovo T500 laptop with Intel integrated graphics and Radeon discrete graphics. vgaswitcheroo works fine with Fedora 14, at least for the one time i tried it. Botting with the latest Fedora 15 kernel fails if the BIOS configures the graphics in "switchable" mode. It works fine if either the integrated Intel chip or the discrete Radeon chip is selected in the BIOS. I can't catch the complete kernel crash message because the notebook does not have a serial ine and i didn't have the time to recompile a kernel with compiled in network and netconsole support, which i hope is initialized *before* the KMS magic start.
can you try booting with nomodeset?, then ssh in, rmmod i915 radeon ; modprobe i915 modeset=1 ; modprobe radeon modeset=1 you might get the dmesg then. I'll see if I can grab a machine tomorrow to test it.
Tried this two times: try 1: Booted with nomodeset kernel cmd line. removed both the i915 and radeon modules modprobe i915 modeset=1 works flawless, screen is switched to smaller font, can start X modprobe radeon modeset=1 works, can power off the the radeon chipset using vga_switcheroo sys debug file try2: Booted with nomodeset kernel cmd line. removed both the i915 and radeon modules modprobe radeon modeset=1 screen still has the large font. pressing Return in the console does not change anything (i hoped the shell prompt scrolls into view). shows no errors in the dmesg output (logged in via ssh, because screen is unusable) is suspect some unhealthy interaction with vga_switcheroo during boot. Maybe the kernel video drivers are initialized before vga_switcheroo. I'm prepared to do some debugging using netconsole, but have to wait until i'm home again, because there's no ethernet LAN where i am now.
Created attachment 509712 [details] radeon init fault on lenovo T500 switchable graphics enabled Captured the boot kernel messages using netconsole. I guess the second fault is is a follow up error. I also saw a radeon ringbuffer overflow error [ 4.789369] radeon 0000:01:00.0: IH ring buffer overflow (0xFFFFFFFF, 0, 15)
Created attachment 509719 [details] dmesg output if only radeon card is enabled in BIOS Enabled only the discrete graphics in the BIOS config section. Machine boots up with no problems. Attached the dmesg output of a successful boot.
*** Bug 698511 has been marked as a duplicate of this bug. ***
Seems like MSI interrupt allocation or handling does not work in this case and the driver overflows the ringbuffer.
Created attachment 509889 [details] dmesg when booting with rdblacklist=radeon Starting kernel with rdblacklist=radeon. Modeswiching works, vgaswitcheroo works and let me poweroff the radeon card. # cat /sys/kernel/debug/vgaswitcheroo/switch 0:DIS: :Off:0000:01:00.0 1:IGD:+:Pwr:0000:00:02.0 I added some debugging printk. Don't be confused.
Created attachment 509890 [details] dmesg when booting with rdblacklist=i915 Booting with rdblacklist=i915. vgaswitchero works and let me poweroff the radeon card. # cat /sys/kernel/debug/vgaswitcheroo/switch 0:DIS: :Off:0000:01:00.0 1:IGD:+:Pwr:0000:00:02.0 I noticed that the screen is unusable after the radeon modeswitching kicks in. The screen is restored to higher resolution later. I guess the i915 driver is doing the modeswitch, but I'm not sure about it.
The rdblacklist=radeon kernel command line only works from time to time. Seems to be a timing issue.
I also had this problem, but this becae very rare with more recent kernels aka. 2.6.40/3.0 under Fedora 15.
Is this still hapening to someone?
I updated to Fedora 16 beta on the machine where I saw this and the problem did not exist there.
Sorry for responding so late, but i have been away from notebook. Just upgraded to Fedore 16 with all updates and problem still persists. But i found out one more fact. The T500 has a display port adapter, which is only usable with the radeon card and i have a monitor attached to it. So i can check if the radeon card is active during boot. What i observed multiple times is, that the kernel crashes if the boot screen is displayed on the externel monitor (rendered by the radeon card) but did not crash if the bootscreen is rendered on the notebook screen. Maybe this observation helps.
Finally i got around to look into this problem again. After upgrading to F16 and updating to the newest kernel release, the bug moved into another area. It's not udev anymore causing the error, but plymouth. I also got the chance to connect a monitor to the display port video output.On the T500 the display port can only be used by the radeon card. What i observed is that the plymouth boot logo appears on the monitor every time the kernel crashes afterwards. radeon.modeset=0 on the kernel command line reliably prevented the kernel to crash. the kernel stack shows that the crash is happening in the close() function of the /dev/dri/card0 file. So my conclusion of these facts is: It depends on the order the cards register themselves. If i915 comes first, /dev/dri/card0 is the i915 card and everything works fine. If radeon comes first, /dev/dri/card0 is the radeon card and nothing is displayed during boot on the LVD. The muxer connects the LVD to the i915, but plymouth uses the radeon card for rendering and therefore the boot screen is shown on the monitor connected to the display port. I don't know if the kernel crash caused by plymouth when closing /dev/dri/card0 is because the driver has a bug, plymouth has a bug, or because the card is disconnected from the LVD.
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.