Date: Thu, 23 Sep 2004 11:24:47 +0700 From: Pavel Gubin <pg@ie.tusur.ru> To: John Baldwin <jhb@FreeBSD.org> 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) Message-ID: <20040923042447.GA88335@ie.tusur.ru> In-Reply-To: <200409221628.51977.jhb@FreeBSD.org> References: <20040922095257.GA81709@ie.tusur.ru> <200409221628.51977.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
--
Processors: APIC ID Version State Family Model Step Flags
0 0x14 BSP, usable 6 7 1 0x0055
--
Bus: Bus ID Type
0 PCI
1 PCI
2 ISA
--
I/O APICs: APIC ID Version State Address
2 0x11 usable 0xfec00000
--
I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#
ExtINT conforms conforms 2 0 2 0
INT conforms conforms 2 1 2 1
INT conforms conforms 2 0 2 2
INT conforms conforms 2 3 2 3
INT conforms conforms 2 4 2 4
INT conforms conforms 2 6 2 6
INT conforms conforms 2 7 2 7
INT active-hi edge 2 8 2 8
INT conforms conforms 2 9 2 9
INT conforms conforms 2 12 2 12
INT conforms conforms 2 13 2 13
INT conforms conforms 2 14 2 14
INT conforms conforms 2 15 2 15
INT active-lo level 0 2:A 2 16
INT active-lo level 1 0:A 2 16
INT active-lo level 0 10:A 2 18
INT active-lo level 0 2:D 2 20
INT active-lo level 0 2:A 2 23
--
Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#
ExtINT conforms conforms 0 0:A 255 0
NMI conforms conforms 0 0:A 255 1
===============================================================================
> > #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 }
--
Pavel Gubin
TUSC&R / Industrial Electronics dept / System Administrator
2:5005/14@fidonet / Phone +7-3822-423067 / ICQ 28835566
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040923042447.GA88335>