From: jiho@c-zone.net
To: Zygo Blaxell <zblaxell@umail.hungrycats.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.21 IDE and IEEE1394+SBP2 regressions, orinoco_pci progress
Date: Wed, 09 Jul 2003 19:17:16 -0700 [thread overview]
Message-ID: <3F0CCCAC.8020405@c-zone.net> (raw)
In-Reply-To: E19aFLE-0003NF-00@satsuki.furryterror.org
Thanks for the explanation. I thought maybe it had something to do with
some other IDE issues that can result in lost interrupts.
Then again, who knows, maybe it does.... ;)
Zygo Blaxell wrote:
> [This is an email copy of a Usenet post to "vger.linux.kernel"]
>
> On Tue, 08 Jul 2003 23:13:08 -0400, jiho wrote:
>
>>Zygo Blaxell wrote:
>>Excuse my ignorance -- I suppose I'm blundering around here with a
>>number of IDE issues -- but what do you mean by, "at suspend time"?
>>
>
> At the time I either hit the appropriate key sequence on the laptop, or
> run the 'apm -s' command, or when battery power drops below an arbitrary
> threshold, which causes the laptop to go into a low power mode (memory is
> powered, but CPU is stopped and all non-memory-related hardware is turned
> off).
>
>
>>How can there be a "suspend time" while a disk I/O request is "in
>>progress"?
>>
>
> For this to happen there has to be a process or processes doing a lot of
> disk I/O at the moment that the suspend event occurs (which is typical if
> e.g. compiling a kernel while on battery power, and the battery power runs
> out half way through).
>
> I'm guessing here, but I suspect that at least one IDE request has been
> sent to the drive, but a reply has not been received yet, when the APM
> BIOS stops executing Linux and cuts power to the drive. When the laptop
> resumes some time later, the APM BIOS turns the drive back on and resumes
> executing Linux. AFAICT APM expects the OS to take care of re-issuing the
> last command to the IDE disk, or expects the OS to avoid issuing a command
> just before the OS tells APM that it's ready to suspend. Either approach
> would work.
>
> Linux is still waiting for this command to complete after it resumes, but
> of course the drive and controller hardware don't remember what the
> command was as they've been turned off in the meantime.
>
> In 2.4.20 and earlier, the kernel would wait a few seconds, then reset the
> IDE hardware and try the command again. In 2.4.21, the kernel locks up
> hard. Judging from my boolean CPU meter (aka the laptop fan, which
> activates during periods of high CPU activity), the CPU isn't very busy
> when it is locked up like this.
>
>
next prev parent reply other threads:[~2003-07-10 2:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-09 2:49 2.4.21 IDE and IEEE1394+SBP2 regressions, orinoco_pci progress Zygo Blaxell
2003-07-09 2:12 ` Ben Collins
2003-07-09 14:54 ` Zygo Blaxell
2003-07-09 3:13 ` jiho
2003-07-09 13:50 ` Zygo Blaxell
[not found] ` <E19aFLE-0003NF-00@satsuki.furryterror.org>
2003-07-10 2:17 ` jiho [this message]
2003-07-09 9:34 ` Benjamin Herrenschmidt
2003-07-09 14:31 ` Zygo Blaxell
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=3F0CCCAC.8020405@c-zone.net \
--to=jiho@c-zone.net \
--cc=linux-kernel@vger.kernel.org \
--cc=zblaxell@umail.hungrycats.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.