Hi,
as I can see, there are IDE driver updates in the 2.4.19pre kernels
including support for bus tri-state feature on some newer chipsets.
How about the good old PIIX4 chip? Here is the datasheet:
http://www.intel.com/design/intarch/DATASHTS/29056201.pdf
See page 66, bits 11 and 12 of GENCFG register (function 0, address
0xb0 in PCI config space). Is anyone working on supporting this?
Sure, hot-swapping IDE disks is still risky, but some people are
doing it anyway :) so let's make it a little less risky - unmount
everything, then "hdparm -Y" (flush any write cache, spin down),
then "hdparm -b0" and only then remove the disk.
Perhaps there should be some higher level logic here, like this:
- if no device is found on an IDE bus on startup (or module load),
tri-state that bus (so it is "safe" to connect a device later)
- if the driver is told to tri-state an IDE bus, first make sure
the devices on that bus are not busy, tell them to go to sleep,
unregister them (as they will be removed - if not, the bus will
be rescanned later anyway, after it is re-enabled)
- if the driver is told to rescan the bus that was tri-stated,
re-enable it first (if no devices found, tri-state it again)
- if the system is being shut down (or driver module is removed),
also tri-state the bus (as above, first tell all devices to go to
sleep, etc.) - the "go to sleep" part is already being done by
the Debian shutdown scripts, as it seems to be the only sure way
to flush write caches on some disks before power off.
I admit I haven't looked much at 2.5 yet, so excuse me if parts of
this are already done. It's just a few small suggestions...
Thanks,
Marek
-
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 : Sun Jun 23 2002 - 22:00:13 EST