home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / bsd / 4466 < prev    next >
Encoding:
Text File  |  1992-08-19  |  3.3 KB  |  85 lines

  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!destroyer!sol.ctr.columbia.edu!ucselx!crash!fpm
  3. From: fpm@crash.cts.com (Frank Maclachlan)
  4. Subject: wd.c problem (w/ Patch)
  5. Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
  6. Date: 19 Aug 92 16:32:35 PDT
  7. Message-ID: <1992Aug19.163236.16943@crash>
  8. Summary: bad144 bug fixed
  9. Keywords: bad144, ESDI
  10. Lines: 73
  11.  
  12. Greetings:
  13.  
  14. I think there is a problem in 'usr/src/sys.386bsd/i386/isa/wd.c'
  15. when the first sector in a multi-sector read or write request is
  16. present in the bad144 table.  The bad144 table search code at
  17. line 382 finds the sector in the bad144 table and replaces the
  18. block number, cylinder, head, and sector addresses with values
  19. corresponding to the replacement sector.  At line 434, the sector
  20. count register is loaded with the number of sectors in the entire
  21. transfer.  This is wrong; it *MUST* be set to *one* sector.  A
  22. read would return the wrong data in sectors after the first; a
  23. write would *overwrite* other replacement sectors or even the
  24. bad144 table on the last track.
  25.  
  26. You could fix this by changing lines 382 and 383 from
  27.  
  28.     if ((du->dk_flags & (/*DKFL_SINGLE|*/DKFL_BADSECT))
  29.         == (/*DKFL_SINGLE|*/DKFL_BADSECT))
  30.  
  31. to
  32.     if ((du->dk_flags & (DKFL_SINGLE|DKFL_BADSECT))
  33.         == (DKFL_SINGLE|DKFL_BADSECT))
  34.  
  35. This prevents the defective sector from being replaced the first
  36. time through (DKFL_SINGLE is not set).  Assuming the sector is
  37. marked bad, the read or write of the defective sector will fail,
  38. and the interrupt routine (wdintr) will retry the operation with
  39. the DKFL_SINGLE bit set.  This causes the sector to be replaced
  40. and the transfer count is properly set to 1.
  41.  
  42. Another solution is to leave the above two lines unchanged and
  43. apply the following patch.  This has the advantage of immediately
  44. replacing a defective sector at the start of a transfer without
  45. requiring that the operation first fail.
  46.  
  47. ---- snip snip ----
  48. *** wd.c.ORIG    Wed Aug 19 15:43:21 1992
  49. --- wd.c    Wed Aug 19 16:16:18 1992
  50. ***************
  51. *** 402,407 ****
  52. --- 402,408 ----
  53.               cylin = blknum / secpercyl;
  54.               head = (blknum % secpercyl) / secpertrk;
  55.               sector = blknum % secpertrk;
  56. +             du->dk_flags |= DKFL_SINGLE;
  57.   #ifdef    WDDEBUG
  58.                   printf("new = %d\n", blknum);
  59.   #endif
  60. ---- snip snip ----
  61.  
  62. Note that the bad144 code *doesn't* work unless *all* sectors
  63. present in the bad144 table are marked bad (any attempt to read
  64. or write any of them will return an immediate error - usually a
  65. BAD BLOCK error code).
  66.  
  67. On a different note, when setting up your hard disk, be aware that
  68. many diagnostic packages assume that the last cylinder on a hard
  69. disk is a test cylinder and will cheerfully scribble on it when
  70. performing hard disk diagnostics.  Also, if the hard disk has more
  71. than 1024 cylinders and the BIOS parameter table entry for the
  72. drive shows less than the number of cylinders on the drive (a
  73. Western Digital WD1007v-se2 controller attached to a drive having
  74. 1222 cylinders sets up a BIOS parameter table indicating 1023
  75. cylinders), disk diagnostics assume that the last cylinder as
  76. specified by the BIOS parameter table is a test cylinder.  I once
  77. trashed an SCO Xenix filesystem by running a diagnostic which
  78. wrote test patterns on cylinder 1023 on a 1222 cylinder hard disk.
  79. You have been warned!
  80. --
  81. UUCP: {hplabs!hp-sdd ucsd nosc}!crash!fpm
  82. ARPA: crash!fpm@nosc.mil
  83. INET: fpm@crash.cts.com
  84.  
  85.