cvs commit: src/sys/dev/acpica acpi_pci_link.c

[John Baldwin]

On Wednesday 01 December 2004 06:17 pm, Pawel Jakub Dawidek wrote:
> On Wed, Dec 01, 2004 at 09:05:02PM +0000, John Baldwin wrote:
> +> jhb         2004-12-01 21:05:02 UTC
> +>
> +>   FreeBSD src repository
> +>
> +>   Modified files:
> +>     sys/dev/acpica       acpi_pci_link.c
> +>   Log:
> +>   - Do a better job of handling any Dependent Functions (aka DPFs) that
> appear +>     in the _PRS or _CRS of link devices.  If faced with multiple
> DPFs in a +>     _PRS, we just use the first one.  We assume that if _CRS
> has DPF tags they +>     only contain a single set since multiple DPFs
> wouldn't make any sense.  In +>     practice, the only DPFs I've seen so
> far for link devices are that the one +>     IRQ resource is surrounded by
> a DPF tag pair for no apparent reason, and +>     this should handle that
> case fine now.
> +>   - Only allocate link structures for IRQ resources for link devices
> rather +>     than allocating a link structure for every resource.
>
> On my box things looks much worse (not sure if this is related):
>
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) XEON(TM) CPU 1.80GHz (1799.75-MHz 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0xf24  Stepping = 4
>  
> Features=0x3febfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MC
>A,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM>
> Hyperthreading: 2 logical CPUs
> real memory  = 1073741824 (1024 MB)
> avail memory = 1046126592 (997 MB)
> ACPI APIC Table: <INTEL          APIC  >
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
>  cpu2 (AP): APIC ID:  6
>  cpu3 (AP): APIC ID:  7
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x9
> fault code              = supervisor write, page not present
> instruction pointer     = 0x8:0xc05ac7c9
> stack pointer           = 0x10:0xc0820cb4
> frame pointer           = 0x10:0xc0820cd0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 0 (swapper)
> [thread pid 0 tid 0 ]
> Stopped at      cpu_fork+0x1a1: incl    0x8(%eax)
> db> tr
> Tracing pid 0 tid 0 td 0xc0617e20
> cpu_fork(c0617e20,c1e8b000,c1e83300,60034,c1e8b068,0,c05cd0e1,287,c0619fe0,
>c05cd0e1,283) at cpu_fork+0x1a1
> fork1(c0617e20,60034,0,c0820d4c) at fork1+0xbe5
> kthread_create(c0488eac,0,0,40000,0) at kthread_create+0x33
> ktrace_init(0,c1e70f70,81ec00,81e000,828000) at ktrace_init+0xac
> mi_startup() at mi_startup+0xb3
> begin() at begin+0x2c
> db>

This is well before the link code.  Can you use gdb to find the file/line for 
cpu_fork+0x1a1?

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