Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Nov 2005 14:51:56 -0700
From:      Scott Long <scottl@samsco.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/amd64/amd64 machdep.c
Message-ID:  <438B7BFC.7030604@samsco.org>
In-Reply-To: <200511281637.11153.jhb@freebsd.org>
References:  <200511211839.jALIdIff064683@repoman.freebsd.org> <200511281527.41530.jhb@freebsd.org> <438B7144.2050709@samsco.org> <200511281637.11153.jhb@freebsd.org>

index | next in thread | previous in thread | raw e-mail

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


home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?438B7BFC.7030604>