I failed to make the point clear.
One thing I learned was never trust the BIOS, even if you wrote it.
Now if you are missing ACPI hooks to beat the BIOS silly for whatever
reason you want, I will load two barrels towards Andy for not finishing
the task or not explaining how to throttle them.
I do not care if the BIOS want to do monkey flips.
If there is an event any piece of hardware can not handle, ie where you
have inserted tests that default to panic, it had better allow you to
throttle to full enable.
If it does not, the solution is to make a blackball list of hardware
which fails to conform to acpi rules. Fair warning you had better have a
means to prove it because, public lists make companies nervous.
So, that I am clear ... would you consider changing the default method of
operations for errors.
How a BUG() and a really long long timer until the battery dies, a panic
gives little or no information, but this is my opinion.
LAD Storage Consulting Group
On Tue, 21 Jan 2003, Pavel Machek wrote:
> > Could you do me just one tiny favor?
> > Please consider attempting an error recovery level path, maybe ...
> > Every patch I have glanced at has 'panic("blah blah");'
> > If you do not have enough hardware to generate an accurate path for
> > recovery, then please do not force the kernel into panic. Would you
> > consider failing the request making it jump back to S1 ? This at least
> > allows it crash like a power failure.
> If I make it go S1, auto-reboot will not apply etc, and machine will
> crash during ENABLE, anyway...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:26 EST