Re: init scripts problems ?

"Also sprach denis bonnenfant:"
> without -e ,
> 
> 
> stopping client involved  in a raid array fails :

That sounds like the problem of the death-deadlock again - probably
with another kernel area as source. 

The first problem we solved was that on last close, the kernel flushes
to the device.  This is, uh, unfortunate, when the last close is that of
the last daemon, since one needs the daemon to handle requests, so the
flushed requests can't be handled and block the flush.  But nor can the
daemon die fully (which would alert the driver to switch off the device
and kill incoming requests) until the kernel completes the flush and
tells the driver that the close has happened.

This is an unfortunate sequence - the kernel does "userspace-dies flush
tell-driver go-zombie".  It should do "userspace-dies tell-driver flush
go-zombie" if the driver is to have any hope of preventing the daemon
close sequence from hanging.

One "solves" it either (a) by killing blocked requests with external
user aid (echo 0 ...), or (b) stopping the kernel from doing that then,
by fooling it that the device is still open always.


> here is my ps output ( I use ps axf opid,wchan:20,cmd  which specify the WCHAN 
> width )
> 
>   2967 -                    [enbd-client]
>   2970 -                     \_ [enbd-client]
>   2971 sync_page             \_ enbd-client se3-croise 12355 -i A-2 -n 2 -m -b 
> 512 /dev/nda

Sync page??? can you add the state to those ps format flags? D/T/S etc.

> so it's clearly the last child
> 
> nda has disappeared from cat /proc/mdstat, is it normal ?

That argues that the array has been notified that the device is faulty.

> echo 0 kill enbd-client, but something remains locked somewhere, as md can't be 
> stopped now !

I'm sure it can :-). Are you sure there is no oops in the dmesg output?

> with -e, no more problems stopping client, but raid can't be stopped too.

That is a strange statement! The -e should only affect the default
state of the client at startup, avoiding problems before the array
entrains it.

In a separate patch here I moved the array notifications into a
tasklet, since I was worried about racing or deadlock in a circle.  I
could give you that patch to see if it helps. If it doesn't, it at least
eliminates the array communication as a problem. 

I'm afraid that "sync_page" is too generic to help me much! The process
state might help. D, I suppose. It would help me locate where in
sync_page it is.

I still see indications that there are some possible circular deadlocks
around taking the nda block device semaphore on device open/close but
they "go away" after a 90s timeout.  I think I see a new master client
daemon stuck in "io_schedule" (D) presumably on open nda while waiting
for a previous client daemon to die.  ...  weirrrrd. The slow to die
daemon is in its sync to device routine on last close, having taken the
device semaphore, thus preventing anyone else from taking the device
semaphore and opening the device. But we arranged to fool the kernel
as to last cloe, so something else is doing the sync. Sigh. I'll have
to do a debug kernel run.


Peter