Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Oct 2005 12:39:57 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Andrew Thompson <thompsa@freebsd.org>
Cc:        njl@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: RC1 panic on boot
Message-ID:  <200510181239.58502.jhb@freebsd.org>
In-Reply-To: <20051018014031.GA38996@heff.fud.org.nz>
References:  <20051015014313.GA25990@heff.fud.org.nz> <200510171735.18054.jhb@freebsd.org> <20051018014031.GA38996@heff.fud.org.nz>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 17 October 2005 09:40 pm, Andrew Thompson wrote:
> On Mon, Oct 17, 2005 at 05:35:17PM -0400, John Baldwin wrote:
> > On Monday 17 October 2005 05:12 pm, Andrew Thompson wrote:
> > > On Mon, Oct 17, 2005 at 04:54:02PM -0400, John Baldwin wrote:
> > > > On Friday 14 October 2005 09:43 pm, Andrew Thompson wrote:
> > > > > Hi,
> > > > >
> > > > >
> > > > > I am getting this panic on RC1, I am booting disc1 to install the
> > > > > system. Its a HP Omnibook 4150 and no PC cards are inserted.
> > > > >
> > > > > It has 5.4 on the drive at the moment which installed fine. I have
> > > > > attached a couple of dmesg logs.
> > > > >
> > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on
> > > > > acpi0 cpu0: <ACPI CPU> on acpi0
> > > > > acpi_throttle0: <ACPI CPU Throttling> on cpu0
> > > > > acpi_lid0: <Control Method Lid Switch> on acpi0
> > > > > pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> > > >
> > > > Your LNKC pci_link device didn't probe and attach for some reason. 
> > > > Can you post your ASL somewhere?  ACPI is supposed to force all the
> > > > link devices to probe first.
> > >
> > > thanks,
> > >
> > > http://www.fud.org.nz/~andy/omnibook-4150.asl
> > > http://www.fud.org.nz/~andy/omnibook-4150.dsdt
> > >
> > > Ive been doing a binary search in between other things and have
> > > narrowed the breakage to late November 2004. mid nov boots fine and the
> > > 27th onwards panics, i'll keep going.
> >
> > That would be because the new pci_link code was committed on November 23
> > and isn't in 5.x.  I didn't see anything weird in your ASL.  LNKC looks
> > fine, so I'm not sure why it isn't attaching.  A good first step might be
> > to add some printf's in acpi_pci_link.c in the probe routine to see if
> > the LNKC device is even getting probed and if the probe is failing, why
> > it is failing.
>
> LNKC doesnt seem to be probed at all.
>
>
>
> Copyright (c) 1992-2005 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD 7.0-CURRENT #0: Tue Oct 18 11:22:14 NZDT 2005
>     root@dev.fud.org.nz:/usr/obj/usr/src/sys/GENERIC
> WARNING: WITNESS option enabled, expect reduced performance.
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel Celeron (448.05-MHz 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x681  Stepping = 1
>  
> Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV
>,PAT,PSE36,MMX,FXSR,SSE> real memory  = 536870912 (512 MB)
> avail memory = 515850240 (491 MB)
> npx0: [FAST]
> npx0: <math processor> on motherboard
> npx0: INT 16 interface
> acpi0: <HP-MCD CK RSDT> on motherboard
> acpi0: Power Button (fixed)
> acpi_pci_link_probe: ACPI_ID_PROBE OK for 'LNKA'
> pci_link0: <ACPI PCI Link LNKA> irq 10 on acpi0
> acpi_pci_link_probe: ACPI_ID_PROBE OK for 'LNKB'
> pci_link1: <ACPI PCI Link LNKB> irq 10 on acpi0
> acpi_pci_link_probe: ACPI_ID_PROBE OK for 'LNKD'
> pci_link2: <ACPI PCI Link LNKD> irq 10 on acpi0
> unknown: memory range not supported
> unknown: memory range not supported
> unknown: memory range not supported
> unknown: memory range not supported
> unknown: memory range not supported
> unknown: memory range not supported
> acpi_pci_link_probe: ACPI_ID_PROBE failed for 'XROM'
> acpi_pci_link_probe: ACPI_ID_PROBE failed for 'MBRD'
> acpi_pci_link_probe: ACPI_ID_PROBE failed for 'EC0_'

Hmm, that would seem to be a bug in ACPI then if it doesn't see LNKC as a 
device.  Can you try adding some printf's to the ACPI code that adds child 
devices to see if LNKC is ever added as a child device?  You'd do this in the 
acpi_probe_child() function in acpi.c.

Also, maybe try turning #if 0'ing out the call to device_probe_and_attach() in 
acpi_probe_child() (the one that's if (probe_now)) as I think it's a bug.  
Adjusting the order should be sufficient, but always insta-probing early 
devices could result in probing a device too early.  (Order 3 device before 
an Order 1 device because of namespace order for example.)

> acpi_ec0: <Embedded Controller: GPE 0x9> port 0x62,0x66 on acpi0
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
> acpi_pci_link_probe: ACPI_ID_PROBE failed for 'CPU0'
> cpu0: <ACPI CPU> on acpi0
> acpi_throttle0: <ACPI CPU Throttling> on cpu0
> acpi_pci_link_probe: ACPI_ID_PROBE failed for 'LID_'
> acpi_lid0: <Control Method Lid Switch> on acpi0
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x0
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc0ad2e1e
> stack pointer           = 0x28:0xc0c20ba0
> frame pointer           = 0x28:0xc0c20bac
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 0 (swapper)
> [thread pid 0 tid 0 ]
> Stopped at      acpi_pci_link_lookup+0x1e:      movl    0(%eax),%eax
> db>

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510181239.58502.jhb>