Skip site navigation (1)Skip section navigation (2)
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>