Bug 596581 - KMS does not work well with kexec
KMS does not work well with kexec
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.0
All Linux
high Severity high
: rc
: ---
Assigned To: Dave Airlie
Han Pingtian
:
Depends On:
Blocks: 1279013 524819
  Show dependency treegraph
 
Reported: 2010-05-26 23:01 EDT by Cong Wang
Modified: 2015-11-07 00:47 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1279013 (view as bug list)
Environment:
Last Closed: 2011-06-13 16:25:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Cong Wang 2010-05-26 23:01:43 EDT
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):
RHEL6 beta
Fedora 12
upstream

How reproducible:
Always

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.
  
Actual results:
Console or kexec hangs there.

Expected results:
The second kernel should be loaded successfully and its boot messages should be always displayed.
Comment 1 Cong Wang 2010-05-26 23:05:14 EDT
David, this is a problem of KMS, since adding "nomodeset" makes the problem disappear.
Comment 3 Cong Wang 2010-05-27 03:41:39 EDT
On my machine, upstream kernel 2.6.32, 2.6.33, 2.6.34 all doesn't work if no "nomodeset". FYI.
Comment 5 Dave Airlie 2010-05-28 00:09:10 EDT
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.
Comment 6 Dave Airlie 2010-05-28 00:16:39 EDT
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.
Comment 7 Cong Wang 2010-05-28 00:25:24 EDT
(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
> /boot/vmlinuz-2.6.32-dael6
> 
> 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.
Comment 8 Dave Airlie 2010-05-28 00:30:28 EDT
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?
Comment 9 Cong Wang 2010-05-28 00:41:44 EDT
(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
> past?    

Sorry, I have no idea, I just know kexec reboot skips bios.
Comment 10 Dave Airlie 2010-06-16 20:35:35 EDT
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.
Comment 11 Cong Wang 2010-06-17 02:52:44 EDT
(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.
Comment 12 Dave Airlie 2010-07-07 19:36:01 EDT
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.
Comment 13 Dave Airlie 2010-07-28 19:03:07 EDT
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.
Comment 16 Tomas Pelka 2011-05-30 08:22:41 EDT
Dear reporter,

could you please provide info about current status of this issue? Please try to reproduce on current kernel (RHEL6.1 Beta).

Thanks Tom
Comment 18 RHEL Product and Program Management 2011-06-13 16:25:06 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

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