Re: Re: fr1-2.16 patch for 2.6.10 kernel

"Also sprach denis bonnenfant:"
> > with CERC megaraid controller)! megaraid driver has changed, and now it 
> > doesn't necognise my hardware anymore !
> > So I'm going back to 2.6.8 !
> > 
> > I backported some of the changes made to 2.6.8.

Well, there was already a patch for 2.6.8.1 !

> > I'm going to test it now.
> 
> this is the result of a
> 
> mdadm --manage /dev/md0 --fail /dev/sda1

Uh, raidsetfaulty?

> ... some copy md0 ...
> mdadm --manage /dev/md0 --add /dev/sda1

raidhotadd?

> .....
> I don't wait the end of reconstruction

I don't know what effect that has. If you fail a device, it should stop
the sync.

> ....
> mdadm --manage /dev/md0 --fail /dev/sda1
> mdadm --manage /dev/md0 --add /dev/sda1

fail and then add should start a resync.

> and then it crashes !

Well, that's the default state of code.

> md0: notifying dev 800002 it is now in array
> md0: set repair bit to 1 on superblock f7cc1880
> md0: md_check_recovery 2: cleared recovery bits on sb f7cc1880
> md0: md_check_recovery 2: restored repair bit on sb f7cc1880
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
>   printing eip:

Access a null pointer to a struct, in a field that is one integer
offset from the start of the struct.

> f88ac3d7
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT
> Modules linked in: raid1 md epic100 usbkbd parport_pc lp parport
> CPU:    0
> EIP:    0060:[<f88ac3d7>]    Not tainted
> EFLAGS: 00010002   (2.6.8-enbd-fr1)
> EIP is at raid1_add_disk+0x4f/0xf8 [raid1]
> eax: 00000000   ebx: f6985228   ecx: 00000001   edx: f7cd0e80
> esi: d0d64540   edi: 00000001   ebp: f7cc1880   esp: d32e1f30
> ds: 007b   es: 007b   ss: 0068
> Process md0_raid1 (pid: 1658, threadinfo=d32e0000 task=d34f5410)
> Stack: d0d64540 f7cc1880 d2e9c800 f7cc1890 00000000 f7cd0e80 f88b9c80 
> f7cc1880
>         d0d64540 d2975780 d32e0000 d32e1fdc d32e0000 f7cc190c 00000000 
> f88ac9f5
>         f7cc1880 d2975780 d32e0000 d32e1fdc d32e0000 00000000 d34f5410 
> 0243d580
> Call Trace:
>   [<f88b9c80>] md_check_recovery+0x288/0x3b8 [md]

Well, it's a bit more than half-way through a routine in md.c. It's
infrequently used, so you should be able to pin down exactly where the
error is by inserting printks.

You probably want to compare your patch with the existing 2.6.8.1
patch.


>   [<f88ac9f5>] raid1d+0x19/0x1b8 [raid1]
>   [<f88b854f>] md_thread+0x14f/0x188 [md]
>   [<f88b8400>] md_thread+0x0/0x188 [md]
>   [<c01145a8>] autoremove_wake_function+0x0/0x40
>   [<c01145a8>] autoremove_wake_function+0x0/0x40
>   [<c0102245>] kernel_thread_helper+0x5/0xc
> Code: 8b 50 04 8b 46 14 8b 40 04 8b 40 30 39 42 30 75 5f 83 3b 00
>   <6>note: md0_raid1[1658] exited with preempt_count 1
> 
> Tomorrow, i'm trying to reproduce it.

I hastily hacked a patch for 2.6.10 (uncompiled, unpatched) which you
can compare with yours if you like.

Peter