Re: 2.4.21 IDE and IEEE1394+SBP2 regressions, orinoco_pci progress

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.
> 
>