mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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...


  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®