Date: Mon, 11 Nov 1996 19:46:38 -0700 From: Steve Passe <smp@csn.net> To: Peter Wemm <peter@spinner.dialix.com> Cc: "Eric L. Hernes" <erich@lodgenet.com>, Janick.Taillandier@ratp.fr (Janick TAILLANDIER), freebsd-smp@freefall.freebsd.org Subject: Re: One In A Row!!! Message-ID: <199611120246.TAA25124@clem.systemsix.com> In-Reply-To: Your message of "Tue, 12 Nov 1996 00:09:41 %2B0800." <199611111609.AAA00340@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter, >I did notice one BIG difference this time, and I'll bet this would explain >the timer/syscons problems I was seeing yesterday before the commits.. > >Before: imen: 0x00ffdb07 >After: imen: 0x00ffdb05 any idea WHY the timer started to become unmasked? -- >Note also that irq13 is enabled! so the score here is: happens on 2 Neptunes doesn't on my TritonII: imen: 0x00f3ff25 < 19, 18, 7, 6, 4, 3, 1 this is before 2,8 are started. -- >The system slowed to a crawl with keyboard interrupts being lost or ignored. >I think I'll try it again without APIC_LAZY. this is like the symptom I get when /sys is linked to /usr/src/sys (ie current) instead of /d1usr/src/sys (the SMP sys, ie last synced Oct 6). Its a very preditcable way to create broken SMP kernels here. More specifically if I continue to type, the "missing" chars seem to be there, just not echoed. for instance typing: 'ls -alt<return><return>' echoes 'ls -al' but causes ls -alt to run. if I re-type the missing chars during the sequence the command gets screwed. doesn't matter whether APIC_LAZY is defined or not. -- >My initial thoughts are that we need a different strategy for each type, and >both would be reasonably different to the 8259 case (they are different >animals). Another important fact to remember about the APIC is that it uses a different method of setting priority. its based on the 'vector group'. Specifically each group of 16 vectors have equal priority, so INTs 0-15 are all of equal priority in this paradigm. The way I read the datasheet, within this group its just potluck as to which is serviced first. So we might want to start using other vectors, maybe group tty INTS into group 48-63, bio into 64-79, etc. Also: there is a 2 deep fifo for each priority level. the datasheet recommends ONLY ALLOCATING 2 INT VECTORS per group. If the fifo is full the message is discarded and the IO APIC has to resend till it takes. Section 19.3.1.1 of the P5 manual describes these 2 facts. Section 7.4.2 of the P6 manual discusses the same thing, but more grimely: "To avoid loosing interrupts software should allocate no more than 2 interrupt vectors per priority" -- >Also, we should keep in mind that we will need to deal with systems that >have some interrupts only visible to the 8259's and are not connected to >the APIC (eg: one of Dell's current range apparently). On these systems, >we have 16 "mask" bits in imen, plus at least 16 more APIC "mask" bits, >plus the 4 software interrupt bits. That's more than 32 for those who > ... >Macros like INTREN() would be thrown into chaos by this, as they'd need >to know whether the IRQ was being handled on an 8259 input, or on one of >the IO apics.. Oh, what fun.. :-) I agree with the strategy you go on to descibe, but as to this specific issue of the DELL, The only INT "unconnected" is the timer. I plan to: program the 8259 for auto EOI, mask ALL 8259 INTs but the timer, program the IO APIC to expect a type 3 INT (ie 8259 vectored) on pin 1 (INT0) NEVER mess with the 8259 once initially programmed. it would be a programming nightemare to have to determine whether we are touching the 8259 and/or IO APIC in the INT routines on an INT by INT basis. the only 2 "possible non-connects" are IRQ 0 (timer) and IRQ 13 (EISA chaining INT). Correct me if I'm wrong, but its my belief that EISA DMA chaining is only used by NON-busmaster EISA cards, so I think we can afford to not support it. That leaves only IRQ0 as possibly "unconnected". The strategy I outline above should make using "mixed mode", ie vectored 8259, INTs not too terribly painful for unconnected IRQ0s. I personally would rather start contributing to a "Hardware Replacement Foundation" than have to tackle arbitrary mixed 8259/IO APIC programming models!!! -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611120246.TAA25124>