> Russell King writes:
> >x86, I believe, is one example of such a platform that can leave PCI
> >devices jabbering over a warm reboot.
>
> The standards on pcisig.com are apparently proprietary, so I'm
> afraid I can only quote a proprietary book I have handy:
Rebooting on x86 is returning control to the BIOS not pressing the external
reset line.
> So, you must be talking about a PC that does not ground RST#
> during a warm reboot or out of spec (according to this book) PCI devices,
> which would not be specific to x86 unless we're talking about motherboard
> chipset devices.
Exactly an in spec, PC does not need to ground RST# on reboot.
> I understand the benefits of being conservative, but let's not
> be taken in by urban legend, or, more likely, some quirkly hardware
> that we can set a flag for while we can reboot more quickly with most
> other hardware. Anyhow, if you or anyone can give me specifics about
> devices jabbering away after reboot, that would be great
On 2.4.x don't down a network interface, before you reboot.
> I have no objection to replacing or supplementing the reboot
> notifier chain with a method in struct device_driver, but let's not
> overload these methods with ambiguous semantics. I do not want to
> call thirty functions that primarily return memory to various memory
> allocators, mark a bunch of inodes as invalid, and otherwise arrange
> things so that the kernel can smoothly continue to run user level
> programs when, in fact, we just want to pull the reset line on the
> computer.
As soon as you start tracking the code and complaining about the correct
pieces I think it will start digging up a list. Currently I do not
see that a productive piece of conversation.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/