Re: fr1-2.16 patch for 2.6.10 kernel

Peter T. Breuer <[email protected]> wrote:
> I forgot to say that the 2.6 enbd patch still has one issue that often
> bites me .... whenever I hibernate my laptop with an enbd client
> running, on resume the enbd client dies through timeout (or the server
> does, I don't know which goes first!) and a new client is started to
> replace it, but the new client can't get into the kernel to register
> until I "echo 0 >/proc/nbdinfo". Then the old client finally "really
> really" dies and the new one starts up.

I managed to get a snapshot of the problem. The _incoming_ enbd client
is stuck in state D in "io_schedule" (not a function of mine).

 root     14920  0.0  0.2  1568  624 ?        D    Feb17   0:00 /tmp/enbd-client localhost 4044 -n 1 /dev/nda

 14920 /tmp/enbd-client io_schedule

The outgoing enbd client is waiting to receive a TERM signal from the
incoming, but the incoming won't come in ...


> the client is not in my code, but rather is in a semaphore somewhere
> else in the kernel. I suspect that the "echo 0 >/proc/nbdinfo" clears
> the lock by running invalidate_buffers.

Indeed, that clears the state fine. The outgoing client disappears, and
the incoming says:

    % enbd-client 14920: client (0) opened device /dev/nda
      ...
      enbd-client 14920: client (0) begins main loop

    
I really should check to see if just "invalidate buffers" does the
trick.  As far as I can see the incoming client cannot first open the
device even to start talking to it.  2.6 only.

Peter