Hi, On Sat, Jan 28, 2012 at 01:53:00PM +0100, Martin Steigerwald wrote: > > [ 5671.580366] mmcblk0: error -110 transferring data, sector 15563278, nr 122, card status 0x200900 > > [ 5671.603701] end_request: I/O error, dev mmcblk0, sector 15563278 > > Well I think thats clear: Thats an I/O error when trying to access the MMC > flash. I think the cleaner shouldn´t hang on it, but aside from that I do > not see a NILFS issue here. Well, please consider my message as a bugreport against the cleaner, i.e. "defect/featurerequest: if the cleaner daemon stops due to I/O errors, output an informational message suggesting to 1. Fully power off the media and reboot 2. In case it doesn't help, try another controller." I'm not sure if the facility to mark bad blocks and skip them is needed on modern devices, so it's not clear if that's reasonable to expect it from NILFS. As to the fsck, it would be very nice to have at least some very basic utility, probably even doing only diagnostic output. And with Debian on NILFS rootfs i had to substitute it with /bin/true because Debian expects a usable fsck for its root. > As to the exact nature of the MMC error I have no idea. Maybe searching > for parts of the dmesg message does help. Probably some glitch in the embedded controller, dmesg had no interesting related data. > I have I/O errors sometimes with the internal card reader on my ThinkPad > T520 with Kingston Ultimate SD cards which work perfectly well with an > external USB card reader. I reported these to bugzilla.kernel.org after I > noticed that some similar sounding issue was reported there as well. I wonder if that might be related to the power supply voltage. I think external cardreaders always use 5V for the card but the internal can vary it and if the card's descriptor permits lower voltages, it goes for the lowest; similar reasoning applies to the frequency. Also some cards are more prone to RF interference than the others. At OpenMoko we had reports of I/O errors occuring simultaneously with the GSM activity. I guess laptop's insides have enough sources of interference too. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
