Can a process stop with a locked inode?

[Pond Scum]

I'm seeing some strange behavior on file systems mounted on a device
driver (erasable optical disk) I wrote.  Almost everything seems to be ok,
I can newfs the disk, mount it, copy files to it, fsck it, etc.  However,
if I copy a huge file to the disk and send the cp process a SIGSTOP while
it's copying the file, I can't stat(2) the destination file.  It just hangs
until I either continue the cp in the foreground or background, or kill it.
No data is lost or anything else, but if I do an ls -l it hangs until
the cp starts running again or exits.  It's as if the cp is getting stopped
while holding a lock on the inode for the destination file, and the stat
is sleeping until the inode is free.  Is this even possible?  I can't think
of anything else to explain what I'm seeing.  I checked to make sure that
the driver's interrupt routine always calls the start routine until there
are no more bufs in its queue, so that's not the problem.  I can do an ls
on the directory, and an ls -l on all the other files, but ls -l on the
destination hangs, so I'm assuming that it's the stat(2) on the destination
file that causes the hang.

The driver we got from the distributor that sold us the disk also exhibits
the same behavior.

The environment is a Sun SPARCStation 2 running SunOS 4.1.1.  I would greatly
appreciate any help.

Thanks
Jonathan			hue at island.COM