home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / apple2 / 26153 < prev    next >
Encoding:
Text File  |  1992-12-30  |  4.0 KB  |  92 lines
  1. Newsgroups: comp.sys.apple2
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!gatech!destroyer!cs.ubc.ca!alberta!glyn
  3. From: glyn@cs.UAlberta.CA (Reade Glyn Devin)
  4. Subject: help -- problems with hard drive
  5. Message-ID: <1992Dec30.201622.19839@cs.UAlberta.CA>
  6. Sender: news@cs.UAlberta.CA (News Administrator)
  7. Nntp-Posting-Host: manning.cs.ualberta.ca
  8. Organization: University of Alberta, Edmonton, Canada
  9. Date: Wed, 30 Dec 1992 20:16:22 GMT
  10. Lines: 80
  11.  
  12. Hi folks.
  13.  
  14. I've got a problem with my hard drive that I haven't been able to
  15. track down, and I would appreciate any suggestions.  I'm using a 40 Meg
  16. AE Vulcan Gold upgrade, ZipGS 9/32, Prosel 16 with error recovery and 
  17. disk verification on backup.  There are (normally) two partitions, the
  18. first one being 25024.0k.  Memory is a Ramkeeper with 3Meg GSRam+ and
  19. 500k apple card.  Other cards are normally used, but were removed for
  20. trouble-shooting.  Here's the story:
  21.  
  22. The problem first came up while trying to do a complete-mode
  23. optimization of my first partition using ProSel.16.  The error was
  24. a block reference error.
  25.  
  26. I did a restoration from backup (I keep a series of three backups
  27. for each partition, used in succession).  I encountered an error $27
  28. (I/O error) on the restoration.
  29.  
  30. By the way, I always do a directory repair & bad block lockout (Prosel
  31. volume repair) before any restorations from backup.
  32.  
  33. I tried again starting with a low level format by typing 'AE' at the
  34. main menu in Partition Manager (Vulcan Gold version).  It reported the
  35. bad tracks of $15.0  $1A.2  $1B.2  $1C.2
  36.  
  37. In addition to the (three) bad blocks reported by Prosel (2762, 2773,
  38. 5955), I also locked out the blocks mentioned in the paragraph above.
  39. I think I translated them correctly as:
  40.     2267, 2268
  41.     2888, 2889
  42.     2996, 2997
  43.     3104, 3105
  44. I included two blocks each to account for a possible off-by-one error.
  45.  
  46. I no longer got error $27 on restoration, but every time I try a complete-
  47. mode optimization I get 'Block Reference Error, Reference Address $0CCD'
  48. I've tried this multiple times with different backup sets.  I have tried
  49. locking out any index blocks used by the file (and its parent directories)
  50. being optimized at *crash* time.  The same error (Reference Address $0CCD)
  51. always occurs even though different blocks are being optimized at the 
  52. crash time.  $0CCD is also locked out.  There are no problems when I
  53. do an optimiztion in Turbo-mode (turbo-mode does not optimize directories
  54. or index blocks, just data blocks).
  55.  
  56. I thought that maybe I had a bad set of initial blocks on my partition
  57. (blocks 0-5 and the bit-map), so I tried making a small '/BAD' partition
  58. with my normal partitions following.  Only when /BAD is 1.5Meg or larger
  59. do the problems disappear.  When the size of /BAD is changed, the blocks
  60. assigned to BAD.BLOCKS are recalulated with the offset.  When resizing
  61. /BAD, I was careful not to get any known bad blocks in the first $12 blocks
  62. of the partition.
  63.  
  64. An interesting thought is that regardless of the size of /BAD, the error
  65. is _always_ "Reference Address $0CCD".  If $0CCD was a bad block, you
  66. would expect the reference to change with the size of /BAD.  Since index
  67. files store addresses with the (reversed) high and low bits offset by
  68. $100, I don't have a utility which can tell me which blocks make
  69. reference to $0CCD (remember that since $0CCD is locked out, Prosel
  70. Info Desk will report it as part of BAD.BLOCKS).
  71.  
  72. I lock out blocks out by using Prosel 16 Zap Block Editor (Block Warden),
  73. modifying the BAD.BLOCKS file (only file on disk at the time) then using
  74. directory repair to fix the volume bit-map.
  75.  
  76. I've verified that all software in use (Prosel, Partition Manager) match,
  77. byte-for-byte, with the original disks.
  78.  
  79. There is no possibility of virus-infected software being involved at
  80. this stage, unless it can hide itself in the BRAM (which I seriously
  81. doubt).
  82.  
  83. I checked my ROM disk (now being used as a boot volume) and RAM using
  84. the Ramkeeper CDA.  MemoryTest.CL reports no errors on RAM.  There is
  85. no RAM disk.
  86.  
  87. As you can see, I'm grasping at straws.  Any help appreciated.
  88.  
  89. --Devin        glyn@cs.ualberta.ca
  90.  
  91.  
  92.