I too see this error for Seagate 'ST3500418AS' SATA drives via 88SE9123
PCIe SATA 6.0 Gb/s controller (Ubuntu 16.04.2, latest 4.8 Kernel)
```
exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0
irq_stat 0x40000001
failed command: SET FEATURES
cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 4
status: { DRDY ERR }
error: { ABRT }
```
Note:
- `Emask 0x1` = "device reported error"
- `status: { DRDY ERR }` = device ready, but with error
If it relates to other posts on the internet, it might be benign and
simply failed power management setting attempts, or the like via the
Marvel controller.
To note, I have other SSD drives in the system that are connected via a
different controller (SB850) and also don't support APM, but they don't
exhibit this error!
`cmd ef/05:fe:00:00:00/00:00:00:00:00/40` requires understanding ATA commands
to know what the above command is attempting. As per the "Enable/disable
advanced power management" section of the ATA.8 standard:
- "Subcommand code `05h` allows the host to enable Advanced Power Management."
- `FEh` = Maximum performance
So this confirms:
- ATA command = ef = SET FEATURE
- ATA Feature = 05 = Advanced Power Management4
- ATA NSect = fe = 254 = Maximum performance
- remainder of string ":00:00:00/00:00:00:00:00/40" is addressing
SOMETHING during boot is trying to set APM on drives that don't support
it!!!
I checked udev rules - this doesn't seem to be udev...
```
$ grep -r hdparm /lib/udev/*
/lib/udev/hdparm:. /lib/hdparm/hdparm-functions
/lib/udev/hdparm: if grep -wq nohdparm /proc/cmdline ; then
/lib/udev/hdparm:OPTIONS=$(hdparm_options $DEVNAME)
/lib/udev/hdparm: /sbin/hdparm $OPTIONS $DEVNAME 2>/dev/null
/lib/udev/rules.d/85-hdparm.rules:ACTION=="add", SUBSYSTEM=="block",
KERNEL=="[sh]d[a-z]", RUN+="/lib/udev/hdparm"
```
Tracing the udev -> hdparm scritping, I found that in
`/lib/hdparm/hdparm-functions`, there is `hdparm_options()` and
`hdparm_try_apm()`, which might default to `hdparm_set_option -B254`
```
and
```
hdparm_try_apm()
{
# set our default global apm policy here.
if [ -z "$ID_PATH" ]; then
local ID_PATH="$(udevadm info -n "$1" -q property 2>/dev/null | sed -n
's/^ID_PATH=//p')" || true
fi
case $ID_PATH in
pci-*-ieee1394-*|pci-*-usb-*)
return 1
;;
esac
return 0
}
```
But in my case, when I query udev properties for the device, I see this
```
$ udevadm info -n /dev/sdg
...
E: ID_ATA_FEATURE_SET_PM=1
E: ID_ATA_FEATURE_SET_PM_ENABLED=1
...
```
But I do not see `ID_ATA_FEATURE_SET_APM=1` so udev is, or it shouldn't
be setting APM on my drive that doesn't support it...
So if it's not the normal system udev rules, I wondered if it might be
something about the init on initramfs trying to enable this, given that
does try to load block device drivers and probably runs udev rules in
preparation for mounting root. I uncompressed initramfs, but failed to
identify anything that sets the APM on drives that don't support it.
So it's still a mystery why APM is attempted when, clearly, it's obvious
the drives don't support it, and also, why only the HDD drives on the
marvel controller vs other SSDs (not on Marvel) that don't have APM?
Also, if I force `sudo hdparm -B 254 /dev/sdg` and tail
/var/log/kern.log, I can't trigger that same error seen during boot.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1629512
Title:
HDD failed command: SET FEATURES error
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1629512/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
