On Jan 7, 2008 9:03 AM, Mister Olli <[EMAIL PROTECTED]> 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