On Wednesday 18 March 2009, Kay Sievers wrote: > On Wed, Mar 18, 2009 at 20:44, David Brownell <david-b@xxxxxxxxxxx> wrote: > > > I have a machine running Debian and it's been getting nasty > > boot messages like: > > > > ... > > Synthesizing the initial hotplug events...done. > > Waiting for /dev to be fully populated...uncorrectable error : <3>end_request: I/O error, dev mtdblock0, sector 0 > > Buffer I/O error on device mtdblock0, logical block 0 > > uncorrectable error : <3>end_request: I/O error, dev mtdblock0, sector 8 > > Buffer I/O error on device mtdblock0, logical block 1 > > end_request: I/O error, dev mtdblock0, sector 16 > > Buffer I/O error on device mtdblock0, logical block 2 > > end_request: I/O error, dev mtdblock0, sector 24 > > Buffer I/O error on device mtdblock0, logical block 3 > > uncorrectable error : <3>end_request: I/O error, dev mtdblock0, sector 0 > > Buffer I/O error on device mtdblock0, logical block 0 > > done. > > Setting parameters of disc: (none). > > ... > > > > Where /dev/mtdblock0 is something of a special NAND partition, > > used by the mask ROM on the ARM to get a second stage loader, > > which is then loaded from /dev/mtdblock1 etc. The messages > > about "uncorrectable error" are from the kernel, since that > > first partition uses a different ECC scheme than the rest of > > the flash. > > > > What's happening is that it's trying to read partition data > > from the MTD devices ... which is inappropriate, they don't > > use internal partition data. And the mtdblock0 read fails, > > because of the ECC differences, producing messages ... ones > > that should never have appeared, since it shouldn't have > > been trying to read partition data. > > > > The boot is easily cleaned up by a patch to a udev rules > > file: /etc/udev/rules.d/60-persistent-storage.rules is > > already skipping a bunch of devices, it just needs to add > > the "mtd*" devices to what should be skipped: > > > > KERNEL=="ram*|loop*|fd*|mtd*|nbd*|gnbd*|dm-*|md*", GOTO="persistent_storage_end" > > > > It'd be good to see this bug fixed before lenny goes final... > > Udev, by default, investigates all block devices which are created by > the kernel. Except for the seven exceptions listed above... I'm just pointing out an eighth one that should be included in that list, as a bugfix: "mtd*". (Or maybe "mtdblock*".) > People use label/uuid and other metadata based stuff, so > we should look at them. Yes, people are stupid too. Such things are basically meaningless for MTDs. They don't have labels as those tools understand them, and partition data is normally part of board-specific kernel configuration data (or even kernel command line data passed from bootloaders). And there's MTD-specific metadata, like the OTP bits provided on most modern chips and which MTD technology is used by that device. Not that it's used like disk labels are ... but if "metadata" is going to be your argument, rather than "sort out which disk goes where", you've come up with yet another reason to treat MTD hardware differently than udev does today. See also: http://www.linux-mtd.infradead.org/faq/general.html#L_mtd_what http://www.linux-mtd.infradead.org/faq/general.html#L_mtd_vs_hdd Plus the "can I use ext2 on an MTD device" section. Don't be deceived by the need to have a block device to mount JFFS2. Anyone trying to use one of the /dev/mtdblock devices as a general block device is risking system damage. Example, with an MLC NAND operation, don't just randomly update an erase block 1000 times, you will probably kill it forever. And if it's already a bad block ... well, it doesn't handle that well. > I don't see how userspace could work around this, Well, the obvious fix is the one I described: add the /dev/mtdblock devices to that existing exception list in udev. A less obvious one would be to teach every tool that udev could possibly point towards MTDs to first check if the device is an MTD, and refuse to use it. Since that set of tools is unbounded, this approach clearly loses. Another would be to use MTD-specific tools for MTDs. Of course, those tools aren't used to do anything like what that persistent-rules file is doing -- and in fact those tools use the chardev interfaces to MTDs, not the blockdev ones -- so that's equivalent to the original fix: do nothing for any mtdblock device nodes you find. > and guess the kernel > should stop printing errors for stuff it has announced to userspace, > but is not usable when we look at it. It's perfectly usable. Not by the tools udev tries to use with it, but by "mount" ... /dev/mtdblock* nodes exist only to support "mount". (And maybe just for JFFS2; UBIFS doesn't need them, and I've not looked at other options.) Agreed it would be nice to see /dev/mtdblock* vanish, but that wouldn't be a near-term change. JFFS would first need to vanish; I don't know about YAFFS2 (which may never make mainline given UBIFS). > Would it help, if we make it easier to disable these rules for > specific devices from a custom udev rule? What's needed is to recognize that MTDs are not block devices in any meaningful sense. This is not a "custom" thing -- it's a "standard" thing. - Dave > Thanks, > Kay > > -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
