Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Nov 2005 14:06:12 -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:  <438B7144.2050709@samsco.org>
In-Reply-To: <200511281527.41530.jhb@freebsd.org>
References:  <200511211839.jALIdIff064683@repoman.freebsd.org> <200511281527.41530.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

Scott



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