home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / bsd / 4368 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  1.5 KB
  1. Path: sparky!uunet!sun-barr!ames!data.nas.nasa.gov!taligent!apple!veritas!amdcad!BitBlocks.com!bvs
  2. From: bvs@BitBlocks.com (Bakul Shah)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: X386 far too busy?
  5. Message-ID: <1992Aug18.172513.9692@BitBlocks.com>
  6. Date: 18 Aug 92 17:25:13 GMT
  7. References: <1992Aug17.211128.7958@novatel.cuc.ab.ca>
  8. Organization: Bit Blocks, Inc.
  9. Lines: 26
  10.  
  11. hpeyerl@novatel.cuc.ab.ca (Herb Peyerl) writes:
  12.  
  13. >I started the server about 18 hours ago and left it with only 
  14. >two xterm's, an icon box, and an xclock running... There was
  15. >basically no activity all night.  This morning I did a "ps -agx"
  16. >and noticed that X386 had racked up 1145:23.29 CPU (minutes?)... 
  17.  
  18. I suspect this is due to a bug in the com.c driver as I used to
  19. get the same symptom when I connected a serial mouse to com2.
  20.  
  21. Here is a much simplified explanation:
  22. When there is nothing else to do, the X server waits for some
  23. input activity.  It checks this by doing a select() on various
  24. input sources, mouse being one of them.  But due to the above
  25. mentioned bug in the com.c driver, select() on /dev/com2 always
  26. returns true so the server is continuously checking for input,
  27. even though there is no new input.
  28.  
  29. The fix is to upgrade to Chris Demetriou's latest com.c (from
  30. agate.berkeley.edu) or apply Christoph Robitschko's patches to
  31. the stock com.c (it was posted a while ago).
  32.  
  33. Information about this and other bugs for which solutions exist
  34. should probably go in the FAQ.
  35.  
  36. -- Bakul Shah <bvs@bitblocks.com>
  37.