Date: Sun, 15 Mar 1998 21:04:55 +0100 From: J Wunsch <j@uriah.heep.sax.de> To: scsi freebsd <freebsd-scsi@FreeBSD.ORG> Cc: Harry Patterson <toj@gorillanet.gorilla.net> Subject: Re: CTT8000-S problems solved Message-ID: <19980315210455.35920@uriah.heep.sax.de> In-Reply-To: <01bd4eab$0df24fc0$5fca4ace@hp.harry.com>; from Harry Patterson on Fri, Mar 13, 1998 at 01:08:41PM -0500 References: <01bd4eab$0df24fc0$5fca4ace@hp.harry.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980315210455.35920>