Date: Sat, 22 Oct 2005 01:08:10 -0700 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Andrew Thompson <thompsa@freebsd.org> Subject: Re: RC1 panic on boot Message-ID: <4359F36A.7000308@root.org> In-Reply-To: <200510181239.58502.jhb@freebsd.org> References: <20051015014313.GA25990@heff.fud.org.nz> <200510171735.18054.jhb@freebsd.org> <20051018014031.GA38996@heff.fud.org.nz> <200510181239.58502.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > 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.) It's not probing LNKC because it's disabled on boot and his ASL is less than standard. If you look at _STA for LNKC, it returns 0xB if enabled and 0x1 if disabled. The problem is, the disabled case is returning "PRESENT" but not "FUNCTIONAL" and so we don't probe that device. It happens to work for the others because they are enabled by the BIOS. Comment out this code in acpi.c: /* * Check that the device is present. If it's not present, * leave it disabled (so that we have a device_t attached to * the handle, but we don't probe it). */ if (type == ACPI_TYPE_DEVICE && !acpi_DeviceIsPresent(child)) { device_disable(child); break; } We can probably add a hack to that if() that says: && !acpi_MatchHid(handle, "PNP0C0F") That way we special case link devices. I'm worried about changing this for all devices since there are some that really aren't probe-able when !FUNCTIONAL and being too lenient might be more trouble than it's worth. If my suggestion works, feel free to commit it. I'm still away a lot. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4359F36A.7000308>