Well.. the drive definitely met it's maker.. but I've figured out
where all the ATA error noise is coming from!
systemd-udevd invokes /lib/udev/rules.d/85-hdparm.rules
... which invokes /lib/udev/hdparm
... which imports /lib/hdparm/hdparm-functions
... which has a function hdparm_options
... which calls performs various checks etc. and determines that it'll
try and set power management on anything even vaguely resembling a
drive :-/
... which passes those options back to /lib/udev/hdparm
... which then tries to run hdparm with the options
... which fails because the drive doesn't like it
root@AH01:/lib/udev# . /lib/hdparm/hdparm-functions
root@AH01:/lib/udev# hdparm_options /dev/sda
-B254
root@AH01:/lib/udev# hdparm `hdparm_options /dev/sda` /dev/sda
/dev/sda:
setting Advanced Power Management level to 0xfe (254)
HDIO_DRIVE_CMD failed: Input/output error
APM_level = not supported
root@AH01:/lib/udev# dmesg | grep ata9 | tail
...
[ 1397.244573] ata9.00: exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0
[ 1397.244577] ata9.00: irq_stat 0x40000001
[ 1397.244579] ata9.00: failed command: SET FEATURES
[ 1397.244583] ata9.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 11
[ 1397.244584] ata9.00: status: { DRDY ERR }
[ 1397.244585] ata9.00: error: { ABRT }
What's the preferred method of telling hdparm to kindly bugger off in
this context? I feel like it's maybe a bug because not all drives
support all APM values consistently and I suspect that because the
Marvell "Virtual" ATA device is in the mix, that the hdparm scripts
are blindly seeing it as a drive as well - and that sending
unsupported drive parameters to a given device is asking for trouble.
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main
