I was testing out my son's new Fisher Price Digital Camera to see if it works under linux. The output from lsusb is: Bus 005 Device 005: ID 2770:915d NHJ, Ltd Cyberpix S-210S / Little Tikes My Real Digital Camera (Apparently this same deviceId/ProductId is used in *alot* of different things) Long story made short, I've found that it works (i.e. I can mount it and look at files) under gentoo-sources-2.6.29-r5 and does not work under gentoo-sources-2.6.31-r6. In testing, I've also found that it does *not* work under gentoo-sources-2.6.30-r5 as well. When it works, the relevant dmesg output is: usb 5-2: USB disconnect, address 4 usb 5-2: new full speed USB device using uhci_hcd and address 5 usb 5-2: configuration #1 chosen from 1 choice scsi7 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 5 usb-storage: waiting for device to settle before scanning scsi scan: INQUIRY result too short (5), using 36 scsi 7:0:0:0: Direct-Access USB Mass Storage v1.0 PQ: 0 ANSI: 2 sd 7:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete sd 7:0:0:0: [sdb] 12609 512-byte logical blocks: (6.45 MB/6.15 MiB) sd 7:0:0:0: [sdb] Write Protect is off sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00 sd 7:0:0:0: [sdb] Assuming drive cache: write through sd 7:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 7:0:0:0: [sdb] Assuming drive cache: write through sd 7:0:0:0: [sdb] Attached SCSI removable disk Under 2.6.31 there is an addition message within the sd output: sd 7:0:0:0: [sdb] Adjusting the sector count from its reported value: 12609 Apparently this message was added in 2.6.30 (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5c211caa9f341f9eefbda89436d1440d1eccb3bc) but didn't change any behavior. I can find an entry in drivers/usb/unusual_devs.h for this device (0x2770:0x915d anyways) that would appear to trigger the capacity adjustment. This is present in both 2.6.31 and 2.6.29. However, removing this entry (as in the attached patch) does fix the problem. I don't think this is a long term solution, as it was obviously added for a reason. So either something changed to activate this fix or something changed in what's done when the fix is active. This appears to be the same issue as open bugs: OpenSuSE https://bugzilla.novell.com/show_bug.cgi?id=552353 Fedora https://bugzilla.redhat.com/show_bug.cgi?id=540105 Reproducible: Always
Created attachment 213354 [details, diff] Patch to remove camera entry (0x2770 0x915d) from unusual_devs.h
And with a few well placed printk's, I can verify that the unusual_dev fix is indeed active for the camera with 2.6.29. So I guess the question is, what changed between 2.6.29 and 2.6.30 that makes the 'fix' cause breakage?
Can we have full dmesg logs from a correctly functioning kernel and from a 'defective' one? Also, can you fully describe what the issue is? Is a device interface created in /dev? Be a bit more detailed ;) Thanks!
(Sorry. Having dug in so much, it all just seemed apparent to me.) I don't have access to the device at the moment (it's wrapped up as a gift)...I'll be able to get to it again after Dec. 25th. :) The behavior is that device nodes are created: /dev/sdb /dev/sdb1 Attempting to mount /dev/sdb1 fails (unknown fstype, etc.). (Gnome automount doesn't even register that the device is added.) Trying to force the fstype to vfat when mounting doesn't help. This all works perfectly (including automount) with 2.6.29 and with 2.6.31 once I patch the kernel. If I try to dump the partition table of /dev/sdb from fdisk, I notice that it does not recognize the partition table with 2.6.31, while, again, 2.6.29 works fine. Dumping the first 512 bytes of /dev/sdb (using dd), I get completely different sets of values between 2.6.29 and 2.6.31. (2.6.29 is mostly zero bytes with about 10 non-zero values. 2.6.31 is 95% non-zero values) For 2.6.29 this matches the partition table (as given by fdisk). This is just to keep the ball rolling. I'll get the dmesg logs (or copies of any other output you think would be useful) once I can get to the camera again.
Created attachment 215777 [details] dmesg output from gentoo-sources-2.6.29-r5 dmesg output from a working kernel, unpatched.
Created attachment 215779 [details] dmesg output from unpatched gentoo-sources-2.6.31-r6 dmesg output from non-working kernel.
Created attachment 215780 [details] dmesg output from patched gentoo-sources-2.6.31-r6 dmesg output from the kernel patched so that the camera will successfully mount. Upstream kernel now has this bug report as well: http://bugzilla.kernel.org/show_bug.cgi?id=14914
Thanks, we'll watch the upstream bug and backport any patches we can
