Re: "Multiple entries for PCI IRQ 16" and "xlock already held" panics on 5.3-BETA(3,4,5)

On Wednesday 22 September 2004 05:52 am, Pavel Gubin wrote:
> Hello,
>
> I'm trying to set up RELENG_5 on a box, and got some panices.
>
> 1) Box configuration: MSI MS-6568 (SiS740 + SiS961B), Duron 1100, Realtek
> RTL8101 on-board, BIOS v1.2 (04102002, the latest)
>
> 2) Panices are reproducible during all last RELENG_5 stages (3,4,5 betas)
>
> 3) Kernel config is derived from GENERIC by commenting out unneeded devices
> and adding some options:
>
> === cut here ===
> machine		i386
> cpu		I686_CPU
> ident		Pine
>
> makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols
>
> [...]
>
> options 	KDB			# Enable kernel debugger support.
> options 	DDB			# Support DDB.
> options 	GDB			# Support remote GDB.
> options 	INVARIANTS		# Enable calls of extra sanity checking
> options 	INVARIANT_SUPPORT	# Extra sanity checks of internal structures,
> required by INVARIANTS options 	WITNESS			# Enable checks to detect
> deadlocks and cycles
> options 	WITNESS_SKIPSPIN	# Don't run witness on spinlocks for speed
> options		BREAK_TO_DEBUGGER
> options		KDB_TRACE
>
> options		AUTO_EOI_1
> options		INCLUDE_CONFIG_FILE
> options		QUOTA
> options		IPFIREWALL
> options		IPFIREWALL_FORWARD
> options		IPFIREWALL_DEFAULT_TO_ACCEPT	#allow everything by default
> options		IPDIVERT		#divert sockets
> options		BRIDGE
> options		DUMMYNET
>
> options 	SMP		# Symmetric MultiProcessor Kernel
> device		apic		# I/O APIC
> [...]
> === cut here ===
>
> Panices.
> --------
>
> 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.

> #2 Panic log
> ------------
> panic: _sx_xlock (user map): xlock already held _at_
> /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?

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org