Date: Wed, 9 Jul 2008 22:18:05 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Adam McDougall <mcdouga9@egr.msu.edu> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 legacy.c src/sys/dev/acpica acpi.c src/sys/dev/cpufreq ichss.c src/sys/i386/i386 legacy.c Message-ID: <200807092218.05668.jhb@freebsd.org> In-Reply-To: <20080710013217.GP57161@egr.msu.edu> References: <200806270351.m5R3p0iZ023807@repoman.freebsd.org> <20080710013217.GP57161@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 09 July 2008 09:32:18 pm Adam McDougall wrote: > This commit (verified by binary search) causes my Sun Fire X4100 > problems booting. I found it by upgrading a new 7-rel install > recenty, and I have similar servers running a build from about > 3 weeks ago without problem. I have not tried this on a X4100M2 > yet. Upon comparing dmesg output, pci stuff is probed differently, > and the obvious symptoms include probing up until > "Timecounters tick every 1.000 msec" > > then after a few minutes I get stuff like: > > umass0: BBB reset failed, TIMEOUT > umass1: CBI reset failed, TIMEOUT > umass0: BBB bulk-in clear stall failed, TIMEOUT > umass1: CBI bulk-in stall clear failed, TIMEOUT > umass0: BBB bulk-out clear stall failed, TIMEOUT > umass1: CBI bulk-out stall clear failed, TIMEOUT > umass0: BBB reset failed, TIMEOUT > umass1: CBI reset failed, TIMEOUT > > and eventually it arrives at a mount root prompt. > > This happens with or without cpufreq loaded from module. > > I have BIOS version 44 installed. > > It occurs with GENERIC from today but my 'broken' dmesg below > is from a custom kernel config that I can provide if necessary. > > dmesg from 7.0-RELEASE: > http://www.egr.msu.edu/~mcdouga9/dmesg-x4100-7rel.txt > dmesg from today's src (after commit): > http://www.egr.msu.edu/~mcdouga9/dmesg-x4100-7-20080709.txt > > This system was previously running 6.x and I am preparing it to > replace an identical system with it, so I have some time to tackle > this problem. I can provide remote access including console access > if needed, or I can run suggested stuff. Please let me know if > more information or cooperation from me is needed, thanks. I missed MFC'ing something, specifically rev 1.248 of acpi.c. You can try this diff: Index: acpi.c =================================================================== --- acpi.c (revision 180262) +++ acpi.c (working copy) @@ -132,7 +132,7 @@ static int acpi_set_powerstate_method(device_t bus static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids); static void acpi_probe_children(device_t bus); -static int acpi_probe_order(ACPI_HANDLE handle, int *order); +static void acpi_probe_order(ACPI_HANDLE handle, int *order); static ACPI_STATUS acpi_probe_child(ACPI_HANDLE handle, UINT32 level, void *context, void **status); static BOOLEAN acpi_MatchHid(ACPI_HANDLE h, const char *hid); @@ -1527,21 +1527,19 @@ acpi_probe_children(device_t bus) } /* - * Determine the probe order for a given device and return non-zero if it - * should be attached immediately. + * Determine the probe order for a given device. */ -static int +static void acpi_probe_order(ACPI_HANDLE handle, int *order) { ACPI_OBJECT_TYPE type; - u_int addr; /* * 1. I/O port and memory system resource holders * 2. Embedded controllers (to handle early accesses) * 3. PCI Link Devices - * 11 - 266. Host-PCI bridges sorted by _ADR - * 280. CPUs + * ACPI_DEV_BASE_ORDER. Host-PCI bridges + * ACPI_DEV_BASE_ORDER + 10. CPUs */ AcpiGetType(handle, &type); if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02")) @@ -1550,15 +1548,10 @@ acpi_probe_order(ACPI_HANDLE handle, int *order) *order = 2; else if (acpi_MatchHid(handle, "PNP0C0F")) *order = 3; - else if (acpi_MatchHid(handle, "PNP0A03")) { - if (ACPI_SUCCESS(acpi_GetInteger(handle, "_ADR", &addr))) - *order = 11 + ACPI_ADR_PCI_SLOT(addr) * (PCI_FUNCMAX + 1) + - ACPI_ADR_PCI_FUNC(addr); - else - *order = 11; - } else if (type == ACPI_TYPE_PROCESSOR) - *order = 280; - return (0); + else if (acpi_MatchHid(handle, "PNP0A03")) + *order = ACPI_DEV_BASE_ORDER; + else if (type == ACPI_TYPE_PROCESSOR) + *order = ACPI_DEV_BASE_ORDER + 10; } /* @@ -1608,13 +1601,13 @@ acpi_probe_child(ACPI_HANDLE handle, UINT32 level, * placeholder so that the probe/attach passes will run * breadth-first. Orders less than ACPI_DEV_BASE_ORDER * are reserved for special objects (i.e., system - * resources). Orders between ACPI_DEV_BASE_ORDER and 300 + * resources). Orders between ACPI_DEV_BASE_ORDER and 100 * are used for Host-PCI bridges (and effectively all * their children) and CPUs. Larger values are used for * all other devices. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str)); - order = level * 10 + 300; + order = level * 10 + 100; acpi_probe_order(handle, &order); child = BUS_ADD_CHILD(bus, order, NULL, -1); if (child == NULL) -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807092218.05668.jhb>