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.