New interrupt stuff breaks ASUS 2 CPU system

[John Baldwin]

On 10-Nov-2003 Marius Strobl wrote:
> On Thu, Nov 06, 2003 at 12:22:45PM -0500, John Baldwin wrote:
>> 
>> On 06-Nov-2003 Harti Brandt wrote:
>> > JB>I figured out what is happenning I think.  You are getting a spurious
>> > JB>interrupt from the 8259A PIC (which comes in on IRQ 7).  The IRR register
>> > JB>lists pending interrupts still waiting to be serviced.  Try using
>> > JB>'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if
>> > JB>the spurious IRQ 7 interrupts go away.
>> > 
>> > Ok, that seems to help. Interesting although why do these interrupts
>> > happen only with a larger HZ and when the kernel is doing printfs (this
>> > machine has a serial console). I have also not tried to disable SIO2 and
>> > the parallel port.
>> 
>> Can you also try turning mixed mode back on and using
>> http://www.FreeBSD.org/~jhb/patches/spurious.patch
>> 
>> You should get some stray IRQ 7's in the vmstat -i output as well as a few
>> printf's to the kernel console.
>> 
> 
> I think I'm seeing something related here, with the old interrupt code I
> got:
> <...>
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...               
> ACPI autoload failed - no such file or directory
> stray irq 7
> ^^^^^^^^^^^
> Copyright (c) 1992-2003 The FreeBSD Project.

Peter has seen this on an amd64 machine.  It seems we can get an interrupt
from the AT PIC before we get a chance to program the PICs to mask all their
inputs.

> <...>
> 
> With the new interrupt code I get:
> <...>
> OK boot
> cpuid = 0; apic id = 00
> instruction pointer     = 0x0:0xa00
> stack pointer           = 0x0:0xffe
> frame pointer           = 0x0:0x0
> code segment            = base 0x0, limit 0x0, type 0x0
>                         = DPL 0, pres 0, def32 0, gran 0
> processor eflags        = interrupt enabled, vm86, IOPL = 0
> current process         = 0 ()
> kernel: type 30 trap, code=0
> Stopped at      0xa00:  cli
> db> tr
> (null)(0,0,0,0,0) at 0xa00
> <...>
> 
> However, if I enter 'continue' at the DDB prompt it continues to boot
> and the system seems to runs fine:
> 
> <...>
> db> continue
> SMAP type=01 base=0000000000000000 len=000000000009f400
> SMAP type=02 base=000000000009f400 len=0000000000000c00
> SMAP type=02 base=00000000000d0000 len=0000000000030000
> SMAP type=01 base=0000000000100000 len=000000001fdf0000
> SMAP type=03 base=000000001fef0000 len=000000000000f000
> SMAP type=04 base=000000001feff000 len=0000000000001000
> SMAP type=01 base=000000001ff00000 len=0000000000080000
> SMAP type=02 base=000000001ff80000 len=0000000000080000
> SMAP type=02 base=00000000fec00000 len=0000000000004000
> SMAP type=02 base=00000000fee00000 len=0000000000001000
> SMAP type=02 base=00000000fff80000 len=0000000000080000
> Copyright (c) 1992-2003 The FreeBSD Project.
> <...>
> 
> Neiter the spurious interrupt patch nor setting 'options NO_MIXED_MODE'
> makes a difference. This is on a Tyan Tiger MPX S2466N-4M board, a full
> verbose boot log is at: http://quad.zeist.de/newintr.log
> 

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/