[ENBD] nbd 2.4.27 recommended kernel

[Cicero Mota]

Dear Peter,

After run make test as you suggested, once more I got seg fault/kernel Oops.
Thus, I decided give up 2.4.10 and try 2.4.28 kernel. This time, everything 
did work wonderfully.

If you care about kernel 2.4.10 I'll send you the test logs, otherwise

Many thanks for wasting you time with me (Muchas Gracias)


Cicero



On Wednesday 13 March 2002 11:44, you wrote:
> Let me more specific about my debugging instructions to you ...
>
> "A month of sundays ago Peter T. Breuer wrote:"
>
> > "A month of sundays ago Cicero Mota wrote:"
> >
> > > Here is what I did, hope you can give some help
> > > dd if=/dev/zero of=/tmp/delme bs=1024 count=5000000
> > > nbd-server  2610: server (0) set new signal handlers for slave server
> > > 2610 nbd-server  2610: newproto net errored on packet. Breaking off.
> >
> > Except here we get a basic communication problem.
> >
> > > nbd-client  2609: client (0) begins main loop
> >
> > Well, the other end wan't that happy with it. Doesn't it die?
> >
> > But what does /proc/nbdinfo say? It's pointless proceding until the
> > device has been set up.
> >
> > > dereference at virtual address 00000a33
> >
> > 0 plus 2600 or so. I don't have any structure that big.
> >
> > > Mar 12 19:41:34 fourier kernel:  printing eip:
> > > Mar 12 19:41:34 fourier kernel: c0114528
> > > Mar 12 19:41:34 fourier kernel: *pde = 00000000
> > > Mar 12 19:41:34 fourier kernel: Oops: 0002
> > > Mar 12 19:41:34 fourier kernel: CPU:    0
> > > Mar 12 19:41:34 fourier kernel: EIP:
> > > 0010:[interruptible_sleep_on_timeout+44/104]
>
> OK
>
>
> 1) run "make test" from the package. Do not do your own setup.
> 2) if the test device sets itself up properly, (on /dev/nda? I
>    don't recall), run
>
>      nbd-test /dev/nda -t 1:2
>
> 3) if the above segfaults, redo the test after having recompiled the
>    module with DEBUG=1 (or 2, or 3) as a parameter. I.e.
>
>      rm /tmp/nbd.o
>      make DEBUG=1
>
>    and replace the loaded module with the new one. Oh yes, sorry, but
>    you have to reboot after a kernel oops. Maybe things are OK, maybe
>    they aren't .. I need to know they are OK.
>
>    Run the test again. There should be a lot of debugging info in
>    dmesg. If that's not enough to pinpoint the segfault, do it again
>    with a higher DEBUG number. Start with "1", though. Too much
>    information is as difficult to deal with as too little.
>
> When I have news back from you we can go on to chase it down some
> more.
>
> Peter
> _______________________________________________
> ENBD mailing list
> ENBD@lists.community.tummy.com
> http://lists.community.tummy.com/mailman/listinfo/enbd