Alexander Best wrote:
> the current implementation (kern.cam.power_down) uses a singe "sleep"
> operation, whereas the patch by oliver uses "flush" and "standby immediate".
Sleep is just more aggressive. It puts device into deeper sleep state. I
don't think it is important from wearing point of view.
> unfortunately almost nobody was aware of mav's work at the time of the
> discussion. would have been nice to have a note in cam(4) explaining the
> purpose of kern.cam.power_down. that way a lot of double work could have been
> avoided.
That code was expected to handle spindown on shutdown in unified fashion
for ATA and SCSI devices without dependency from peripheral driver (even
without one), just using different commands for each protocol. It works,
but in current implementation it is unreliable. The problem is that it
uses polled operation mode, not supported by some controllers or
unreliable on some (e.g. atapicam). So the code is disabled now by
default. I haven't yet decided it's future: it should be either reworked
or reverted.
As positive side -- as soon as CAM is not using NewBus at the moment,
CAM registers own shutdown handlers. That allows CAM to receive the
howto argument, which allows to separate cases of reboot and shutdown
cases just by:
if ((howto & RB_POWEROFF) == 0)
> is the ATA(4) subsystem still being actively worked on or will it die out
> after
> officially switching to ATA_CAM? the question is, if it is worth implementing
> hdd spin down for ATA(4)?
I don't think it will be really critical. Next months I am going to work
on ataraid(4) replacement, which was main declared show stopper for the
switch. I hope to trash legacy code some time after switching to ATA_CAM
to clear number of odd things (like almost not working port multipliers
support or duplicate drivers), required by it.
--
Alexander Motin
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
