home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / sun / hardware / 5738 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  2.5 KB
  1. Xref: sparky comp.sys.sun.hardware:5738 comp.periphs.scsi:5543
  2. Newsgroups: comp.sys.sun.hardware,comp.periphs.scsi
  3. Path: sparky!uunet!wupost!gumby!destroyer!ncar!csn!teal.csn.org!milton
  4. From: milton@teal.csn.org (Milton Scritsmier)
  5. Subject: Re: Problems with Fast SCSI-II on Sun Sparc 10 (long)
  6. Message-ID: <Bxy9x9.MEH@csn.org>
  7. Sender: news@csn.org (news)
  8. Nntp-Posting-Host: teal.csn.org
  9. Organization: Colorado SuperNet, Inc.
  10. References: <MRD.92Nov13160506@morsel.stdavids.picker.com> <1992Nov15.121008.12717@pt.com> <37088@cbmvax.commodore.com>
  11. Date: Thu, 19 Nov 1992 06:27:07 GMT
  12. Lines: 40
  13.  
  14. In article <37088@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
  15. >jjg@pt.com (John Grana) writes:
  16. >>As one who has spent the past year dealing with Fast SCSI on single ended
  17. >>busses, all on SBus, I can offer the following:
  18. >
  19. >> Also, our driver performs a speed
  20. >>reduction when it detects a sync. problem. So, the system would start at
  21. >>10 MB/sec., then drop to 8 and maybe even 6.7 MB/sec before it would
  22. >>stabilize.
  23. >
  24. >    What method do you use to determine when a sync problem has occurred?
  25. >Mismatched transfer sizes?  How do you tell this is different from either
  26. >commands which return less than requested, or people who use CAM (or the
  27. >equivalent) and tell you the command will do more or less IO than it actually
  28. >does?
  29. >
  30.  
  31. Your're right, that's a real problem. While there are cases where you
  32. definitely know a sync problem has occurred (eg., offset count
  33. exceeded), there are also ambiguous cases where you don't know for
  34. sure (eg., the transfer hangs).
  35.  
  36. The best way I can think of uses the assumption that sync problems
  37. are chip problems while transfer count problems are due to firmware
  38. problems (including programming the chip with the wrong count).
  39. Thus if you renegotiate for a slower synchronous transfer speed (or
  40. better yet for an asynchronous transfer), retry the command that
  41. failed, and have it succeed, then probably you are dealing with a
  42. sync problem. This assumes the firmware on the target goes through
  43. the same basic steps in either case, except for the setting of the
  44. transfer mode and speed.
  45.  
  46. There could be firmware bugs which are timing dependent and hence
  47. sensitive to the transfer rate, or firmware bugs where the chip
  48. is programmed wrong for certain transfer modes. However, from the
  49. host's point of view, it probably doesn't matter. With one transfer
  50. rate the command fails, while with another transfer rate the command
  51. succeeds. Whatever the cause, the work-around is the same.
  52.  
  53.  
  54.