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

[Scott Long]

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
>>>amd64.
>>
>>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
be:

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
there?

Scott