Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!sequoia!ultima!kralizec.zeta.org.au!kralizec.zeta.org.au!not-for-mail From: bde@kralizec.zeta.org.au (Bruce Evans) Newsgroups: comp.os.386bsd.bugs Subject: Re: bad144 problem? Date: 22 Aug 1993 12:15:39 +1000 Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis Lines: 34 Message-ID: <256ksbINN1nv@kralizec.zeta.org.au> References: <1993Aug15.214815.3942@limbic.ssdl.com> <D> <9322908.27770@mulga.cs.mu.oz.au> <1993Aug17.121710.1498@limbic.ssdl.com> NNTP-Posting-Host: kralizec.zeta.org.au In <1993Aug17.121710.1498@limbic.ssdl.com> gil@limbic.ssdl.com (Gil Kloepfer Jr.) writes: >For those who have had the disklabel problem - I discovered this bug several >weeks back, and the problem is that one of the patches undoes setting the >DKFL_QUIET flag when accessing the raw partition (/dev/rwd?d - not c as some >of the comments imply). The patch undoes an important kludge that was incorrectly attached to the setting of the bogus DKFL_QUIET flag. The kludge is to allow opening of the 'd' partition when there is no disk label. It is quite dangerous using partitions when there is no label. This includes this specially opened 'd' partition - the only thing that is safe to do with it is to write a label that has the correct disk geometry. The geomtry is taken from the label and must be correct or the label may be written in the wrong place. This problem is unrelated to bad144. >my netnews/mail feeds going. I'm going to see if I can identify completely >and fix the problem with bad144 checking and post my results to the net. >However, I would really prefer not to have to reinvent the wheel, so if >anyone knows of a solution to this (other than using both forms of >bad block control and facing my computer toward Mecca) please let me know. The NetBSD version of the driver already has some subtantial improvements to bad144 handling. (The patchkit 0.2.4 version has some small fixes. The original 0.1 version has fatal bugs.) I use the patchkit version. The only problem with it is that the disk must not have any sometimes-bad sectors. This problem is easily avoided on ESDI drives by marking both bad and sometimes-bad sectors as bad in the controller's tables. Note that the controller's bad sector tables are unrelated to the bad144 tables. -- Bruce Evans bde@kralizec.zeta.org.au