From owner-freebsd-hackers Mon Mar 20 13:33:40 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA06832 for hackers-outgoing; Mon, 20 Mar 1995 13:33:40 -0800 Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA06796 for ; Mon, 20 Mar 1995 13:33:23 -0800 Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.8/8.6.6) with SMTP id OAA28893 for ; Mon, 20 Mar 1995 14:34:27 -0700 Message-Id: <199503202134.OAA28893@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol To: hackers@FreeBSD.org Subject: Re: Problems with 2940 and 950210snap In-reply-to: Your message of "Mon, 20 Mar 1995 09:21:26 CST." <199503201521.AA11221@plains.NoDak.edu> Date: Mon, 20 Mar 1995 14:34:25 -0700 From: Steve Passe Sender: hackers-owner@FreeBSD.org Precedence: bulk >> If I try to backup something to the DAT, mainly from the scsi disk, the system >> panics randomly after a few megabytes (it lasts much longer when data comes >> from the IDEs disks but it also panics..) > I am not sure this will help you, but I have a Adaptec 1542 and a Sony DAT. > FreeBSD 2.x is a lot more picky about DAT use than FreeBSD 1.x, namely it does > not like extremely large blocksizes. The problems I had were in reading a tape > with dd or restore that was created with large blocksizes causes the system to > panic. tar is a little more stable. try: > /sbin/dump 0usdf 3940 61000 /dev/nrst0 /dev/rsd0a Hello, I too have problems with 4mmDAT and dump/restore. I am using an Adaptec 1542B and an HP 1533A DDS-2 4mmDAT. In my case I can "dump 0f /dev/rst0 /dev/sd0x" a tape, but "restore isf 1 /dev/rst0" panics immediately. I tried the above incantation and it works! However I could not see how it limited blocksize (recordsize). If I read it right it sets the number of feet on the tape to 3940 and the tape density to 61000 BPI. Examinging the code (950210-SNAP) I found that a side effect of setting density is to set the recordsize to 32 (1024 byte) blocks. Sure enough "dump 0bf 32 /dev/rst0 /dev/sd0a", "restore isf /dev/rst0" works. (at least it gets to the prompt without panicing.) Looked at the code, found several things wrong, but nothing to explain this. So I rebuilt restore with -g, and paniced from what looked like a gdb problem. This tickled my memory about panic problems with gdb. Can I get the gdb binary from freefall and expect it to work under 950210-SNAP? My network connectivity is BAD right now and sup'ing my system to -current is out of the question. I really am eager to track this problem down and fix for the 2.1 release! Steve Passe smp@clem.systemsix.com