Re: fr1-2.16 patch for 2.6.10 kernel

In article <[email protected]> you wrote:
> Sorry, i'm very busy and don't have much time for debugging...

That's fine. Thanks for the effort.

> I put a lot of  printks in md.c (one for each if block) and found that the last
> printed is here, near line 3850 :
> 
>                 if (mddev->degraded) {
>                         ITERATE_RDEV(mddev,rdev,rtmp)
>                                 if (rdev->raid_disk < 0
>                                     && !rdev->faulty) {
>                                         printk(KERN_INFO "md: debug line 3853\n");
>                                         if (mddev->pers->hot_add_disk(mddev,rdev))
>  
> 
> I'm continuing investigation... 

OK, are you saying it broke before getting out of that loop and into
the following:

 if (!spares && (mddev->recovery_cp == MaxSector )) {
         /* nothing we can do ... */
         goto unlock;
 }

?? It didn't die in the call, so the best bet is that the iteration goes
wrong, or rdev somehow ends up NULL. You might test the value of rdev,
or just add

    if (!rdev)
        break;

inside the loop. Mind you, it's fairly disastrous that rdev can be
zero, and I don't see how it managed to negogiate the just-prior
iteration. 

If you can pin the line down exactly, that would be great. It does look
like rdev is NULL.  I believe offset 4 (that was the oops, no?) in rdev
would be the prev pointer in the list_head at the front of the struct.
So that would be the iterator going wrong.

If I am correct, rdev->same_set.next should be NULL just before the
oops.


> Just an idiot question, but i'm newbie in kernel hacking !   
> Is there a simple (and fast) way to compile *only* md.c ? (assuming that deps
> has not changed)?

Sure - type "make modules" after touching md.c.  That's precisely what
make does.

If you mean you want to extract and run the relevant gcc line yourself,
you'll have to run

   make modules V=1

(or KBUILD_VERBOSE=1)

and notice the gcc command line for md.c.


Peter