* Re: usb storage traces
@ 2003-11-10 22:04 Pat LaVarre
2003-11-11 21:59 ` Pat LaVarre
0 siblings, 1 reply; 35+ messages in thread
From: Pat LaVarre @ 2003-11-10 22:04 UTC (permalink / raw)
To: linux-scsi
If anyone here already has ...
... traces of Win XP/2K with DVD/CD as life begins after plug in ...
... you could save me some work by sharing those now.
Pat LaVarre
P.S. Yes I am now continuing that effort last snapshot as:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106427309605764
>
> List: linux-scsi
> Subject: usb storage traces
> Date: 2003-09-22 23:25:17
> From: Pat LaVarre ...
>
> > > Tell me we care to hear specifically what
> > > some win sends to some of my usb hdd/rmb,
> > > and I'll go collect a few sample usb bus
> > > traces.
> >
> > From: Andries... Brouwer...
> > Date: Tue, 23 Sep 2003 01:07:59 +0200 (MEST)
> >
> > I'll collect and publish.
> > (Change the subject line to "USB storage
> > traces" or so.)
> > Must have some old traces somewhere myself too.
>
> ... I'm replying before you publish
> only to confirm we agree we wish to survey ...
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-11-10 22:04 usb storage traces Pat LaVarre
@ 2003-11-11 21:59 ` Pat LaVarre
2003-11-13 18:42 ` Pat LaVarre
0 siblings, 1 reply; 35+ messages in thread
From: Pat LaVarre @ 2003-11-11 21:59 UTC (permalink / raw)
To: linux-scsi
> ... traces of Win XP/2K with DVD/CD
> as life begins after plug in ...
Saw one, thanks.
Wow. Lookathat. At least once on Earth, we saw Microsoft Windows Do
The Right Thing according to T10. Wow. Maybe Microsoft wrote the pdt
x05 DVD/CD code after being informed by their history of pain with pdt
x00 HDD/flash?
I actually saw Win XP SP1 begin life after plug in with three
politically correct speeches:
1) GPCMD_INQUIRY for standard length:
gccscsi -i x24 -y "12 00:00:00 24 00"
2) GPCMD_GET_CONFIGURATION for header alone:
gccscsi -i 8 -y "46 00 00:00:00:00 00 00:08 00"
3) GPCMD_GET_CONFIGURATION for offset + field length + value of
additionalLength field, which for this sample drive was:
gccscsi -i xF8 -y "46 00 00:00:00:00 00 00:F8 00"
Wow. Lookathat.
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <20031219091450.GC828@one-eyed-alien.net>]
* Re: usb storage traces
[not found] <20031219091450.GC828@one-eyed-alien.net>
@ 2003-12-19 14:51 ` Alan Stern
2003-12-19 16:21 ` Pat LaVarre
2003-12-20 23:56 ` Matthew Dharm
0 siblings, 2 replies; 35+ messages in thread
From: Alan Stern @ 2003-12-19 14:51 UTC (permalink / raw)
To: Matthew Dharm
Cc: Pat LaVarre, David Brownell, Alex Sanks, Julian Back,
USB Storage List, SCSI development list
On Fri, 19 Dec 2003, Matthew Dharm wrote:
> On Fri, Dec 12, 2003 at 03:48:06PM -0700, Pat LaVarre wrote:
> > > Also, I'm open to requests for particular host/device option
> > > combinations.
> >
> > My wish list is:
> >
> > a) Device = x 08 (02|05|06) 50 = msft win generic usb-storage.
>
> Did anyone ever get a chance to capture this data?
>
> Matt
Andries Brouwer has just created a web page to hold USB Mass Storage
traces, and I have submitted the ones I've had time to collect so far.
They include Pat LaVarre's wish list, but only for Windows ME -- other
versions of Windows will have to wait until the New Year or after.
The URL for my traces is:
http://www.win.tue.nl/~aeb/linux/usb/traces/winme/
Also present in that directory is a README.txt file, although it doesn't
show up in the default directory listing. You can retrieve it through
http://www.win.tue.nl/~aeb/linux/usb/traces/winme/README.txt
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-19 14:51 ` Alan Stern
@ 2003-12-19 16:21 ` Pat LaVarre
2003-12-20 23:56 ` Matthew Dharm
1 sibling, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-19 16:21 UTC (permalink / raw)
To: Alan Stern
Cc: linux-scsi, usb-storage, Matthew Dharm, David Brownell,
Alex Sanks, Julian Back
> The URL for my traces is:
> http://www.win.tue.nl/~aeb/linux/usb/traces/winme/
Thank you!
> ... doesn't show up in the default directory listing ...
> http://www.win.tue.nl/~aeb/linux/usb/traces/winme/README.txt
To the wish list for RMB please add:
Traces of disk absent (not just traces of disk present).
> One interesting thing about Windows ME
> stands out from reading the files:
> It seems to think the right way to recover
> from a "device was reset" response is to reset the device twice!
On my second reading I guess we here mean to be speaking of sk asc x 6
29. I agree, silly to respond to a notification of reset received by
sending another reset.
On my first reading I wrongly guessed we here were speaking of some
other kind of trouble, to which I answered:
Why should this surprise us?
Reset, like any i/o operation, may fail. Hosts that live by
"be liberal in what you accept" time out and retry resets, yes. In
particular, by trying twice we more liberally tolerate those apparently
generic devices that in fact occasionally choose to scramble the status
phase data toggle at the end of a class-specific reset. Naive hosts see
that as indefinite NAK.
Pat LaVarre
http://plavarre.blog-city.com/index.cfm?d=19&m=12&y=2003
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-19 14:51 ` Alan Stern
2003-12-19 16:21 ` Pat LaVarre
@ 2003-12-20 23:56 ` Matthew Dharm
2003-12-21 2:26 ` Alan Stern
1 sibling, 1 reply; 35+ messages in thread
From: Matthew Dharm @ 2003-12-20 23:56 UTC (permalink / raw)
To: Alan Stern
Cc: Pat LaVarre, David Brownell, Alex Sanks, Julian Back,
USB Storage List, SCSI development list
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
Looking at your traces, I don't see any MODE SENSE commands. I find that
odd, especially since earlier traces show that data.
Looking at them, I'm starting to suspect that you need to have a valid
filesystem there before Windows will issue that command. What an odd way
to do things....
Anyway, could you add that to your test cases?
The data you've provided so far is excellent.
Matt
On Fri, Dec 19, 2003 at 09:51:12AM -0500, Alan Stern wrote:
> On Fri, 19 Dec 2003, Matthew Dharm wrote:
>
> > On Fri, Dec 12, 2003 at 03:48:06PM -0700, Pat LaVarre wrote:
> > > > Also, I'm open to requests for particular host/device option
> > > > combinations.
> > >
> > > My wish list is:
> > >
> > > a) Device = x 08 (02|05|06) 50 = msft win generic usb-storage.
> >
> > Did anyone ever get a chance to capture this data?
> >
> > Matt
>
> Andries Brouwer has just created a web page to hold USB Mass Storage
> traces, and I have submitted the ones I've had time to collect so far.
> They include Pat LaVarre's wish list, but only for Windows ME -- other
> versions of Windows will have to wait until the New Year or after.
>
> The URL for my traces is:
>
> http://www.win.tue.nl/~aeb/linux/usb/traces/winme/
>
> Also present in that directory is a README.txt file, although it doesn't
> show up in the default directory listing. You can retrieve it through
>
> http://www.win.tue.nl/~aeb/linux/usb/traces/winme/README.txt
>
> Alan Stern
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed
suction darts!
-- Salesperson to Greg
User Friendly, 12/30/1997
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-20 23:56 ` Matthew Dharm
@ 2003-12-21 2:26 ` Alan Stern
0 siblings, 0 replies; 35+ messages in thread
From: Alan Stern @ 2003-12-21 2:26 UTC (permalink / raw)
To: Matthew Dharm
Cc: Pat LaVarre, David Brownell, Alex Sanks, Julian Back,
USB Storage List, SCSI development list
On Sat, 20 Dec 2003, Matthew Dharm wrote:
> Looking at your traces, I don't see any MODE SENSE commands. I find that
> odd, especially since earlier traces show that data.
>
> Looking at them, I'm starting to suspect that you need to have a valid
> filesystem there before Windows will issue that command. What an odd way
> to do things....
Could be. Or it could be a difference between Windows ME and Windows
2000.
> Anyway, could you add that to your test cases?
I will.
> The data you've provided so far is excellent.
Thank you. More to come after the holidays.
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <1070649445.12411.347.camel@patibmrh9>]
* Re: usb storage traces
[not found] <1070649445.12411.347.camel@patibmrh9>
@ 2003-12-05 19:27 ` Alan Stern
2003-12-05 20:27 ` Pat LaVarre
0 siblings, 1 reply; 35+ messages in thread
From: Alan Stern @ 2003-12-05 19:27 UTC (permalink / raw)
To: Pat LaVarre; +Cc: SCSI development list
On 5 Dec 2003, Pat LaVarre wrote:
> > Anyway, the page x08 data indicates WCE off. So maybe Windows was just
> > trying to turn it on
>
> Apparently yes. Cool, thanks for sharing. I'm now guessing this occurs
> only when rmb is clear.
>
> If so, then we can say msft turns write-behind etc. on when the drive is
> hot-pluggable, but turns write-behind etc. off when the disk is fully
> hot-pluggable or even only hot-pluggable while not prevented. Not good
> policy, though too late now I suppose.
Be careful with your nomenclature. Hot-pluggable and removable-media are
two different things.
> That reality will encourage device folk to virtually unplug the drive
> when the disk ejects ... else disconnect mode page x08 from reality.
>
> > There was a prior x1a = MODE-SENSE(6) for page x08. Here is the returned
> > data:
> >
> > 12 00 00 00 00 00 00 00 08 0a 00 00 00 00 00 00
> > 00 00 00 00
> >
> > I read this as: mode data length = 18 (inconsistent with the amount of
> > returned data, which is 19 bytes not counting the mode data length byte
> > itself),
>
> Help I'm lost.
>
> Did we get these plain hex bytes via Windows, rather than from a bus
> trace? They internally contradict themselves.
>
> Have we unwittingly involved the slightly broken Win mode sense 6/10
> translator? This plain hex could be the result from a compliant device
> if what actually crossed the bus was an op x5A mode sense 10, and then
> Win gave us the data in unedited, even after Win had helpfully edited
> the cdb we asked to send.
The trace came from USB Snoopy. I don't know enough about the internals
of Windows to say whether the data have been mangled or not.
> > these plain hex bytes ... internally contradict themselves.
>
> Digital numbers have value and length, not just value.
>
> Yes x 08 0a 00 00 00 00 00 00 00 00 00 00 appears to be an x0C (12) byte
> mode page.
>
> But x 12 00 00 00 00 00 00 00 appears to be an eight byte header for op
> x5A mode sense 10, which by ANSI T10 SPC definition contains the
> additional length x 12 00, which at offset zero fits a total available
> length of x14 (20), which is the number of data bytes you quote.
>
> But we say we traced op x1A mode sense 6, not op x5A mode sense 10.
>
> Help?
Don't ask me, I don't know.
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-05 19:27 ` Alan Stern
@ 2003-12-05 20:27 ` Pat LaVarre
0 siblings, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-05 20:27 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-scsi
> > If so, then we can say msft turns write-behind etc. on when the drive is
> > hot-pluggable, but turns write-behind etc. off when the disk is fully
> > hot-pluggable or even only hot-pluggable while not prevented. Not good
> > policy, though too late now I suppose.
>
> Be careful with your nomenclature. Hot-pluggable and removable-media are
> two different things.
Sorry I was unclear. I mean to say Four things:
a) Write-behind risks more if people commonly do yank the device cable
or the disk itself while an fs of the disk is mounted.
b) Here we may be seeing msft choose to reduce thruput by turning off
write-behind while still shattering streams into just a few bytes/cdb.
c) Here we may be seeing msft making this choice whenever the device
sets op x12 Inquiry bytes[1] & x80 RMB to say the disk can unplug
without the drive unplugging.
d) Massively distributing host silliness like that provokes silliness in
device design. Give an advantage to devices that don't say the disk can
unplug without the drive unplugging, and more devices will learn to
electronically unplug the drive when the disk unplugs.
Is my jargon still wrong? Am I still unclear? If I have failed again
might you tell me?
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
@ 2003-12-04 18:30 Alan Stern
2003-12-04 18:44 ` Matthew Dharm
2003-12-05 4:31 ` Douglas Gilbert
0 siblings, 2 replies; 35+ messages in thread
From: Alan Stern @ 2003-12-04 18:30 UTC (permalink / raw)
To: SCSI development list
Here is a digested version of a log trace contributed by Alex Sanks. It
was collected from a generic USB Bulk-only storage device (actually the
g_file_storage file-backed storage gadget) attached to a host running
Windows XP SP1. It agrees quite well with the results of my own tests
using USB Snoopy on a Windows 2000 host.
In this trace, the number following the command name is the command length
in decimal; following it are the command bytes in hex, then the direction
and transfer length in decimal.
INQUIRY 6: 12 00 00 00 24 00 In 36
Vendor-specific 10: 23 00 00 00 00 00 00 00 fc 00 In 252
Provokes an Invalid Command error
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
Bug in Windows: REQUEST-SENSE is really a 6-byte command
Vendor-specific 10: 23 00 00 00 00 00 00 00 fc 00 In 252
Retry previous failed command; it still doesn't work
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
Vendor-specific 10: 23 00 00 00 00 00 00 00 fc 00 In 252
Another futile retry
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
Provokes Unit Attention: Reset Occurred
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
This time it works
READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
Read the first sector
READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
Windows likes reading the first sector
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
It also likes reading the disk capacity
MODE-SENSE 6: 1a 00 1c 00 c0 00 In 192
Page 1c is listed as reserved; I don't know what it is;
provokes Invalid Field in CDB error
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
MODE-SENSE 6: 1a 00 3f 00 c0 00 In 192
So page 3f should work if we request 192 bytes!
MODE-SENSE 6: 1a 00 08 00 c0 00 In 192
And so should page 08!
MODE-SELECT 6: 15 10 00 00 18 00 Out 24
Although not shown here, a USB Snoopy trace reveals that this
attempts to set the WCE (write cache enable) bit in page 8;
here it provokes Invalid Field in CDB error
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
MODE-SELECT 6: 15 10 00 00 18 00 Out 24
Retry of previous failed command; it fails again
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
Windows really likes to get the capacity!
READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
And it really likes to read the first sector!
READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
Ommitted: this command was repeated 8 times
TEST-UNIT-READY 6: 00 00 00 00 00 00
MODE-SENSE 6: 1a 00 00 00 0c 00 In 12
I don't know what Windows expects to find in page 0;
but this fails
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
Ommitted: this command was repeated 3 times
TEST-UNIT-READY 6: 00 00 00 00 00 00
MODE-SENSE 6: 1a 00 00 00 0c 00 In 12
Fails again
REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
Some of the activity may depend on the contents of the partition table
stored in the first sector. But it seems clear that, subject to the
unknown function of command x23 and of mode page x1c, we might be able to
work with devices that advertise themselves as Bulk-only by requesting 192
bytes from page x3f and page 8.
Does anybody know what command x23 and mode page x1c do? Although
nominally vendor-specific, they must be reasonably standardized if Windows
can get away with using them on a generic device.
Unfortunately, there's nothing to stop a manufacturer from supplying their
own driver which would avoid reading those pages. So even an apparently
normal device might react badly to these commands. However I think it's
still worth a try.
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-04 18:30 Alan Stern
@ 2003-12-04 18:44 ` Matthew Dharm
2003-12-04 20:59 ` Alan Stern
2003-12-05 4:31 ` Douglas Gilbert
1 sibling, 1 reply; 35+ messages in thread
From: Matthew Dharm @ 2003-12-04 18:44 UTC (permalink / raw)
To: Alan Stern; +Cc: SCSI development list
[-- Attachment #1: Type: text/plain, Size: 5346 bytes --]
Did the device advertise 'generic scsi' or one of the other protocol codes?
Microsoft has published information that indicates that they 'translate'
the mode-sense commands into the 10-byte variants for everything bug
'transparent scsi' -- I think actually seeing that information would be
necessary in constructing a new algorithm for Linux.
Matt
On Thu, Dec 04, 2003 at 01:30:16PM -0500, Alan Stern wrote:
> Here is a digested version of a log trace contributed by Alex Sanks. It
> was collected from a generic USB Bulk-only storage device (actually the
> g_file_storage file-backed storage gadget) attached to a host running
> Windows XP SP1. It agrees quite well with the results of my own tests
> using USB Snoopy on a Windows 2000 host.
>
> In this trace, the number following the command name is the command length
> in decimal; following it are the command bytes in hex, then the direction
> and transfer length in decimal.
>
>
> INQUIRY 6: 12 00 00 00 24 00 In 36
> Vendor-specific 10: 23 00 00 00 00 00 00 00 fc 00 In 252
> Provokes an Invalid Command error
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
> Bug in Windows: REQUEST-SENSE is really a 6-byte command
>
> Vendor-specific 10: 23 00 00 00 00 00 00 00 fc 00 In 252
> Retry previous failed command; it still doesn't work
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
> Vendor-specific 10: 23 00 00 00 00 00 00 00 fc 00 In 252
> Another futile retry
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
>
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
> Provokes Unit Attention: Reset Occurred
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
> This time it works
>
> READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
> Read the first sector
> READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
> Windows likes reading the first sector
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
> It also likes reading the disk capacity
>
> MODE-SENSE 6: 1a 00 1c 00 c0 00 In 192
> Page 1c is listed as reserved; I don't know what it is;
> provokes Invalid Field in CDB error
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
>
> MODE-SENSE 6: 1a 00 3f 00 c0 00 In 192
> So page 3f should work if we request 192 bytes!
>
> MODE-SENSE 6: 1a 00 08 00 c0 00 In 192
> And so should page 08!
>
> MODE-SELECT 6: 15 10 00 00 18 00 Out 24
> Although not shown here, a USB Snoopy trace reveals that this
> attempts to set the WCE (write cache enable) bit in page 8;
> here it provokes Invalid Field in CDB error
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
>
> MODE-SELECT 6: 15 10 00 00 18 00 Out 24
> Retry of previous failed command; it fails again
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
>
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
> Windows really likes to get the capacity!
> READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
> And it really likes to read the first sector!
> READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
> READ 10: 28 00 00 00 00 00 00 00 01 00 In 512
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
> Ommitted: this command was repeated 8 times
>
> TEST-UNIT-READY 6: 00 00 00 00 00 00
> MODE-SENSE 6: 1a 00 00 00 0c 00 In 12
> I don't know what Windows expects to find in page 0;
> but this fails
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
>
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
> Ommitted: this command was repeated 3 times
>
> TEST-UNIT-READY 6: 00 00 00 00 00 00
> MODE-SENSE 6: 1a 00 00 00 0c 00 In 12
> Fails again
> REQUEST-SENSE 12: 03 00 00 00 12 00 00 00 00 00 00 00 In 18
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
> READ-CAPACITY 10: 25 00 00 00 00 00 00 00 00 00 In 8
>
>
> Some of the activity may depend on the contents of the partition table
> stored in the first sector. But it seems clear that, subject to the
> unknown function of command x23 and of mode page x1c, we might be able to
> work with devices that advertise themselves as Bulk-only by requesting 192
> bytes from page x3f and page 8.
>
> Does anybody know what command x23 and mode page x1c do? Although
> nominally vendor-specific, they must be reasonably standardized if Windows
> can get away with using them on a generic device.
>
> Unfortunately, there's nothing to stop a manufacturer from supplying their
> own driver which would avoid reading those pages. So even an apparently
> normal device might react badly to these commands. However I think it's
> still worth a try.
>
> Alan Stern
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
Hey Chief. We've figured out how to save the technical department. We
need to be committed.
-- The Techs
User Friendly, 1/22/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-04 18:44 ` Matthew Dharm
@ 2003-12-04 20:59 ` Alan Stern
2003-12-04 21:27 ` Matthew Dharm
` (5 more replies)
0 siblings, 6 replies; 35+ messages in thread
From: Alan Stern @ 2003-12-04 20:59 UTC (permalink / raw)
To: Matthew Dharm
Cc: Pat LaVarre, Alex Sanks, Julian Back, David Brownell,
SCSI development list
On Thu, 4 Dec 2003, Matthew Dharm wrote:
> Did the device advertise 'generic scsi' or one of the other protocol codes?
>
> Microsoft has published information that indicates that they 'translate'
> the mode-sense commands into the 10-byte variants for everything bug
> 'transparent scsi' -- I think actually seeing that information would be
> necessary in constructing a new algorithm for Linux.
>
> Matt
It was generic (transparent) scsi.
Perhaps I'll try implementing some of the other protocol codes in FSG,
maybe also the "removeable media" flag. This would also require
implementing the PREVENT-ALLOW-MEDIUM-REMOVAL, READ-FORMAT-CAPACITIES, and
START-STOP, possibly also REZERO-UNIT, SEEK, READ(12), and WRITE(12).
(1). Am I missing anything important?
(2). Can I afford to leave out some of those? The last four don't look
very useful.
As I understand it, the only real difference between the protocols is that
everything but transparent scsi and RBC requires padding the commands to
12 bytes. Pat LaVarre says that protocols x02 (SFF-8020i = CD/DVD) and
x05 (SFF-8070i = Removeable media, floppy) are the most important, since
they are the only other ones the generic Windows USB mass storage drivers
recognize.
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-04 20:59 ` Alan Stern
@ 2003-12-04 21:27 ` Matthew Dharm
2003-12-04 21:33 ` Pat LaVarre
` (4 subsequent siblings)
5 siblings, 0 replies; 35+ messages in thread
From: Matthew Dharm @ 2003-12-04 21:27 UTC (permalink / raw)
To: Alan Stern
Cc: Pat LaVarre, Alex Sanks, Julian Back, David Brownell,
SCSI development list
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On Thu, Dec 04, 2003 at 03:59:58PM -0500, Alan Stern wrote:
> On Thu, 4 Dec 2003, Matthew Dharm wrote:
>
> > Did the device advertise 'generic scsi' or one of the other protocol codes?
> >
> > Microsoft has published information that indicates that they 'translate'
> > the mode-sense commands into the 10-byte variants for everything bug
> > 'transparent scsi' -- I think actually seeing that information would be
> > necessary in constructing a new algorithm for Linux.
>
> It was generic (transparent) scsi.
>
> Perhaps I'll try implementing some of the other protocol codes in FSG,
> maybe also the "removeable media" flag. This would also require
> implementing the PREVENT-ALLOW-MEDIUM-REMOVAL, READ-FORMAT-CAPACITIES, and
> START-STOP, possibly also REZERO-UNIT, SEEK, READ(12), and WRITE(12).
>
> (1). Am I missing anything important?
Based on the information I've seen, any one of the other protocol codes
will be fine -- you don't need to do all, just transparent SCSI and one
other. Of course, all codes would be good for testing.
> (2). Can I afford to leave out some of those? The last four don't look
> very useful.
I agree about the last four. I can't think of anything else that might be
good to test.
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
G: Money isn't everything, A.J.
AJ: Who convinced you of that?
G: The Chief, at my last salary review.
-- Mike and Greg
User Friendly, 11/3/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-04 20:59 ` Alan Stern
2003-12-04 21:27 ` Matthew Dharm
@ 2003-12-04 21:33 ` Pat LaVarre
2003-12-04 21:34 ` Pat LaVarre
` (3 subsequent siblings)
5 siblings, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-04 21:33 UTC (permalink / raw)
To: Matthew Dharm, Alan Stern
Cc: linux-scsi, Alex Sanks, Julian Back, David Brownell
> > From: Matthew Dharm ...
> >
> > Microsoft has published information that indicates that they
> > 'translate' the mode-sense commands into the 10-byte variants for
> > everything bug 'transparent scsi' -- I think actually seeing that
> > information would be necessary in constructing a new algorithm for
> > Linux.
> ...
> As I understand it, the only real difference between the protocols is that
> everything but transparent scsi and RBC requires padding the commands to
> 12 bytes.
diff vs. bInterfaceSubClass=x06 as sketched by MSFT is as follows.
---
From: http://www.microsoft.com/whdc/hwdev/bus/usb/usbfaq.mspx
...
Usbstor.sys and Device Class Support
Q: Which device classes does usbstor.sys understand?
In Windows XP, Windows 2000, and Windows Me, usbstor.sys makes only one
distinction:
bInterfaceSubClass == 06h
- OR -
bInterfaceSubClass != 06h
The value bInterfaceSubClass == 06h means that:
Command descriptor blocks (CDBs) should not be padded to 12 bytes.
Mode Sense / Mode Select commands should not be translated from 1AH /
15h to 5AH / 55h.
Subclass 0x06 should generally be used for flash memory devices.
The value bInterfaceSubClass != 06h means that:
CDBs should be padded to 12 bytes.
Mode Sense / Mode Select commands should be translated from 1AH / 15h to
5AH / 55h.
---
Includes a plea I nutshell as { generic usb flash = x 08 06 50 }.
To make sense of this text we have to remember Linux usb-storage
"protocols" = usb.org bInterfaceSubClass != usb.org bInterfaceProtocol.
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-04 20:59 ` Alan Stern
2003-12-04 21:27 ` Matthew Dharm
2003-12-04 21:33 ` Pat LaVarre
@ 2003-12-04 21:34 ` Pat LaVarre
2003-12-04 21:37 ` Pat LaVarre
` (2 subsequent siblings)
5 siblings, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-04 21:34 UTC (permalink / raw)
To: Alan Stern
Cc: Matthew Dharm, Alex Sanks, Julian Back, David Brownell,
SCSI development list
> Pat LaVarre says that protocols x02 (SFF-8020i = CD/DVD) and
> x05 (SFF-8070i = Removeable media, floppy) are the most important, since
> they are the only other ones the generic Windows USB mass storage drivers
> recognize.
I mean to be paraphrasing the windows/inf/usbstor.inf quotation:
...
[Generic]
%GenericBulkOnly.DeviceDesc%=USBSTOR_BULK, USB\Class_08&SubClass_02&Prot_50
%GenericBulkOnly.DeviceDesc%=USBSTOR_BULK, USB\Class_08&SubClass_05&Prot_50
%GenericBulkOnly.DeviceDesc%=USBSTOR_BULK, USB\Class_08&SubClass_06&Prot_50
[...
>From that quotation I ignorantly guess that plugging anything other than
x 08 (02|05|06) 50 into Win XP/ 2K/ ME requires an idVendor:idProduct
match (possibly already found elsewhere in Windows e.g. elsewhere in
that same file), else installing a driver (possibly as trivial as
additional .inf text) to match the device.
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-04 20:59 ` Alan Stern
` (2 preceding siblings ...)
2003-12-04 21:34 ` Pat LaVarre
@ 2003-12-04 21:37 ` Pat LaVarre
2003-12-04 21:38 ` Pat LaVarre
2003-12-05 5:08 ` Patrick Mansfield
5 siblings, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-04 21:37 UTC (permalink / raw)
To: Alan Stern
Cc: Matthew Dharm, Alex Sanks, Julian Back, David Brownell,
SCSI development list
> As I understand it, the only real difference between the protocols is
> that everything but transparent scsi and RBC requires padding the
> commands to 12 bytes.
If we dig I believe we can unearth specific binary incompatibilities
among the de jure paper definitions of bInterfaceSubClass.
Me, I invented bInterfaceSubClass = x06 in 1998 to give my device a way
of reporting that I chose to perpetuate my employer's binary-code-only
legacy of an ANSI T10 SPC interpretation, rather than abandoning that
legacy in favour of the technically binary incompatible SFF proposal
which had not yet become ANSI T10 MMC.
For example, SFF/ MMC requires the device to zero the the byte 2 Version
of op x12 Inquiry data, SCSI-2/ SPC recommends nonzero. SFF/ MMC
requires the device to exclude block descriptors from mode sense data,
SCSI-2/ SPC recommends inclusion.
Hopefully we will find SFF/ MMC never requires something SCSI-2/ SPC
actually forbids.
Hopefully we will find we only dig up insignificant incompatibilities.
I think I remember these binary incompatibilities didn't appear
officially incorporated into ANSI T10 until bleeding-edge T10 (= MMC 4,
trails SFF) i.e. may be absent from last stable T10 (= MMC 3).
Frustrates me that clueless folk repeatedly design pointless binary
incompatibility into competing SCSI definitions. For example, the SFF
folk could have ducked the block descriptor issue by requiring the host
to set the standard mode sense cdb bit that disables block descriptors.
Instead the SFF folk pointlessly chose to require the host and the
device to redefine what a zero bit there means. I've heard the latest
SFF drafts try to patch up this mess somehow.
Truth or slander I do not know, but I've heard that the RBC folk messed
up legacy mode sense, and that some FireWire folk neglected to implement
legacy op x12 Inquiry (!!!).
Once upon a time, the usb.org bInterfaceSubClass = x06 specifications
very carefully referenced no specific de jure paper. The original
English for x06 was something like "Windows, Linux, Mac, Sun SCSI".
People lost the sense of that by voting in the replacement text
"Transparent SCSI". In the time since, people may have polluted that
accurately pure description by linking to technically less than
completely accurate texts.
So far as I know, we have no executable specification of SCSI in open
source, unless you count Linux itself, which by being designed to work
consciously includes such redefining exceptions as the
US_FL_FIX_CAPACITY of drivers/usb/storage/unusual_devs.h.
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-04 20:59 ` Alan Stern
` (3 preceding siblings ...)
2003-12-04 21:37 ` Pat LaVarre
@ 2003-12-04 21:38 ` Pat LaVarre
2003-12-04 22:24 ` Pat LaVarre
2003-12-05 5:08 ` Patrick Mansfield
5 siblings, 1 reply; 35+ messages in thread
From: Pat LaVarre @ 2003-12-04 21:38 UTC (permalink / raw)
To: linux-scsi
Cc: Alan Stern, Matthew Dharm, Alex Sanks, Julian Back,
David Brownell
> > > > As before, if still now always we each launch a new thread
> > > > to reply to posts of this thread, then this thread will grow
> > > > to contain only an index of usb storage traces.
> > >
> > > Subject: Re: usb storage traces
> > Subject: Re: usb storage traces
> Subject: Re: usb storage traces
Ouch I see we've lost control of this thread. Hopefully someone better
connected than I will volunteer ...
... to go create a web page offline to keep track of contributed
usb-storage traces.
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-04 21:38 ` Pat LaVarre
@ 2003-12-04 22:24 ` Pat LaVarre
2003-12-04 22:28 ` Pat LaVarre
2003-12-05 15:01 ` Alan Stern
0 siblings, 2 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-04 22:24 UTC (permalink / raw)
To: Alan Stern
Cc: linux-scsi, Matthew Dharm, Alex Sanks, Julian Back,
David Brownell
> Does anybody know what ... mode page x1c do? Although
> nominally vendor-specific, they must be reasonably standardized if Windows
> can get away with using them on a generic device.
I fetch my SPC guess from the web as follows. As ever we cannot know if
MMC contradicts unless we check nearby. To sort these clicks from most
to least applicable I logged them in reverse chronological order.
1Ch = Informational Exceptions Control
page 297 of 467 ...
7.4.5 Mode page and subpage formats and page codes ...
page 299 of 467 ...
Table 222 -- Mode page codes
SCSI Primary Commands - 3 (SPC-3)
http://www.t10.org/ftp/t10/drafts/spc3/spc3r15.pdf
SPC-3 SCSI Primary Commands - 3 ...
http://www.t10.org/drafts.htm#spc3
ANSI T10
http://www.t10.org/scsi-3.htm
Fun: Ramshackle World
http://members.aol.com/ppaatt/essay/why/
Pat LaVarre
http://members.aol.com/ppaatt/
http://www.google.com/search?q=Pat+LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-04 22:24 ` Pat LaVarre
@ 2003-12-04 22:28 ` Pat LaVarre
2003-12-05 15:01 ` Alan Stern
1 sibling, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-04 22:28 UTC (permalink / raw)
To: Alan Stern
Cc: linux-scsi, Matthew Dharm, Alex Sanks, Julian Back,
David Brownell
> MODE-SENSE 6: 1a 00 00 00 0c 00 In 12
> I don't know what Windows expects to find in page 0;
> but this fails
Last I checked, page 0 was vendor-specific. I don't clearly remember if
the header before page 0 was standard. If yes, then Win could be
legitly fetching header alone e.g. to check write-protect.
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-04 22:24 ` Pat LaVarre
2003-12-04 22:28 ` Pat LaVarre
@ 2003-12-05 15:01 ` Alan Stern
2003-12-05 17:19 ` Pat LaVarre
1 sibling, 1 reply; 35+ messages in thread
From: Alan Stern @ 2003-12-05 15:01 UTC (permalink / raw)
To: Pat LaVarre
Cc: linux-scsi, Matthew Dharm, Alex Sanks, Julian Back,
David Brownell
On 4 Dec 2003, Pat LaVarre wrote:
> > Does anybody know what ... mode page x1c do? Although
> > nominally vendor-specific, they must be reasonably standardized if Windows
> > can get away with using them on a generic device.
According to my newly-located source, page x1c is the Timer and Protect
page. It includes values for the Inactivity Time Multiplier, Disable
Media Access, and Software Write Protect.
Windows may use it to try and set the drive's spin-down time.
Incidentally, Pat, can you confirm whether bInterfaceSubClass x01 = RBC
(Reduced Block Commands, T10 project 1240-D) uses 0-padding of commands to
12 bytes or not? The Linux usb-storage driver seems to think that it
doesn't.
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-05 15:01 ` Alan Stern
@ 2003-12-05 17:19 ` Pat LaVarre
2003-12-05 18:22 ` Alan Stern
0 siblings, 1 reply; 35+ messages in thread
From: Pat LaVarre @ 2003-12-05 17:19 UTC (permalink / raw)
To: Alan Stern
Cc: linux-scsi, Matthew Dharm, Alex Sanks, Julian Back,
David Brownell
> According to my newly-located source,
Source has url?
> page x1c ... includes ... Software Write Protect.
I remember software write protect as being one of the ways in which the
SFF 8070i Compaq LS-120 manual was an inaccurate description of other
RMB PDT x00 HDD/ Flash. Also bleeding-edge MMC has a totally different
"SWP".
> Windows may use it to try and set the drive's spin-down time.
Sorry I do not know.
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-05 17:19 ` Pat LaVarre
@ 2003-12-05 18:22 ` Alan Stern
0 siblings, 0 replies; 35+ messages in thread
From: Alan Stern @ 2003-12-05 18:22 UTC (permalink / raw)
To: Pat LaVarre
Cc: linux-scsi, Matthew Dharm, Alex Sanks, Julian Back,
David Brownell
On 5 Dec 2003, Pat LaVarre wrote:
> > page x1c ... includes ... Software Write Protect.
>
> I remember software write protect as being one of the ways in which the
> SFF 8070i Compaq LS-120 manual was an inaccurate description of other
> RMB PDT x00 HDD/ Flash. Also bleeding-edge MMC has a totally different
> "SWP".
>
> > Windows may use it to try and set the drive's spin-down time.
>
> Sorry I do not know.
>
> Pat LaVarre
Never mind. It's not worth worrying about; I just won't support it.
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-04 20:59 ` Alan Stern
` (4 preceding siblings ...)
2003-12-04 21:38 ` Pat LaVarre
@ 2003-12-05 5:08 ` Patrick Mansfield
2003-12-05 16:01 ` Alan Stern
5 siblings, 1 reply; 35+ messages in thread
From: Patrick Mansfield @ 2003-12-05 5:08 UTC (permalink / raw)
To: Alan Stern
Cc: Matthew Dharm, Pat LaVarre, Alex Sanks, Julian Back,
David Brownell, SCSI development list
On Thu, Dec 04, 2003 at 03:59:58PM -0500, Alan Stern wrote:
> It was generic (transparent) scsi.
>
> Perhaps I'll try implementing some of the other protocol codes in FSG,
> maybe also the "removeable media" flag. This would also require
> implementing the PREVENT-ALLOW-MEDIUM-REMOVAL, READ-FORMAT-CAPACITIES, and
> START-STOP, possibly also REZERO-UNIT, SEEK, READ(12), and WRITE(12).
What is FSG?
-- Patrick Mansfield
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-05 5:08 ` Patrick Mansfield
@ 2003-12-05 16:01 ` Alan Stern
2003-12-05 16:11 ` Pat LaVarre
0 siblings, 1 reply; 35+ messages in thread
From: Alan Stern @ 2003-12-05 16:01 UTC (permalink / raw)
To: Patrick Mansfield
Cc: Matthew Dharm, Pat LaVarre, Alex Sanks, Julian Back,
David Brownell, SCSI development list
On Thu, 4 Dec 2003, Patrick Mansfield wrote:
> On Thu, Dec 04, 2003 at 03:59:58PM -0500, Alan Stern wrote:
>
> > It was generic (transparent) scsi.
> >
> > Perhaps I'll try implementing some of the other protocol codes in FSG,
> > maybe also the "removeable media" flag. This would also require
> > implementing the PREVENT-ALLOW-MEDIUM-REMOVAL, READ-FORMAT-CAPACITIES, and
> > START-STOP, possibly also REZERO-UNIT, SEEK, READ(12), and WRITE(12).
>
> What is FSG?
>
> -- Patrick Mansfield
Sorry about not explaining that. FSG is my File-backed Storage Gadget.
It's a driver for a Linux-based USB _device_ (as opposed to _host_) that
emulates a USB Mass Storage device, using a file or block device as
backing storage in somewhat the same manner as the loop driver.
Since FSG is totally under our control, it's perfect for logging the
sequence of commands issued by an arbitrary host when connected to a
generic USB storage device. Unfortunately, although I am keenly
interested in seeing the results of such tests against a variety of
Windows hosts, I don't have any USB device hardware capable of running
Linux. So I have to rely on tests done by the relatively few people who
do have such hardware.
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-05 16:01 ` Alan Stern
@ 2003-12-05 16:11 ` Pat LaVarre
2003-12-05 17:14 ` David Brownell
0 siblings, 1 reply; 35+ messages in thread
From: Pat LaVarre @ 2003-12-05 16:11 UTC (permalink / raw)
To: Alan Stern
Cc: linux-scsi, Patrick Mansfield, Matthew Dharm, Alex Sanks,
Julian Back, David Brownell
> > What is FSG?
> ...
> ... File-backed Storage Gadget.
> It's a driver for a Linux-based USB _device_ (as opposed to _host_) that
> emulates a USB Mass Storage device, using a file or block device as
> backing storage in somewhat the same manner as the loop driver.
> ... Unfortunately, ...
Wow, our lead FSG developer has no Linux USB _device_.
Ouch. Some sponsor with money should fix that.
> ...
Mostly I'm writing to mention, recently one of the semi-private
usb-storage ancestors of this thread also gave me:
http://www.linux-usb.org/gadget/
explained as follows.
Pat LaVarre
-----Forwarded Message-----
Subject: Re: [usb-storage] g_file_storage logs for Windows hosts
Date: 04 Dec 2003 15:59:45 -0700
Pat LaVarre wrote:
> What I lack is (a) free time and (b) a tutorial I can rapidly
> assimilate for how I fetch and deploy current fsg to h/w I own.
See www.linux-usb.org/gadget for the bare info. Clone kernel from BK
(or just pull into your own repository), configure your kernel, build
and install with the file storage gadget; "modprobe g_file_storage ..."
as shown on that page. That assumes you have appropriate hardware.
> Possibly the only appropriate hardware I have is a once-free-with-msdn
> "ViewSonic" "Pocket PC V37". On that, Windows --> Settings --> System
> --> About reports "Intel PXA255" "36.45 MB".
Hardware that will run ... FSG code includes 2.4 or 2.6 systems
running Linux is less common than generic PCs or USB disks:
- PXA 2xx hardware, which tends to be semi-custom. www.handhelds.org
is a good source of info. (They don't list that ViewSonic, and
focus on iPaqs even though Zaurii run Linux too.)
- PCI-based hardware with a net2280 (www.netchip.com); simplest as
a PCI card in a generic PC. (This is the high speed option.)
- PCI-based hardware with a Toshiba TC86c001 chip, includes some
MIPS systems; a PCI card version needs a 3.3V slot.
- ... can probably say something about the SuperH hardware
that runs it; this support is 2.4-only for now.
I understand there are drivers for some other device-side USB
controllers which are in development, or otherwise not widely
circulated. Such as some other NetChip hardware, Cypress SX2, some
other ARM-based SOCs, and more.
...
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: usb storage traces
2003-12-05 16:11 ` Pat LaVarre
@ 2003-12-05 17:14 ` David Brownell
2003-12-05 17:35 ` Pat LaVarre
2003-12-16 17:00 ` Randy.Dunlap
0 siblings, 2 replies; 35+ messages in thread
From: David Brownell @ 2003-12-05 17:14 UTC (permalink / raw)
To: Pat LaVarre
Cc: Alan Stern, linux-scsi, Patrick Mansfield, Matthew Dharm,
Alex Sanks, Julian Back
Pat LaVarre wrote:
>>>What is FSG?
>>
>>...
>>... File-backed Storage Gadget.
>>It's a driver for a Linux-based USB _device_ (as opposed to _host_) that
>>emulates a USB Mass Storage device, using a file or block device as
>>backing storage in somewhat the same manner as the loop driver.
>>... Unfortunately, ...
>
>
> Wow, our lead FSG developer has no Linux USB _device_.
Well, he does have the "dummy_hcd" which lets him test
on the same machine running the USB host ... I'll leave
it to experts to contrast that with CONFIG_SCSI_DEBUG.
The driver was basically working before it hit real
hardware.
> Ouch. Some sponsor with money should fix that.
Or Santa Claus ... ;)
- Dave
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-05 17:14 ` David Brownell
@ 2003-12-05 17:35 ` Pat LaVarre
2003-12-05 18:21 ` Alan Stern
2003-12-05 18:24 ` David Brownell
2003-12-16 17:00 ` Randy.Dunlap
1 sibling, 2 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-05 17:35 UTC (permalink / raw)
To: David Brownell
Cc: linux-scsi, Alan Stern, Patrick Mansfield, Matthew Dharm,
Alex Sanks, Julian Back
> > Wow, our lead FSG developer has no Linux USB _device_.
>
> Well, he does have the "dummy_hcd" which lets him test
> on the same machine running the USB host ... I'll leave
> it to experts to contrast that with CONFIG_SCSI_DEBUG.
Ah.
Does that mean I likewise can test fsg with a PC, rather than having to
divine how to burn Linux into my 'once-free-with-msdn "ViewSonic"
"Pocket PC V37" whose Windows --> Settings --> System > --> About
reports "Intel PXA255" "36.45 MB"'?
Pat LaVarre
P.S. With CONFIG_SCSI_DEBUG as yet personally I have gotten no further
than finding it in `make xconfig` and changing the default off to =m.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-05 17:35 ` Pat LaVarre
@ 2003-12-05 18:21 ` Alan Stern
2003-12-05 18:41 ` Pat LaVarre
2003-12-05 18:24 ` David Brownell
1 sibling, 1 reply; 35+ messages in thread
From: Alan Stern @ 2003-12-05 18:21 UTC (permalink / raw)
To: Pat LaVarre
Cc: David Brownell, linux-scsi, Patrick Mansfield, Matthew Dharm,
Alex Sanks, Julian Back
On 5 Dec 2003, Pat LaVarre wrote:
> > > Wow, our lead FSG developer has no Linux USB _device_.
> >
> > Well, he does have the "dummy_hcd" which lets him test
> > on the same machine running the USB host ... I'll leave
> > it to experts to contrast that with CONFIG_SCSI_DEBUG.
>
> Ah.
>
> Does that mean I likewise can test fsg with a PC, rather than having to
> divine how to burn Linux into my 'once-free-with-msdn "ViewSonic"
> "Pocket PC V37" whose Windows --> Settings --> System > --> About
> reports "Intel PXA255" "36.45 MB"'?
Well, sort of. You can indeed run FSG using the dummy_hcd driver under
Linux. It's good enough for testing and seeing how things work. If you
want more detailed instructions I'll send them later.
But you can't connect to another host. dummy_hcd is strictly a "loopback"
adapter. So FSG/dummy_hcd can talk to usb-storage but there's no way to
hook it up to Windows (not even using VMWare).
Alan Stern
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-05 18:21 ` Alan Stern
@ 2003-12-05 18:41 ` Pat LaVarre
0 siblings, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-05 18:41 UTC (permalink / raw)
To: Alan Stern
Cc: linux-scsi, David Brownell, Patrick Mansfield, Matthew Dharm,
Alex Sanks, Julian Back
> You can indeed run FSG using the dummy_hcd driver under
> Linux. It's good enough for testing and seeing how things work. If you
> want more detailed instructions I'll send them later.
Yes please.
cc linux-scsi@vger.kernel.org of course would give us a google url we
can use thereafter.
> But you can't connect to another host. dummy_hcd is strictly a "loopback"
> adapter. So FSG/dummy_hcd can talk to usb-storage but there's no way to
> hook it up to Windows (not even using VMWare).
True til the lk win emulators let us plug usb devices into win. Truth
or slander, I hear Microsoft's Mac OS X Virtual PC can do this.
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-05 17:35 ` Pat LaVarre
2003-12-05 18:21 ` Alan Stern
@ 2003-12-05 18:24 ` David Brownell
1 sibling, 0 replies; 35+ messages in thread
From: David Brownell @ 2003-12-05 18:24 UTC (permalink / raw)
To: Pat LaVarre
Cc: linux-scsi, Alan Stern, Patrick Mansfield, Matthew Dharm,
Alex Sanks, Julian Back
Pat LaVarre wrote:
>>>Wow, our lead FSG developer has no Linux USB _device_.
>>
>>Well, he does have the "dummy_hcd" which lets him test
>>on the same machine running the USB host ... I'll leave
>>it to experts to contrast that with CONFIG_SCSI_DEBUG.
>
>
> Ah.
>
> Does that mean I likewise can test fsg with a PC...
I don't think you can test windows interop that way,
even with windows emulators. But yes, you could test
it against usb-storage. That whole stack is available
through the "gadget-2.6" tree ... give it a whirl!
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-05 17:14 ` David Brownell
2003-12-05 17:35 ` Pat LaVarre
@ 2003-12-16 17:00 ` Randy.Dunlap
2003-12-16 17:07 ` Pat LaVarre
1 sibling, 1 reply; 35+ messages in thread
From: Randy.Dunlap @ 2003-12-16 17:00 UTC (permalink / raw)
To: David Brownell
Cc: p.lavarre, stern, linux-scsi, patmans, mdharm-scsi, alex, jback
On Fri, 05 Dec 2003 09:14:21 -0800 David Brownell <david-b@pacbell.net> wrote:
| Pat LaVarre wrote:
| >>>What is FSG?
| >>
| >>...
| >>... File-backed Storage Gadget.
| >>It's a driver for a Linux-based USB _device_ (as opposed to _host_) that
| >>emulates a USB Mass Storage device, using a file or block device as
| >>backing storage in somewhat the same manner as the loop driver.
| >>... Unfortunately, ...
| >
| >
| > Wow, our lead FSG developer has no Linux USB _device_.
|
| Well, he does have the "dummy_hcd" which lets him test
| on the same machine running the USB host ... I'll leave
| it to experts to contrast that with CONFIG_SCSI_DEBUG.
|
| The driver was basically working before it hit real
| hardware.
|
|
| > Ouch. Some sponsor with money should fix that.
|
| Or Santa Claus ... ;)
or http://www.linux-usb.org/beanieForm.html
(sorry about my lateness, still catching up)
--
~Randy
MOTD: Always include version info.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-16 17:00 ` Randy.Dunlap
@ 2003-12-16 17:07 ` Pat LaVarre
0 siblings, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-16 17:07 UTC (permalink / raw)
To: Randy.Dunlap
Cc: linux-scsi, David Brownell, stern, patmans, mdharm-scsi, alex,
jback
> | >>>What is FSG? ... File-backed Storage Gadget.
> | >>It's a driver for a Linux-based USB _device_ (as opposed to _host_) that
> | >>emulates a USB Mass Storage device, using a file or block device as
> | >>backing storage in somewhat the same manner as the loop driver.
> | >>... Unfortunately, ...
> | > Wow, our lead FSG developer has no Linux USB _device_.
> |
> | Well, he does have the "dummy_hcd" ...
> | > Ouch. Some sponsor with money should fix that.
> | Or Santa Claus ... ;)
>
> or http://www.linux-usb.org/beanieForm.html
By now I have heard another sponsor with money already did fix this.
I appreciate that link all the same, yes new to me, now there I see:
---
Slashdot Beanie Award Application Form
This form should be used to apply for part of the Slashdot Beanie Award
that the Linux USB project was awarded. Please read the following
information before submitting the form (found at the end of this page).
About the Linux-USB Purchase Request Fund
The Linux-USB Purchase Request fund (PRQ) is a limited-duration cash
distribution fund established with part of the Award made at the "2000
Slashdot Beanies", where the Linux USB community won US$... for the Most
Improved Kernel Module - see
http://slashdot.org/articles/00/02/06/1950248.shtml.
The aim of the Linux-USB PRQ is to support the Open Source development
of Linux-USB. A secondary goal is to support related projects;
especially those that are likely to assist Linux-USB, such as other
hotplug support (devices or infrastructure).
The fund was started with US$... in Sept. 2000. No additional funds are
being sought, and the PRQ will be wound up when all funds are
distributed.
...
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
2003-12-04 18:30 Alan Stern
2003-12-04 18:44 ` Matthew Dharm
@ 2003-12-05 4:31 ` Douglas Gilbert
1 sibling, 0 replies; 35+ messages in thread
From: Douglas Gilbert @ 2003-12-05 4:31 UTC (permalink / raw)
To: Alan Stern; +Cc: SCSI development list
Alan Stern wrote:
<snip/>
> Does anybody know what command x23
READ FORMAT CAPACITIES (found in MMC-3 and MMC-4)
> and mode page x1c do? Although
> nominally vendor-specific,
Vendor specific mode pages start at 0x20 so mode
page 0x1c (Informational Exceptions) is not vendor
specific.
<snip/>
Doug Gilbert
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: usb storage traces
@ 2003-12-04 16:13 Pat LaVarre
0 siblings, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-12-04 16:13 UTC (permalink / raw)
To: linux-scsi
> Subject: Re: usb storage traces
As before, if still now always we each launch a new thread to reply to
posts of this thread, then this thread will grow to contain only an
index of usb storage traces.
> ...
A usb storage trace kindly posted offline is:
http://marc.theaimsgroup.com/?l=linux-scsi&m=106877150809363
List: linux-scsi
Subject: Re: [usb-storage] Re: [PATCH] fix Sony USB mass storag...
Date: 2003-11-14 0:55:07
In particular we see there the MODE_SENSE (6) commands:
-i x0C -y "1A 00 00 00 0C 00"
-i xC0 -y "1A 00 08 00 C0 00
-i xC0 -y "1A 00 1C 00 C0 00"
-i xC0 -y "1A 00 3F 00 C0 00"
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [linux-usb-devel] Re: USB storage problems on OHCI..
@ 2003-09-22 23:07 Andries.Brouwer
2003-09-22 23:25 ` usb storage traces Pat LaVarre
0 siblings, 1 reply; 35+ messages in thread
From: Andries.Brouwer @ 2003-09-22 23:07 UTC (permalink / raw)
To: linux-scsi, linux-usb-devel, p.lavarre
Cc: andries.brouwer, hch, james.bottomley, mdharm-scsi, stern,
torvalds
> Tell me we care to hear specifically what some win sends to some of my
> usb hdd/rmb, and I'll go collect a few sample usb bus traces.
I'll collect and publish.
(Change the subject line to "USB storage traces" or so.)
Must have some old traces somewhere myself too.
Andries
^ permalink raw reply [flat|nested] 35+ messages in thread
* usb storage traces
2003-09-22 23:07 [linux-usb-devel] Re: USB storage problems on OHCI Andries.Brouwer
@ 2003-09-22 23:25 ` Pat LaVarre
0 siblings, 0 replies; 35+ messages in thread
From: Pat LaVarre @ 2003-09-22 23:25 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: linux-scsi
> > Tell me we care to hear specifically what
> > some win sends to some of my usb hdd/rmb,
> > and I'll go collect a few sample usb bus
> > traces.
>
> From: Andries.Brouwer@cwi.nl
> Date: Tue, 23 Sep 2003 01:07:59 +0200 (MEST)
>
> I'll collect and publish.
> (Change the subject line to "USB storage
> traces" or so.)
> Must have some old traces somewhere myself too.
Thank you.
I'm replying before you publish only to confirm we agree we wish to
survey both:
bInterfaceSubClass == x06 TransparentScsi
bInterfaceSubClass != x06 TransparentScsi
as suggested by:
USB Storage FAQ
Updated: May 20, 2003
http://www.microsoft.com/whdc/hwdev/bus/usb/usbfaq.mspx
---
Q: Which device classes does usbstor.sys understand?
In Windows XP, Windows 2000, and Windows Me, usbstor.sys makes only one
distinction:
bInterfaceSubClass == 06h
- OR -
bInterfaceSubClass != 06h
The value bInterfaceSubClass == 06h means that:
Command descriptor blocks (CDBs) should not be padded to 12 bytes.
Mode Sense / Mode Select commands should not be translated from 1AH /
15h to 5AH / 55h.
Subclass 0x06 should generally be used for flash memory devices.
The value bInterfaceSubClass != 06h means that:
CDBs should be padded to 12 bytes.
Mode Sense / Mode Select commands should be translated from 1AH / 15h to
5AH / 55h.
---
Pat LaVarre
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2003-12-21 2:26 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-10 22:04 usb storage traces Pat LaVarre
2003-11-11 21:59 ` Pat LaVarre
2003-11-13 18:42 ` Pat LaVarre
[not found] <20031219091450.GC828@one-eyed-alien.net>
2003-12-19 14:51 ` Alan Stern
2003-12-19 16:21 ` Pat LaVarre
2003-12-20 23:56 ` Matthew Dharm
2003-12-21 2:26 ` Alan Stern
[not found] <1070649445.12411.347.camel@patibmrh9>
2003-12-05 19:27 ` Alan Stern
2003-12-05 20:27 ` Pat LaVarre
-- strict thread matches above, loose matches on Subject: below --
2003-12-04 18:30 Alan Stern
2003-12-04 18:44 ` Matthew Dharm
2003-12-04 20:59 ` Alan Stern
2003-12-04 21:27 ` Matthew Dharm
2003-12-04 21:33 ` Pat LaVarre
2003-12-04 21:34 ` Pat LaVarre
2003-12-04 21:37 ` Pat LaVarre
2003-12-04 21:38 ` Pat LaVarre
2003-12-04 22:24 ` Pat LaVarre
2003-12-04 22:28 ` Pat LaVarre
2003-12-05 15:01 ` Alan Stern
2003-12-05 17:19 ` Pat LaVarre
2003-12-05 18:22 ` Alan Stern
2003-12-05 5:08 ` Patrick Mansfield
2003-12-05 16:01 ` Alan Stern
2003-12-05 16:11 ` Pat LaVarre
2003-12-05 17:14 ` David Brownell
2003-12-05 17:35 ` Pat LaVarre
2003-12-05 18:21 ` Alan Stern
2003-12-05 18:41 ` Pat LaVarre
2003-12-05 18:24 ` David Brownell
2003-12-16 17:00 ` Randy.Dunlap
2003-12-16 17:07 ` Pat LaVarre
2003-12-05 4:31 ` Douglas Gilbert
2003-12-04 16:13 Pat LaVarre
2003-09-22 23:07 [linux-usb-devel] Re: USB storage problems on OHCI Andries.Brouwer
2003-09-22 23:25 ` usb storage traces Pat LaVarre
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox