The two-mode passthru is probably the best solution for 2.4 -- that's what ide-scsi does (SCSI emulation for IDE/ATAPI devices). Anything that comes from the SG interface is not rewritten.
Of course, I fixed this for 2.5/2.6 by just changing the INQUIRY behavior to start with an op x12 for x24 bytes. In general, we don't want to blanket-rewrite data whenever possible. There are several SG-based apps (cdrecord most notably) which insist on wanting the raw data. Matt On Mon, Dec 30, 2002 at 09:26:40AM -0700, Pat LaVarre wrote: > > The US_FL_FIX_INQUIRY flag tells the usb-storage > > driver not to send INQUIRY commands to the device > > but instead to fake a reply. > > Thanks, I tried that quick walk thru the source: > http://lxr.linux.no/ident?v=2.5.49&i=US_FL_FIX_INQUIRY > http://lxr.linux.no/source/drivers/usb/storage/usb.c?v=2.5.49#L430 > http://lxr.linux.no/ident?v=2.5.49;i=fill_inquiry_response > http://lxr.linux.no/source/drivers/usb/storage/usb.c?v=2.5.49#L246 > http://lxr.linux.no/ident?v=2.5.49;i=INQUIRY > http://lxr.linux.no/source/include/scsi/scsi.h?v=2.5.49#L40 > > Looks to me like here, when we have no > US_FL_FIX_INQUIRY, the default TalkLikeWindows > violation is to pass thru op x12 Inquiry other than > the Windows Inquiry of cmdp = x "12 0 0 0 24 0" with > dxfer_len = x24? > > So far so good? > > Then why is the fix for this to fabricate op x12 > Inquiry data altogether? > > Why not always pass thru any op x12 Inquiry as a > Windows Inquiry? > > Why penalise the many devices that talk well with > Windows today, rather than the rare devices that > implement the standard as published? > > Wouldn't it make sense to have two pass-thru's? > > One truly transparent pass thru, for apps that do know > what they are doing, but the default heavily filtered > since so many apps can't cope with reality? > > And how are we going to cope when the 64-bit > motherboards change the Windows Inquiry to be, > perhaps, -x "12 0 0 0 20 0" -i x20 instead? > > Curiously yours in breathtaking ignorance, Pat LaVarre > > -----Original Message----- > From: Alan Stern [mailto:[EMAIL PROTECTED]] > Sent: Mon 12/30/2002 9:06 AM > To: Jason Bowman; Matthew Dharm > Cc: [EMAIL PROTECTED]; USB Storage List > Subject: [usb-storage] Re: [linux-usb-devel] Fuji FinePix F401 - patch > > > > On Wed, 25 Dec 2002, Jason Bowman wrote: > > > > > Hello all, > > > > I've been playing with a Fuji FinePix F401 Digital Camera lately. Under XP it > > connect no-prob as a usb-storage device, but under linux just plugging it in > > would freeze the entire machine. This was tried with: stock 2.4.18+acpi, > > Mandrake90 2.4.19, and stock 2.4.20+acpi with the same results. I finally > > fixed it by applying the patch included below. As you can see I simply > > modified the entry above it to use '0x0114' instead of '0x0100'. > > > > Please update this (or whatever is necesary) so that others don't run into >the > > same problem. > > > > I am more concerned with why, without this entry, plugging in a usb device > > would lock my entire machine (esp when it worked in XP). I believe the > > problem is related to when the usb-storage device tried to set up scsi > > emulation. This be because I would monitor /proc/scsi/scsi right before it > > crashed and an entry would appear but most of the fields would be blank as > > you can see below: > > > > [root@waturu jasonb]# while true; do sleep 1; date; lsusb; cat > > /proc/scsi/scsi; done > > Wed Dec 25 18:02:29 EST 2002 > > Bus 002 Device 001: ID 0000:0000 > > Bus 001 Device 001: ID 0000:0000 > > Bus 001 Device 002: ID 04cb:0114 Fuji Photo Film Co., Ltd. > > Attached devices: > > Host: scsi0 Channel: 00 Id: 02 Lun: 00 > > Vendor: MATSHITA Model: UJDA720 DVD/CDRW Rev: 1.00 > > Type: CD-ROM ANSI SCSI revision: 02 > > Host: scsi1 Channel: 00 Id: 00 Lun: 00 > > Vendor: Model: Rev: > > Type: <NULL> ANSI SCSI revision: ffffffff > > > > > > So why did this crash my machine and what can be done to stop it? I am fully > > willing to jump into the code and try to resolve this issue... thou someone > > would definitely has to point to in the right direction as I've never done > > any kernel development before. > > > > Thanks, > > Jason B. > > > > ------------------------- > > > > *** drivers/usb/storage/unusual_devs.h 2002-11-28 18:53:15.000000000 >-0500 > > --- drivers.new/usb/storage/unusual_devs.h 2002-12-25 17:52:18.000000000 > > -0500 > > *************** > > *** 100,109 **** > > --- 100,114 ---- > > UNUSUAL_DEV( 0x04cb, 0x0100, 0x0000, 0x2210, > > "Fujifilm", > > "FinePix 1400Zoom", > > US_SC_8070, US_PR_CBI, NULL, US_FL_FIX_INQUIRY), > > > > + UNUSUAL_DEV( 0x04cb, 0x0114, 0x0000, 0x2210, > > + "Fujifilm", > > + "FinePix F401", > > + US_SC_8070, US_PR_CBI, NULL, US_FL_FIX_INQUIRY), > > + > > You are correct that SCSI emulation triggered the problem you saw. What's > going on is that some devices do not respond properly to a SCSI INQUIRY > command -- maybe they don't respond at all, maybe they give an error, > maybe they provide bogus data. The US_FL_FIX_INQUIRY flag tells the > usb-storage driver not to send INQUIRY commands to the device but instead > to fake a reply. The SCSI emulation of course needs to use the INQUIRY > data to function correctly. > > Your comment leads me to wonder if we can't do a better job of detecting > automatically the devices that need this treatment. Rather than hanging > or crashing, we ought to be able to realize when an INQUIRY has failed or > yielded obviously bad data, and set the US_FL_FIX_INQUIRY flag ourselves. > Matt, what do you think? > > Alan Stern > > _______________________________________________ > usb-storage mailing list > [EMAIL PROTECTED] > http://www2.one-eyed-alien.net/mailman/listinfo/usb-storage > -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998
msg10329/pgp00000.pgp
Description: PGP signature
