Description of problem: I have usb-1.1 external enclosure for 2.5" hdd and it doesn't work with linux. During anaconda boot usb-storage driver was inserted and there are following lines on VT4: USB Mass Storage device found at 4 but cat /proc/scsi/scsi has only following line: Attached devices: none Version-Release number of selected component (if applicable): 2.4.20-2.2 This device works perfectly on win2k and winxp with their generic usb storage driver. /proc/bus/usb/devices will be attached
Created attachment 88887 [details] /proc/bus/usb/devices
I've just tried this device: http://www.transcendusa.com/Transcend/PressDetail.asp?pruid=89 and it doesn't work too. It has the same chip 05e3/0702 but revision is 2 (for USB 2.0) kernel version is now 2.4.20-9.
This drive seem's to be working on kernel-2.4.20-9. For 2.4.18-27.7x kernel drivers/usb/storage/unusual_devs.h: change struct from : UNUSUAL_DEV( 0x05e3, 0x0702, 0x0000, 0xffff, "EagleTec", "External Hard Disk", US_SC_SCSI, US_PR_BULK, NULL, US_FL_FIX_INQUIRY ), to: UNUSUAL_DEV( 0x05e3, 0x0702, 0x0000, 0x0001, "EagleTec", "External Hard Disk", US_SC_SCSI, US_PR_BULK, NULL, US_FL_FIX_INQUIRY ), For eagletec with 113 revision on 2.4.18-* kernels: UNUSUAL_DEV( 0x05e3, 0x0702, 0x0113, 0x0113, "EagleTec", "External Hard Disk", US_SC_SCSI, US_PR_BULK, NULL, US_FL_FIX_INQUIRY | US_FL_START_STOP ), But Eagletec 1.13 seems not working with same fix on 2.4.20-9 :-(
The main reason I am very reluctant to add unusual_devs.h entries from bug reports is that they often break someone's else device. This is what the 2.4.20-18 has (from upstream). /* Reported by Peter Marks <peter.marks> * Like the SIIG unit above, this unit needs an INQUIRY to ask for exactly * 36 bytes of data. No more, no less. That is the only reason this entry * is needed. * * ST818 slim drives (rev 0.02) don't need special care. */ UNUSUAL_DEV( 0x05e3, 0x0702, 0x0000, 0x0001, "EagleTec", "External Hard Disk", US_SC_SCSI, US_PR_BULK, NULL, US_FL_FIX_INQUIRY ), Essentially, the device has an upstream entry now and I am not willing to override it without a serious research. Another thing, in several 2.4's in a row, US_FL_START_STOP was totally, utterly broken. I am doubly suspicious when people request entries with it, because it simply cannot work as they expect. And 90% of the submitters simply copy it from other entries without even looking at the code. Leonid, please retry testing with 2.4.20-18.
It doesn't work. See dmesg attached
Created attachment 92152 [details] dmesg output
I check this drive (05e3/0702 rev 1.13) with 2.4.20-18 kernel. It still have to be patched with adding this record: UNUSUAL_DEV( 0x05e3, 0x0702, 0x0113, 0x0113, "EagleTec", "External Hard Disk", US_SC_SCSI, US_PR_BULK, NULL, US_FL_FIX_INQUIRY | US_FL_START_STOP ), After adding this to drivers/usb/storage/unusual_devs.h, this drive works well. without START_STOP: usb.c: USB device 3 (vend/prod 0x5e3/0x702) is not claimed by any active driver. SCSI subsystem driver Revision: 1.00 Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage usb-uhci.c: interrupt, status 2, frame# 1828 usb_control/bulk_msg: timeout scsi0 : SCSI emulation for USB Mass Storage devices Vendor: EagleTec Model: External Hard Di Rev: 0113 Type: Direct-Access ANSI SCSI revision: 02 WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 3 USB Mass Storage support registered. usb_control/bulk_msg: timeout usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -110 usb_control/bulk_msg: timeout usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -110 Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: 39070081 512-byte hdwr sectors (20004 MB) sda: test WP failed, assume Write Enabled sda: sda1 sda2 < sda5 > with START_STOP: usb.c: USB device 2 (vend/prod 0x5e3/0x702) is not claimed by any active driver. hub.c: new USB device 00:1f.2-2, assigned address 3 input0: USB HID v1.00 Mouse [4D Mouse USB Mouse] on usb1:3.0 SCSI subsystem driver Revision: 1.00 Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage usb-uhci.c: interrupt, status 2, frame# 920 usb_control/bulk_msg: timeout scsi0 : SCSI emulation for USB Mass Storage devices Vendor: EagleTec Model: External Hard Di Rev: 0113 Type: Direct-Access ANSI SCSI revision: 02 WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 2 USB Mass Storage support registered. Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: 39070081 512-byte hdwr sectors (20004 MB) sda: test WP failed, assume Write Enabled sda: sda1 sda2 < sda5 >
Leonind needed 0x0113 firmware, from his .../devices. Adding that. CVS 2.4.20-19+.
Closing out some bugs that have been in MODIFIED state. Please reopen if they persist.
This device isn't supported again in 2.4.22-1.2115.nptl scsi0 : SCSI emulation for USB Mass Storage devices WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 6 USB Mass Storage support registered. usbdevfs: USBDEVFS_CONTROL failed dev 6 rqt 128 rq 6 len 18 ret -84 usbdevfs: USBDEVFS_CONTROL failed dev 6 rqt 128 rq 6 len 18 ret -84
Leonid, I do not see any evidence for "device isn't supported" in the trace above.
Try this: UNUSUAL_DEV( 0x05e3, 0x0702, 0x0113, 0x0113, "EagleTec", "External Hard Disk", US_SC_SCSI, US_PR_BULK, NULL, US_FL_FIX_INQUIRY | US_FL_MODE_XLATE), Seems like this device only understands some scsi commands in 10bytes mode. (PowerPC version of linux-2.4.22-ben2 on Apple Powerbook Pismo) -Michael
[root@leon root]# cat /proc/scsi/scsi Attached devices: none [root@leon root]# cat /proc/bus/usb/devices ... T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05e3 ProdID=0702 Rev= 1.13 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 96mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms [root@leon root]# uname -a Linux leon.asp-linux.com.ua 2.4.22-1.2115.nptl #1 Wed Oct 29 15:42:51 EST 2003 i686 i686 i386 GNU/Linux With 2.4.20-20.9 it works.
Finally, we can put this to rest, at least as far as 1.13 firmware is concerned. What a drag. :-) cc: list please open own bugs, unless you have 1.13s.