Lock up issue

[Urban Widmark]

On Wed, 28 Feb 2001, Mike Baptiste wrote:

> I've found since I first put this system together that if I have 2
> applications accessing SMB shares (not necessarily the same one) at the same
> time, the samba subsystem locks up along with the applications.  It first

The smbfs subsystem. The reason the apps lock up is that they are waiting
for smbfs to respond.

> document like Gnumeric or AbiWord.  It would lock the apps up.  Killing the
> parent process would leave defunt zombies that could NOT be killed.  Even
> root kill -9 would not work.

A defunct process is already dead, you can't kill it. It is waiting for
the parent to collect them (but if the parent really is dead init should
do that ...)


> Once it freezes, the shares are dead.  Any application tryin gto access them
> (even 'df') will freeze when it gets to the SMB shares.

One way to get this effect of complete lockup is if the server isn't
responding (down). Which doesn't seem likely here.


> The shares cannot be unmounted.  Durin gshutdown, I get errors from
> smb_request as the system tries to unmount the shares.  I get smb_request
> error=-512 setting invalid and then a few error=-3.

-512 errors happens if the current process has caught a SIGSTOP or SIGKILL
signal when smbfs tries to send something. It is a bug that usually causes
the mount to stop working.

You are sure you do not see these before unmounting? And you don't get any
other messages from 'dmesg'? (Getting them at shutdown is expected).

> It should be noted that sometimes during a shutdown when the shares are NOT
> forzen, I'll get error=-104 I believe though the shares to that point were
> functioning fine.

You get these when the server disconnected and smbfs re-connected. They
are not really errors (or rather, they are temporary errors).


> When I've had just ONE applciation using a share - never had a problem.
> I've played MP3s for days straight - no problem.  But open another app
> accessing different files or even a different share and it doesn't take long
> for hte shares to lock.

Can't say that I have ever seen this. Trying this now and it's doing just 
fine. Could you perhaps give a more detailed "script" of what you need to 
do to get a lockup? Something like:

1. start xmms (version?), 'xmms *.mp3 &'
2. start gnumeric on the same share and the same shell
3. edit the sheet
4. save in xyz format
5. repeat 3-4 for 10 minutes
...


> I know this is light on debug info - is there any tool or /proc file that
> might shed some light on this?  I can reproduce it fairly easily (just play
> MP3s and then do normal stuff :) )

When the shares lock you could check what the processes are doing.

'ps -ln -p <pid>' for all pid's accessing smbfs.

You could also, if you have enabled "sysrq debugging" press sysrq-t
(alt gr - sysrq/print screen - t). This dumps all processes and the kernel
call trace.

Both of these are useless without a way to map the numbers to symbols. For
that I'd need your System.map. If you have smbfs as a module, then I think
I need the output of 'cat /proc/ksyms' too and the smbfs.o from
/lib/modules/2.4.2/kernel/fs/smbfs/smbfs.o.

Also a list of which processes are accesing which share.


/Urban