Re: [PATCH] kexec for 2.5.51....

[ebiederm@xmission.com (Eric W. Biederman)]

Ed Tomlinson <tomlins@cam.org> writes:

> Eric W. Biederman wrote:
> 
> > Linus,
> > 
> > My apologies for not resending this earlier I've been terribly
> > busy with other things..
> > 
> > No changes are included since the last time I sent this except
> > the diff now patches cleanly onto 2.5.51.  If there is some problem
> > holler and I will see about fixing it.
> > 
> > When I bypass the BIOS in booting clients my only current failure
> > report is on an IBM NUMAQ and that almost worked.
> 
> I applied this to a 2.5.51 kernel with usb and fbcon updated via bk pulls.
> Then after rebooting into the new kernel I tried
> 
> kexec -l /vmlinux.25 --append="console=tty0 console=ttyS0,38400
> video=matrox:mem:32 idebus=33 profile=1"
> 
> kexec -ed
> 
> This rebooted but hangs at:
> 
> drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0
> 

Hurray! a bug report :)

> One other datum.  Without the --append line a kernel booted with kexec hangs
> when
> 
> tring to mount the real root - it cannot find the device.

I suspect you want to specify --append="root=/dev/xyz" when calling kexec.


> Am I using kexec correctly?  What else can I try?  Is there any debug
> info I can gather?

Generally you want to put kexec -e your shutdown scripts just before
the call to reboot.  And then you can just say: kexec ...
and the you get a clean system shutdown.  Dropping to run level 1
before calling kexec tends to get most of the user space shutdown
called as well.  It is definitely a good idea to be certain X is
shutdown before calling kexec. 

With respect to USB it is quite possible something in the USB drivers
does not shutdown correctly on a reboot, and the driver then has trouble
reinitializing the device.

Since you got to the point of mounting root earlier when you did not
specify anything I wonder if you some of your command line arguments
made the situation worse.  

Which kernel are you booting with kexec anyway?

This is actually an expected failure mode, but one I have not seen
much of yet.  The new kernel not coming up because the old drivers
left the hardware in a state the new drivers cannot handle.

Eric