Re: udev problem (and fix) for /dev/mtdblock*

[David Brownell <david-b@pacbell.net>]

On Wednesday 18 March 2009, Kay Sievers wrote:
> On Wed, Mar 18, 2009 at 20:44, David Brownell <david-b@pacbell.net> 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
> 
>