Date: Wed, 03 Dec 1997 18:01:57 -0700 From: Steve Passe <smp@csn.net> To: Joe Eykholt <jre@Ipsilon.COM> Cc: smp@freebsd.org Subject: Re: SMP Message-ID: <199712040101.SAA10349@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Wed, 03 Dec 1997 16:24:49 PST." <3485F851.3F54BC7E@ipsilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Joe, I think I see the "double level INT" problem: line 242 of i386/isa/apic_vector.s: movl $0, lapic_eoi ; /* XXX too soon? */ \ incb _intr_nesting_level ; \ ; \ /* entry point used by doreti_unpend for HWIs. */ \ __CONCAT(Xresume,irq_num): ; \ --- as you can see I already recognized this as a problem, but didn't have an easy answer. The lapic_eoi should NOT really be sent until after the hardware specific code has been run. At that point the INT source will have been cleared, and it would be safe to send the lapic_eoi, which tells the IO apic that if the level is still asserted it should send another INT. The problem is that we can't place in in the code at the proper place: line 258: ; \ pushl _intr_unit + (irq_num) * 4 ; \ incl _inside_intr ; \ sti ; \ call *_intr_handler + (irq_num) * 4 ; \ cli ; \ decl _inside_intr ; \ ; proper place for lapic_eoi (ie NOT in current): movl $0, lapic_eoi ; we can't do this since this code is sometimes (often) run from doreti as oppossed to the ISR that was invoked when the INT occured. Its already done when the ISR discovers that it can't proceed, and masks the INT at line 276, followed by the lapic_eoi. Doing it again from doreti would be a problem. I think the trick is to modify UNMASK_IRQ(irq_num) to test for level INTs when unmasking an INT. If its a level INT send the lapic_eoi then. If I send you a patch to current apic_vector.s as of earlier today would you be able to run your test code on it? -- 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?199712040101.SAA10349>