Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]

On Wed, 6 Aug 2014 22:48+0200, Trond Endrestøl wrote:

> On Wed, 6 Aug 2014 19:21+0200, Trond Endrestøl wrote:
> 
> > On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote:
> > 
> > > 
> > > On Aug 5, 2014, at 2:29 PM, Michael Butler <imb_at_protected-networks.net> wrote:
> > > 
> > > > On 08/05/14 16:56, Michael Butler wrote:
> > > >> On 08/05/14 16:02, John Baldwin wrote:
> > > >> 
> > > >>> My guess is that the recent Xen changes tickled something.
> > > >> 
> > > >> I can confirm this on a kernel which is otherwise up to date ..
> > > >> 
> > > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD
> > > >> 11.0-CURRENT #2 r269608M: Tue Aug  5 16:48:12 EDT 2014
> > > >> 
> > > >> I backed out all of SVN r269507 through r269515.
> > > >> 
> > > >> Now working ..
> > > > 
> > > > [ .. snip .. ]
> > > > 
> > > >> Now to see if it's related to the other machine's disk woes (it's a
> > > >> single-core device),
> > > > 
> > > > And it fixes the inability to probe disks on my single-core machine :-)
> > > 
> > > It looks like the MADT code to probe the I/O APICs isn't working so 
> > > it's trying to fall back to using the ATPIC while using SMP (which 
> > > doesn't work).  I know it's a pain on a laptop, but if it is at all 
> > > possible to capture either a verbose or non-verbose dmesg that would 
> > > really help narrow it down.
> > > 
> > > Also, if anyone can try reverting just the MADT-related changes in 
> > > the recent Xen changes to see if you can narrow down which exact one 
> > > triggers the panic that would be really helpful.
> > 
> > I noticed this panic on i386 head r269607 yesterday, running in VBox 
> > on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 _at_ 3.20GHz 
> > (3175.67-MHz 686-class CPU).
> > 
> > Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a 
> > verbose dmesg from i386 head r268838 from the same VM and a couple of 
> > screenshots of the crash while booting r269607 with the verbose flag 
> > on.
> > 
> > I'm rewinding /usr/src to r269507, and I'll take it from there, one 
> > commit at the time.
> 
> Reverting r269510 did the trick, i.e.:
> 
> cd /usr/src && svn up && svn diff -r 269510:269509 | patch
> 
> My i386 head VM is running smoothly with r269641M, with M meaning only 
> the above reversal.
> 
> > I'll also try to investigate this panic using my amd64 head VM.
> 
> Work in progress.

amd64 is unaffected, as r269644 worked without any modifications.

I'm guessing the changes to sys/x86/x86/local_apic.c and 
sys/x86/xen/xen_intr.c come as a pair. If not, then the changes done 
to sys/x86/x86/local_apic.c is the culprit somehow.


Trond,
going to bed.

-- 
+-------------------------------+------------------------------------+
| Vennlig hilsen,               | Best regards,                      |
| Trond Endrestøl,              | Trond Endrestøl,                   |
| IT-ansvarlig,                 | System administrator,              |
| Fagskolen Innlandet,          | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,       | Cellular...: +47 952 62 567,       |
| sentralbord 61 14 54 00.      | Switchboard: +47 61 14 54 00.      |
+-------------------------------+------------------------------------+