Red Hat Bugzilla – Bug 596581
KMS does not work well with kexec
Last modified: 2015-11-07 00:47:48 EST
Description of problem:
When I tested kexec-tools, I found KMS doesn't work well with kexec.
My console stucks when the second kernel is being loaded, this problem
disappears after I add "nomodeset" in grub.conf.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum install -y kexec-tools
2. kexec --initrd=/your/initrd -l /your/kernel
3. kexec -e
4. console hangs here
5. reboot the machine manually, add "nomodeset" into kernel commandline in grub
6. repeat step 1-3, you can see the second kernel is booting, no hang.
Console or kexec hangs there.
The second kernel should be loaded successfully and its boot messages should be always displayed.
David, this is a problem of KMS, since adding "nomodeset" makes the problem disappear.
On my machine, upstream kernel 2.6.32, 2.6.33, 2.6.34 all doesn't work if no "nomodeset". FYI.
What hardware is this on?
On Intel box here I can kexec fine under KMS
kexec -l --initrd=/boot/initramfs-2.6.32-dael6.img --reuse-cmdline --args-linux /boot/vmlinuz-2.6.32-dael6
works great for me.
can you try --reset-vga maybe on your hw?
I'll try and test it on some other hw but it would be nice to know what you have.
also tested under radeon, kexec boots fine.
Now we don't have a VGA console to go back to see things, so this isn't a perfect situation, but there isn't really a nice way for graphics drivers to get back to text mode without using the BIOS to reset things, and that is notoriously unreliably. If we want this functionality added to the KMS drivers we probably need to approach upstream about it to see what solution could be worked out.
btw that 2.6.32-dael6 kernel is 2.6.32-30 from git.
(In reply to comment #5)
> What hardware is this on?
> On Intel box here I can kexec fine under KMS
> kexec -l --initrd=/boot/initramfs-2.6.32-dael6.img --reuse-cmdline --args-linux
> works great for me.
I use an AMD x86_64 machine. I also tried an Intel x86_64 machine, got the same result.
> can you try --reset-vga maybe on your hw?
I just tried, nothing on screen. I don't know if kexe is working or not in the background, but displaying nothing is really a bug, I expect to see the boot log of the second kernel.
what graphics hw?
processor info isn't useful here.
Well unless --reset-vga works there isn't anything the driver can really do. We cannot exec bios calls inside the kernel to reset the graphics hw, how does kexec work on things like ppc where nvidiafb/radeonfb etc have been used in the past?
(In reply to comment #8)
> what graphics hw?
> processor info isn't useful here.
01:08.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00 [VGA controller])
Subsystem: Dell PowerEdge T105 Embedded ATI ES1000
Flags: bus master, stepping, fast Back2Back, medium devsel, latency 66, IRQ 19
Memory at d8000000 (32-bit, prefetchable) [size=128M]
I/O ports at 3000 [size=256]
Memory at d0100000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at d0120000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: radeon
Kernel modules: radeon, radeonfb
> Well unless --reset-vga works there isn't anything the driver can really do. We
> cannot exec bios calls inside the kernel to reset the graphics hw, how does
> kexec work on things like ppc where nvidiafb/radeonfb etc have been used in the
Sorry, I have no idea, I just know kexec reboot skips bios.
two possible solutions:
a) build graphics drivers into the kernel, and include all the firmware, this is a major bloat to the kernel (you'd be in the region of > 1MB of text code + firmwares) - not sure this is a starter
b) get back to text mode - this is difficult problem to do without just execing the BIOS which we can't do. It will take a fair bit of upstream work and I'm not sure we can do this in scope for RHEL6.0.
Do we have major customers debugging kexec problems on graphical consoles? as this doesn't break kexec, we just don't see debug from it when it fails to get to the initramfs.
(In reply to comment #10)
> two possible solutions:
> a) build graphics drivers into the kernel, and include all the firmware, this
> is a major bloat to the kernel (you'd be in the region of > 1MB of text code +
> firmwares) - not sure this is a starter
I assume you mean the second kernel when you say "kernel"?
This is not doable, since kdump uses the same kernel. But kdump initrd already includes all firmwares.
> b) get back to text mode - this is difficult problem to do without just execing
> the BIOS which we can't do. It will take a fair bit of upstream work and I'm
> not sure we can do this in scope for RHEL6.0.
Hmm, ok. Since a) is also not doable, we have to append "nomodeset" in crash kernel cmdline as a workaround?
> Do we have major customers debugging kexec problems on graphical consoles? as
> this doesn't break kexec, we just don't see debug from it when it fails to get
> to the initramfs.
I don't know, I always do this.
So kexec is working, it just doesn't print debugging when it fails to find initramfs, i.e. if its incorrectly configured.
The other option I've thought about it to somehow pass the new kernel a framebuffer parameters for where it can find the current framebuffer and have a dumb fb driver like vesafb/efifb take over the console early, and later load the real driver.
I can't see this being fixed for 6.0 at this point, it needs to happen upstream the risk of doing it for 6.0 is too high.
I suggest we move it to 6.1. Since kexec doesn't give us any idea its going to just run a new kernel, it needs to be kexec + some sort of fb device to make this work. There is simply no place to put code to make the gpu reset back to text mode that can make this work.
could you please provide info about current status of this issue? Please try to reproduce on current kernel (RHEL6.1 Beta).
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.