From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: When I used the kernel that came with RH 9 the system would usually crash when I connected my camera. But this have been fixed with the errata kernel. Whenever I connect my camera usb-storage seems to get stuck. The only way for me (and others) to have the camera working is to modify usb-storage/unusual_devs.h Then the camera will work marvelous (kernel finds it with real name, mounting, copying to/from, umounting, rmmod). Version-Release number of selected component (if applicable): kernel-2.4.20-9 How reproducible: Always Steps to Reproduce: 1. Turn on the camera 2. System finds camera 3. Messages like these appear: hub.c: new USB device 00:10.1-2, assigned address 3 scsi2 : SCSI emulation for USB Mass Storage devices usb-uhci.c: interrupt, status 3, frame# 854 4. Doing cat /proc/bus/usb/devices gives usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout <long delay> 5. Doing cat /proc/scsi/scsi Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: Model: Rev: Type: <NULL> ANSI SCSI revision: ffffffff 6. Trying to rmmod usb-storage and you have to wait for ever. When rebooting there are complaints that you can't umount /usr (for example) Additional info:
Created attachment 91247 [details] unusual_devs entry The problem and different patches have floated around for some time. I now noticed that a fix for this have appeared in 2.5.68 +UNUSUAL_DEV( 0x0a17, 0x0004, 0x1000, 0x1000, + "ASAHI PENTAX", + "PENTAX OPTIO 430", + US_SC_8070, US_PR_CBI, NULL, + US_FL_FIX_INQUIRY ), http://www.geocrawler.com/mail/msg.php3?msg_id=9914734&list=4563 + US_SC_8070, US_PR_CB, NULL, + US_FL_MODE_XLATE|US_FL_FIX_INQUIRY http://www.mail-archive.com/linux-usb-devel%40lists.sourceforge.net/msg12594.html + US_SC_8070, US_PR_CB, NULL, + US_FL_MODE_XLATE|US_FL_FIX_INQUIRY ), http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1838.html + US_SC_8070, US_PR_CBI, NULL, + US_FL_FIX_INQUIRY ), What is the difference between US_PR_CB and US_PR_CBI (seems the pentax cams can work with either). The models that needs this are at least: Optio 330 Optio 430 Optio S
Use CB (Control/Bulk). The CBI (Conrol/Bulk/Interrupt) taxes Interrupt endpoints and those may have problems in some HCDs (temporarily - I am discussing it with Greg K-H). In any case most devices like CB more.
Hi Pete, I've also talked to Greg about this but he wasn't as specific as you were ;=) > What is the difference between US_PR_CB and US_PR_CBI Quite a bit :) It's the way the device talks to the host. I'm going to send him a patch this week once I get some feedback from some other Pentax camera users. The patch I sent to them had US_PR_CBI. If that works for them would US_PR_CB work too?
Per, please poke Matt Dharm or Greg Kroah for a backport. We just issued 2.4.20-18 today, cut from latest, and ... no pentax! Hrm... I really cannot advocate it for you without the equipment. Please let me know of any updates.
The patch I made is in the 2.4 and 2.5 tree @ linuxusb.bkbits.net. Greg said he won't push it to Marcel until for 2.4.22. I can send you the Pentax bits from that file if you want right now, or do you want to wait until they goes in .22? Please note that I never got any response from Greg if we should use US_PR_CB or US_PR_CBI (which the trees now have). Anyway, it works great for me!
I forgot about the situation with the 2.4.22. Many fixes are held up.
The patch only adds two unusal_devs.h entries so it's not that massive ;=)
Okay Pete, The patch has been in .22pre now for a while. Perhaps you could take the Pentax unusual_devs.h bits now!?! (There are other entries that I think you should add as well from the .22pre file too)
Mental note: compare with bug 97260.
CVS 2.4.20-19+.
Per, it's a responsibility of a requestor to re-test and close modified bugs. Closing on faith now.
Sorry Pete, I didn't realise I was the one that should close it :=)