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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox