On Jan 7, 2008 9:03 AM, Mister Olli <mister.olli AT googlemail DOT com> wrote:
> (gdb) bt
> #0  0x281ece17 in shmget () from /lib/libc.so.6
> #1  0x080520f4 in attach_buffers ()
> #2  0x0804b872 in main ()

Eek -- this is where the taper is allocating the memory that it will
share with the tape-writer process.  Have any FreeBSD folks seen this
error before?  On my mac, which is as close as I've got, signal 12 is
SIGSYS -- bad argument to syscall.  The most likely "bad" argument is
probably the middle one -- size, the size of the space for buffers.
It's calculated as follows:

page_size + tapebufs * (buffer_size + epsilon)

where page_size is the page size for your kernel (probably 4k?),
tapebufs is from amanda.conf, buffer_size is the blocksize from the
relevant tapetype in your amanda.conf, rounded up to the next
page_size, and epsilon is a few bytes for headers -- probably about
20.

I think the likely next step is to calculate those parameters for your
config, and see what the result comes out to.  I bet your
tapetype/blocksize or your tapebufs are too large.  Note that tapebufs
is a *count*, not a size.  If you specify, e.g.,
  tapebufs 128k
and
  blocksize 32k
then you've actually specified 131,072 buffers, each of 32768 bytes --
4G, which is too large to allocate on a 32-bit machine.  If that's the
case, then you probably meant
  tapebufs 128
which will allocate a total of 4M of buffers -- much more reasonable.

Even if the size is too large, though, I'm not sure why the kernel
would send a signal, rather than just returning an error like most
syscalls.  I would pontificate on how to fix that, but this code is
not present in the next version of Amanda (the Device API's tape
driver uses a different model), so it's not worth worrying about.

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com