From owner-freebsd-stable@FreeBSD.ORG Fri Nov 30 17:30:08 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D25FF95; Fri, 30 Nov 2012 17:30:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2A4928FC15; Fri, 30 Nov 2012 17:30:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA22451; Fri, 30 Nov 2012 19:30:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50B8ED1B.8080009@FreeBSD.org> Date: Fri, 30 Nov 2012 19:30:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andreas Longwitz , John Baldwin Subject: Re: page fault on verbose boot References: <50ABE8BC.1010904@incore.de> <50B8CD59.1050308@FreeBSD.org> <50B8DD1C.4010308@incore.de> In-Reply-To: <50B8DD1C.4010308@incore.de> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 17:30:08 -0000 on 30/11/2012 18:21 Andreas Longwitz said the following: > ioapic1: routing intpin 15 (PCI IRQ 31) to lapic 0 vector 54 > kernel trap 12 with interrupts disabled [snip] > db> bt > Tracing pid 0 tid 100000 td 0xc0a35350 > intr_execute_handlers(0,c1020cb4,3,c1020cf8,c08e4625,...) at > intr_execute_handlers+0x15 > lapic_handle_intr(36,c1020cb4) at lapic_handle_intr+0x4c > Xapic_isr1() at Xapic_isr1+0x35 > --- interrupt, eip = 0xc08ee8fb, esp = 0xc1020cf4, ebp = 0xc1020cf8 --- > spinlock_exit(c09a1e2e,0,36,3,c1020d38,...) at spinlock_exit+0x2b > ioapic_assign_cpu(c4d1565c,0,0,0,c08f3d29,...) at ioapic_assign_cpu+0x2b0 > intr_shuffle_irqs(0,101ec00,101ec00,101e000,1025000,...) at > intr_shuffle_irqs+0xba > mi_startup() at mi_startup+0xac > begin() at begin+0x2c Thank you for all the additional information, which proved to be very useful. Something struck me now that I didn't realize before: your BSP has APIC ID of 3 while the other CPU has ID of zero. So, lapic3 is the BSP's lapic and lapic0 is the other one. Hence, it looks like IRQ31 (a signal on pin 15 of ioapic1) was delivered to a new vector of 54 (as opposed to vector 48) but to the old LAPIC/CPU 3 (as opposed to newly configured lapic0). So it looks like that the interrupt was handled at IO-APIC in the middle of pin reconfiguration. Looking at the code in ioapic_program_intpin() this seems to be possible indeed: /* Write the values to the APIC. */ intpin->io_lowreg = low; ioapic_write(io->io_addr, IOAPIC_REDTBL_LO(intpin->io_intpin), low); The line above reprograms vector number AND _unmasks_ the pin (which was specifically masked before reprogramming in ioapic_assign_cpu). The lines below reprogram the destination LAPIC/CPU: value = ioapic_read(io->io_addr, IOAPIC_REDTBL_HI(intpin->io_intpin)); value &= ~IOART_DEST; value |= high; ioapic_write(io->io_addr, IOAPIC_REDTBL_HI(intpin->io_intpin), value); So a pending interrupt would be happily delivered to a wrong destination (new vector + old lapic). I am not sure if just swapping these two blocks of lines would fix the issue, but I hope that it would. Could you please try that? John, what do you think (if you've got a spare minute)? Thank you very much. P.S. I am also quite unsure if it's a good idea for apic_idt_to_irq() to return zero for a non-configured vector. Perhaps, there should be an assert or some such (at least in the context of lapic_handle_intr) ... -- Andriy Gapon