Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!hookup!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!rat!decwrl!netcomsv!netcom.com!jmonroy From: jmonroy@netcom.com (Jesus Monroy Jr) Subject: Re: FreeBSD, fd0d: hard error Message-ID: <jmonroyCvsoAq.Gxw@netcom.com> Organization: NETCOM On-line Communication Services (408 261-4700 guest) X-Newsreader: TIN [version 1.2 PL1] References: <33j9hp$41l@sol.sun.csd.unb.ca> <jmonroyCvozLK.5q9@netcom.com> <bakulCvpyuw.5nB@netcom.com> <jmonroyCvqswn.Ktn@netcom.com> <bakulCvrwAA.E4v@netcom.com> Date: Thu, 8 Sep 1994 04:54:25 GMT Lines: 78 Bakul Shah (bakul@netcom.com) wrote: : jmonroy@netcom.com (Jesus Monroy Jr) writes: : >: > To make this short, it is quite possible that one of : >: > the applications you ran decided that it could read : >: > more than 15 sectors on a track, which on a 1.2 meg : >: > diskette is not possible. This is pointed to by : >: > the remaining registers that point to the last : >: > successfully completed transfer, a side effect of : >: > most FDC controllers. : >: Sectors are numbered 1 through 15 and the error message reports : >: sec 15, which is a valid sector number. : >: : > Yes, but the number 15 is the last correctly used : > by the FDC, which is my comment. : Your analysis is incorrect; I should've pointed it out clearly : last time. If an attempt is made to read a sector beyond 15, you : would get a different error (End of Cylinder, bit 7 in ST1) but : *not* CRC error (bit 5 in ST1) which is what was reported. Since : the command was *abnormally* terminated, the returned sector : number points to the sector that caused error. : Essentially, I would say you are correct. However, I have seen a few FDC chips n *NOT* return the correct error information. This is one reason that in my FDC driver the errors are listed as general. More to the point -- no direct conclusion can be drawn from this single piece of information. : >: One possibility is the value in the GPL byte of the read/write : >: command is incorrect. I don't have FreeBSD sources anymore but a : >: cursory glance at fd.c of NetBSD reveals this value to be on the : >: high side for atleast the 1.2MB floppy type. In general the gap1 : >: value should be lower for higher number of sectors/track. The : >: gap1 values used in FreeBSD fd driver should be compared against : >: what Linux and dos do and corrected if necessary. : >: : > I'm sorry to disagree, but the GPL is not (as far as : > i remember) returned. : You need to read carefully. I said `GPL byte in the read/write : command'. Nothing was said about the returned bytes. The reason : Sorry... I mis-read your earlier message. However, to the point of the GPL it is in some FDC chips (namely the National Semiconductor) a null parameter and is only kept for compatiblity this goes for head - load/unload time also. This is not to say that I am write or that your are wrong.... it is just to say I don't have enough information. : > If you have the data guide near by, please check the : > ST1 register... I should have decoded this but : > I didn't write the software... so you are only : > getting my best (half-hearted) guess. : ST1 was 0x20, which translates to CRC error either in the data or : the ID field of a sector. ST2's numeric value was not printed in : the original error message but the symbolic value was CRC error, : which says the CRC error was in the data field. : Again, no enough information. If the last command issued was a seek sector, then perhaps can't find ID field is the correct error. If so, then the problem is as I described. The FreeBSD FDC driver is a moving target. -- Jesus Monroy Jr jmonroy@netcom.com Zebra Research /386BSD/device-drivers /fd /qic /clock /documentation ___________________________________________________________________________