From owner-cvs-all@FreeBSD.ORG Thu Jul 10 02:25:37 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC221065686; Thu, 10 Jul 2008 02:25:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7AAF08FC1D; Thu, 10 Jul 2008 02:25:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6A2OvB0028341; Wed, 9 Jul 2008 22:25:28 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Adam McDougall Date: Wed, 9 Jul 2008 22:18:05 -0400 User-Agent: KMail/1.9.7 References: <200806270351.m5R3p0iZ023807@repoman.freebsd.org> <20080710013217.GP57161@egr.msu.edu> In-Reply-To: <20080710013217.GP57161@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807092218.05668.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 09 Jul 2008 22:25:29 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7680/Wed Jul 9 19:31:16 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2008 02:25:38 -0000 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