On Sat, 19 Sep 2009, Eric Ding wrote: > >> As for why it works under Windows, I can only guess it's because > >> Windows doesn't try to read 64 sectors starting at sector 2047768. > >> Perhaps if some Windows program tried to do so, the same failure would > >> happen. > >> > >> Probably the Linux program that does the offending read is udev's > >> vol_id. If you disable that then perhaps the reader won't crash. > > > > Hmm... I'm not too familiar with the inner workings of udev, but here's > > what I have tried so far: > > > > 1) Comment out all lines in /lib/udev/rules.d files that refer to > > vol_id. Errors still occur. If I look further, it appears that > > hald-probe-volume is running while errors are popping up, so I conclude > > that hald-probe-volume is provoking this error. So next, I... > > > > 2) Turn off udev daemon altogether. This eliminates the error, and I can > > now manually mount /dev/sdb1 and read/write files to and from the card reader. > > > > OK, so now I've concluded that the way udev and hald interact with my USB > > card reader tickle this bug/issue in my card (reader). I suspect I'm > > wandering outside the domain of this list, since it seems you're implying > > that there's no kernel workaround for this bug. So now what? Is there a > > way to tell hald/udev to treat this device specially and not probe it in > > this way? Or is there some kind of a kernel workaround I could try? > > Just to follow up: I browsed the source code of udev and did a *lot* of > trial-and-error playing around with vol_id, and have stumbled on what I > cautiously will call a successful workaround. It appears that the part of > vol_id which probes for RAID filesystem types is causing the problem... > since I don't use RAID at all (and certainly not on my memory card!), I > passed the --skip-raid argument to vol_id, and now everything seems to > work... for now. What about hald-probe-volume? Doesn't that still cause problems? > A glance at the development sources for udev suggests that vol_id will soon > be deprecated, and blkid from e2fsprogs will be used instead. Hopefully > that will mean no more workaround in the future, rather than a need for a > whole new workaround. :) I don't know... If blkid does the same sort of probing for RAID signatures as vol_id then it's likely to provoke the same response. Besides, if blkid is part of e2fsprogs, doesn't that imply that it finds IDs only on ext2- or ext3-formatted filesystems? udev wants to work with everything, including FAT filesystems and even swap partitions. As for kernel workarounds, I can't think of any workable approach. If you can write a Windows program that accesses those same sectors and demonstrate that it doesn't work, then you would have grounds to complain to the manufacturer. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
