Bug#583917: #583917: same here, maybe some additional data

[Roland Mas]

  Hi,

I had the very same problem, and downgrading mdadm to 3.1.1-1 did fix it
for me too.  In case additional information about my setup might be
useful in the general case, here's the symptoms I had.

  Setup: two disks sda and sdb.  Partitions sda1 and sdb1 are aggregated
in a RAID1 device /dev/md0, mounted on /boot.  Partitions sda2 and sdb2
are aggregated in a RAID1 device /dev/md/main (= /dev/md127).
/dev/md/main is used as the backing store for LUKS device
/dev/mapper/raid_crypt, which is in turn a physical volume for the LVM
volume group vg_mirexpress.  That VG contains 23 logical volumes,
including vg_mirexpress-root (mounted on /), vg_mirexpress-usr (mounted
on /usr), and so on.  Including a vg_mirexpress-swap which I use for
swapping and hibernating.

  Observed behaviour: lots of /sys/devices/virtual/block/md{0,127}
(<number>) messages; the numbers look like they could be pids (they're
consecutive and growing), but in the 8000 range so that's a bit
suspicious.  These series of messages scroll by twice, each time causing
several seconds of delay.

  I also see the series of udevd-work warnings.  Interestingly (maybe),
the time between two of them seems to grow geometrically.  I can't judge
for the first few ones, but if the message about dm-8 appears about one
second after the one for dm-7, then dm-9 takes about two seconds to
appear, dm-10 about four, dm-11 about eight and so on.  The pattern
seems to continue, but I lose patience once I reach a minute or two.
The base delay varies wildly across boots, however, which means that
sometimes I give up because I've been waiting for dm-17 for a minute,
and other times the time between dm-22 and dm-23 (the last one) is under
30 seconds.  There seems to be some degree of correlation between these
delays and the time since boot (maybe the time since the arrays were
started): anecdotal evidence shows that when I typo my LUKS passphrase,
I end up rebooting rather than waiting for hours, whereas if I get it
right first time the boot time is reasonable (and even more reasonable
if I type it right *and* fast first time).

  The disks' activity LEDs are continuously on during that time, too
(that might or might not be relevant).

  As mentioned, a downgrade to 3.1.1-1 fixed the problem for me.
Hopefully this additional information can help pinpoint the actual
bug :-)

Roland.
-- 
Roland Mas

Au royaume des aveugles, il y a des borgnes à ne pas dépasser.
  -- in Soeur Marie-Thérèse des Batignoles (Maëster)