From owner-freebsd-current@FreeBSD.ORG Thu Sep 23 15:13:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15F6716A4CE for ; Thu, 23 Sep 2004 15:13:00 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA2C443D46 for ; Thu, 23 Sep 2004 15:12:59 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 556 invoked from network); 23 Sep 2004 15:12:59 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 23 Sep 2004 15:12:59 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8NFCibh009523; Thu, 23 Sep 2004 11:12:55 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Pavel Gubin Date: Thu, 23 Sep 2004 10:29:47 -0400 User-Agent: KMail/1.6.2 References: <20040922095257.GA81709@ie.tusur.ru> <200409221628.51977.jhb@FreeBSD.org> <20040923042447.GA88335@ie.tusur.ru> In-Reply-To: <20040923042447.GA88335@ie.tusur.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409231029.47945.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org Subject: Re: "Multiple entries for PCI IRQ 16" and "xlock already held" panics on 5.3-BETA(3,4,5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2004 15:13:00 -0000 On Thursday 23 September 2004 12:24 am, Pavel Gubin wrote: > On Wed, Sep 22, 2004 at 04:28:51PM -0400, John Baldwin wrote: > > > 1) When MPS 1.4 is enabled with the BIOS setting and ACPI disabled > > > either by BIOS or by unsetting `acpi_load' loader variable, the kernel > > > panices immediately with "panic: Multiple entries for PCI IRQ 16" > > > message. As one can see from #1 Bootlog, there are really two entries > > > for IRQ16. I think this is the BIOS bug, but I also think the > > > diagnostics for this situation should be more precise than that. > > > > There's not much more precise that can be done. mptable output would be > > extremely helpful here. > > =========================================================================== >==== > > MPTable, version 2.0.15 > > --------------------------------------------------------------------------- >---- > > MP Floating Pointer Structure: > > location: BIOS > physical address: 0x000fb960 > signature: '_MP_' > length: 16 bytes > version: 1.4 > checksum: 0x7f > mode: Virtual Wire > > --------------------------------------------------------------------------- >---- > > MP Config Table Header: > > physical address: 0x000f62b0 > signature: 'PCMP' > base table length: 256 > version: 1.4 > checksum: 0xcb > OEM ID: 'SiS ' > Product ID: '740 ' > OEM table pointer: 0x00000000 > OEM table size: 0 > entry count: 25 > local APIC address: 0xfee00000 > extended table length: 0 > extended table checksum: 0 > > --------------------------------------------------------------------------- >---- > > MP Config Base Table Entries: > > -- > I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# > INT active-lo level 0 2:A 2 16 > INT active-lo level 0 2:A 2 23 This is the real bug and I guess I can improve the message. Then problem is not two lines for IRQ 16, but that the PCI interrrupt for bus 0, device 2, pin #A has two different IRQs listed, so we don't know which one we are supposed to use. This is definitely a BIOS bug and your motherboard manufacturer needs to harassed into giving you a BIOS update. > > > #2 Panic log > > > ------------ > > > panic: _sx_xlock (user map): xlock already held @ > > > /var/data/5/src/sys/vm/vm_map.c:2997 cpuid = 0 > > > KDB: stack backtrace: > > > kdb_backtrace(100,c0f794e0,c0e983c8,1,bb5) at kdb_backtrace+0x29 > > > panic(c05eaffa,c05d320c,c05fd313,c05fd393,bb5) at panic+0x114 > > > _sx_xlock(c0e983c8,c05fd393,bb5) at _sx_xlock+0x44 > > > _vm_map_lock_read(c0e98384,c05fd393,bb5,1f49a0c,c113692c) at > > > _vm_map_lock_read+0x37 > > > vm_map_lookup(c9f49a64,bfca2000,1,c9f49a68,c9f49a58) at > > > vm_map_lookup+0x28 vm_fault(c0e98384,bfca2000,1,0,c0f794e0) at > > > vm_fault+0x66 > > > trap_pfault(c9f49b2c,0,bfca253c) at trap_pfault+0xd2 > > > trap(18,10,10,c0e98444,c0c95c48) at trap+0x30d > > > calltrap() at calltrap+0x5 > > > --- trap 0xc, eip = 0xc05b541c, esp = 0xc9f49b6c, ebp = 0xc9f49b78 --- > > > pmap_enter_quick(c0e98444,2894f000,c0d7c2e8,0,0) at > > > pmap_enter_quick+0xc8 > > > > This is the real bug, can you do 'l *0xc05b541c' from kgdb? > > (kgdb) l *0xc05b541c > 0xc05b541c is in pmap_enter_quick > (/var/data/5/src/sys/i386/i386/pmap.c:2130). > 2125 * entering the page into the current pmap. In order to > support > 2126 * quick entry into any pmap, one would likely use > pmap_pte_quick. > 2127 * But that isn't as quick as vtopte. > 2128 */ > 2129 pte = vtopte(va); > 2130 if (*pte) { > 2131 if (mpte != NULL) { > 2132 pmap_unwire_pte_hold(pmap, mpte); > 2133 mpte = NULL; > 2134 } I would try asking alc@ if he has any ideas for this one. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org