From: Andre Hedrick <andre@linux-ide.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Grover <andrew.grover@intel.com>,
kernel list <linux-kernel@vger.kernel.org>,
ACPI mailing list <acpi-devel@lists.sourceforge.net>
Subject: Re: Ask devices to powerdown before S3 sleep
Date: Tue, 21 Jan 2003 03:38:35 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.10.10301210326580.16070-100000@master.linux-ide.org> (raw)
In-Reply-To: <20030121104737.GC24349@atrey.karlin.mff.cuni.cz>
Pavel,
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.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Tue, 21 Jan 2003, Pavel Machek wrote:
> Hi!
>
> > 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...
next prev parent reply other threads:[~2003-01-21 11:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-19 21:46 Pavel Machek
2003-01-21 1:27 ` Andre Hedrick
2003-01-21 10:47 ` Pavel Machek
2003-01-21 11:38 ` Andre Hedrick [this message]
2003-01-21 7:56 ` Zwane Mwaikambo
2003-01-21 10:46 ` Pavel Machek
2003-01-21 10:55 ` Zwane Mwaikambo
2003-01-21 11:03 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.10.10301210326580.16070-100000@master.linux-ide.org \
--to=andre@linux-ide.org \
--cc=acpi-devel@lists.sourceforge.net \
--cc=andrew.grover@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®