Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!wotan.compaq.com!moxie!limbic!gil From: gil@limbic.ssdl.com (Gil Kloepfer Jr.) Subject: bad144 problem? Organization: Southwest Systems Development Labs, Sugar Land, TX Summary: EIO returned on disk I/O, appears to be bad144 problem Message-ID: <1993Aug15.214815.3942@limbic.ssdl.com> Date: Sun, 15 Aug 1993 21:48:15 GMT Lines: 26 If this has been covered before, please e-mail me the fix. I have two Maxtor XT4380E 320MB ESDI disk drives on my machine running 386BSD 0.1.2.4. On both drives, files are mysteriously getting corrupt and an error 5 (EIO) is being sent back to the program reading the file. I suspect that the problem is that the wd.c driver is not handling the bad144 table correctly -- one of the patches causes the bad sector table check to be made ONLY if the transfer is a single-block transfer (DKFL_SINGLE). As far as I can see, there is only one case where DKFL_SINGLE can get set, and that's if there's a disk transfer error. If the sector that's addressed is a "marginal" sector, this sector may actually be used (during a newfs), then at a future date may be bad, but the "bad144" remapped sector will not contain the data associated with the file. Would someone who is more familiar with the wd.c driver please check my reasoning on this. I would much rather use bad144 than badsect, but at this point, the machine has become so unreliable that using badsect may be the only alternative. Some of the source code is now corrupt (because of the disk problems), so now I can't even build a new kernel on this machine (will need to use another system which has an IDE drive). Thanks in advance for any help! Gil. (gil@limbic.ssdl.com)