> -----Original Message----- > From: NeilBrown [mailto:neilb@xxxxxxx] > Sent: Wednesday, February 16, 2011 1:43 AM > To: Wojcik, Krzysztof > Cc: linux-raid@xxxxxxxxxxxxxxx > Subject: Re: Single-drive RAID0 > > On Tue, 15 Feb 2011 16:30:05 +0000 "Wojcik, Krzysztof" > <krzysztof.wojcik@xxxxxxxxx> wrote: > > > > It might help to put a "WARN_ON(1)" in the place where it prints > > > "detected > > > capacity change ..." so we get a stack trace and can see how it got > > > there. > > > That might git a hint to what is looping. > > > Also a printk in md_open if it returns ERESTARTSYS would be > > > interesting. > > > > In attachment part of logs from kernel with WARN_ON(1) and value > returned by md_open() > > (line preceded with "##### KW: err= x"). > > > > I am trying to look for in new areas. I've run: > > Udevd --debug --dedug-traces > > > > Logs from udev and kernel in attachment. > > Maybe it will help to find solution... > > It seems to udev adds and removes device in loop... > > Thanks for the extra logs.... it helps a bit, but I'm not a lot closer. > > I've seen something a little bit like this which was fixed by adding > > TEST!="md/array_state", GOTO="md_end" > > just after > > # container devices have a metadata version of e.g. 'external:ddf' and > # never leave state 'inactive' > > in /lib/udev/rules.d/64-md-raid.rules > > > Could you try that?? I tried. It not helps :( > > It looks like the 'bdev' passed to md_open keeps changing, which it > shouldn't. > > If the above doesn't help, please add: > > printk("bdev=%p, mddev=%p, disk=%p dev=%x\n", bdev, mddev, mddev- > >gendisk, bdev->bd_dev); > > at the top of 'md_open', and see what it produces. I tried this also but I can't see any useful information that can make me some idea. Could you look at logs in attachment? Regards Krzysztof > > Thanks, > NeilBrown
Attachment:
kernel_log.tgz
Description: kernel_log.tgz
