home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sun / hardware / 4161 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  2.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!cbfsb!cbnewsc!att-out!rutgers!news.cs.indiana.edu!lynx!zia.aoc.nrao.edu!rmilner
  2. From: rmilner@zia.aoc.nrao.edu (Ruth Milner)
  3. Newsgroups: comp.sys.sun.hardware
  4. Subject: SCSI changes in 4.1.2
  5. Message-ID: <1992Aug31.221224.2005@zia.aoc.nrao.edu>
  6. Date: 31 Aug 92 22:12:24 GMT
  7. Organization: National Radio Astronomy Observatory, Socorro NM
  8. Lines: 46
  9.  
  10. There's been a fair amount of discussion here lately about something in the
  11. SCSI code at SunOS 4.1.2 which results in tapes like Exabyte 8500's and DATs 
  12. producing the "esp0: target n now synchronous ..." messages under some
  13. circumstances (renegotiating sync SCSI).
  14.  
  15. I was wondering why these messages occur. In looking through first the list of
  16. SCSI bugs fixed in 4.1.2, and then the SunSolve bugslist, I find the following
  17. suspicious-looking fix:
  18.  
  19.     Bug Id:     1070535
  20.     Category:  scsa
  21.     Subcategory:  host_adapter
  22.     Release summary: 4.1.2beta1
  23.     Synopsis:  esp: sync xfer rate is not renegotiated after a check condition
  24.     Integrated in releases:  4.1.2beta1
  25.     Patch id:  
  26.     Summary:
  27.      after a check condition the sync xfer rate should be renegotiated. 
  28.      The esp driver does not correctly check for the status != 0. 
  29.      Consequently, the system may hang until a timeout resets the bus.
  30.  
  31. Sounds to me like they put the renegotiation in regardless of what error the 
  32. status actually indicates, i.e. after *every* check condition. But surely, in
  33. this particular case (where the "error" is that you didn't know how many bytes 
  34. to expect in a block, so you ask for a whole bunch and just take what you get, 
  35. and then bytes-requested > bytes-returned), you don't have a condition that 
  36. would hang the bus, do you? So why do the renegotiation? Is it not possible to
  37. detect what the check condition really was?
  38.  
  39. This is an especially interesting question since the problem does not occur
  40. with Exabyte 8200's, even though they also report they are using sync SCSI.
  41. Presumably they return a different status code, or the driver handles it
  42. differently, under these conditions. (?)
  43.  
  44. Is there anyone out there who knows enough about the code to verify that this
  45. is what's happening? 
  46.  
  47. Also, I know this has been reported to Sun as a bug, but does anyone know what 
  48. the status of getting it *fixed* is? Currently the only "patch" that I'm aware 
  49. of is a new esp.o that does nothing but suppress the message that shows up - 
  50. for every device on the bus. This is not a real fix, since the renegotiation 
  51. is still happening, and now I can't tell if my disks might be doing something 
  52. they shouldn't.
  53. -- 
  54. Ruth Milner                          NRAO/VLA                  Socorro NM
  55. Computing Division Head      rmilner@zia.aoc.nrao.edu
  56.