"Multiple entries for PCI IRQ 16" and "xlock already held"
panics on 5.3-BETA(3,4,5)
John Baldwin
jhb at FreeBSD.org
Thu Sep 23 08:13:00 PDT 2004
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 <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-current
mailing list