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>
index | next in thread | previous in thread | raw e-mail
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? Scotthelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?437FF8F9.8000207>