Re: kexec and IRQ sharing

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

Alan Stern <stern@rowland.harvard.edu> writes:

> I can implement either a shutdown method or a reboot notifier for
> uhci-hcd.  Note however that the upcoming changes to the PM core include a
> suspend call (PMSG_FREEZE) that does exactly what you want: quiesce the
> device, disable IRQ and DMA, but don't necessarily switch the power level.  
> (See Documentation/power/devices.txt.)  Unfortunately it won't be
> implemented until another few kernel releases have gone by.

Thanks.
 
> The idea of using kexec to recover from a partially-damaged kernel seems 
> unreliable.  Even attempting to quiesce devices prior to rebooting may 
> not work because of locks whose owners have crashed.

There is still a final bit of feeling our way through the weirdness,
in that case.  But in that case no devices will be quiesced before
we start the next kernel.  Basically very little beyond a jump
jump instruction will be executed at that point.  What is loaded must
be a very robust kernel capable of handling the few devices it needs
from an active state.  The irq weirdness you just ran into is
something that really hasn't been looked at.

In that case I suspect we will probably simply want to specify irqpoll
on the command line by default.  We are as safe as possible from DMA
traffic because we run out of a completely reserved area of memory
that the primary kernel never uses.

And the target is not a complete system recover but rather being able
to do something useful in the event of a crash like write a core
dump.

So in the crash dump case with a non-hardened driver that can't cope
the system may lock up, but I don't see it corrupting your data.
Which is the important bit.  And with drivers that have been
sufficiently hardened you will be able to do things like write
to disk etc.

Eric