Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #111126 > unrolled thread
| Started by | Robert Finch <robfi680@gmail.com> |
|---|---|
| First post | 2025-03-13 00:50 -0400 |
| Last post | 2025-03-17 17:33 -0400 |
| Articles | 11 on this page of 211 — 12 participants |
Back to article view | Back to comp.arch
MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 00:50 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 16:34 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 13:49 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 18:42 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 15:59 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 20:46 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:39 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 17:00 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:27 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:27 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:12 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 18:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:28 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:14 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 21:34 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 23:52 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 14:52 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 15:34 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 17:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 18:12 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 18:42 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-14 22:10 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-15 17:46 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-15 16:46 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-15 22:28 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-16 17:35 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-16 22:00 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 13:38 +0000
Re: MSI interrupts Michael S <already5chosen@yahoo.com> - 2025-03-17 16:11 +0200
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 11:23 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 15:44 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-17 14:33 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 17:14 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-18 14:51 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 17:59 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 23:00 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 13:49 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:54 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:14 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 19:03 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-19 14:03 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:59 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 12:44 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 19:41 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 20:25 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 21:55 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 12:37 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 13:59 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 17:47 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:49 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 12:12 -0700
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 19:46 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:14 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:02 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:05 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:17 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:14 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 13:32 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 17:36 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-24 14:02 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 19:09 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:28 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 22:29 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 23:27 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:43 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 15:08 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 11:48 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 16:29 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 13:28 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-25 13:53 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 20:33 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:47 +0000
Re: MSI interrupts Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-27 10:55 +0100
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 20:31 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:08 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:20 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 13:38 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 22:21 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 16:23 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 23:29 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 16:53 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:55 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-24 13:46 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 12:09 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:11 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 22:50 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 23:45 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 01:53 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 01:26 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 00:07 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 12:23 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:45 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 15:01 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 15:10 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 16:40 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:54 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 20:40 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 22:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 18:49 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 23:33 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 22:58 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 04:40 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 19:42 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 09:17 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 13:42 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 17:09 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 01:00 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 00:56 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 04:08 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 09:55 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 14:57 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-26 13:22 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-03 22:19 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 19:21 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 15:41 -0400
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 15:50 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 23:16 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 21:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 23:22 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 23:48 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 00:18 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 12:46 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 17:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 14:27 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 18:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 19:18 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 01:01 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 01:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 01:47 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 22:02 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:14 -0700
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-29 10:31 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:56 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 21:52 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:58 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:09 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:10 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 21:47 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:53 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 15:24 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-28 11:41 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-28 09:51 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 14:28 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-29 15:23 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 20:58 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-29 22:04 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-25 10:54 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 16:31 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:44 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-28 14:40 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 20:55 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-30 16:34 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-31 03:33 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-31 01:30 -0400
Software synchronization (was: Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-31 14:42 +0000
Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-03-31 15:28 +0000
Re: Threads (was Re: MSI interrupts) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-04-01 16:44 +0200
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 15:31 +0000
Re: Threads (was Re: MSI interrupts) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 12:49 -0700
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 20:01 +0000
Re: Threads (was Re: MSI interrupts) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 13:17 -0700
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 22:04 +0000
Re: Threads (was Re: MSI interrupts) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-02 06:25 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-02 13:04 +0000
Re: Threads (was Re: MSI interrupts) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-04-03 16:45 +0200
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 15:00 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-03 17:16 +0000
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 17:24 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-04 01:44 +0000
Centronics (was Re: Threads (was Re: MSI interrupts)) George Neuner <gneuner2@comcast.net> - 2025-04-03 22:22 -0400
Re: Centronics (was Re: Threads (was Re: MSI interrupts)) scott@slp53.sl.home (Scott Lurndal) - 2025-04-04 02:29 +0000
Re: Threads (was Re: MSI interrupts) George Neuner <gneuner2@comcast.net> - 2025-04-03 01:38 -0400
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-03 12:15 +0000
Re: Threads (was Re: MSI interrupts) Robert Swindells <rjs@fdy2.co.uk> - 2025-04-04 10:41 +0000
Re: Threads (was Re: MSI interrupts) George Neuner <gneuner2@comcast.net> - 2025-04-04 23:10 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-01 10:07 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-01 17:39 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 23:28 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 12:50 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 22:28 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-23 12:16 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-23 16:48 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-24 11:55 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 18:56 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-23 17:48 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:39 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-20 12:03 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 19:52 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-19 13:07 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-19 15:47 -0400
Re: MSI interrupts - Instructions Robert Finch <robfi680@gmail.com> - 2025-03-26 06:56 -0400
Re: MSI interrupts - Instructions EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-26 10:33 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 22:49 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 20:39 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 01:22 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 23:22 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 13:54 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:56 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-17 21:49 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 01:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 18:51 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 19:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-19 11:20 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 16:00 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-19 13:27 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 19:17 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 10:12 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 15:53 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-17 19:06 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 17:33 -0400
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-18 01:34 +0000 |
| Message-ID | <Q44CP.153411$Pbo3.63824@fx34.iad> |
| In reply to | #111213 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote: > >> Michael S wrote: >>> On Mon, 17 Mar 2025 13:38:12 GMT >>> scott@slp53.sl.home (Scott Lurndal) wrote: >------------------ >>> >>> The problem Robert is talking about arises when there are many >>> interrupt source and many target CPUs. >>> The required routing/prioritization/acknowledgment logic (at least a >>> naive logic I am having in mind) would be either non-scalable or >>> relatively complicated. Process of selection for the second case will >>> take multiple cycles (I am thinking about ring). >> >> Another problem is what does the core do with the in flight >> instructions. >> >> Method 1 is simplest, it injects the interrupt request at Retire >> as that's where the state of everything is synchronized. >> The consequence is that, like exceptions, the in flight instructions all >> get purged, and we save the committed RIP, RSP and interrupt control >> word. >> While that might be acceptable for a 5 stage in-order pipeline, >> it could be pretty expensive for an OoO 200+ instruction queue >> potentially tossing hundreds of cycles of near finished work. > >Lowest interrupt Latency >Highest waste of power (i.e., work) > >> Method 2 pipelines the switch by injecting the interrupt request at >> Fetch. >> Decode converts the request to a special uOp that travels down the IQ >> to Retire and allows all the older work to complete. >> This is more complex as it requires a two phase hand-off from the >> Interrupt Control Unit (ICU) to the core as a branch mispredict in the >> in flight instructions might cause a tentative interrupt acceptance to >> later be withdrawn. > >Interrupt latency is dependent on executing instructions, >Lowest waste of power > >But note: In most cases, it already took the interrupt ~150 nanoseconds >to arrive at the interrupt service port. 1 trip from device to DRAM >(possibly serviced by L3), 1 trip from DRAM back to device, 1 tip from >device to interrupt service port; and 4 DRAM (or L3) accesses to log >interrupt into table. How do you handle timer interrupts? Those are generally not message based, but rather internal signals within the core that raise an interrupt (perhaps coordinating with the interrupt controller for priority, security state, and enable bit). These are generally wired (and the enables/state/priority are flops) for low latency. There will generally be at least one general purpose timer per core plus any watchdog timers.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-18 18:51 +0000 |
| Message-ID | <778c8286846f23551e8fe2e11e5db786@www.novabbs.org> |
| In reply to | #111214 |
On Tue, 18 Mar 2025 1:34:40 +0000, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote:
>>
>>Interrupt latency is dependent on executing instructions,
>>Lowest waste of power
>>
>>But note: In most cases, it already took the interrupt ~150 nanoseconds
>>to arrive at the interrupt service port. 1 trip from device to DRAM
>>(possibly serviced by L3), 1 trip from DRAM back to device, 1 tip from
>>device to interrupt service port; and 4 DRAM (or L3) accesses to log
>>interrupt into table.
>
> How do you handle timer interrupts? Those are generally not
> message based, but rather internal signals within the core that
> raise an interrupt (perhaps coordinating with the interrupt controller
> for priority, security state, and enable bit). These are generally
> wired (and the enables/state/priority are flops) for low latency.
Wired interrupts are converted into MSI-X interrupts under control
of INTk->MSI-X control registers in HostBridge. Then these
smell just like any other interrupt and take similar paths.
> There will generally be at least one general purpose timer per
> core plus any watchdog timers.
There are 8 performance counting "things" per major block on die.
major block include {core[*], L2[*], interconnect, L3[*], DRAM[*]
config[*] and MMI/O[*]}.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-18 19:19 +0000 |
| Message-ID | <4a51688d608fb3164e8eab049810ed38@www.novabbs.org> |
| In reply to | #111213 |
On Mon, 17 Mar 2025 21:49:18 +0000, MitchAlsup1 wrote: > On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote: > >> Michael S wrote: >>> On Mon, 17 Mar 2025 13:38:12 GMT >>> scott@slp53.sl.home (Scott Lurndal) wrote: > ------------------ >>> >>> The problem Robert is talking about arises when there are many >>> interrupt source and many target CPUs. >>> The required routing/prioritization/acknowledgment logic (at least a >>> naive logic I am having in mind) would be either non-scalable or >>> relatively complicated. Process of selection for the second case will >>> take multiple cycles (I am thinking about ring). >> >> Another problem is what does the core do with the in flight >> instructions. >> >> Method 1 is simplest, it injects the interrupt request at Retire >> as that's where the state of everything is synchronized. >> The consequence is that, like exceptions, the in flight instructions all >> get purged, and we save the committed RIP, RSP and interrupt control >> word. >> While that might be acceptable for a 5 stage in-order pipeline, >> it could be pretty expensive for an OoO 200+ instruction queue >> potentially tossing hundreds of cycles of near finished work. > > Lowest interrupt Latency > Highest waste of power (i.e., work) > >> Method 2 pipelines the switch by injecting the interrupt request at >> Fetch. >> Decode converts the request to a special uOp that travels down the IQ >> to Retire and allows all the older work to complete. >> This is more complex as it requires a two phase hand-off from the >> Interrupt Control Unit (ICU) to the core as a branch mispredict in the >> in flight instructions might cause a tentative interrupt acceptance to >> later be withdrawn. > > Interrupt latency is dependent on executing instructions, > Lowest waste of power Highest chance of mucking it all up > > But note: In most cases, it already took the interrupt ~150 nanoseconds > to arrive at the interrupt service port. 1 trip from device to DRAM > (possibly serviced by L3), 1 trip from DRAM back to device, 1 tip from > device to interrupt service port; and 4 DRAM (or L3) accesses to log > interrupt into table. > > Also, in most cases, the 200-odd instructions in the window will finish > in 100-cycles or as little as 20ns--but if the FDIV unit is saturated, > interrupt latency could be as high as 640 cycles and as long as 640ns. There is the other issue adding complexity to method 2, The instructions in the window may raise exceptions. The general rule is that the instruction raising the first exception has its address in IP, and then the retire logic has to flush subseq- uent instructions until it arrives at the first instruction of the Interrupt dispatcher. The exception will be handled when control returns from interruption. > >> The ICU believes the core is in a state to accept a higher priority >> interrupt. It sends a request to core, which checks its current state >> and >> sends back an immediate INT_ACK if _might_ accept and stalls Fetch, or a >> NAK. > > In My 66000, ICU knows nothing about the priority level (or state) > of any core in the system. Instead, when a new higher priority > interrupt is raised, the ISP broadcasts a 64-bit mask indicating > which priority levels in the interrupt table have pending inter- > rupts with an MMI/O message to the address of the interrupt table. > > All cores monitoring that interrupt table capture the broadcast, > and each core decides to negotiate for an (not that) interrupt > by requesting the highest priority interrupt from the table. > > When the request returns, and it is still at a higher priority > than the core is running, core performs interrupt control transfer. > If the interrupt is below the core's priority it is returned to > ISP as if NAKed. > > Prior to interrupt control transfer, core remains running what- > ever it was running--and all the interrupt stuff is done by state > machines at the edge of the core and the L3/DRAM controller. > >> When the special uOp reaches Retire, it sends a signal to Fetch which >> then sends an INT_ACCEPT signal to ICU to complete the handoff. >> If a branch mispredict occurs that causes interrupts to be disabled, >> then Fetch sends an INT_REJECT to ICU, and unstalls its fetching. >> (Yes that is not optimal - make it work first, make it work well >> second.) >> >> This also raises a question about what the ICU is doing during this >> long latency handoff. One wouldn't want ICU to sit idle so it might >> have to manage the handoff of multiple interrupts to multiple cores >> at the same time, each as its own little state machine. > > One must assume that ISP is capable of taking a new interrupt > from a device every 5-ish cycles and interrupt handoff is in the > range of 50 cycles, and that each interrupt could be to a different > interrupt table. > > My 66000 ISP treats successive requests to any one table as strongly > ordered, and requests to different tables as completely unordered. > >> One should see that this decision on how the core handles the >> handoff has a large impact on the design complexity of the ICU. > > I did not "see" that in My 66000's interrupt architecture. The ISP > complexity is fixed, and the core's interrupt negotiator is a small > state machine (~10-states). > > ISP essentially performs 4-5 64-bit memory accesses, and possibly > 1 MMI/O 64-bit broadcast on arrival of MSI-X interrupt. Then if > a core negotiates, it performs 3 more memory accesses per negotiator.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-19 11:20 -0400 |
| Message-ID | <jwvh63puk31.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111213 |
MitchAlsup1 [2025-03-17 21:49:18] wrote:
> On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote:
>> Method 1 is simplest, it injects the interrupt request at Retire
>> as that's where the state of everything is synchronized.
[...]
> Lowest interrupt Latency
> Highest waste of power (i.e., work)
>
>> Method 2 pipelines the switch by injecting the interrupt request at
>> Fetch.
[...]
> Interrupt latency is dependent on executing instructions,
> Lowest waste of power
What do existing CPUs do?
Method 2 looks insanely messy, so I'd assume method 1 is the standard
approach, right?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-19 16:00 +0000 |
| Message-ID | <f6cf175a3fbc6893f5bea834bbf3b7f2@www.novabbs.org> |
| In reply to | #111227 |
On Wed, 19 Mar 2025 15:20:20 +0000, Stefan Monnier wrote: > MitchAlsup1 [2025-03-17 21:49:18] wrote: >> On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote: >>> Method 1 is simplest, it injects the interrupt request at Retire >>> as that's where the state of everything is synchronized. > [...] >> Lowest interrupt Latency >> Highest waste of power (i.e., work) >> >>> Method 2 pipelines the switch by injecting the interrupt request at >>> Fetch. > [...] >> Interrupt latency is dependent on executing instructions, >> Lowest waste of power > > What do existing CPUs do? Lean in the direction of method 2 will fallback position of method 1 if anything goes wrong. > Method 2 looks insanely messy, so I'd assume method 1 is the standard > approach, right? It is "not that bad" on the large scale of things. > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-19 13:27 -0400 |
| Message-ID | <vreuqm$1b741$1@dont-email.me> |
| In reply to | #111231 |
On 2025-03-19 12:00 p.m., MitchAlsup1 wrote: > On Wed, 19 Mar 2025 15:20:20 +0000, Stefan Monnier wrote: > >> MitchAlsup1 [2025-03-17 21:49:18] wrote: >>> On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote: >>>> Method 1 is simplest, it injects the interrupt request at Retire >>>> as that's where the state of everything is synchronized. >> [...] >>> Lowest interrupt Latency >>> Highest waste of power (i.e., work) >>> >>>> Method 2 pipelines the switch by injecting the interrupt request at >>>> Fetch. >> [...] >>> Interrupt latency is dependent on executing instructions, >>> Lowest waste of power >> >> What do existing CPUs do? > > Lean in the direction of method 2 will fallback position of method 1 > if anything goes wrong. > >> Method 2 looks insanely messy, so I'd assume method 1 is the standard >> approach, right? > > It is "not that bad" on the large scale of things. > Undaunted he tries to implement the method 2 approach using an IRQ victim queue for IRQs that should not be processed at retire. It is not too bad to code, but I dunno if it works yet. Just a switch at fetch time to select from the victim queue first, otherwise pop the normal IRQ queue. The queue is small, assuming that IRQs are not disabled for great lengths of time. >> >> Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-19 19:17 +0000 |
| Message-ID | <f83e3070856d882d8986c11f88f4eb05@www.novabbs.org> |
| In reply to | #111234 |
On Wed, 19 Mar 2025 17:27:46 +0000, Robert Finch wrote:
> On 2025-03-19 12:00 p.m., MitchAlsup1 wrote:
>> On Wed, 19 Mar 2025 15:20:20 +0000, Stefan Monnier wrote:
>>
>>> MitchAlsup1 [2025-03-17 21:49:18] wrote:
>>>> On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote:
>>>>> Method 1 is simplest, it injects the interrupt request at Retire
>>>>> as that's where the state of everything is synchronized.
>>> [...]
>>>> Lowest interrupt Latency
>>>> Highest waste of power (i.e., work)
>>>>
>>>>> Method 2 pipelines the switch by injecting the interrupt request at
>>>>> Fetch.
>>> [...]
>>>> Interrupt latency is dependent on executing instructions,
>>>> Lowest waste of power
>>>
>>> What do existing CPUs do?
>>
>> Lean in the direction of method 2 will fallback position of method 1
>> if anything goes wrong.
>>
>>> Method 2 looks insanely messy, so I'd assume method 1 is the standard
>>> approach, right?
>>
>> It is "not that bad" on the large scale of things.
>>
> Undaunted he tries to implement the method 2 approach using an IRQ
> victim queue for IRQs that should not be processed at retire. It is not
> too bad to code, but I dunno if it works yet. Just a switch at fetch
> time to select from the victim queue first, otherwise pop the normal IRQ
> queue. The queue is small, assuming that IRQs are not disabled for great
> lengths of time.
Interrupt table MSI-X message undergoes negotiation.
One possible result of interrupt negotiation is that core can reject
said
interrupt, and message is returned to the interrupt table.
During this time, core is not doing anything but running its previously
assigned thread. The negotiation takes place in state machines more
optimally positioned for throughput and latency than the function units
within cores. So, core has not done anything speculative wrt IROing
except that which has a well developed protocol.
Now, once core claims the interrupt, it performs as if it were the
typical von Neumann "perform 1 instructions then move on" Mantra
enforced by boatloads of reservations stations and predictors and
prediction repair mechanisms. Accessing memory with side effects
is not one of those mechanisms and must be ordered properly wrt
{interrupts, exceptions, mispredictions, and program order}.
But on the scale of a FDIV unit that sends out a 0.51 ULP result
on cycle 12 and can send out the 0.500 ULP result on cycle 17,
and fixing the intermediate damage--handing off to an interrupt
handler is "not that bad".
>>>
>>> Stefan
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-17 10:12 -0400 |
| Message-ID | <vr9akc$9p18$1@dont-email.me> |
| In reply to | #111203 |
On 2025-03-17 9:38 a.m., Scott Lurndal wrote: > Robert Finch <robfi680@gmail.com> writes: >> > <please trim posts> > >>> >>> Consider that you have a pool of 4 cores setup to receive interrupts. >>> That those 4 cores are running at differing priorities and the interrupt >>> is at a still different priority. You want the core operating at the >>> lowest >>> priority (with the right software stack) to accept the interrupt !! >> >> Okay, I wrote a naive hardware filter for this which should work okay >> for small numbers of CPUs but does not scale up very well. >> What happens if there is no core ready? Place the IRQ back into the >> queue (regenerate the IRQ as an IRQ miss IRQ)? Or just wait for an >> available core. I do not like the idea of waiting as it could stall the >> system. > > Use a fifo to hold up to N pending IRQ. Define a signal that asserts when > the fifo is non-empty. The CPU can mask the signal to prevent > interruption, when the signal is unmasked the CPU pops the > first IRQ from the FIFO. Or use a bitmap in flops or SRAM > (prioritization happensin the logic that asserts the fact > hat an interrupt is pending to the CPU). > There is already a queue holding N pending IRQ. It is actually P queues sorted by priority. The highest priority queue with an output (non-empty) is presented as the current IRQ. The signal is masked with an threshold value. > Choose whether you want a FIFO/bitmap per target CPU, or global > pending data with the logic to select highest priority pending > IRQ when the CPU signals that interrups are not masked. Okay, there is one controller (FIFO queue) for up to 63 cores. There is a bitmap of which CPUs to notify. This is an affinity mask. I was not sure what to do if none of the CPUs were ready for an IRQ. But I see now there is nothing to do as it is the highest priority interrupt that is output already. There should be no need to feed it back to the queue. It is just a matter of waiting until a core is ready. IE. there cannot be another IRQ to process as there must have been a ready core. IF there was a core able to process a lower priority IRQ then it could certainly have processed the higher priority one. So interrupts are stalled and continue to queue for that group of cores until someone can process the IRQ. Been reading up on the RISCV AIA. For RISCV the CPU core handling the interrupt is indirectly specified by the I/O address set in the device as there is an IMSIC for each RISCV hart. So only a single IMSIC would be responding at that address. It would be up to software to set the I/O address to pick a particular CPU core. It seems to me that MSI interrupt handling using AIA would be heavy-weight. Having a controller for every hart could be a lot of logic if there are a lot of harts. There may be more than one hart per CPU. Reading that the I/O addresses need to be translated by an IOMMU. In Q+ since an interrupt controller number is being used instead of an I/O address there is no need to translate the address. Software needs to determine which group of cores will be handling the interrupt, and select an interrupt controller appropriately. The Q+ controller looks a bit like an IMSIC controller as it has pending and enable bits. I note that there is an enable bit in the vector table and an enable bit array. So, I assume both bits must be enabled for an interrupt to occur.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-17 15:53 +0000 |
| Message-ID | <aAXBP.1055728$FVcd.741153@fx10.iad> |
| In reply to | #111205 |
Robert Finch <robfi680@gmail.com> writes:
>On 2025-03-17 9:38 a.m., Scott Lurndal wrote:
>> Robert Finch <robfi680@gmail.com> writes:
>Been reading up on the RISCV AIA.
>
>For RISCV the CPU core handling the interrupt is indirectly specified by
>the I/O address set in the device as there is an IMSIC for each RISCV
>hart. So only a single IMSIC would be responding at that address. It
>would be up to software to set the I/O address to pick a particular CPU
>core. It seems to me that MSI interrupt handling using AIA would be
>heavy-weight. Having a controller for every hart could be a lot of logic
>if there are a lot of harts. There may be more than one hart per CPU.
>
>Reading that the I/O addresses need to be translated by an IOMMU. In Q+
>since an interrupt controller number is being used instead of an I/O
>address there is no need to translate the address. Software needs to
>determine which group of cores will be handling the interrupt, and
>select an interrupt controller appropriately.
>
>The Q+ controller looks a bit like an IMSIC controller as it has pending
>and enable bits. I note that there is an enable bit in the vector table
>and an enable bit array. So, I assume both bits must be enabled for an
>interrupt to occur.
>
>
Here's a copy of a slide I did a decade ago for ARM64 (GICv3) interrupts,
not much has changed since.
Interrupt Gates
There are a number of gates that must be open to pass an interrupt
from the source to the destination Core
Device Interrupt Enable Register (e.g. A NIC receive interrupt enable)
MSI-X Vector Enable (mask bit in each MSI-X vector control register)
MSI-X PCI-Express Capability Enable (enable bit and function mask in MSI-X
Capability message control field)
The PCI CMD register must have bus mastering enabled
GICv3 Distributor/Redistributor/LPI Properties per-interrupt enable bit
GICv3 Group Enable in distributor (GICD_CTLR)
GICv3 Group Enable in Target core (ICC_IGRPEN{01}_EL1)
Priority Mask register and current running priority on target core
ARM64 core interrupt signal Mask (PSTATE.A/I/F)
Interrupt group, in this context, defines the security state of
the interrupt (group 0: secure, group 1: non-secure) and is a
configuration bit associated with each interrupt.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-17 19:06 +0000 |
| Message-ID | <19ea093cf29c97217c8b111fc60adb77@www.novabbs.org> |
| In reply to | #111208 |
On Mon, 17 Mar 2025 15:53:42 +0000, Scott Lurndal wrote:
> Robert Finch <robfi680@gmail.com> writes:
>
> Here's a copy of a slide I did a decade ago for ARM64 (GICv3)
> interrupts, not much has changed since.
>
> Interrupt Gates
>
> There are a number of gates that must be open to pass an interrupt
> from the source to the destination Core
Here are the enablement's in My 66000 {Borrowing Scott's list}
� Device Interrupt Enable Register (e.g. A NIC receive interrupt
enable)
� MSI-X Vector Enable (mask bit in each MSI-X vector control
register)
� MSI-X PCI-Express Capability Enable (enable bit and function mask
in
MSI-X Capability message control field)
� The PCI CMD register must have bus mastering enabled
� Interrupt table must be enabled to receive this priority
� Interrupt table must be enabled to deliver this priority
� Core Priority must be lower than interrupt priority
Although there is an interrupt enable bit in each core, when control
arrives at dispatcher core is already re-entrant, at the proper SW
stack level, and priority, with the old register file saved in memory
and the register file of that SW stack level loaded. So, many/most
taken interrupts do not need to disable interrupts even for a short
period of time.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-17 17:33 -0400 |
| Message-ID | <vra4g0$teuf$2@dont-email.me> |
| In reply to | #111208 |
On 2025-03-17 11:53 a.m., Scott Lurndal wrote:
> Here's a copy of a slide I did a decade ago for ARM64 (GICv3) interrupts,
> not much has changed since.
>
> Interrupt Gates
>
> There are a number of gates that must be open to pass an interrupt
> from the source to the destination Core
>
> Device Interrupt Enable Register (e.g. A NIC receive interrupt enable)
> MSI-X Vector Enable (mask bit in each MSI-X vector control register)
> MSI-X PCI-Express Capability Enable (enable bit and function mask in MSI-X
> Capability message control field)
> The PCI CMD register must have bus mastering enabled
> GICv3 Distributor/Redistributor/LPI Properties per-interrupt enable bit
> GICv3 Group Enable in distributor (GICD_CTLR)
> GICv3 Group Enable in Target core (ICC_IGRPEN{01}_EL1)
> Priority Mask register and current running priority on target core
> ARM64 core interrupt signal Mask (PSTATE.A/I/F)
>
> Interrupt group, in this context, defines the security state of
> the interrupt (group 0: secure, group 1: non-secure) and is a
> configuration bit associated with each interrupt.
Yes, there is a lot that has to happen for an interrupt to occur. Q+
gets to skip the step about enabling bus mastering as it uses the slave
response bus.
I have got something like the following so far:
set device interrupt enable, MSI message in device
enable the vector in the interrupt table
globally enable interrupts for the interrupt controller
setup the interrupt affinities in the interrupt contoller
set the per vector interrupt enable
set the priorty threshold register in the IC
set the priority level in the CPU core
enable interrupts in the CPU
[toc] | [prev] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.arch
csiph-web