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.
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.
The IEEE1394+SBP2 driver combination in 2.4.21 has problems. When the
kernel is compiled for single-processor the SBP2 driver can't log into my
SBP2 devices and hangs rmmod when the module is removed--in other words,
it's useless. When compiled for SMP, the SBP2 driver works more or less
normally, but still requires an IEEE1394 bus reset to work the second time
a device is attached. Note this is a laptop, so it only has one
processor.
2.4.20 has no such problems with my IEEE1394 SBP2 device--no bus resets
needed, no compile-option-dependent bugs, and it logs in and out of the
device without problems.
On a positive note, the orinoco_pci driver in 2.4.21 is the best driver
I've used for this chipset so far. It's a vast improvement over the same
driver in 2.4.20, which would hang after about 30 seconds. 2.4.21's
driver is even slightly faster than the linux-wlan-ng driver.
The hardware in question is an IBM Thinkpad A30p with an S.400 port and
builtin Prism2.5 chipset. The SBP2 device is a "Prolific PL3507 Combo
Device" (IOGear ION external IDE disk enclosure). Kernel was compiled
with gcc 2.95.4 on Debian.
Further details available on request.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:29 EST