An old trick I used for many years:
to investigate a "problem" filesystem, do a "find" in that filesystem. 
If the find dies, tsm definitly will die.
I'll bet your find will die, and that's why your backup will die/hang or 
whatever also. A find will do a filestat on all files/dirs, actually the same 
the backup does.
So your issue is OS related and not tsm.

Cheers
Henk ()

On Tuesday 29 March 2005 12:11, you wrote:
> On Mar 29, 2005, at 12:37 PM, Zoltan Forray/AC/VCU wrote:
> > ...However, then I try to backup the tree at the third-level (e.g.
> > /coyote/dsk3/), the client pretty much siezes immediately and
> > dsmerror.log
> > says "B/A Txn Producer Thread, fatal error, Signal 11".  The server
> > shows
> > the session as "SendW" and nothing going else going on....
>
> Zoltan -
>
> Signal 11 is a segfault - a software failure.
> The client programming has a defect, which may be incited by a problem
> in that area of the file system (so have that investigated). A segfault
> can be induced by memory constraint, which in this context would most
> likely be Unix Resource Limits, so also enter the command 'limit' in
> Linux csh or tcsh and potentially boost the stack size ('unlimit
> stacksize'). This is to say that the client was probably invoked under
> artificially limited environmentals.
>
>     Richard Sims