Subject: 1.6 and SCSI tapes and Amanda
To: None <port-i386@netbsd.org>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
List: port-i386
Date: 02/03/2003 16:35:46
-----BEGIN PGP SIGNED MESSAGE-----
I run amanda on an old file server to backup my network.
(I have a new case+motherboard on order...)
The machine was recently upgraded to 1.6, custom kernel.
Kernel config is at: http://www.sandelman.ca/tmp/SSW
Dmesg output is at: http://www.sandelman.ca/tmp/istari.dmesg
The system consistently crashes every night while running the tape.
I would have reported this earlier, but I've been avoiding backups for half
of January when I was travelling and could not take care of things.
The only consistent thing is that the stack trace is never the same.
I wish I could provide more info than this. This is my console server,
so I will have to screw around a whole bunch to get a serial console on it.
The SCSI bus looks like:
ahc0 at pci0 dev 18 function 0
ahc0: interrupting at irq 11
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
scsibus0 at ahc0: 16 targets, 8 luns per target
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <QUANTUM, VIKING 2.3 SCA, 880R> SCSI2 0/direct fixed
sd0: 2171 MB, 6144 cyl, 4 head, 180 sec, 512 bytes/sect x 4446801 sectors
sd0: sync (100.0ns offset 8), 16-bit (20.000MB/s) transfers, tagged queueing
sd1 at scsibus0 target 1 lun 0: <DEC, RZ28 (C) DEC, 442E> SCSI2 0/direct fixed
sd1: 2007 MB, 3045 cyl, 16 head, 84 sec, 512 bytes/sect x 4110480 sectors
sd1: sync (100.0ns offset 8), 16-bit (20.000MB/s) transfers, tagged queueing
sd2 at scsibus0 target 3 lun 0: <QUANTUM, VIKING 4.5 SCA, 880R> SCSI2 0/direct fixed
sd2: 4345 MB, 6144 cyl, 8 head, 181 sec, 512 bytes/sect x 8899737 sectors
sd2: sync (100.0ns offset 8), 16-bit (20.000MB/s) transfers, tagged queueing
st0 at scsibus0 target 6 lun 0: <ARCHIVE, Python 04687-XXX, 6580> SCSI2 1/sequential removable
st0: density code 36, 512-byte blocks, write-enabled
st0: sync (128.0ns offset 15), 8-bit (7.812MB/s) transfers
I did have an sd3 on the system. It died two weeks ago, during a power cycle.
It was... 6 years old I think.
It also has:
wd0 at pciide0 channel 0 drive 0: <Maxtor 2R015H1>
wd0: drive supports 16-sector PIO transfers, LBA addressing
wd0: 14305 MB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 29297520 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
which is primarily used as a spool disk for amanda, and not a lot else.
The system ran for months on end with 1.5.x.
istari-[~] mcr 1015 %uname -a
NetBSD istari.sandelman.ottawa.on.ca 1.6_STABLE NetBSD 1.6_STABLE (SSW) #1: Sun Dec 29 23:27:38 EST 2002 mcr@istari.sandelman.ottawa.on.ca:/j/netbsd/obj/SSW i386
I've updated /usr/src/sys and will see what I get from 1.6.1.
I'm going to confirm this tonight, but it does not crash while backing up if
I spool to disk.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPj7groqHRg3pndX9AQHffQP9FwgoPY4xpneeqqhs4SIFh7Hg0hkNi2Ys
Vegp1nZRRTDWxMLuSbTXtfKh9cfqynDr+kFpitRW8Dg7R16AOw/VaiP3MHM/6wgh
eiOfwHR6tsVbo/HiFpx1RP/gJrQznzs9w5eztYvh1ZgMQ4jhHnFFzqp6KRbB1xT9
fbmYEs8oCq0=
=a7iK
-----END PGP SIGNATURE-----