> 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 �+,~w�zf��+,��좷�o$�yy�zW(��h�礅�zxm���������&���{����z���+-��.�ǟ�� ��S��칻 �&ǭ��Z���g�zWZ�m����+-��.�ǟ�� ���+-��b�ا~��{����z��
