Bug 230038 - regression USB mass storage device
Summary: regression USB mass storage device
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 11.2-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2018-07-25 13:51 UTC by Philip Homburg
Modified: 2020-10-26 10:35 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Homburg 2018-07-25 13:51:43 UTC
Since upgrading to 11.2-RELEASE, my laptop doesn't fully recognize my Garmin 
GPSMAP 62s anymore. In mass storage mode, the Garmin presents two block
devices, one to access the internal flash and one for the micro-SD card.

When I connect the Garmin, only the first device appears. After a camcontrol
rescan, the second appears as well.

Here is the dmesg output of connecting the Garmin:
uhub_reattach_port: giving up port reset - device vanished
ugen0.6: <vendor 0x091e product 0x2459> at usbus0
umass0 on uhub2
umass0: <vendor 0x091e product 0x2459, class 0/0, rev 2.00/5.09, addr 6> on usb
us0
umass0:  SCSI over Bulk-Only; quirks = 0xc000
umass0:5:0: Attached to scbus5
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0: <Garmin GARMIN Flash 1.00> Removable Direct Access SPC-3 SCSI device
da0: 40.000MB/s transfers
da0: 1848MB (3784704 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

Then I run 
# camcontrol rescan 5:0:1

And the resulting dmesg output:
da1 at umass-sim0 bus 0 scbus5 target 0 lun 1
da1: <Garmin GARMIN SD Card 1.00> Removable Direct Access SPC-3 SCSI device
da1: 40.000MB/s transfers
da1: 7646MB (15659008 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>
Comment 1 Anton Yuzhaninov 2018-08-01 17:59:42 UTC
I with the same problem on 11.2-PRERELEASE #0 r334549
Garmin GPSmap 62 SD card is recognized only after camcontrol rescan 5:0:1
Comment 2 Friedrich Volkmann 2020-06-27 20:29:28 UTC
Problem persists in 12.1-STABLE r358922. (My Garmin is a Dakota 20.) I get another scbus number, so I wrote a shell script that parses the output of "camcontrol devlist" as a workaround:

#!/bin/bash
camline=`camcontrol devlist|grep 'GARMIN Flash'`
while test -z "$camline" ;do
        echo not found, waiting 5 seconds...
        sleep 5
        camline=`camcontrol devlist|grep 'GARMIN Flash'`
done
# output: <Garmin GARMIN Flash 1.00>         at scbus8 target 0 lun 0 (da0,pass4)
camline=${camline#*scbus}
bus=${camline%% *}
camline=${camline#*target }
target=${camline%% *}
camline=${camline#*lun }
lun=${camline%% *}
echo -n bus:target:lun = $bus:$target:$lun
lun=$(($lun + 1))
echo " -> $bus:$target:$lun"

camcontrol rescan $bus:$target:$lun
Comment 3 Friedrich Volkmann 2020-06-27 20:34:29 UTC
How can we set the status to "confirmed" and the importance to "affects many people"?
Comment 4 Akos Somfai 2020-07-18 21:54:23 UTC
(In reply to Friedrich Volkmann from comment #2)
I have a similar problem with a Dakota 20 but in my case the second device does not appear even after doing a rescan. However, if I add quirk UQ_MSC_NO_INQUIRY then it behaves correctly.
Could you try to add this to your /boot/loader.conf, reboot and check if it fixes your problem as well:

hw.usb.quirk.0="0x091e 0x23c0 0 0xffff UQ_MSC_NO_INQUIRY"
Comment 5 Akos Somfai 2020-08-06 20:59:13 UTC
(In reply to Friedrich Volkmann from comment #3)
Hi, any update on this?
Comment 6 Friedrich Volkmann 2020-08-06 21:16:29 UTC
(In reply to Akos Somfai from comment #5)
Sorry, I have not rebooted yet. When I do, I will hopefully be able to test your suggestion, although the quirks don't look like a final solution. No average user will know that they are needed, and nobody can memorize a string like "0x091e 0x23c0 0 0xffff UQ_MSC_NO_INQUIRY".
Comment 7 Akos Somfai 2020-08-06 21:27:53 UTC
(In reply to Friedrich Volkmann from comment #6)
Ok, just let me know once tested.
BTW, there's no need to memorize anything or even to modify loader.conf in the final solution -- loader.conf modification is for confirmation only and if it works then I'll add it to the kernel usb quirk list that is applied automatically after boot.
Comment 8 Friedrich Volkmann 2020-10-19 10:53:30 UTC
A blackout made me reboot now. The suggested line hw.usb.quirk.0="0x091e 0x23c0 0 0xffff UQ_MSC_NO_INQUIRY" in loader.conf works for me. Devices da1 and da1s1 show up and are usable.
Comment 9 Philip Homburg 2020-10-21 15:39:59 UTC
I didn't use my GPS on my FreeBSD laptop for quite a while, so I sort of forgot about this issue. Part of the release notes of 12.2-RC3 reminded me of this problem.

I tried 12.2-RC3 without any changes and the same issue is still there.
After that I also tried the magic hw.ucb.quirk.0 string and that also didn't have any effect.

Fortunately, a 'camcontrol rescan 4:0:1' still does the trick.
Comment 10 Akos Somfai 2020-10-23 15:28:35 UTC
(In reply to Philip Homburg from comment #9)
The hw.usb.quirk.0 line won't work in your case likely because your device's product id is not the same as Friedrich's one. Could you try adding this line to /boot/loader.conf, reboot and check if it fixes your problem as well:

hw.usb.quirk.0="0x091e 0x2459 0 0xffff UQ_MSC_NO_INQUIRY"
Comment 11 Philip Homburg 2020-10-26 10:35:47 UTC
Great, that works!