Re: init scripts problems ?

"Also sprach denis bonnenfant:"
> EIP is at invalidate_bdev+0xa/0x20
> eax: 00000000   ebx: 00000000   ecx: ffffff96   edx: f2bc620c
> esi: 00000000   edi: 00000000   ebp: f893a5d0   esp: f3ac1ec4
> ds: 007b   es: 007b   ss: 0068
> Process bash (pid: 6224, threadinfo=f3ac0000 task=f7e55a40)
> Stack: 00000000 c0162e4b 00000000 00000000 f8939fec 00000000 f8938e60 f892b005
>         00000000 f8931c22 f893a5d0 f8930b4a 00000c98 00000009 f8931c12 f8938e60
>         00000000 00000002 080e8c08 f8930554 f8938e60 00000000 00000000 d46c0c80

Well, it's not clear that this is the relevant trace - unfortunately one
wants to get the trace from when it is STUCK, not from when it has
oopsed, on the grounds that getting stuck happens first, is bad, and
everything else is secondary.

But it's interesting.

> Call Trace:
>   [<c0162e4b>] __invalidate_device+0x37/0x40

Shrug - what can I say? It oopsed in the kernel's
standard __invalidate_device function, having done a device reset after 
you asked it to with the echo 0> nbdinfo.

Right at the end of it too! It's in fs/inode.c. Must be in the call to
invalidate_bdev. It is.

        invalidate_bdev(bdev, 0);
        return res;
  }

It's half-way through invalidate_bdev. Hmm.

You'll have to take your copy of buffer.o, and run objdump --disassemble
on it, and show me the listing of that function.

In my copy it must indicate a null bdev->bd_inode field:

  void invalidate_bdev(struct block_device *bdev, int destroy_dirty_buffers)
  {

    invalidate_bh_lrus();
    invalidate_inode_pages(bdev->bd_inode->i_mapping);
  }


The really really really hackish thing to do would be to check in the
enbd_soft_reset function if 

   lo->inode->i_bdev->bd_inode 

is NULL or not, and refrain from calling  __invalidate_device if so.

I guess one can see the problem - maybe one should just NOT call 
 __invalidate_device at all there. I only wanted to error out its
requests.


>   [<f892b005>] enbd_soft_reset+0xa1/0x11c [enbd]

You are here:

        ENBD_ALERT("INVALIDATE DEVICE nd%s\n", lo->devnam);
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,12)
        __invalidate_device(lo->inode->i_bdev, 0);
#else
        __invalidate_device(lo->inode->i_bdev);
#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2,6,12) */

        if (1) {
                struct inode *inode = lo->inode;
                struct block_device *bdev = inode ? inode->i_bdev : NULL;
                request_queue_t * q;
                if (!bdev)
                        return 0;
                q = bdev_get_queue (bdev);
                ENBD_ALERT("run enbd_request on nd%s\n", lo->devnam);
                spin_lock_irq(q->queue_lock);
                do_enbd_request (q);
                spin_unlock_irq(q->queue_lock);
        }

        return 0;
}

You should see INVALIDATE DEVICE nda in the logs.

That disgusting addition in the if block appears to be never reached!
It simply runs the request function on any remaining request,
presumably intending to kill them as the device is now reported as
missing to the kernel.  Are they not already hunted down by the kernel?
No - I can see that they wouldn't be, since we have them here in our ht
little hands.

I would say ... that the oops you are seeing is entirely a consequence
of the echo 0 > nbdinfo, which you ONLY did to unstick the sync_page.
So forget about it. Fixing the stuck sync_page will mean that yu don't
have to do that then.

There are two problems - forget about the second. I'll think about it.
A stack trace from the first problem is what's needed.



>   [<f8930554>] enbd_write_proc+0x68/0x300 [enbd]
>   [<c015be42>] locate_fd+0x6e/0x90
>   [<c017b813>] proc_file_write+0x27/0x34
>   [<c014c4e5>] vfs_write+0x8d/0xec
>   [<c014c5f0>] sys_write+0x40/0x6c
>   [<c0102d31>] syscall_call+0x7/0xb
> C

Peter