On Tue, 6 Apr 2004, Peter Santoro wrote: > I've applied the patch, rebuilt the kernel, and did one test (boot PC, > login as root, insert Lexar JumpDrive, try to mount the vfat formatted > device). As before, the mount command took about ~30 sec, but did > successfully complete. I could read and write to the JumpDrive. > Subsequent mounts were quick. This test went about the same as my > original test on my ASUS PC using my SIIG (NEC) pci usb ports. I've > included the debug messages below. I'll try more tests later on > different PCs with the patched kernel, if you'd like me to. Do you want > me to try another test on my ASUS PC without the patch and using the > SIIG pci usb ports, as it worked once before - or do you think that was > just luck?
It's hard to say whether luck was involved or not, but your log shows the device is definitely malfunctioning. With Pete's patch applied, the kernel was able to reset the device and keep on going, but the error recovery procedure required some 30 seconds -- the delay you observed. By the way, your log included every debugging message twice! Apparently you have /etc/syslog.conf set up with one entry for all kernel messages and another entry for just the debugging messages. I've filtered the duplicates out in the sections below. Here's how the first TEST UNIT READY command operated. It shows what should happen when everything is working correctly. > Apr 6 09:45:50 p500 kernel: usb-storage: Command TEST_UNIT_READY (6 bytes) > Apr 6 09:45:50 p500 kernel: usb-storage: 00 00 00 00 00 00 00 00 00 00 eb d7 > Apr 6 09:45:50 p500 kernel: usb-storage: Bulk command S 0x43425355 T 0x2 Trg 0 LUN > 0 L 0 F 0 CL 6 > Apr 6 09:45:50 p500 kernel: usb-storage: Bulk command transfer result=0 > Apr 6 09:45:50 p500 kernel: usb-storage: Attempting to get CSW... > Apr 6 09:45:50 p500 kernel: usb-storage: Bulk status result = 0 > Apr 6 09:45:50 p500 kernel: usb-storage: Bulk status Sig 0x53425355 T 0x2 R 0 Stat > 0x0 Notice the status Signature = 0x53425355, as it should. Also, the Tag = 0x2 matches the Tag from the preceding "Bulk command" line. Here is what happened with the second TEST UNIT READY command. > Apr 6 09:46:24 p500 kernel: usb-storage: Command TEST_UNIT_READY (6 bytes) > Apr 6 09:46:24 p500 kernel: usb-storage: 00 00 00 00 00 00 34 c0 00 a0 30 c0 > Apr 6 09:46:24 p500 kernel: usb-storage: Bulk command S 0x43425355 T 0x6 Trg 0 LUN > 0 L 0 F 0 CL 6 > Apr 6 09:46:24 p500 kernel: usb-storage: Bulk command transfer result=0 > Apr 6 09:46:24 p500 kernel: usb-storage: Attempting to get CSW... > Apr 6 09:46:24 p500 kernel: usb-storage: Bulk status result = 0 > Apr 6 09:46:24 p500 kernel: usb-storage: Bulk status Sig 0x53550000 T 0x65342 R 0 > Stat 0x0 > Apr 6 09:46:24 p500 kernel: usb-storage: Bulk logical error > Apr 6 09:46:24 p500 kernel: usb-storage: -- transport indicates error, resetting The device returned a signature of 0x53550000, which is unquestionably a bug in the firmware. In addition the Tag is 0x65342 which doesn't match the preceding Tag 0x6, another bug (or another aspect of the same bug). The usb-storage perceived this as an error, which it was, and began a reset cycle. Without Pete's patch the reset procedure ultimately crashed the kernel, but with the patch it worked and the device continued to function properly thereafter. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
