Date: Wed, 16 Jul 1997 10:34:55 -0600 From: Steve Passe <smp@csn.net> To: cbrown@aracnet.com Cc: Steve Passe <smp@csn.net>, smp@FreeBSD.ORG Subject: Re: HEADS UP: EISA cards. Message-ID: <199707161634.KAA08806@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Wed, 16 Jul 1997 01:23:35 -0800." <33CC9317.9C7588D8@earthling.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, --- > > Till now we have been using "mixed mode programming" where the 8259 > > PIC's > > INT output is routed thru the APIC and handled as an 'ExtInt' on those > > machines that don't route the 8254 to the APIC. > > I DEFINIATELY agree with the drop mix-mode thing. It is a nightmare. > NT and some of the other unixes have already sucessfully done this. > In addition, you can't support more than one IOAPIC with just > mixed-mode (I think). do you have any references to anything written about how NT or others deal with the APIC? --- > > It turns out that when you do this the 8254 timer INTs (or any INT > > from the > > 8259) are NOT reflected in the APIC IRR/ISR registers, and CANNOT be > > masked > > via the APIC TPR register/process priority scheme. This is > > unacceptable > > Interesting. Do you have an 8259 or 8254 in your machine? I doubt it. > The south bridge / IOAPIC in your machine is emulating their behavior. > This is done for backwards compatibility for brain-dead OSes like DOS. > I am also curious about why this would be unacceptible. It might > have been mentioned in the full decription. your technically correct, but the "emulation" is essentually the same thing from a programming point of view. The "unacceptable" part refers to giving up the ability to use the TPR/PPR registers to block/accept INTs by priority level. It is necessary to receive IPIs while hardware INTs are blocked, and I know of no other way to do this. --- > > ... > > - program the 8259 to pass ONLY the DMA chaining INT > > - program the IO APIC to handle this as a regular (ie not 'ExtInt') > > input > > - abandon the 8254 timer, instead using the APIC's internal timer. > > ... > > I believe that we don't want to abandon the 8254, but instead should > > abandon the DMA chaining INTs (who uses these anyways???) Then we > > can program in a similar way, but instead pass the 8254 INT thru as > > a regular INT. > > Why would you not want to abandon the 8254? Why not use the APIC's > timer? I would imagine that it was put there for this purpose when > running in full symetric mode. > Also, why would you not want to program the IOAPIC to handle > "this" as normal INTs? we have alot invested in 8254 code for one thing. using the APIC timer would require alot of work. maybe sometime in the future. there is also the issue of distributed timers vs. a central timer. which CPU is the "central" timer? do you distribute the tick code across each, or broadcast from one. there are alot of ways to go, and someday an analysis might suggest a "better way" involving the APIC timers, but for now I would rather stick with the 8254. --- > > we need to make a policy decision as to whether we can say > > bye-bye to the DMA chaining INTs. If I don't get thoughtful feedback > > on this > > I will just nmake an arbitrary decision (which I suspect to be axing > > the DMA > > INTs). I think the only situation needing them is non-busmaster EISA > > hardware > > that does DMA via the motherboard chipset DMA registers. Please > > correct me > > if I am wrong on this point. > > What about ISA non-busmastering (most ISA cards) that use MB DMA for > operation. Sound cards come to mind :-). Do you not use the > chipset DMA for this (you know, when you set the DMA channels on > your SB16 to 0 and 1)? I believe this is different circuitry. The DMA hardware I am speaking of is a feature of EISA chipsets only. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707161634.KAA08806>