cvs commit: src/sys/amd64/amd64 machdep.c

Scott Long scottl at
Mon Nov 28 21:52:00 GMT 2005

John Baldwin wrote:

> On Monday 28 November 2005 04:06 pm, Scott Long wrote:
>>John Baldwin wrote:
>>>On Monday 21 November 2005 01:39 pm, John Baldwin wrote:
>>>>jhb         2005-11-21 18:39:17 UTC
>>>> FreeBSD src repository
>>>> Modified files:
>>>>   sys/amd64/amd64      machdep.c
>>>> Log:
>>>> Expand the hack to mask the atpics if 'device atpic' is not in the
>>>>kernel during boot up.  Now we do a full reset of the 8259As and setup a
>>>>simple interrupt handler (we actually borrow the apic one that just does
>>>>an immediate iret) to handle any spurious interrupts triggered by either
>>>>chip. This should fix some folks that were getting a Trap 30 during
>>>>bootup of certain SMP AMD systems.  This might get pushed into the 6.0
>>>>branch as an errata.  For now a suitable workaround is to add 'device
>>>>atpic' to your kernel config.
>>>> Tested by:      scottl
>>>> Helpful info from:      dillon
>>>> MFC after:      1 week
>>>Hmm, we probably still need to reprogram the ATPIC on resume as well. 
>>>I'm not sure it's actually worth not just compiling the atpic code in on
>>Problems aside, what are the benefits to not having the atpic
>>unconditionally included on amd64?
> Purely space savings.  It's whatever the size of atpic.o, elcr.o, and the bits 
> of atpic_vector.S that make it into exception.o are.

Ok, so it doesn't cut down on runtime overhead?  The file sizes look to

atpic.o     15k
elcr.o      2.5k
exception.o 200byte delta

If, down the road, a motherboard shows up without an atpic or one that
is horribly broken, would we be worse off for having the atpic code in


More information about the cvs-src mailing list