From owner-freebsd-hackers Mon Mar 20 21:13:06 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA07940 for hackers-outgoing; Mon, 20 Mar 1995 21:13:06 -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 VAA07932 for ; Mon, 20 Mar 1995 21:13:01 -0800 Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.8/8.6.6) with SMTP id WAA00948; Mon, 20 Mar 1995 22:14:09 -0700 Message-Id: <199503210514.WAA00948@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol To: hackers@FreeBSD.org Cc: moto@CS.cmu.edu, tinguely@plains.nodak.edu Subject: Re: Problems with 2940 and 950210snap In-reply-to: Your message of "Mon, 20 Mar 1995 17:24:08 EST." <17745.795738248@GS81.SP.CS.CMU.EDU> Date: Mon, 20 Mar 1995 22:14:07 -0700 From: Steve Passe Sender: hackers-owner@FreeBSD.org Precedence: bulk Hello, I am closing in on the "restore ..." panics with 4mm DAT drives. Summary: without specific option dump writes (10 * 1024) byte records to tape while restore attempts to read (32 * 1024) byte records from tape. It is something about this read that appears to panic the kernel. Short term fixes: --- create dump tapes by: dump 0bBf 32 2000000 /dev/rst0 /dev/sd0x then: restore isf 1 /dev/rst0 should work. --- if you already have dump tapes created something like: dump 0f /dev/rst0 /dev/sd0x try: restore isbf 1 10 /dev/rst0 --- Notes: the lowercase 'b' option sets the number of 1024 byte blocks per tape record. the uppercase 'B' option sets the number of blocks expected to fit on the tape. Without the 'B' & '2000000' dump writes a relatively SMALL number of records b4 asking for a new tape. --- I would appreciate any feedback on the success/failure of these fixes... Steve Passe smp@clem.systemsix.com