Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Thu, 7 Aug 2014 07:49-0700, David Wolfskill wrote: > On Thu, Aug 07, 2014 at 01:32:45PM +0200, Roger Pau Monné wrote: > > ... > > I think I've found the issue, but since I'm not able to reproduce it, > > could someone try the following patch? (without r269510 reverted). > > ... > > That worked for me; thanks! +1 Verbose dmesg for i386 head r269666M with http://ximalas.info/~trond/atpic_assign_cpu/sys-x86-isa-atpic.c.patch as the sole modification is available at http://ximalas.info/~trond/atpic_assign_cpu/dmesg-verbose-head-i386-r269666M.txt -- +---++ | 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. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Thu, Aug 07, 2014 at 01:32:45PM +0200, Roger Pau Monné wrote: > ... > I think I've found the issue, but since I'm not able to reproduce it, > could someone try the following patch? (without r269510 reverted). > ... That worked for me; thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp0orhqYlMxi.pgp Description: PGP signature
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Thu, 7 Aug 2014 13:32+0200, Roger Pau Monné wrote: > On 06/08/14 23:07, David Wolfskill wrote: > > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote: > >> ... > >> 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. > >> ... > > > > Works for me, as well -- thanks! > > > > FreeBSD 11.0-CURRENT #1333 r269622M/269622:1100028: Wed Aug 6 14:01:30 > > PDT 2014 > > > > (I'll be providing more details to royger@ et al. in a moment.) > > I think I've found the issue, but since I'm not able to reproduce it, > could someone try the following patch? (without r269510 reverted). I'll try it once I'm back home, in about 3 hours. > Thanks, Roger. NP. -- +---++ | 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. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On 06/08/14 23:07, David Wolfskill wrote: > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote: >> ... >> 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. >> ... > > Works for me, as well -- thanks! > > FreeBSD 11.0-CURRENT #1333 r269622M/269622:1100028: Wed Aug 6 14:01:30 PDT > 2014 > > (I'll be providing more details to royger@ et al. in a moment.) I think I've found the issue, but since I'm not able to reproduce it, could someone try the following patch? (without r269510 reverted). Thanks, Roger. >From 91264290520a6a6eee6cd35d05a65e2dd0e61dc8 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Thu, 7 Aug 2014 12:05:10 +0200 Subject: [PATCH] atpic: make sure atpic_init is called after IO APIC initialization After r269510 the IO APIC and ATPIC initialization is done at the same order, which means atpic_init can be called before the IO APIC has been initalized. In that case the ATPIC will take over the interrupt sources, preventing the IO APIC from registering them. Reported by: David Wolfskill Sponsored by: Citrix Systems R&D --- sys/x86/isa/atpic.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sys/x86/isa/atpic.c b/sys/x86/isa/atpic.c index 6ce6d1a..e3fdb34 100644 --- a/sys/x86/isa/atpic.c +++ b/sys/x86/isa/atpic.c @@ -524,7 +524,7 @@ atpic_init(void *dummy __unused) intr_register_source(&ai->at_intsrc); } } -SYSINIT(atpic_init, SI_SUB_INTR, SI_ORDER_SECOND + 1, atpic_init, NULL); +SYSINIT(atpic_init, SI_SUB_INTR, SI_ORDER_FOURTH, atpic_init, NULL); void atpic_handle_intr(u_int vector, struct trapframe *frame) -- 1.7.7.5 (Apple Git-26) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 > > > 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. 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. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/14 17:07, David Wolfskill wrote: > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote: >> ... 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. Solves the problem for both of my machines, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlPinEkACgkQQv9rrgRC1JLZfACgiiXUShFuZSSGcHdp256kdKM+ Du8An2St9nEIaTC6ViBNCrET+rXGD10I =vkkP -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote: > ... > 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. > ... Works for me, as well -- thanks! FreeBSD 11.0-CURRENT #1333 r269622M/269622:1100028: Wed Aug 6 14:01:30 PDT 2014 (I'll be providing more details to royger@ et al. in a moment.) Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpNtzZXKfHZl.pgp Description: PGP signature
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
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 > > 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. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > On Aug 5, 2014, at 2:29 PM, Michael Butler > 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. I'll also try to investigate this panic using my amd64 head VM. -- +---++ | 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. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Aug 5, 2014, at 2:29 PM, Michael Butler 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. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
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 :-) imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
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 .. ada0: ATA-8 SATA 2.x device ada0: Serial Number 101105PCK404VLKU1WXJ ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x0100 VER: 0x00050014 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x00010200 err: 0x00f0 pmc: 0x00010400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 51 msi: Assigning MSI IRQ 256 to local APIC 1 vector 52 hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/2/40/0x3ff SMP: passed TSC synchronization test Timecounter "TSC" frequency 1662536220 Hz quality 1000 Root mount waiting for: usbus4 Now to see if it's related to the other machine's disk woes (it's a single-core device), imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On 08/05/14 16:02, John Baldwin wrote: >> Given that my build machine did not exhibit the symptoms, and given the >> references to atpic, it may be relevant to point out that the machine >> where I see the panic is a Dell Precision M4400 laptop. > > My guess is that the recent Xen changes tickled something. However, can you > capture a verbose dmesg from your working kernel? I have the same (or similar) symptom on an old core-duo Toshiba. It seems to occur just before hwpmc would normally show in the log: kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 kernel: ada0: ATA-8 SATA 2.x device kernel: ada0: Serial Number 101105PCK404VLKU1WXJ kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) kernel: uhub2: 2 ports with 2 removable, self powered kernel: uhub3: 2 ports with 2 removable, self powered kernel: ada0: Command Queueing enabled kernel: ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) kernel: ada0: Previously was known as ad4 kernel: SMP: AP CPU #1 Launched! ** non working kernel panics here ** kernel: hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/2/40/0x3ff kernel: Timecounter "TSC" frequency 1662542340 Hz quality 1000 kernel: Root mount waiting for: usbus4 On another machine, which has 4 drives in two geom mirrors, it refuses to find ada0 or ada1. It reports a CAM timeout on the ATA-IDENTIFY phase with an apparently non-functioning interrupt problem. Reverting to a kernel built on July 27th restores normal behaviour, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Tue, Aug 05, 2014 at 01:02:25PM -0700, John Baldwin wrote: ... > My guess is that the recent Xen changes tickled something. However, can you > capture a verbose dmesg from your working kernel? That was my current hunch, as well. I've attached /var/run/dmesg.boot from a verbose boot running: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1327 r269469M/269469:1100028: Sun Aug 3 06:16:24 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. Table 'FACP' at 0xdf45449c Table 'HPET' at 0xdf454700 Table '' at 0xdf462c00 Table 'APIC' at 0xdf454800 APIC: Found table at 0xdf454800 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: disabled MADT: Found CPU APIC ID 3 ACPI ID 3: disabled Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1327 r269469M/269469:1100028: Sun Aug 3 06:16:24 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc8c0 MEMGUARD map size: 104964 KBytes Preloaded elf kernel "/boot/kernel/kernel" at 0xc2442000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc2442898. Preloaded elf module "/boot/kernel/coretemp.ko" at 0xc2442d5c. Preloaded elf module "/boot/kernel/iwn5000fw.ko" at 0xc244310c. Preloaded elf module "/boot/modules/nvidia.ko" at 0xc2443494. Calibrating TSC clock ... TSC clock: 3059068114 Hz CPU: Intel(R) Core(TM)2 Duo CPU T9900 @ 3.06GHz (3059.07-MHz 686-class CPU) Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x2010 AMD Features2=0x1 TSC: P-state invariant, performance statistics Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 6144 kbytes, 16-way associative, 64 bytes/line real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x02826000 - 0xdb869fff, 3640934400 bytes (888900 pages) avail memory = 3639803904 (3471 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00ffa00 bios32: Entry = 0xffa10 (c00ffa10) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xa7f6 pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfb9b0 00024 (v02 DELL ) ACPI: XSDT 0xdf454600 0006C (v01 DELLM09 27DD0604 ASL 0061) ACPI: FACP 0xdf45449c 000F4 (v04 DELLM09 27DD0604 ASL 0061) ACPI: DSDT 0xdf454c00 05E58 (v02 INT430 SYSFexxx 1001 INTL 20050624) ACPI: FACS 0xdf463400 00040 ACPI: HPET 0xdf454700 00038 (v01 DELLM09 0001 ASL 0061) ACPI: 0xdf462c00 00030 (v01 DELLM09 27DD0604 ASL 0061) ACPI: APIC 0xdf454800 00078 (v01 DELLM09 27DD0604 ASL 0047) ACPI: ASF! 0xdf454400 0006A (v32 DELLM09 27DD0604 ASL 0061) ACPI: MCFG 0xdf4547c0 0003C (v16 DELLM09 27DD0604 ASL 0061) ACPI: TCPA 0xdf454b00 00032 (v01 ASL ) ACPI: SLIC 0xdf45489c 00176 (v01 DELLM09 27DD0604 ASL 0061) ACPI: SSDT 0xdf452aeb 0066C (v01 PmRefCpuPm 3000 INTL 20050624) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Aug 5, 2014, at 7:29 AM, David Wolfskill wrote: > On Mon, Aug 04, 2014 at 12:47:59PM -0700, David Wolfskill wrote: >> ... >> I was unable to get a crash dump, and I only recorded the offsets in the >> backtrace (no arguments; sorry -- I was expecting the build machine to >> allow me to investigate on a machine with a serial console): >> >> ... >> SMP: AP CPU #1 Launched! >> panic: aatpic_assign_cpu: bad cookie >> cpuid=0 >> atpic_assign_cpu(...) at atpic_assign_cpu+0x1a/frame 0xc2820d0c >> intr_shuffle_irqs(...) at intr_shuffle_irqs+0x97/frame 0xc2820d30 >> mi_startup(...) at mi_startup+0xe7/frame 0xc2820d58 >> begin(...) at begin+0x2c >> db> >> >> So... what can I do to help figure out what went wrong? As noted, I >> have no serial console on the laptop, and while I have captured crash >> dumps in the past, I'm guessing that at the point the above happens, the >> machine has yet to obtain a clue about where it might put a dump if one >> were created. >> >> (No problems with stable/9 (@r269499) or stable/10 (@r269498) on the >> same hardware.) >> > > By booting from the previously-built kernel: > > FreeBSD 11.0-CURRENT #1327 r269469M/269469:1100028: Sun Aug 3 06:16:24 PDT > 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > I was able to update sources to r269580 & rebuild (successfully -- both > userland & kernel); the resulting kernel, however, exhibited the same > symptoms -- "panic: aatpic_assign_cpu: bad cookie", with a similar (if > not identical -- I couldn't refer to the previous one while I was > observing the current panic) backtrace. > > I'm willing to try hacking at code (if necessary) to figure out what's > wrong & fix it; I'll need some guidance, though. > > Given that my build machine did not exhibit the symptoms, and given the > references to atpic, it may be relevant to point out that the machine > where I see the panic is a Dell Precision M4400 laptop. My guess is that the recent Xen changes tickled something. However, can you capture a verbose dmesg from your working kernel? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Mon, Aug 04, 2014 at 12:47:59PM -0700, David Wolfskill wrote: > ... > I was unable to get a crash dump, and I only recorded the offsets in the > backtrace (no arguments; sorry -- I was expecting the build machine to > allow me to investigate on a machine with a serial console): > > ... > SMP: AP CPU #1 Launched! > panic: aatpic_assign_cpu: bad cookie > cpuid=0 > atpic_assign_cpu(...) at atpic_assign_cpu+0x1a/frame 0xc2820d0c > intr_shuffle_irqs(...) at intr_shuffle_irqs+0x97/frame 0xc2820d30 > mi_startup(...) at mi_startup+0xe7/frame 0xc2820d58 > begin(...) at begin+0x2c > db> > > So... what can I do to help figure out what went wrong? As noted, I > have no serial console on the laptop, and while I have captured crash > dumps in the past, I'm guessing that at the point the above happens, the > machine has yet to obtain a clue about where it might put a dump if one > were created. > > (No problems with stable/9 (@r269499) or stable/10 (@r269498) on the > same hardware.) > By booting from the previously-built kernel: FreeBSD 11.0-CURRENT #1327 r269469M/269469:1100028: Sun Aug 3 06:16:24 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 I was able to update sources to r269580 & rebuild (successfully -- both userland & kernel); the resulting kernel, however, exhibited the same symptoms -- "panic: aatpic_assign_cpu: bad cookie", with a similar (if not identical -- I couldn't refer to the previous one while I was observing the current panic) backtrace. I'm willing to try hacking at code (if necessary) to figure out what's wrong & fix it; I'll need some guidance, though. Given that my build machine did not exhibit the symptoms, and given the references to atpic, it may be relevant to point out that the machine where I see the panic is a Dell Precision M4400 laptop. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpQeeO_7F8FY.pgp Description: PGP signature
Build machine OK; laptop panics @r269515
I held off until the build machine was able to build & (try to boot) head; unfortunately for me, it had no problems: FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1571 r269515M/269515:1100028: Mon Aug 4 12:14:39 PDT 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 The laptop -- also i386, with a copy of the same sources (though kernel config mostly includes GENERIC, turns off a bunch of stuff I don't ever expect to have on a laptop, and enables IPFW in default-deny mode) -- tried to boot after building head @r269515... and that process terminated quickly: reported uptime was 3 secnds. I was unable to get a crash dump, and I only recorded the offsets in the backtrace (no arguments; sorry -- I was expecting the build machine to allow me to investigate on a machine with a serial console): ... SMP: AP CPU #1 Launched! panic: aatpic_assign_cpu: bad cookie cpuid=0 atpic_assign_cpu(...) at atpic_assign_cpu+0x1a/frame 0xc2820d0c intr_shuffle_irqs(...) at intr_shuffle_irqs+0x97/frame 0xc2820d30 mi_startup(...) at mi_startup+0xe7/frame 0xc2820d58 begin(...) at begin+0x2c db> So... what can I do to help figure out what went wrong? As noted, I have no serial console on the laptop, and while I have captured crash dumps in the past, I'm guessing that at the point the above happens, the machine has yet to obtain a clue about where it might put a dump if one were created. (No problems with stable/9 (@r269499) or stable/10 (@r269498) on the same hardware.) Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp_TKnvYZVwE.pgp Description: PGP signature
