Re: 7-CURRENT-SNAP009-i386-bootonly.iso on Shuttle XPC w/ AMD X2 (was Re: Side note on Shuttle XPC)

From: Scott Long <scottl_at_samsco.org>
Date: Sat, 19 Nov 2005 21:18:01 -0700
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_at_ 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
Received on Sun Nov 20 2005 - 03:18:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:48 UTC