home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / linux / 22344 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  2.7 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!usenet.ins.cwru.edu!wariat!kf8nh
  2. From: kf8nh@kf8nh.wariat.org (Brandon S. Allbery)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: lpd
  5. Message-ID: <75qowB2w165w@kf8nh.wariat.org>
  6. Date: Fri, 01 Jan 93 01:42:17 EST
  7. References: <725836861.AA28903@remote.halcyon.com>
  8. Distribution: world
  9. Organization: Brandon S. Allbery's Personal System
  10. Lines: 48
  11.  
  12. Bob.Martin@f34.n343.z1.fidonet.org (Bob Martin) writes:
  13. > Since I new the diskettes were good and the disk drive is ok (works fine
  14. > under dos and windows) I started looking at the CMOS settings. After
  15. > trial and error I found that if I added 1 wait state the hangups went
  16. > away.
  17. > 
  18. > Any body else seen this before or can confirm this, may just be my
  19. > hardware.  
  20.  
  21. I haven't seen it with Linux or anything else on my 386DX-33, but I *have*
  22. seen something like this.  It's what made me buy the 386DX-33.
  23.  
  24. My previous machine was an XT with an Intel Inboard-386 (386DX-16).  It
  25. started out with 1MB RAM.  When I decided to upgrade it to be almost a real
  26. computer :-) so I could run Borland C++ and multiple DESQview windows (the
  27. Inboard requires special activation to enable 386 capabilities, and no
  28. 386-mode OS supports this activation, so *ix-like OSes were clearly out of
  29. the question) I added a 2MB daughterboard and replaced my ancient MFM
  30. controller and 20MB hard drive with a 50MB IDE setup.
  31.  
  32. Under DOS it worked.  Under DESQview disk reads were often utterly corrupted.
  33.  
  34. The "utter corruption" turned out to be SuperStor, which I had been running
  35. on the 20MB drive and installed on the 50MB drive.  When I removed it, I
  36. found that the computer was occasionally catching a byte sent by the disk
  37. drive *twice*.
  38.  
  39. I tried again, first with an SCSI disk and an ST01 controller, then with an
  40. MFM drive and a newer MFM controller (my old controller was so old that it
  41. couldn't habdle a drive larger than 20MB).  The SCSI was the most reliable,
  42. but even it duplicated characters occasionally.  Forcing wait states on hard
  43. drive reads (this can be done with the Inboard configuration/386 mode
  44. activation TSR) made it even more reliable, but it still had the problem.
  45. By then it was obvious that it was a hardware problem between a fast hard
  46. drive, a fast CPU, and a very slow (XT standard) bus, and bought a real 386.
  47. I suspect hardware wait states would have worked even better, but there was
  48. no way to get them on an XT....
  49.  
  50. Again, this only happened under DESQview.  Had I been capable of booting
  51. something like Linux, it would probably have happened there as well.
  52.  
  53. So:  it is quite possible for hardware timing to be such that things work
  54. under BIOS/DOS, but not in a multitasking environment.
  55.  
  56. ++Brandon
  57.  
  58. He's BAAAACK! Brandon S. Allbery     NOTE NEW ADDRESS!!! kf8nh@kf8nh.wariat.org
  59.  
  60.