it seems like, some change to the kernel destroyed support for my usb device 2770:915d (a umass device of a usb cam)... can u fix it? here r 2 bug reports in distribution related bug report tools: https://bugzilla.redhat.com/show_bug.cgi?id=540105 http://bugs.gentoo.org/show_bug.cgi?id=297357| -arne
oh - maybe i should say, that my uname-a currently says: Linux vaako.riddick.homeunix.org 2.6.31.9-174.fc12.x86_64 #1 SMP Mon Dec 21 05:33:33 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux -arne
i misfiled this bug report... sorry... -arne
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 28 Dec 2009 13:05:03 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=14914 > > Summary: usbstorage for 2770:915d delivers no FAT > Product: Drivers > Version: 2.5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: USB > AssignedTo: greg@kroah.com > ReportedBy: arne_woerner@yahoo.com > Regression: No > > > it seems like, some change to the kernel destroyed support for my usb device > 2770:915d (a umass device of a usb cam)... > > can u fix it? > > here r 2 bug reports in distribution related bug report tools: > https://bugzilla.redhat.com/show_bug.cgi?id=540105 > http://bugs.gentoo.org/show_bug.cgi?id=297357| > This bug report is a bit confusing, but Ryan has a patch at the gentoo.org link. Ryan, if that patch is still good then please resend it via emailed reply-to-all to this email, with a little changelog description and a Signed-off-by: line as per Documentation/SubmittingPatches, thanks.
On Tue, 5 Jan 2010, Andrew Morton wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=14914 > > > > Summary: usbstorage for 2770:915d delivers no FAT > This bug report is a bit confusing, but Ryan has a patch at the > gentoo.org link. > > Ryan, if that patch is still good then please resend it via emailed > reply-to-all to this email, with a little changelog description and a > Signed-off-by: line as per Documentation/SubmittingPatches, thanks. Ryan, please also post a pair of usbmon traces showing what happens when the camera is plugged in with and without the patch. Instructions for usbmon are in the kernel source file Documentation/usb/usbmon.txt. Alan Stern
Reply-To: rmay31@gmail.com On Tue, Jan 5, 2010 at 4:53 PM, Andrew Morton <akpm@linux-foundation.org> wrote: >> it seems like, some change to the kernel destroyed support for my usb device >> 2770:915d (a umass device of a usb cam)... >> >> can u fix it? >> >> here r 2 bug reports in distribution related bug report tools: >> https://bugzilla.redhat.com/show_bug.cgi?id=540105 >> http://bugs.gentoo.org/show_bug.cgi?id=297357| >> > > This bug report is a bit confusing, but Ryan has a patch at the > gentoo.org link. > > Ryan, if that patch is still good then please resend it via emailed > reply-to-all to this email, with a little changelog description and a > Signed-off-by: line as per Documentation/SubmittingPatches, thanks. Here's the patch: From: Ryan May <rmay31@gmail.com> Remove entry for 2770:915d (usb digital camera with mass storage support) from unusual_devs.h. The fix triggered by the entry causes the file system on the camera to be completely inaccessible (no partition table, the device is not mountable). Signed-off-by: Ryan May <rmay31@gmail.com> --- The patch works, but let me clarify a few things about it. All the patch does is remove the entry for this device from the drivers/usb/storage/unusual_devs.h, which is supposed to help with a problem with the device's reported size (I think). I'm pretty sure it was originally added for a reason, so I'm not sure removing it won't cause other problems to reappear. Also, I should note that this unusual_devs.h entry was present (and activating workarounds) in 2.6.29, but in that version everything works fine. Starting with 2.6.30, things no longer work. --- drivers/usb/storage/unusual_devs.h.old 2009-12-17 15:56:50.000000000 -0600 +++ drivers/usb/storage/unusual_devs.h 2009-12-17 15:57:01.000000000 -0600 @@ -1820,13 +1820,6 @@ UNUSUAL_DEV( 0x2735, 0x100b, 0x0000, 0x US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_GO_SLOW ), -/* Reported by Rohan Hart <rohan.hart17@gmail.com> */ -UNUSUAL_DEV( 0x2770, 0x915d, 0x0010, 0x0010, - "INTOVA", - "Pixtreme", - US_SC_DEVICE, US_PR_DEVICE, NULL, - US_FL_FIX_CAPACITY ), - /* Reported by Frederic Marchal <frederic.marchal@wowcompany.com> * Mio Moov 330 */
Reply-To: rmay31@gmail.com On Tue, Jan 5, 2010 at 5:26 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Tue, 5 Jan 2010, Andrew Morton wrote: > >> > http://bugzilla.kernel.org/show_bug.cgi?id=14914 >> > >> > Summary: usbstorage for 2770:915d delivers no FAT > >> This bug report is a bit confusing, but Ryan has a patch at the >> gentoo.org link. >> >> Ryan, if that patch is still good then please resend it via emailed >> reply-to-all to this email, with a little changelog description and a >> Signed-off-by: line as per Documentation/SubmittingPatches, thanks. > > Ryan, please also post a pair of usbmon traces showing what happens > when the camera is plugged in with and without the patch. > Instructions for usbmon are in the kernel source file > Documentation/usb/usbmon.txt. I attached the output from cat /sys/kernel/debug/usb/usbmon/0u for unpatched and patched 2.6.31 kernels. I also attached the usbmon output from 2.6.29 which works with out patching, but still has the unusual_dev.h workaround active. Let me know what else I can do to help. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
On Sat, 9 Jan 2010, Ryan May wrote: > I attached the output from cat /sys/kernel/debug/usb/usbmon/0u for > unpatched and patched 2.6.31 kernels. I also attached the usbmon > output from 2.6.29 which works with out patching, but still has the > unusual_dev.h workaround active. Thank you. Although there are numerous differences, nothing stands out as particularly meaningful. What do you get when you do "dd if=/dev/sde count=1 | hexdump -C", under kernels with and without the patch? (Replace "sde" with the appropriate device name for the camera.) I would rather expect the output to be the same whether the patch is present or not... but you never know. Alan Stern
On Sat, 9 Jan 2010, Alan Stern wrote: > What do you get when you do "dd if=/dev/sde count=1 | hexdump -C", > under kernels with and without the patch? (Replace "sde" with the > appropriate device name for the camera.) I would rather expect the > output to be the same whether the patch is present or not... but you > never know. One other thing to try, again on both types of kernel. After plugging in the camera, unmount the partition (for the patched kernel, of course). Then do: blockdev --flushbufs /dev/sdb (or sd-whatever). Start up a usbmon trace, and then try to mount the partition. That should generate significantly different activity on the two kernels. Alan Stern
Reply-To: rmay31@gmail.com On Sat, Jan 9, 2010 at 10:53 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Sat, 9 Jan 2010, Alan Stern wrote: > >> What do you get when you do "dd if=/dev/sde count=1 | hexdump -C", >> under kernels with and without the patch? (Replace "sde" with the >> appropriate device name for the camera.) I would rather expect the >> output to be the same whether the patch is present or not... but you >> never know. > > One other thing to try, again on both types of kernel. After plugging > in the camera, unmount the partition (for the patched kernel, of > course). Then do: > > blockdev --flushbufs /dev/sdb > > (or sd-whatever). Start up a usbmon trace, and then try to mount the > partition. That should generate significantly different activity on > the two kernels. Actually, all of the usbmon traces I sent before should include the devices being mounted, are at least an attempt at mounting. I'll send the output from dd when I get the chance, but I can at least tell you from trying that before that the results are indeed different, which I found interesting. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
On Sat, 9 Jan 2010, Ryan May wrote: > Actually, all of the usbmon traces I sent before should include the > devices being mounted, are at least an attempt at mounting. Sure, but there's no simple way to tell _where_ in the traces the attempted mounts occur. That's why I recommended flushing the kernel's buffers before starting a trace and doing a mount; then all the mount-related I/O will occur right at the beginning of the trace. Alan Stern
Reply-To: rmay31@gmail.com On Sat, Jan 9, 2010 at 8:52 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Sat, 9 Jan 2010, Ryan May wrote: > >> Actually, all of the usbmon traces I sent before should include the >> devices being mounted, are at least an attempt at mounting. > > Sure, but there's no simple way to tell _where_ in the traces the > attempted mounts occur. That's why I recommended flushing the kernel's > buffers before starting a trace and doing a mount; then all the > mount-related I/O will occur right at the beginning of the trace. Oh, ok. I'll get you those when I get the chance. In the meanwhile, here is the output from dd | hexdump -C. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
On Sat, 9 Jan 2010, Ryan May wrote: > Oh, ok. I'll get you those when I get the chance. In the meanwhile, > here is the output from dd | hexdump -C. Wow. Are you sure you issued the same command for the patched and unpatched versions of 2.6.31? The outputs are completely different. Assuming the computer is sending the same commands to the device (which you can check by doing a "blockdev --flushbufs /dev/sdb" before the "dd" and using usbmon), the device itself must be behaving very strangely. Or else the kernel's block cache has gotten messed up, which is very unlikely. (It's worth mentioning that the usbmon traces you already posted each show a few places where the computer reads the first sector, and the data sent by the device agrees with your patched data here, not the unpatched data. That's true even with the usbmon trace made using the unpatched kernel.) Alan Stern
hi! thx for all the effort u undertake to solve my problem... can we integrate this report http://bugzilla.kernel.org/show_bug.cgi?id=14955 somehow (i didnt know how to set the correct kernel number in my first report)... is there a way to disable that "unusual device" entry without compiling my own kernel? because: i m afraid that i dont do it right... thx. bye arne __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
Reply-To: rmay31@gmail.com On Sun, Jan 10, 2010 at 7:29 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Sat, 9 Jan 2010, Ryan May wrote: > >> Oh, ok. I'll get you those when I get the chance. In the meanwhile, >> here is the output from dd | hexdump -C. > > Wow. Are you sure you issued the same command for the patched and > unpatched versions of 2.6.31? The outputs are completely different. > > Assuming the computer is sending the same commands to the device (which > you can check by doing a "blockdev --flushbufs /dev/sdb" before the > "dd" and using usbmon), the device itself must be behaving very > strangely. Or else the kernel's block cache has gotten messed up, > which is very unlikely. Well, I'm not sure that it's the device itself, given that the purpose of the entry in unusual_dev.h is adjusting the number of blocks reported by the drive. To my untrained eyes, it would seem that the with unpatched 2.6.31, the drive is reading one block off from where it should be. But that just be the crazy rambling of a non-kernel hacker. (Still working on getting the full set of the usbmon traces.) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
Reply-To: rmay31@gmail.com On Sun, Jan 10, 2010 at 7:29 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > Wow. Are you sure you issued the same command for the patched and > unpatched versions of 2.6.31? The outputs are completely different. > > Assuming the computer is sending the same commands to the device (which > you can check by doing a "blockdev --flushbufs /dev/sdb" before the > "dd" and using usbmon), the device itself must be behaving very > strangely. Or else the kernel's block cache has gotten messed up, > which is very unlikely. > > (It's worth mentioning that the usbmon traces you already posted each > show a few places where the computer reads the first sector, and the > data sent by the device agrees with your patched data here, not the > unpatched data. That's true even with the usbmon trace made using the > unpatched kernel.) Alright, I'm back on this if you're still interested. I know Greg KH has already pushed the patch forward, but I also know that you seemed baffled by some of the behavior. Instead of patching the kernel now, I've compiled usb_storage as a module and simply need to pass modprobe the quirks=2770:915d: (as you told AW). This will make it easier for me to try a bunch of things without rebooting, plus it makes it easier to repeat the same commands. I've attached output of dd if=/dev/sdb count=1 | hexdump -C and a usbmon trace (from just trying to mount the device after a blockdev --flushbufs /dev/sdb) for the case of noquirks (which is broken) and using quirks (which works). Let me know if there's anything else you'd like to see. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States
On Thu, 28 Jan 2010, Ryan May wrote: > Alright, I'm back on this if you're still interested. I know Greg KH > has already pushed the patch forward, but I also know that you seemed > baffled by some of the behavior. Instead of patching the kernel now, > I've compiled usb_storage as a module and simply need to pass modprobe > the quirks=2770:915d: (as you told AW). This will make it easier for > me to try a bunch of things without rebooting, plus it makes it easier > to repeat the same commands. I've attached output of dd if=/dev/sdb > count=1 | hexdump -C and a usbmon trace (from just trying to mount the > device after a blockdev --flushbufs /dev/sdb) for the case of noquirks > (which is broken) and using quirks (which works). Let me know if > there's anything else you'd like to see. The traces confirm it -- the device gives different responses to the same command depending on whether or not the quirk is present. I can't imagine what would trigger this variation in behavior. I suspect that trying to figure out the true cause of the device's buggy behavior will be a losing game. As long as it works okay with the unusual_devs entry removed, we might as well not worry and be happy. Provided, that is, the reason for the entry being added in the first place no longer applies. Until we hear back from Rohan, there's no way to know about that. Thanks for going to all the trouble of running the tests, even if things did turn out to be rather anti-climactic in the end. Alan Stern