home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / ultrix / 6767 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.8 KB  |  63 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!decwrl!deccrl!news.crl.dec.com!rdg.dec.com!decvax.dec.com!decvax.DEC.COM!jag
  3. From: jag@decvax.DEC.COM (John A. Gallant UEG)
  4. Subject: Re: SCSI/CAM problems
  5. Message-ID: <1992Sep8.171248.21775@decvax.dec.com>
  6. Sender: usenet@decvax.dec.com (Usenet News System)
  7. Nntp-Posting-Host: witsend.zk3.dec.com
  8. Reply-To: jag@zk3.dec.com
  9. Organization: OSF Engineering, Digital Equipment Corp.
  10. References: <ROBM.92Sep4150116@ataraxia.Berkeley.EDU> <1992Sep5.011659.7675@news.iastate.edu> <Bu862I.Dq@ie.utoronto.ca>
  11. Date: Tue, 8 Sep 1992 17:12:48 GMT
  12. Lines: 49
  13.  
  14. In article <Bu862I.Dq@ie.utoronto.ca>, andy@ie.utoronto.ca (Andy Sun) writes:
  15. >john@iastate.edu (John Hascall) writes:
  16.  
  17. >>What happens is we start getting *tons* of:
  18. >>   XPT Packet Pool HIGH Water Mark Reached.
  19. >>   cam_logger: CAM_ERROR packet
  20. >>   cam_logger: No associated bus target lun
  21. >>messages on the console and also (in the two times I have seen it happen)
  22. >>the dreaded "cant get mbufs" message also appears.  It seems to be somehow
  23. >>related to uptime (memory leak?) and load (so, of course, today, with a
  24. >>machine which hung last night and being the Friday before a long weekend,
  25. >>we had neither and I couldn't reproduce it for DEC *sigh*).
  26. >
  27. >I am afraid that the same thing happens to us (a DECsystem 5000/200
  28. >recently upgraded to 4.2a with SCSI/CAM). Similar messages appear in the
  29. >error log (viewed through uerf). ......................................
  30.  
  31.     How similar ?, are they High / Low or both water marks ?  Please try
  32. the /usr/etc/cam_report program.  The uerf utility is not able to decode
  33. all of the CAM error log information.  We had to provide a second log
  34. decoder that provides more than a person could dream of.
  35.  
  36. >................................ Even more horrible, our machine hung up
  37. >on us twice so far (i.e. no response, not even from console). I attempted
  38. >a core trace without any luck. It seems to be related to our USENET news
  39. >activities, when there were lots of read/write to an RZ58 partition.
  40.  
  41.      Try increasing the pool size ?   What does the vmstat -K on the 
  42. cores look like ?  A large buffer cache in the file system code can 
  43. result in a big "spike" in disk I/O when a flush occurs.
  44.  
  45. >>I was told that backing out of SCSI/CAM was NOT as simple as
  46. >>just "setld -d ..."  If we can't get a fix by next week we are
  47. >>resigned to going backwards to 4.2a.
  48. >
  49. >OH MY GOD!! (fainted...)
  50.  
  51.     No No No (waving ammonia salts ...), only for the CAMBASE* subset is
  52. there a problem.  For the kernel, a delete and a rebuild is all that is
  53. needed.
  54.  
  55. -- 
  56. John A. Gallant                                jag@zk3.dec.com
  57. Software Engineer - OSF Engineering Group
  58. Digital Equipment Corp. (603) 881-2472
  59.  
  60.         In the common people there is no wisdom, no penetration, no
  61.         power of judgment.
  62.     Marcus Cicero
  63.