From owner-freebsd-current Fri Jun 7 21:44:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C378F37B429; Fri, 7 Jun 2002 21:44:30 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA30901; Sat, 8 Jun 2002 14:44:24 +1000 Date: Sat, 8 Jun 2002 14:45:06 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Brooks Davis Cc: "David O'Brien" , , Subject: Re: dump (via amanda) causing panics In-Reply-To: <20020607150716.A19826@Odin.AC.HMC.Edu> Message-ID: <20020608143938.M18304-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 7 Jun 2002, Brooks Davis wrote: > On Fri, Jun 07, 2002 at 02:16:45PM -0700, Brooks Davis wrote: > > On Fri, Jun 07, 2002 at 01:30:37PM -0700, David O'Brien wrote: > > > On Fri, Jun 07, 2002 at 12:59:55PM -0700, Brooks Davis wrote: > > > > Applying phk's patch seems to have fixed it. It's a bit overkill for > > > > fixing dump, but it did work and I guess this way I can do some limited > > > > testing of the ufs2 patch. Is that the full ufs2 patch? phk also committed a quick fix for dump. > > > Can you reduce PHK's ufs2 patch down to the minium required to fix dump? > > > That could then be committed now. > > > > The changes to dump are rather large so I doubt I'd have much luck. > > Also, it appears I spoke too soon. I was able to dump / and /var, but > > my /usr partition failed when I did another amanda run. I'm running a > > new test to /dev/null to see if I get anything useful out of it. > > Here's a sample of the errors I'm seeing: > > DUMP: read error from /dev/ad0s2f: Invalid argument: [sector -1980991191]: count=-1 > DUMP: read error from /dev/ad0s2f: Invalid argument: [sector -1980991190]: count=-1 > ... I saw similarly bogus sector (block) numbers when I first debugged this problem. They were caused by missing prototypes. 32-bit block numbers were passed to unprototyped functions that expected daddr_t block numbers. When daddr_t was changed to 64 bits, there was garbage in the top 32 bits. dump doesn't compile cleanly at a high WARNS level, so now would be a good time to WARNSify it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message