Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!bakul From: bakul@netcom.com (Bakul Shah) Subject: Re: FreeBSD, fd0d: hard error Message-ID: <bakulCvrwAA.E4v@netcom.com> Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <33j9hp$41l@sol.sun.csd.unb.ca> <jmonroyCvozLK.5q9@netcom.com> <bakulCvpyuw.5nB@netcom.com> <jmonroyCvqswn.Ktn@netcom.com> Date: Wed, 7 Sep 1994 18:49:21 GMT Lines: 72 jmonroy@netcom.com (Jesus Monroy Jr) writes: > but... in essence, I beleive my analyzes is correct, > unless, of course, someone else has the data guide > out and found me at error again... I quoted from the uPD765A datasheet to correct a factual error. No big deal. >: > 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. >: 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 I suspected GPL is because that value determines how long the VCO (Voltage Controlled Oscillator) in the PLL circuit will be inhibited. VCO needs to be enabled before the PLL can sync to the incoming signal. If VCO is not enabled early enough, before the sync bytes, you would see missing address mark or CRC error. But let me also say that I am not an expert so this is just a somewhat educated guess. > 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. > To be as nice as I can, I not seriously concearned > because I didn't write it. It doesn't take much time to lookup the right reference material. I will admit that reading uPD765A material is not easy but you, as someone who claims to have written floppy drivers, should be intimately familiar with it. If you don't want to bother checking your information is correct, atleast say so clearly in your post. Bakul Shah