elf == _die_notifier && ev != DIE_OOPS)
> return NOTIFY_DONE;
>
> ftrace_dump(ftrace_dump_on_oops);
>
> return NOTIFY_DONE;
> }
Or better yet:
if (ftrace_dump_on_oops) {
/* The die notifier requires DIE_OOPS to trigger */
altering a lot of call sites. :-(
> @@ -162,10 +194,16 @@ int atomic_notifier_chain_unregister(struct
> atomic_notifier_head *nh,
> struct notifier_block *n)
> {
> unsigned long flags;
> - int ret;
> + int ret = 0;
>
> spi
there be a better way? Certainly but
to prove it out starting with a block device wrapper is a trivial way to
go.
This sounds like a solution to a non-existent problem.
Alan Stern
___
kexec mailing list
kexec@lists.infradead.org
http
of requests to filter through an extra software
layer is a clumsy way of accomplishing this. There ought to be a
better approach.
Alan Stern
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
the device driver can reclaim and reinitialize it,
but the hardware will not be touched.
device_reattach reattaches the driver to the hardware.
How would these differ from the already-existing remove and probe
methods?
Alan Stern
___
kexec mailing list
, then it should just turn off
ACPI before passing control to the image kernel. Then the image kernel
can turn ACPI back on and all should be well. If you do this, does the
NVS region still need to be preserved?
Alan Stern
___
kexec mailing list
kexec
On Tue, 18 Mar 2008, Eric W. Biederman wrote:
Alan Stern [EMAIL PROTECTED] writes:
Could it be connected with the way the boot kernel hands control over
to the image kernel? Presumably ACPI isn't prepared to deal with that
sort of thing during a boot from S5. It would have to be fooled
, but it ought to be
possible somehow...
Alan Stern
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
probably more complicated than this, with weird
interactions between the firmware and the various ACPI methods.
Nevertheless, the main idea seems valid.
Alan Stern
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo
