Bug#446323: mdadm: recovery in infinite loop

[Lukasz Szybalski]

On 10/11/07, Neil Brown <neilb at suse.de> wrote:
> On Thursday October 11, szybalski at gmail.com wrote:
> > Package: mdadm
> > Version: 2.5.6-9
> > Severity: normal
> >
> > Hello,
> > I am trying to setup raid1 on my pc.
> > I have 2 identical drives. 270+gb. each with 3 partitions.
> > 30gb hdb1   -> md0
> > 250gb hdb2   ->md2
> > 4gb swap hdb5  ->md4
> >
> > Initially my raid had only one drive. I have added the second one with
> > mdadm --add /dev/md2 /dev/hda1 then 2 then 4
> >
> > It started doing recovery for drives. IT finished for md0,md4 but for
> > md2 it is in infinite loop. IT goes to 15 % and starts again
>
> Very weird....
>
> This is a kernel problem rather than an 'mdadm' problem, but anyway...
>
> Th recovery process thinks that it is either getting an error or being
> interrupted.
>
> If it was getting a write error to the new drive, that drive would be
> marked faulty, so that isn't happening.
> If it was getting a read error from the good drive, it would say
>    raid1: md2: unrecoverable I/O read error fro block XXXXXX
> and that isn't happening.. So it cannot be an IO error.
>
> There are three ways to interrupt the resync.
>
>  1/ Send a signal to the thread.  That would result in the message
>         md: md_do_sync() got signal ... exiting
>  2/ Stop the array (mdadm -S).  If you did that, the array would stop.
>  3/ Write 'idle' to /sys/block/md2/md/sync_action
>
> Given the logs that you posted, the last one is the only option I can
> think of.  By why would you be doing that.
> It could be done with
>     /usr/share/mdadm/checkarray -x all
> but I cannot see that being done either.
>
> So I am confused.
>
> Have you tried rebooting to see if that helps?
>
yes I have.
Then I tried booting in knoppix to see if maybe there are hdd problems
so I run e2fsck on both drives to see if there are any issues.
reboot and it still does the same thing.

Is mdadm able to sync in init 1?
Is there a debug mode so I could get more logs for the mdadm?
If this seems as a kernel problem, how could I find out that is the
case? Where would I start?

Lucas