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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2003-07-09 at 04:49, Zygo Blaxell wrote:
> Previously on kernels up to 2.4.20, an IDE disk I/O request that was in
> progress at suspend time would trigger a DMA reset upon resume, after a
> short delay while waiting for the timeout.  2.4.20 looked like this:
> 
>         ide_dmaproc: chipset supported ide_dma_lostirq func only: 13 hda:
>         lost interrupt
> 
> After this, the machine happily resumes whatever it was doing.  There is a
> delay of a few seconds while this happens.
> 
> Now in 2.4.21, the kernel prints the following message:
> 
>         hda: dma_timer_expiry: dma status == 0x04
> 
> and that's the last thing it ever does--the kernel locks up hard.

Whatever happens, you shouldn't let the machine suspend while ongoing
disk IOs are in progress. A lot of bad things could result from that.

Actually, the proper fix is to implement some working suspend/resume
handlers in the IDE layer like we did in 2.5, though the problem here
is that 2.4 lacks proper infrastructure for doing that in a properly
ordered way.

> Note that in order to see this you need to be doing a lot of I/O at
> suspend time, e.g. 'cp -a /usr /tmp' or some such thing.
> 
> Also in 2.4.21, a filesystem mounted from a CD-ROM via ide-scsi will start
> to get I/O errors if it is accessed during the suspend/resume sequence. 
> In 2.4.20, there were no ill effects when this happens.

Same thing. You need the driver to block requests during that sequence,
and to complete any pending one before suspend is entered.