CTT8000-S problems solved
Harry Patterson
Thanks to Tom, David and Christopher for their ideas and moral support.
Thanks to pure coincidence on Friday the 13th, the great Seagate Tapestor
mystery has been solved. The problem turned out to be an IRQ conflict with
USB and the SCSI controller on my new machine. We discovered this quite by
accident after setting up an exact duplicate of this computer with Windows95
for one of our users. Windows95 yelled about the IRQ 11 conflict between
the Adaptec aha1505 and the USB. It instantly clicked with me that the same
must be happening on the FreeBSD box. I quickly changed the IRQ of the
network card from 10 to 3 and the aha1505 from 11 to 10, rebooted, adjusted
the kernel and instant success.
Of course not all questions are answered yet which brings me to the next
set:
What does FreeBSD offer to identify these type of IRQ conflicts?
When I first used dump I used a derivative of Curt's suggestion (12/8/96)
and used "dump 0ubBf 32 /dev/nrst0 /" which worked but did not include the
entire disk (only backed up 14,950 tape blocks vs the 333348 for /usr). I
modified it to be the /usr directory and it backed up all of /usr. What do I
use to back up the entire disk and how do I determine the optimum parameters
for dump, including blocksize (-b 32), for my drive?
Thanks again,
Harry
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
J Wunsch
As Harry Patterson wrote:
> What does FreeBSD offer to identify these type of IRQ conflicts?
It doesn't register conflicting drivers at all. There's no driver for
the conflicting USB however, so FreeBSD stood no chance of seeing the
problem. Blame the USB hardware for clamping the IRQ line high even
if not being in active use at all.
> What do I
> use to back up the entire disk
dump always works filesystem-wise. Call it twice (with the non-rewind
tape device, /dev/nrst0) in order to dump two filesystems.
> and how do I determine the optimum parameters
> for dump, including blocksize (-b 32), for my drive?
The default blocksize is probabably reasonable enough. You can pipe
the output through team(1) (from the ports collection) in order to
improve the streaming behaviour. In theory, this might bogotify the
end-of-tape detection (and dump's prompting for a new tape), but in
practice the end-of-tape signalling of the st(4) driver is broken
anyway. (As a consequence, ``dump ... -a'' doesn't work.)
In -current, someone might rewrite dump to use AIO, as far as i
understand, this should have the same effect as piping the data stream
through team(1).
--
cheers, J"org
joerg_...@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)