A description of a firmware bug in external USB storage that
cause disk error reports, and the way to avoid them.
Problem Description
When you connect an external USB drive you may see:
sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
sd 0:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
sd 0:0:0:0: [sda] tag#0 Add. Sense: Invalid command operation code
sd 0:0:0:0: [sda] tag#0 CDB: Write same(16) 93 08 00 00 00 00 00 00 00 22 00 00 00 06 00 00
critical target error, dev sda, sector 34 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0
critical target error, dev sda, sector 40 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 2
If the following are true, you have the same problem:
- You see DISCARD or UNMAP
- You see Write same(16), and
- The external storage is a spinning disk
- You delete a lot of data, or reformat the disk
Explanation
These commands are all the same as what is also known as trim,
which is used to tell an SSD disk to mark a data area as re-usable.
Spinning disks do not support trim, and so reject it.
The kernel is attempting to run the command because the USB enclosure
told the kernel that it supports the commands writesame16 or unmap.
The error is reported because that command fails.
Root Cause
The root cause is that the USB enclosure supports the command in firmware,
and the spinning disk does not. The USB enclosure fails to negotiate
this command with the harddrive before negotiating it with the OS.
This happens when manufacturers use the same USB chips for SSD and
spinning disk drives on the cheap.
Solution
The solution is to tell the kernel that this does not work, for this
device, by using a udev rule, eg.
/etc/udev/rules.d/99-cheap-disk.rulesACTION=="add", SUBSYSTEM=="scsi_disk", SUBSYSTEMS=="scsi",
ATTRS{vendor}=="WD", ATTRS{model}=="My Passport *",
OPTIONS="log_level=debug",
PROGRAM="/usr/bin/logger -t udev/99-cheap-disk Found cheap disk",
ATTR{provisioning_mode}="disabled"
In my case, the bad harddrive was a “Western Digital My Passport 2626“,
with revision 1034.
Thanks
For the exact same problem and solution for SAN/NAS, see:
Chris Hofstaedtler
Who Is This Post For?
Anyone who has tried to connect a Garmin smart device to the
cloud with Garmin Connect.
Anyone who has tried to connect any smart device that has no
keyboard to any cloud anywhere.
What Device
A Garmin Index S2 scale. This is a human weight scale that can
upload your weight to the cloud.
The connects to the cloud directly via wifi. It can connect
to a phone via bluetooth, but only for wifi configuration. Everything
after that goes via wifi.
Even small things like 12/24 hour clock configuration go via wifi.
The scale has no keyboard, and a limited screen, so configuration
is via a phone.
Problem Experienced
The scale does not send any weight data to the cloud. The
scale does not receive any configuration changes from the cloud.
The scale does display weight data, and a wifi signal strength icon.
The scale does not display any errors. There is no indication
that anything is wrong.
Garmin Connect App on the phone does not display any errors.
It claims everything is working.
More About Garmin Connect
- Garmin Connect means two different things:
- A Phone App, used to configure various devices
- A Web App, used to view the data
More About Errors Not Displayed
On the Scale
The scale doesn’t show wifi errors. It can display some text,
like your name, but doesn’t even show E123, or any other error
code. The user believes it works.
The scale does show a wifi signal strength icon (triangle,
4 lines for strength), and displays a sync icon (twirling circle).
Neither icon changes to an error (red X, for example.) The user
is lead to believe it works.
On the Phone
The phone does not show any errors, wifi or otherwise.
The phone does display setup complete.
The phone app let’s you test wifi. It’s a bit complicated,
but you can. It will then display Wifi Connected OK.
Suspected Error
Eventually, after re-configuring hundreds of times, I suspect
an network error. I suspect the scale is trying to connect
to garmin.com on a non-standard port.
It’s not that, but it gives…
The Only Error Displayed
Hours later, I finally look on the router. I’m looking
at the network traffic, and see:
4-Way handshake failed for ifindex: 3, reason: 15
KEY_SEQ not returned in GET_KEY reply
So I know wifi isn’t working. The WPA2 handshake
is not completing even though the phone app thinks
the scale’s wifi is OK.
Non-specified Requirements
Bluetooth or Wifi? Bluetooth and Wifi
When you configure the scale, you should eventually
see a message on Garmin Connect on the phone that
sync completed, along with a green icon.
If you do not see this, the scale is on a different
wifi network than the phone.
Why would that be? In my case the phone is on a 5G
network (because it can) and the scale is on a 2.4G
network (because it can’t)
Until you put the phone on the same network as the
scale, the last message you will see is:
configuration completed, not sync completed,
and this means that the scale is not working.
At this point, the scale isn’t syncing to the
Garmin cloud. It’s just synced it’s configuration
with the phone.
WPA? WPA2? WPA1.5
The scale claims to support WPA2 on a 2.4G network.
For a device was first announced in 2020, this is
attrocious, but that’s true for a lot of these
smart devices.
Even then, it doesn’t work with the entire gamut
of WPA2 protocols.
In my case, I had to swap from iwd to
wpa_supplicant to connect the scale.
Questions for Garmin
- Why do you display that the wifi network tested OK
when the 4-way handshake failed? Couldn’t you add
a connections to https://test.garmin.com or something?
- Why do you not display a sync error message on either,
but preferably both the scale and phone app?
- Why do you not check that the phone and scale wifi
are the same? The setup fails silently otherwise.
- Why do you display configuration complete, when
it isn’t yet complete?