From owner-freebsd-stable Tue Jul 28 07:07:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA14719 for freebsd-stable-outgoing; Tue, 28 Jul 1998 07:07:35 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from pop.asahi-net.or.jp (pop.asahi-net.or.jp [202.224.39.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA14700 for ; Tue, 28 Jul 1998 07:07:24 -0700 (PDT) (envelope-from tfuruya@dilemma.tf.or.jp@ppp142007.asahi-net.or.jp) Received: from galois.tf.or.jp (ppp142007.asahi-net.or.jp [202.213.142.7]) by pop.asahi-net.or.jp (8.8.8/3.6W) with ESMTP id XAA16836; Tue, 28 Jul 1998 23:12:29 +0900 Received: from dilemma.tf.or.jp (dilemma.tf.or.jp [192.168.1.3]) by galois.tf.or.jp (8.8.8/3.6W-ht5t-fry@asahi-net-98042218) with ESMTP id XAA22149; Tue, 28 Jul 1998 23:06:44 +0900 (JST) Received: from dilemma.tf.or.jp (localhost [127.0.0.1]) by dilemma.tf.or.jp (8.8.8/3.6W-CF3.6W-dilemma-tf.or.jp-9807) with ESMTP id XAA03014; Tue, 28 Jul 1998 23:10:37 +0900 (JST) Message-Id: <199807281410.XAA03014@dilemma.tf.or.jp> To: smarzloff@carif-idf.org Cc: freebsd-stable@FreeBSD.ORG, Tetsuro FURUYA Subject: Re: Disk problem. From: Tetsuro FURUYA Reply-To: Tetsuro FURUYA In-Reply-To: Your message of "Mon, 27 Jul 1998 09:54:56 +0200" References: <19980727095456.A26476@rafiki.intranet.carif.asso.fr> X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3 X-fingerprint: F1 BA 5F C1 C2 48 1D C7 AE 5F 16 ED 12 17 75 38 X-URL: http://sodan.komaba.ecc.u-tokyo.ac.jp/~tfuruya/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Date: Tue, 28 Jul 1998 23:10:34 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id HAA14708 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh, you have returned. In Message-ID: <19980727095456.A26476@rafiki.intranet.carif.asso.fr> Stephane Marzloff wrote: > Dans un message du 09 Jul à 06:49, Tetsuro FURUYA écrivait : > > > > > > Your ide disk sector is broken. > > Try > > bad144 -s -v /dev/wd0 > > or > > badsect & fsck (This is rather difficult. So, please read man). > > Hello.. > I'm back. > > So I launch the 'bad144 -s -v wd0, it run about 48H for a 4,8Go. We have to pay attention to drive assignment, or we will destroy disk. Block device name is required. We have to read man bad144(8) carefully. So it took 48 Hours, but finally bad144 finished. It seems too long. Something may be abnormal except disk sectors. > > This is the report : > > [18:22] root@rafiki:~ # bad144 -s -v wd0 > cyl: 621, tracks: 255, secs: 63, sec/cyl: 16065, start: 0, end: 9992178 > 9976365 of 9992178 blocks ( 99%) > bad block information at sector 9992304 in /dev/rwd0c: > cartridge serial number: -1108550333(10) > bt_flag=a70a(16)? > bad144: /dev/rwd0c: bad flag in bad-sector table > bad144: /dev/rwd0c: bad magic number ??? > bad144: cyl/trk/sect out of range in existing entry: sn=656226137, cn=40848, tn=44, sn=245 This seems to be a gabage data on the bad sector information which is located in the first 5 even numbered sectors of the last track of the disk pack. If there exists bad sectors, they are processed before these data. > bad144: cyl/trk/sect out of range in existing entry: sn=429083853, cn=26709, tn=58, sn=114 ............ > bad144: cyl/trk/sect out of range in existing entry: sn=577960943, cn=35976, tn=102, sn=77 > Exit 1 If there are bad sectors, bad144 displays those blocks when executing access to those blocks, such as, Block: 1308727 will be marked BAD. Did you have messages like this ? Unfortunately, bad144 leaves no data of bad blocks on /var/log/messages. So, I get this data doing, ============================ #/usr/local/bin/bash (or /bin/sh) #bad144 -s -v 2>1& | tee bad144.log #echo "#include ">cr.cc;echo "using namespace std;\ main(){char cc;while(cin.get(cc)){if(cc==0x0d)cc=0x0a;cout << cc;}}" >>cr.cc; #g++ cr.cc;./a.out < bad144.log | egrep -i BAD ======================================================= And, it says "/dev/rwd0c: bad flag in bad-sector table". It is difficult to know the meaning of this statement. Does "bad flag" mean that bad-sector table is broken ? Or, is "bad sector" registered as a flag in bad-sector table ? If there are bad sectors and the case is the latter, you can know these are fixed or not by achieving some simple tests. For example, ===================================== /usr/local/bin/bash (or /bin/sh) su root sync cat /dev/zero >/usr/ttt 2> catzero1.log sync cat /usr/ttt > /dev/null 2> catzero2.log rm /usr/ttt sync find /usr -name "peanuts" > /dev/null 2> find.log sync egrep -R "peanuts" /usr > /dev/null 2> egrep.log less /var/log/messages ================================================== And if wd driver has hung up, bad144 could not end and display these gabage data. So, there seems to be no need for a patch to wd.c. In this case, fdisk do not show whether there is bad sectors or not, because, there are bad sectors in my disk, but my fdsik shows the same list. > > # fdisk > ******* Working on device /dev/rwd0 ******* > parameters extracted from in-core disklabel are: > cylinders=622 heads=255 sectors/track=63 (16065 blks/cyl) > > parameters to be used for BIOS calculations are: > cylinders=622 heads=255 sectors/track=63 (16065 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 63, size 9992367 (4879 Meg), flag 80 (active) > beg: cyl 0/ sector 1/ head 1; > end: cyl 621/ sector 63/ head 254 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > > -- > Stéphane Marzloff -> smarzloff@carif-idf.org > (setq viper-mode t) > If you cannot find bad sectors, and the defects continues, that was not for bad sectors. Tetsuro Furuya These are my logs. ===================================== #bad144 -s -v wd0 2>1& | tee bad144.log #/usr/local/bin/bash (or /bin/sh) #bad144 -s -v 2>1& | tee bad144.log #echo "#include ">cr.cc;echo "using namespace std;\ main(){char cc;while(cin.get(cc)){if(cc==0x0d)cc=0x0a;cout << cc;}}" >>cr.cc; #g++ cr.cc;./a.out < bad144.log cyl: 657, tracks: 64, secs: 63, sec/cyl: 4032, start: 0, end: 2652804 0 of 2652804 blocks ( 0%) 4032 of 2652804 blocks ( 0%) 8064 of 2652804 blocks ( 0%) ...... 1278144 of 2652804 blocks ( 48%) Block: 1278972 will be marked BAD. Block: 1279172 will be marked BAD. Block: 1279173 will be marked BAD. ...... Block: 1310765 will be marked BAD. Too many bad sectors, can only handle 126 per slice. #egrep -R "peanuts" /usr/ports > /dev/null 2> egrep.log #cat egrep.log egrep: /usr/ports/archivers/gshar+gunshar/patches/patch-aa: Input/output error egrep: /usr/ports/comms/mgetty+sendfax/work/mgetty-1.0.0/tools/g3.o: Input/output error egrep: /usr/ports/japanese/mew/work/mew-1.54/mew-header.el: Input/output error egrep: /usr/ports/japanese/mew/work/mew-1.54/Makefile.orig: Input/output error ...... #tail -5 /var/log/messages Jul 28 22:45:01 dilemma /kernel: wd0s1f: hard error reading fsbn 1215944 of 1215944-1215951 (wd0s1 bn 1342920; cn 333 tn 4 sn 12)wd0: status 59 error 10 Jul 28 22:45:20 dilemma /kernel: wd0: interrupt timeout: Jul 28 22:45:21 dilemma /kernel: wd0: status 58 error 10 Jul 28 22:47:35 dilemma /kernel: wd0s1f: hard error reading fsbn 1215936 of 1215936-1215939 (wd0s1 bn 1342912; cn 333 tn 4 sn 4)wd0: status 59 error 10 Jul 28 22:48:17 dilemma /kernel: wd0s1f: hard error reading fsbn 1215940 of 1215940-1215943 (wd0s1 bn 1342916; cn 333 tn 4 sn 8)wd0: status 59 error 40 Tetsuro Furuya ======================================================================== TEL: 048-852-3520 FAX: 048-858-1597 || E-Mail: 8==------ ht5t-fry@asahi-net.or.jp , tfu@ff.iij4u.or.jp * || pgp-fingerprint: \|/ pub Tetsuro FURUYA Key fingerprint = F1 BA 5F C1 C2 48 1D C7 AE 5F 16 ED 12 17 75 38 ========================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message