I'll apologize in advance for posting this to both users and devel, but it
didn't get much attention on the users list.
I have a Casio 2000ux camera that worked fine under linux through 2.4.22:
Jan 28 00:44:54 localhost kernel: Vendor: Casio Model: QV DigitalCamera Rev:
9009
Jan 28 00:44:54 localhost kernel: Type: Direct-Access ANSI
SCSI revision: 02
Jan 28 00:44:54 localhost kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0,
lun 0, type 0
By 2.4.23 it stopped working in a most unfriendly manner, spewing more
nonsense than dmesg could report. A sampling from /var/log/messages:
Jan 16 22:24:43 localhost kernel: sda : READ CAPACITY failed.
Jan 16 22:24:43 localhost kernel: sda : status=0, message=00, host=7, driver=00
Jan 16 22:24:43 localhost kernel: sda : sense not available.
Jan 16 22:24:43 localhost kernel: sda: assuming Write Enabled
Jan 16 22:24:43 localhost kernel: sda: assuming drive cache: write through
Jan 16 22:25:55 localhost kernel: sda : READ CAPACITY failed.
Jan 16 22:25:55 localhost kernel: sda : status=0, message=00, host=7, driver=00
Jan 16 22:25:55 localhost kernel: sda : sense not available.
Jan 16 22:25:55 localhost kernel: sda: assuming Write Enabled
Jan 16 22:25:55 localhost kernel: sda: assuming drive cache: write through
Jan 16 22:26:11 localhost kernel: usb 1-1: USB disconnect, address 2
Jan 16 22:26:11 localhost kernel: scsi0 (0:0): rejecting I/O to dead device
Jan 16 22:26:11 localhost kernel: scsi0 (0:0): rejecting I/O to dead device
Jan 16 22:26:11 localhost kernel: sda : READ CAPACITY failed.
Jan 16 22:26:11 localhost kernel: sda : status=0, message=00, host=1, driver=00
Jan 16 22:26:11 localhost kernel: sda : sense not available.
Jan 16 22:26:11 localhost kernel: sda: assuming Write Enabled
Jan 16 22:26:11 localhost kernel: sda: assuming drive cache: write through
Jan 16 22:26:11 localhost kernel: sda:<3>scsi0 (0:0): rejecting I/O to dead device
Jan 16 22:26:11 localhost kernel: Buffer I/O error on device sda, logical block 0
Jan 16 22:26:11 localhost kernel: scsi0 (0:0): rejecting I/O to dead device
Jan 16 22:26:11 localhost kernel: Buffer I/O error on device sda, logical block 0
Jan 16 22:26:11 localhost kernel: unable to read partition table
Jan 16 22:26:11 localhost kernel: sda:<3>scsi0 (0:0): rejecting I/O to dead device
Jan 16 22:26:11 localhost kernel: Buffer I/O error on device sda, logical block 0
Jan 16 22:26:11 localhost kernel: unable to read partition table
Jan 16 22:26:11 localhost kernel: scsi0 (0:0): rejecting I/O to dead device
Jan 16 22:26:11 localhost kernel: Attached scsi removable disk sda at scsi0, channel
0, id 0, lun 0
Jan 16 22:26:11 localhost kernel: ------------[ cut here ]------------
Jan 16 22:26:11 localhost kernel: kernel BUG at drivers/usb/storage/usb.c:848!
Jan 16 22:26:11 localhost kernel: invalid operand: 0000 [#1]
The problem seems clear enough; here is the unusual_devs.h entry from
2.4.22:
/* Casio QV 2x00/3x00/4000/8000 digital still cameras are not conformant
* to the USB storage specification in two ways:
* - They tell us they are using transport protocol CBI. In reality they
* are using transport protocol CB.
* - They don't like the INQUIRY command. So we must handle this command
* of the SCSI layer ourselves.
*/
UNUSUAL_DEV( 0x07cf, 0x1001, 0x1000, 0x9009,
"Casio",
"QV DigitalCamera",
US_SC_8070, US_PR_CB, NULL,
US_FL_FIX_INQUIRY ),
and from 2.4.23 and beyond (up to 2.6.2-rc2):
UNUSUAL_DEV( 0x07cf, 0x1001, 0x1000, 0x9999,
"Casio",
"QV DigitalCamera",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_INQUIRY ),
There are 3 differences, but the key one seems to be replacing
US_PR_CB with US_PR_DEVICE, given that the comment states that the
camera lies about the transport protocol. I replaced the entry in
2.6.2-rc2 with the older version and the camera again works fine. I
know this has been discussed here in the past; I gather from the
archives that newer Casio cameras don't have this problem and perhaps
nobody else is still using the old cameras (hence the lack of outrage
after the change). Still, I think this entry should be at least
partially reverted or a new entry added for the older cameras.
--
Dan Scholnik
[EMAIL PROTECTED]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
