Subject: Re: detachable device: stuck in biowait
To: Bill Studenmund <wrstuden@netbsd.org>
From: Ferry Sutanto <fsutanto@yahoo.com>
List: tech-kern
Date: 01/29/2002 16:45:42
Hi Bill,

Thank you very much for the information. Can u
elaborate more on "invalidating the file system" ? The
kernel gets the "device gone" interrupt, the first
thing it does is unmounting the FFS and call
config_detach. Is this what u mean by "invalidating
FFS" ?

I notice that although config_detach has finished, the
kernel still tries to write by calling either vn_write
or bwrite. I put little hack (a global flag == true if
device has gone) which will bail out if the device has
gone and I called brelse to clean up the buffer. FTP
exit with EIO error, but the csh (shell) hangs. Does
anybody have this problem before ? 

Thanks!

Ferry



--- Bill Studenmund <wrstuden@netbsd.org> wrote:
> On Mon, 28 Jan 2002, Ferry Sutanto wrote:
> 
> > Thank you for all the information. I have done all
> > that in normal cases. Right now, I am trying to
> put a
> > support in the kernel in a case where the
> > device/compact flash is pulled out during ftp
> write
> > session. FTP will call write to write to the flash
> and
> > write will call vn_write and eventuall access the
> > device driver. The problem I have now is that I
> > mounted the compact flash with MNT_SYNCHRONOUS so
> > bwrite (in vfs_bio.c) will call biowait to wait
> for
> > "write completion" interrupt from the device.
> Since
> > the device is already gone, no interrupt will
> come,
> > hence, the kernel hangs because it is waiting for
> > somebody to wake the buffer it puts to sleep
> (using
> > tsleep). I haven't solved this problem yet, but I
> > encountered another one.
> >
> > If the kernel calls bdwrite (delayed write), how
> does
> > it work. I see that somebody calls the bwrite and
> it
> > will eventual do the work. What is the condition
> that
> > the actual write will occur ?
> 
> The problem is that you shouldn't still have a file
> system when the device
> is gone. Yor error occured earlier when you let the
> kernel think there was
> still a devive when there wasn't.
> 
> When you get the eject event in the disk driver, you
> need to invalidate
> the file system then.
> 
> > Question on VOP_LEASE macro. It is not really
> obvious
> > which function will get executed for FFS. Can
> anybody
> > point it out to me ?
> 
> Look in sys/ufs/ffs/ffs_vnode.c. There are three
> dispatch tables. As with
> all file systems that support fifos, there is one
> dispatch table for fifos
> (fifo_this, fifo_that in it). As for all file
> systems that support device
> nodes, there is one for device nodes (spec_this,
> spec_that). Then there is
> one table for everything else in the filesystem.
> 
> So for most things, ufs_lease_check gets called. For
> device nodes,
> spec_lease_check. For fifos, fifo_lease_check.
> 
> Take care,
> 
> Bill
> 


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com