From owner-freebsd-stable Sun Sep 28 03:42:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA25115 for stable-outgoing; Sun, 28 Sep 1997 03:42:08 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA25109 for ; Sun, 28 Sep 1997 03:42:02 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA15728; Sun, 28 Sep 1997 20:39:18 +1000 Date: Sun, 28 Sep 1997 20:39:18 +1000 From: Bruce Evans Message-Id: <199709281039.UAA15728@godzilla.zeta.org.au> To: jfarmer@sabre.goldsword.com, mdean@best.com Subject: Re: bad144 Cc: freebsd-stable@freebsd.org, jfarmer@goldsword.com Sender: owner-freebsd-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I am not really worried what bad144 thinks, I worried that if it returns >errors so will freebsd in general since it does run under freebsd and uses >freebsd system calls I assume. It seems to be just another application bug. Untested fix: diff -c2 bad144.c~ bad144.c *** bad144.c~ Fri Sep 5 13:13:13 1997 --- bad144.c Fri Sep 5 13:13:23 1997 *************** *** 145,149 **** } ! lseek(f, curr_sec * ss, L_SET); if ((n = read(f, buf, ss)) != ss) { --- 145,149 ---- } ! lseek(f, (off_t)ss * curr_sec, SEEK_SET); if ((n = read(f, buf, ss)) != ss) { >> Why use bad144 at all? It's a relic left over from the VAX/PDP-11 days... >> Search the archives, this has come up several times. It the drive checks >> good with the vendors utilities (for IDE and SCSI) then it's good. >> >> bad144 had it's day when drives _didn't_ do automatic bad block >> replacement. >> >> John (Yes, I'm old enought to have had to deal with such beasts. >> My first Unix box was a PDP-11/34 with Version 6.... And >> _big_ RK-05 drives, all of 2.5mb each...) For FreeBSD, bad144 should only be necessary for MFM and ESDI drives. Bruce