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

[Trond Endrestøl]

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 @ 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.

-- 
+-------------------------------+------------------------------------+
| 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.      |
+-------------------------------+------------------------------------+