Comment 21 for bug 1629512

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.