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 _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? > > (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_at_ 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.orgReceived on Thu Sep 23 2004 - 13:13:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:13 UTC