Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Nov 2005 21:18:01 -0700
From:      Scott Long <scottl@samsco.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        amd64@freebsd.org, freebsd-current@freebsd.org, Peter Wemm <peter@freebsd.org>
Subject:   Re: 7-CURRENT-SNAP009-i386-bootonly.iso on Shuttle XPC w/ AMD X2 (was Re: Side note on Shuttle XPC)
Message-ID:  <437FF8F9.8000207@samsco.org>
In-Reply-To: <200511182206.49195.jhb@freebsd.org>
References:  <20051117010651.97608.qmail@web50303.mail.yahoo.com>	<437E6AF7.1040402@samsco.org>	<200511190018.jAJ0ItTe013855@apollo.backplane.com> <200511182206.49195.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:

> On Friday 18 November 2005 07:18 pm, Matthew Dillon wrote:
> 
>>:So the amd64 snapshot didn't boot but the i386 one did?  Interesting.
>>:Thanks a lot for investigating this.
>>:
>>:Scott
>>
>>    Yup.  My guess is that the 64-bit boot issue that early in the boot
>>    sequence is something stupid simple.  It looks it from the consistency
>>    of the crash.
> 
> 
> Actually, your comments about the stray ICU interrupts led me to it on the way 
> home tonight.  Peter has a hack in amd64 that if you don't include 'device 
> atpic' in your kernel config (not in GENERIC amd64 by default in HEAD) he 
> just masks the PICs.  However, he doesn't setup handlers for the spurious 
> interrupts that can still occur (since they are unmaskable).  Couple that 
> with the fact that HEAD (until a few hours ago) didn't print the trap message 
> for a T_RESERVED trap, and you'll see that your panic on amd64 was caused by 
> a spurious ICU interrupt.  I have part of peter's hack expanded to do a full 
> reset of the ICUs, and I'll update it for Monday to adjust the base interrupt 
> such that the spurious ICU vectors get sent to the APIC spurious interrupt 
> vector.  That should fix your issue as well as the same issue reported by 
> someone else on the amd64@ list recently.
> 

Does this imply that the 'correct' fix involves catching the stray ICU 
interrupt via a trap handler?  How often do these interrupts happen,
and therefore what is the performance consequence to having to handle
them?

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?437FF8F9.8000207>