umass regression

[Hans Petter Selasky]

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 [1]. This dump covers 30 seconds from
> plugging in.
>
> - Bartosz
>
> [1] http://www.fabianowski.eu/garmin_dakota_20_attach.usbdump

Hi,

1)

The following transaction shows that the device supports two luns. I suspect
that there is a miscommunication between UMASS and CAM layer.

 frame[0] WRITE 8 bytes
 0000  A1 FE 00 00 00 00 01 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 1 bytes
 0000  01 -- -- -- -- -- -- --  -- -- -- -- -- -- -- --  |.               |

Does anyone @ current know how this should be properly done?

2)

The 31-byte messages is a UMASS header containing the SCSI command:

http://fxr.watson.org/fxr/source/dev/usb/storage/umass.c#L249

18:42:08.572437 usbus1.8 SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=32,IVAL=0
 frame[0] WRITE 31 bytes
 0000  55 53 42 43 02 00 00 00  10 00 00 00 80 00 0C A0  |USBC............|
                                               ^^ LUN
                                                  ^^ LEN + SCSI command
 0010  00 00 00 00 00 00 00 00  10 00 00 00 00 00 00 --  |............... |

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[poyopoyo]

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.

Hi,

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.

--
kuro
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Bartosz Fabianowski]

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
[1]):

* SCSI command "REPORT LUNS" is sent:

55 53 42 43 03 00 00 00  18 00 00 00 80 00 0C A0
00 00 00 00 00 00 00 00  18 00 00 00 00 00 00

* List of LUNs is received:

00 00 00 10 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01

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.

- Bartosz
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Bartosz Fabianowski]

I managed to snip out the link I was referring to, here it is:

[1] http://www.fabianowski.eu/garmin_dakota_20_attach.usbdump
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Bartosz Fabianowski]

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
the form:

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.

- Bartosz
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Bartosz Fabianowski]

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:

http://www.freebsd.org/cgi/query-pr.cgi?pr=163932

Thanks for the pointers and discussion that led to this solution.

- Bartosz
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[poyopoyo]

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:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=163932

Hi,
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
as yours.

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.

Thank you very much. Great analysis.

--
kuro
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"