From owner-freebsd-stable@freebsd.org Sun Sep 4 08:23:15 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FA26BCFDC0 for ; Sun, 4 Sep 2016 08:23:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 37B00E10 for ; Sun, 4 Sep 2016 08:23:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 36E60BCFDBE; Sun, 4 Sep 2016 08:23:15 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3695BBCFDBD for ; Sun, 4 Sep 2016 08:23:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 73043E0E for ; Sun, 4 Sep 2016 08:23:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA16972; Sun, 04 Sep 2016 11:20:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bgSfO-000IgF-FB; Sun, 04 Sep 2016 11:20:38 +0300 Subject: Re: X2APIC support To: Slawa Olhovchenkov , Konstantin Belousov References: <20151212130615.GE70867@zxy.spb.ru> <20151212133513.GL82577@kib.kiev.ua> <20160901112724.GX88122@zxy.spb.ru> <20160901114500.GJ83214@kib.kiev.ua> <20160901121300.GZ88122@zxy.spb.ru> Cc: stable@FreeBSD.org From: Andriy Gapon Message-ID: <4ba05c00-f737-f562-553d-a7fa59145768@FreeBSD.org> Date: Sun, 4 Sep 2016 11:19:16 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160901121300.GZ88122@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 08:23:15 -0000 On 01/09/2016 15:13, Slawa Olhovchenkov wrote: > DMAR: Found table at 0x79b32798 > x2APIC available but disabled by DMAR table > Event timer "LAPIC" quality 600 > LAPIC: ipi_wait() us multiplier 1 (r 116268019 tsc 2200043851) > ACPI APIC Table: > Package ID shift: 5 > L3 cache ID shift: 5 > L2 cache ID shift: 1 > L1 cache ID shift: 1 > Core ID shift: 1 > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = ff > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80537e74 > stack pointer = 0x28:0xffffffff814b4a60 > frame pointer = 0x28:0xffffffff814b4a70 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff805272e7 at kdb_backtrace+0x67 > #1 0xffffffff804dd662 at vpanic+0x182 > #2 0xffffffff804dd4d3 at panic+0x43 > #3 0xffffffff807a3791 at trap_fatal+0x351 > #4 0xffffffff807a3983 at trap_pfault+0x1e3 > #5 0xffffffff807a2f0c at trap+0x26c > #6 0xffffffff80787ca1 at calltrap+0x8 > #7 0xffffffff8083b52a at topo_probe+0x61a Interesting. Could you please do 'list *topo_probe+0x61a' in kgdb, so that I can see what code is being executed when the trap happens? Also, disassembly of the function could be useful as well. Wait... Kostik, I see one strange thing which is common to both successful and unsuccessful configurations. All "SMP: Added CPU..." lines have "AP" in them. It seems like the platform does not tell explicitly tell which CPU is the BSP, see cpu_add() function. This can break quite a few assumption. And I am not even sure how the successful scenario works. Ah... I see that there is a backup code in cpu_mp_start() where boot_cpu_id is set based on the current CPU's Local APIC ID. I suspect then that this information is incorrect in the failing case. Slawa, my guess can be checked by adding a printf to cpu_mp_start() right after boot_cpu_id assignment. > #8 0xffffffff8078fe81 at cpu_mp_start+0x1b1 > #9 0xffffffff805382ca at mp_start+0x3a > #10 0xffffffff80465cd8 at mi_startup+0x118 > #11 0xffffffff8028dfac at btext+0x2c > Uptime: 1s -- Andriy Gapon