home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8237 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  1.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!appserv.Eng.Sun.COM!ouroborous.Eng.Sun.COM!limes
  2. From: limes@ouroborous.Eng.Sun.COM (Greg Limes)
  3. Newsgroups: comp.arch
  4. Subject: Re: Sun 600MP Benchmark Anomaly
  5. Date: 23 Jul 1992 18:25:35 GMT
  6. Organization: Sun Microsystems, Inc.
  7. Lines: 16
  8. Message-ID: <l6tucvINNbqt@appserv.Eng.Sun.COM>
  9. References: <l6asqqINNhvm@exodus.Eng.Sun.COM> <l6c2l5INNcds@appserv.Eng.Sun.COM> <1992Jul23.145502.20975@ncrcae.ColumbiaSC.NCR.COM>
  10. NNTP-Posting-Host: ouroborous
  11.  
  12. In article <1992Jul23.145502.20975@ncrcae.ColumbiaSC.NCR.COM> Jeff.McElroy@ColumbiaSC.NCR.COM writes:
  13. | So, how many processors can take and service interrupts?  
  14.  
  15. Two answers, as usual ;-)
  16.  
  17. First answer: All CPUs can accept and service interrupts,
  18. without regard to which CPU initiated the action that
  19. eventually triggered the interrupt. The same chip that handles
  20. MBus arbitration handles distribution of the interrupts; an
  21. internal register tells it which CPU gets them.
  22.  
  23. Second answer: Only one CPU at a time can receive interrupt
  24. requests from devices in the system, and the software design of
  25. the 4.1.2mp kernel requires that device interrupt service
  26. routines execute within the single lock, so only one CPU at a
  27. time will be inside interrupt service routines.
  28.