On Tuesday 03 January 2012 17:49:01 Bartosz Fabianowski wrote:
> > Is it possible that you could run usbdump to capture the traffic on the
> > bus where the USB device is connected?
> Absolutely. I uploaded the dump at . This dump covers 30 seconds from
> plugging in.
> - Bartosz
>  http://www.fabianowski.eu/garmin_dakota_20_attach.usbdump
The following transaction shows that the device supports two luns. I suspect
that there is a miscommunication between UMASS and CAM layer.
At Tue, 3 Jan 2012 18:15:32 +0100,
Hans Petter Selasky wrote:
> The following transaction shows that the device supports two luns. I suspect
> that there is a miscommunication between UMASS and CAM layer.
I have posted about the same issue some days ago to -scsi@.
<a href="http://docs.FreeBSD.org/cgi/mid.cgi?86r4zkx50t.wl%poyopoyo">http://docs.FreeBSD.org/cgi/mid.cgi?86r4zkx50t.wl%poyopoyo To: [hidden email] Subject: Garmin Edge705: LUN1 of umass device not recognized
I follow your suspicion as I figured out this regression happened at
r208911, modification to LUN discovery code.
Interesting timing. I am just in the middle of a debug session to try
and debug this. I know nothing about umass and/or SCSI, so it is all one
big learning experience for me. Here is what I am seeing (snippets from
This list contains exactly two LUNs, 0 and 1. The list is then processed
by scsi_xpt.c. After reading the first entry, LUN 0 is scanned and da0
created. Then, the next entry is read. And something seems to go wrong
here. The debug output I get is:
cam_debug: next lun to try at index 1 is 0
IMHO, this should not be. The entry at index 1 is LUN 1, not LUN 0. It
seems that instead of scanning LUN 0 and LUN 1, the code ends up
scanning LUN 0 twice. I have no idea why though.
Looking into this further, I think that the issue is down to Garmin
devices supplying incorrect information.
In reply to the SCSI INQUIRY command, the HISUP bit is not set. This
means that single level LUN structure is used (which appears to be all
that FreeBSD supports anyway). Consequently, the second LUN should be of
00 01 00 00 00 00 00 00
Instead, the device reports a second LUN of:
00 00 00 00 00 00 00 01
This is invalid as it uses all four addressing levels, not the single
level LUN structure.
I think a quirk will be needed here, for example one that ignores the
list entries and looks at the length of the list only, assuming that for
a list of length n, the LUNs will be 0, 1, 2, ..., n - 1.
Replying to myself one last time, the kind of quirk I was thinking of
actually does exist already. It is called CAM_QUIRK_NORPTLUNS. Enabling
this quirk fixes the issue for me - both LUNs are detected and two umass
At Sun, 08 Jan 2012 21:06:57 +0200,
Bartosz Fabianowski wrote:
> Replying to myself one last time, the kind of quirk I was thinking of
> actually does exist already. It is called CAM_QUIRK_NORPTLUNS. Enabling
> this quirk fixes the issue for me - both LUNs are detected and two umass
> devices appear.
> I submitted a patch in the following PR:
I now aware of why my da1 did not appear once I tried this quirk
the other day; I set it FIXED device. It should be REMOVABLE device
ugen0.5: <vendor 0x091e> at usbus0
umass0: <vendor 0x091e product 0x2271, class 0/0, rev 1.10/5.09, addr 5> on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x4000
umass0:10:0:-1: Attached to scbus10
da0 at umass-sim0 bus 0 scbus10 target 0 lun 0
da0: <Garmin Edge 705 Flash 1.00> Removable Direct Access SCSI-5 device
da0: 1.000MB/s transfers
da0: 976MB (1998848 512 byte sectors: 64H 32S/T 976C)
da1 at umass-sim0 bus 0 scbus10 target 0 lun 1
da1: <Garmin Edge 705 SD Card 1.00> Removable Direct Access SCSI-5 device
da1: 1.000MB/s transfers
da1: 1910MB (3911680 512 byte sectors: 255H 63S/T 243C)
> Thanks for the pointers and discussion that led to this solution.