Hi Martin, On Sat, Aug 24, 2013 at 8:54 PM, Martin Wilck <mwilck@xxxxxxxx> wrote: > Hi Francis, > >> On Fri, Aug 2, 2013 at 8:19 PM, Martin Wilck <mwilck@xxxxxxxx> wrote: >>> On 08/02/2013 02:46 PM, Francis Moreau wrote: >>> >>>>> >>>>> # mdadm -E /dev/sda | egrep "state" >>>>> state[0] : Optimal, Consistent >>>>> init state[0] : Fully Initialised >>> >>> This would correspond to "00 02", and it's what we should see after >>> initialization. On my system the BIOS sets "00 01" (Optimal, consistent, >>> Quick Init in progress) when it first creates an array, because the BIOS >>> doesn't do a full initialization. But "not initialized" is weird. The >>> mdadm DDF code won't set this by itself, AFAIK. Please make sure again >>> that the "before" data matches what mdadm/mdmon wrote just after >>> stopping during shutdown. >> >> I did it again and got the same result: both disks have: >> >> 00000860 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| >> >> and I checked again that "mdadm -E" reported an initialized state. >> >> Moreover this time I did a "sync" before dumping the ddf headers. >> >> So I'm quite lost, I can see only 2 cases: >> >> - with my HW setup some metadata are not written to disks by the >> kernel but stood somewhere in RAM (cache) >> >> - the state is not stored at address 00000860 (very unlikely) >> >> - the dumps are incorrect >> >> How can I debug this more ? >> >> Thanks for your help. > > have you got any further insight? Unfortunately no progress on this issue, I'm really stuck. I'll try to test a different distribution to see if the same issue persist. Maybe CentOS ;) > I have LSI DDF fake RAID with mdadm > running on my system right now, and it seems to work nicely; no problems > over reboots. > > You may want to retry with my latest patch set. In particular, "DDF: > container_content_ddf: set safe_mode_delay > 0" might help. Will give it a test. Thanks. -- Francis -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
