From owner-freebsd-arch@FreeBSD.ORG Mon Apr 25 19:15:10 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C050C106564A; Mon, 25 Apr 2011 19:15:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 90E958FC13; Mon, 25 Apr 2011 19:15:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3A0A346B9C; Mon, 25 Apr 2011 15:15:10 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B2C808A01B; Mon, 25 Apr 2011 15:15:09 -0400 (EDT) From: John Baldwin To: Alexander Motin Date: Mon, 25 Apr 2011 15:09:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DAE9B86.8040106@FreeBSD.org> In-Reply-To: <4DAE9B86.8040106@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104251509.47482.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 25 Apr 2011 15:15:09 -0400 (EDT) Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 19:15:10 -0000 On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: > Hi. > > On 19.04.2011 21:50, John Baldwin wrote: > > I've already had at least one testing report that this fixes the issues with > > some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI > > is enabled as this code re-discovers the original windows and programs them > > correctly. More testing would be good however. > > I would like this helped my Acer TM6292 which also has alike problems > with missing PCIe bridge resources, but unluckily it doesn't. > > Here is verbose dmesg when my system uses this dirty hack: > http://people.freebsd.org/~mav/tm6292_pcie.patch > to restore bridges resources to the pre-ACPI state: > http://people.freebsd.org/~mav/dmesg.boot.hacks > > Here is respective `pciconf -lvcb` output: > http://people.freebsd.org/~mav/pciconf.hacks > > Here is dmesg with patches, but without NEW_PCIB: > http://people.freebsd.org/~mav/dmesg.boot.olbpcib > > Here is dmesg with patches with NEW_PCIB: > http://people.freebsd.org/~mav/dmesg.boot.newpcib Ah, your problem is we pick bad ranges when we alloc fresh resources for your bridges. I am working on making that better for ACPI, but for now you can try setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. Although, it looks like it is not being honored currently. Try adding a printf in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the type, start, and end of each resource range. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Apr 25 21:27:57 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 061681065784; Mon, 25 Apr 2011 21:27:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CB9598FC1A; Mon, 25 Apr 2011 21:27:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7DA2746BA1; Mon, 25 Apr 2011 17:27:56 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0AB5A8A02A; Mon, 25 Apr 2011 17:27:56 -0400 (EDT) From: John Baldwin To: Alexander Motin Date: Mon, 25 Apr 2011 17:21:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DAE9B86.8040106@FreeBSD.org> <201104251509.47482.jhb@freebsd.org> In-Reply-To: <201104251509.47482.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104251721.53027.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 25 Apr 2011 17:27:56 -0400 (EDT) Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 21:27:57 -0000 On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: > On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: > > Hi. > > > > On 19.04.2011 21:50, John Baldwin wrote: > > > I've already had at least one testing report that this fixes the issues with > > > some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI > > > is enabled as this code re-discovers the original windows and programs them > > > correctly. More testing would be good however. > > > > I would like this helped my Acer TM6292 which also has alike problems > > with missing PCIe bridge resources, but unluckily it doesn't. > > > > Here is verbose dmesg when my system uses this dirty hack: > > http://people.freebsd.org/~mav/tm6292_pcie.patch > > to restore bridges resources to the pre-ACPI state: > > http://people.freebsd.org/~mav/dmesg.boot.hacks > > > > Here is respective `pciconf -lvcb` output: > > http://people.freebsd.org/~mav/pciconf.hacks > > > > Here is dmesg with patches, but without NEW_PCIB: > > http://people.freebsd.org/~mav/dmesg.boot.olbpcib > > > > Here is dmesg with patches with NEW_PCIB: > > http://people.freebsd.org/~mav/dmesg.boot.newpcib > > Ah, your problem is we pick bad ranges when we alloc fresh resources for your > bridges. I am working on making that better for ACPI, but for now you can try > setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. > > Although, it looks like it is not being honored currently. Try adding a printf > in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the > type, start, and end of each resource range. Actually, try this patch. Then I think you can use the host_mem_start tunable: --- //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c 2011-04-16 21:33:25.000000000 0000 +++ /home/jhb/work/p4/pci/sys/dev/acpica/acpi_pcib_acpi.c 2011-04-16 21:33:25.000000000 0000 @@ -551,10 +551,16 @@ * found to do it. This is typically only used on older laptops * that don't have pci busses behind pci bridge, so assuming > 32MB * is likely OK. + * + * PCI-PCI bridges may not allocate smaller ranges for their windows, + * but the heuristics here should apply to those, so we allow several + * different end addresses. */ - if (type == SYS_RES_MEMORY && start == 0UL && end == ~0UL) + if (type == SYS_RES_MEMORY && start == 0UL && (end == ~0UL || + end == 0xffffffff)) start = acpi_host_mem_start; - if (type == SYS_RES_IOPORT && start == 0UL && end == ~0UL) + if (type == SYS_RES_IOPORT && start == 0UL && (end == ~0UL || + end == 0xffff || end == 0xffffffff)) start = 0x1000; return (bus_generic_alloc_resource(dev, child, type, rid, start, end, count, flags)); -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 01:59:08 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91B901065673 for ; Tue, 26 Apr 2011 01:59:08 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 66E898FC1F for ; Tue, 26 Apr 2011 01:59:08 +0000 (UTC) Received: from cpe-74-66-24-70.nyc.res.rr.com ([74.66.24.70] helo=[192.168.1.119]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QEXYR-00047K-OQ for arch@freebsd.org; Mon, 25 Apr 2011 21:59:07 -0400 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Apr 2011 21:59:06 -0400 Message-Id: <7DC6C171-3802-4B5D-B2D8-2191C6FF6DBA@neville-neil.com> To: arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Subject: Is there any reason not to remove all the spl() calls in rtsock.c? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 01:59:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Howdy, I was just reviewing the code in rtsock.c, specifically rts_attach(). = Is there any reason not to just remove the spl* calls? I don't see anything obvious that = needs protection that is not now protected by a finer grained lock. Best, George -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk22JuoACgkQYdh2wUQKM9KWJgCglcc31hS2sQrzlrJTcZRK1zCc Y0gAnjNcE4AdBpOeh7oQGtD2nUTXr6tx =3Dzx2e -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 02:39:12 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F81C106574B for ; Tue, 26 Apr 2011 02:39:12 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 20A918FC1C for ; Tue, 26 Apr 2011 02:39:11 +0000 (UTC) Received: by eyg7 with SMTP id 7so73578eyg.13 for ; Mon, 25 Apr 2011 19:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0q/5E6xqFXURU3EAkcgB310443GDv7N4uzgslz8Yfe0=; b=TOmfbOWFFfM6rb1TR9gihAoWc11DtlFznLsBUH7zxWDRTMThaTgrUMK3gwEKEW1JXr +yMIQVTjHnSXuyxO8BBzlFv4/l3Syxx9O5DNocSs0BHnH6ORC1jw1Gd1pmn6YWPRG8ya QsqXPDyA/OBSHjO8nEPoY2xOBr+u/y4wjHeUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eOoPx8GV57M8jo39N3mR+4J0xw6aHVCwT7KpKl4fBYvkK2EIRKTrURgPVd3rOXftXF hicm3MwZ2jGDUSIXnYYDp8zunrVedI6pkAcKc43yMzVmu0/IKZye/FMMp2eRlI9BLoL/ vqJhSQEmfmsoBeS+xSwU6SWTwao8KHEeAh+rI= MIME-Version: 1.0 Received: by 10.213.29.73 with SMTP id p9mr1376185ebc.149.1303783792504; Mon, 25 Apr 2011 19:09:52 -0700 (PDT) Received: by 10.213.35.70 with HTTP; Mon, 25 Apr 2011 19:09:52 -0700 (PDT) In-Reply-To: <7DC6C171-3802-4B5D-B2D8-2191C6FF6DBA@neville-neil.com> References: <7DC6C171-3802-4B5D-B2D8-2191C6FF6DBA@neville-neil.com> Date: Mon, 25 Apr 2011 22:09:52 -0400 Message-ID: From: Ryan Stone To: George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Is there any reason not to remove all the spl() calls in rtsock.c? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 02:39:12 -0000 On Mon, Apr 25, 2011 at 9:59 PM, George Neville-Neil wrote: > Howdy, > > I was just reviewing the code in rtsock.c, specifically rts_attach(). =A0= Is there any reason > not to just remove the spl* calls? =A0I don't see anything obvious that n= eeds protection > that is not now protected by a finer grained lock. > > Best, > George The spl* calls have been no-ops for over 10 years now(since r71240), so I certainly hope that there's nothing requiring their protection. It's probably long-past time to kill off those stubs, I'd imagine. From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 04:11:24 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C35A1065670 for ; Tue, 26 Apr 2011 04:11:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 27F1C8FC15 for ; Tue, 26 Apr 2011 04:11:24 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3Q47bjG027246 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 25 Apr 2011 22:07:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 25 Apr 2011 22:07:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7DC6C171-3802-4B5D-B2D8-2191C6FF6DBA@neville-neil.com> To: Ryan Stone X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 25 Apr 2011 22:07:39 -0600 (MDT) Cc: arch@FreeBSD.org, George Neville-Neil Subject: Re: Is there any reason not to remove all the spl() calls in rtsock.c? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:11:24 -0000 On Apr 25, 2011, at 8:09 PM, Ryan Stone wrote: > On Mon, Apr 25, 2011 at 9:59 PM, George Neville-Neil > wrote: >> Howdy, >>=20 >> I was just reviewing the code in rtsock.c, specifically rts_attach(). = Is there any reason >> not to just remove the spl* calls? I don't see anything obvious that = needs protection >> that is not now protected by a finer grained lock. Likely they can go. Only reason to keep them at all at this point is if = there's still stuff that isn't locked, which should be only a tiny = fraction of the tree... Warner >>=20 >> Best, >> George >=20 > The spl* calls have been no-ops for over 10 years now(since r71240), > so I certainly hope that there's nothing requiring their protection. >=20 > It's probably long-past time to kill off those stubs, I'd imagine. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 06:53:29 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B56C1065670; Tue, 26 Apr 2011 06:53:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id ACAB98FC1C; Tue, 26 Apr 2011 06:53:28 +0000 (UTC) Received: by bwz12 with SMTP id 12so406191bwz.13 for ; Mon, 25 Apr 2011 23:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W1iq9pIFe7QgHiwVOlPEuBGtXmGR4cbdtbNqlX3UY0c=; b=LLGWFCw05YUI1EMvx4CHcc65Ub+PUF25nTXnsI2rGa+MAJ2ELI1KUQPJAY/zCA/9yh x2V++9i0KVxYxuCuLTMM1kJ9TsK3pNZ1BlyCoYPov7DnSCovzEEw9k0jVipMmDw+3uvZ RYMoD3oPvROo1I1exOoXJHStMy3nHx8yRPKdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cNS6onvBCTJf/KYDSiDP9Dpz5hsAJXgIIYsE+UKOblR5twSWXxprd7L+yfUUS5Y++m vEdy2D90YXd474eUYCyB67NFH0Ceb9NCi8RgncUC187CZp/IJQ228e0xue+DWv71t5oW sMlYb58eDxRDXGi7AjWgbvKpe8m4V4yf17Wco= Received: by 10.204.83.7 with SMTP id d7mr301575bkl.206.1303800807570; Mon, 25 Apr 2011 23:53:27 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w3sm3652795bkt.17.2011.04.25.23.53.26 (version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 23:53:26 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB66BE4.8070709@FreeBSD.org> Date: Tue, 26 Apr 2011 09:53:24 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4DAE9B86.8040106@FreeBSD.org> <201104251509.47482.jhb@freebsd.org> <201104251721.53027.jhb@freebsd.org> In-Reply-To: <201104251721.53027.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 06:53:29 -0000 On 26.04.2011 00:21, John Baldwin wrote: > On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: >> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: >>> On 19.04.2011 21:50, John Baldwin wrote: >>>> I've already had at least one testing report that this fixes the issues with >>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI >>>> is enabled as this code re-discovers the original windows and programs them >>>> correctly. More testing would be good however. >>> >>> I would like this helped my Acer TM6292 which also has alike problems >>> with missing PCIe bridge resources, but unluckily it doesn't. >>> >>> Here is verbose dmesg when my system uses this dirty hack: >>> http://people.freebsd.org/~mav/tm6292_pcie.patch >>> to restore bridges resources to the pre-ACPI state: >>> http://people.freebsd.org/~mav/dmesg.boot.hacks >>> >>> Here is respective `pciconf -lvcb` output: >>> http://people.freebsd.org/~mav/pciconf.hacks >>> >>> Here is dmesg with patches, but without NEW_PCIB: >>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib >>> >>> Here is dmesg with patches with NEW_PCIB: >>> http://people.freebsd.org/~mav/dmesg.boot.newpcib >> >> Ah, your problem is we pick bad ranges when we alloc fresh resources for your >> bridges. I am working on making that better for ACPI, but for now you can try >> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. >> >> Although, it looks like it is not being honored currently. Try adding a printf >> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the >> type, start, and end of each resource range. > > Actually, try this patch. Then I think you can use the host_mem_start tunable: I've tried it. With this patch host_mem_start tunable seems like makes effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are still not working. Here is dmesg with the patch: http://people.freebsd.org/~mav/newpcib/dmesg.wpatch , with the tunable set: http://people.freebsd.org/~mav/newpcib/dmesg.wpatch.tunable and with additional printf (but without snd_hda to fit the log size): http://people.freebsd.org/~mav/newpcib/dmesg.wpatch.tunable.debug It it helps, here is `devinfo -vr` outputs. Original (hacked): http://people.freebsd.org/~mav/newpcib/devinfo.orig , with the patch: http://people.freebsd.org/~mav/newpcib/devinfo.wpatch and with the tunable set: http://people.freebsd.org/~mav/newpcib/devinfo.wpatch.tunable -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 13:55:31 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D45E106568E; Tue, 26 Apr 2011 13:55:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 588218FC23; Tue, 26 Apr 2011 13:55:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0A79646B58; Tue, 26 Apr 2011 09:55:31 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9723C8A02A; Tue, 26 Apr 2011 09:55:30 -0400 (EDT) From: John Baldwin To: Alexander Motin Date: Tue, 26 Apr 2011 09:55:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104251721.53027.jhb@freebsd.org> <4DB66BE4.8070709@FreeBSD.org> In-Reply-To: <4DB66BE4.8070709@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104260955.29280.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 26 Apr 2011 09:55:30 -0400 (EDT) Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:55:31 -0000 On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote: > On 26.04.2011 00:21, John Baldwin wrote: > > On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: > >> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: > >>> On 19.04.2011 21:50, John Baldwin wrote: > >>>> I've already had at least one testing report that this fixes the issues with > >>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI > >>>> is enabled as this code re-discovers the original windows and programs them > >>>> correctly. More testing would be good however. > >>> > >>> I would like this helped my Acer TM6292 which also has alike problems > >>> with missing PCIe bridge resources, but unluckily it doesn't. > >>> > >>> Here is verbose dmesg when my system uses this dirty hack: > >>> http://people.freebsd.org/~mav/tm6292_pcie.patch > >>> to restore bridges resources to the pre-ACPI state: > >>> http://people.freebsd.org/~mav/dmesg.boot.hacks > >>> > >>> Here is respective `pciconf -lvcb` output: > >>> http://people.freebsd.org/~mav/pciconf.hacks > >>> > >>> Here is dmesg with patches, but without NEW_PCIB: > >>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib > >>> > >>> Here is dmesg with patches with NEW_PCIB: > >>> http://people.freebsd.org/~mav/dmesg.boot.newpcib > >> > >> Ah, your problem is we pick bad ranges when we alloc fresh resources for your > >> bridges. I am working on making that better for ACPI, but for now you can try > >> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. > >> > >> Although, it looks like it is not being honored currently. Try adding a printf > >> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the > >> type, start, and end of each resource range. > > > > Actually, try this patch. Then I think you can use the host_mem_start tunable: > > I've tried it. With this patch host_mem_start tunable seems like makes > effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are > still not working. Hmmm, I think I need to clear the completely bogus windows when we fail to allocate the initial window. Try this (relative to the previous patches): --- //depot/projects/pci/sys/dev/pci/pci_pci.c 2011-04-19 17:42:14.000000000 0000 +++ /home/jhb/work/p4/pci/sys/dev/pci/pci_pci.c 2011-04-19 17:42:14.000000000 0000 @@ -60,6 +60,7 @@ static int pcib_resume(device_t dev); static int pcib_power_for_sleep(device_t pcib, device_t dev, int *pstate); +static void pcib_write_windows(struct pcib_softc *sc, int mask); static device_method_t pcib_methods[] = { /* Device interface */ @@ -181,6 +182,9 @@ device_printf(sc->dev, "failed to allocate initial %s window: %#jx-%#jx\n", w->name, (uintmax_t)w->base, (uintmax_t)w->limit); + w->base = 0; + w->limit = max_address; + pcib_write_windows(sc, w->mask); return; } -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 14:45:43 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 488AC1065673; Tue, 26 Apr 2011 14:45:43 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A183B8FC17; Tue, 26 Apr 2011 14:45:42 +0000 (UTC) Received: by fxm11 with SMTP id 11so663626fxm.13 for ; Tue, 26 Apr 2011 07:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=OolT/5cUEQsStsngigOtiJTP5r5LFotDAcroZ9fG0HE=; b=sUmaePjbfZbSQ07ImZpFhc3QLRGz5wX73hpRpfO/7t77ZjFXPcxZxc77RriYWAvy5P i0Fp4FVxtnEAnXHL09nHA54UJ6knY8OHoqvDPEnid6ekaZ4SiqTRtrPd8sMnFWugtJJr Zi7ZAyySDR13iE0UnC+kEScgDZMosZlTkN4+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UD16NZfBC5XGxXnkEl76MVYFmi1hoN67FG/2l8/0BR3JjTTlVnRLl1G5UtULQGUIYp Lmd1DUugrFa/avRxfGB559WdRqKqoCcd1OSH1PZBuGX8djFp6WcBJK8WTl8caFEZ4NkE q0EQuhKvu4TnpvHuVfJkxm1K1/xWc0AAjeQ6E= Received: by 10.204.227.193 with SMTP id jb1mr792047bkb.157.1303829141269; Tue, 26 Apr 2011 07:45:41 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id l1sm3908164bkl.13.2011.04.26.07.45.39 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 07:45:40 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB6DA8D.1040802@FreeBSD.org> Date: Tue, 26 Apr 2011 17:45:33 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: John Baldwin References: <201104251721.53027.jhb@freebsd.org> <4DB66BE4.8070709@FreeBSD.org> <201104260955.29280.jhb@freebsd.org> In-Reply-To: <201104260955.29280.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 14:45:43 -0000 John Baldwin wrote: > On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote: >> On 26.04.2011 00:21, John Baldwin wrote: >>> On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: >>>> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: >>>>> On 19.04.2011 21:50, John Baldwin wrote: >>>>>> I've already had at least one testing report that this fixes the issues with >>>>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI >>>>>> is enabled as this code re-discovers the original windows and programs them >>>>>> correctly. More testing would be good however. >>>>> I would like this helped my Acer TM6292 which also has alike problems >>>>> with missing PCIe bridge resources, but unluckily it doesn't. >>>>> >>>>> Here is verbose dmesg when my system uses this dirty hack: >>>>> http://people.freebsd.org/~mav/tm6292_pcie.patch >>>>> to restore bridges resources to the pre-ACPI state: >>>>> http://people.freebsd.org/~mav/dmesg.boot.hacks >>>>> >>>>> Here is respective `pciconf -lvcb` output: >>>>> http://people.freebsd.org/~mav/pciconf.hacks >>>>> >>>>> Here is dmesg with patches, but without NEW_PCIB: >>>>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib >>>>> >>>>> Here is dmesg with patches with NEW_PCIB: >>>>> http://people.freebsd.org/~mav/dmesg.boot.newpcib >>>> Ah, your problem is we pick bad ranges when we alloc fresh resources for your >>>> bridges. I am working on making that better for ACPI, but for now you can try >>>> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. >>>> >>>> Although, it looks like it is not being honored currently. Try adding a printf >>>> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the >>>> type, start, and end of each resource range. >>> Actually, try this patch. Then I think you can use the host_mem_start tunable: >> I've tried it. With this patch host_mem_start tunable seems like makes >> effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are >> still not working. > > Hmmm, I think I need to clear the completely bogus windows when we fail to > allocate the initial window. Try this (relative to the previous patches): Dmesg changed a bit, but still no luck: http://people.freebsd.org/~mav/newpcib/dmesg.next -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 15:46:42 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BA63106566C; Tue, 26 Apr 2011 15:46:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B459C8FC0A; Tue, 26 Apr 2011 15:46:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3CF7346B0D; Tue, 26 Apr 2011 11:46:41 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A82E28A02A; Tue, 26 Apr 2011 11:46:40 -0400 (EDT) From: John Baldwin To: Alexander Motin Date: Tue, 26 Apr 2011 11:46:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104260955.29280.jhb@freebsd.org> <4DB6DA8D.1040802@FreeBSD.org> In-Reply-To: <4DB6DA8D.1040802@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104261146.39731.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 26 Apr 2011 11:46:40 -0400 (EDT) Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 15:46:42 -0000 On Tuesday, April 26, 2011 10:45:33 am Alexander Motin wrote: > John Baldwin wrote: > > On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote: > >> On 26.04.2011 00:21, John Baldwin wrote: > >>> On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: > >>>> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: > >>>>> On 19.04.2011 21:50, John Baldwin wrote: > >>>>>> I've already had at least one testing report that this fixes the issues with > >>>>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI > >>>>>> is enabled as this code re-discovers the original windows and programs them > >>>>>> correctly. More testing would be good however. > >>>>> I would like this helped my Acer TM6292 which also has alike problems > >>>>> with missing PCIe bridge resources, but unluckily it doesn't. > >>>>> > >>>>> Here is verbose dmesg when my system uses this dirty hack: > >>>>> http://people.freebsd.org/~mav/tm6292_pcie.patch > >>>>> to restore bridges resources to the pre-ACPI state: > >>>>> http://people.freebsd.org/~mav/dmesg.boot.hacks > >>>>> > >>>>> Here is respective `pciconf -lvcb` output: > >>>>> http://people.freebsd.org/~mav/pciconf.hacks > >>>>> > >>>>> Here is dmesg with patches, but without NEW_PCIB: > >>>>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib > >>>>> > >>>>> Here is dmesg with patches with NEW_PCIB: > >>>>> http://people.freebsd.org/~mav/dmesg.boot.newpcib > >>>> Ah, your problem is we pick bad ranges when we alloc fresh resources for your > >>>> bridges. I am working on making that better for ACPI, but for now you can try > >>>> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. > >>>> > >>>> Although, it looks like it is not being honored currently. Try adding a printf > >>>> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the > >>>> type, start, and end of each resource range. > >>> Actually, try this patch. Then I think you can use the host_mem_start tunable: > >> I've tried it. With this patch host_mem_start tunable seems like makes > >> effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are > >> still not working. > > > > Hmmm, I think I need to clear the completely bogus windows when we fail to > > allocate the initial window. Try this (relative to the previous patches): > > Dmesg changed a bit, but still no luck: > http://people.freebsd.org/~mav/newpcib/dmesg.next Oh, I'm dumb. 'w->base' should be set to 'max_address' and 'w->limit' should be set to 0 to turn off the bogus windows like this: --- //depot/projects/pci/sys/dev/pci/pci_pci.c 2011-04-19 17:42:14.000000000 0000 +++ /home/jhb/work/p4/pci/sys/dev/pci/pci_pci.c 2011-04-19 17:42:14.000000000 0000 @@ -60,6 +60,7 @@ static int pcib_resume(device_t dev); static int pcib_power_for_sleep(device_t pcib, device_t dev, int *pstate); +static void pcib_write_windows(struct pcib_softc *sc, int mask); static device_method_t pcib_methods[] = { /* Device interface */ @@ -181,6 +182,9 @@ device_printf(sc->dev, "failed to allocate initial %s window: %#jx-%#jx\n", w->name, (uintmax_t)w->base, (uintmax_t)w->limit); + w->base = max_address; + w->limit = 0; + pcib_write_windows(sc, w->mask); return; } -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 16:04:49 2011 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1921106566C; Tue, 26 Apr 2011 16:04:49 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 95F188FC18; Tue, 26 Apr 2011 16:04:49 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id p3QFkjfZ067439; Tue, 26 Apr 2011 11:46:45 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id p3QFkjUs067438; Tue, 26 Apr 2011 11:46:45 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 26 Apr 2011 11:46:45 -0400 From: David Schultz To: Rui Paulo Message-ID: <20110426154645.GA67273@zim.MIT.EDU> Mail-Followup-To: Rui Paulo , "arch@freebsd.org" , "current@freebsd.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 16:04:49 -0000 On Wed, Aug 18, 2010, Rui Paulo wrote: > Hi, > I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. > The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. > If there's anyone against this, speak now or forever be silent. :-) For what it's worth, I still occasionally use icc for simple tasks-- mainly as a reference for code generation, since it produces reasonable output in many cases where gcc does not. As I recall, making it work required minimal changes... possibly just making sure __va_list gets defined in _types.h. I have the following in one of my trees, although this is obviously not the right fix. Index: _types.h =================================================================== --- _types.h (revision 219357) +++ _types.h (working copy) @@ -105,7 +105,7 @@ */ #ifdef __GNUCLIKE_BUILTIN_VARARGS typedef __builtin_va_list __va_list; /* internally known to gcc */ -#elif defined(lint) +#else typedef char * __va_list; /* pretend */ #endif #if defined(__GNUC_VA_LIST_COMPATIBILITY) && !defined(__GNUC_VA_LIST) \ From owner-freebsd-arch@FreeBSD.ORG Tue Apr 26 21:54:44 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 457BA106564A; Tue, 26 Apr 2011 21:54:44 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 991268FC1E; Tue, 26 Apr 2011 21:54:43 +0000 (UTC) Received: by bwz12 with SMTP id 12so1309118bwz.13 for ; Tue, 26 Apr 2011 14:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=FmUICAGRz0nvhZoZ3tZIknJzur+4TB03go8RLZa/aw0=; b=T6zVYKu+GLiR/2YRunezfNw7kzl5KwG++MgsJXEHIQflUkRj1NZsCJVH0kpX07ATVI jl7zW3PheW594GmVdW8V5PCfp0O5DIqMMod8NuJ3jp79sUJBJYoXEhuQRUEpiLW/RPzl FYzlZKSin4rVHztfmpQwN8Sn77kE1N+fX14Ag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=MzBYGBi1V0GWXvA72g8aH1Mbl0vApARDRLJd+2D8UERj6ZpH13NmeOi20mCLrPXl0g l1dp0BvVTysJYfkRdeF+iR9Pj1mTcTPb/fyW4tVwXntqPku0B37RWo9lRjDIUE5gsduw xOFZYOgfQbrU3IYa1IVqYU1M5zFfiga9X5tYI= Received: by 10.204.6.203 with SMTP id a11mr1236296bka.15.1303854882381; Tue, 26 Apr 2011 14:54:42 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id l1sm77748bkl.1.2011.04.26.14.54.40 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 14:54:41 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB73F1A.4000009@FreeBSD.org> Date: Wed, 27 Apr 2011 00:54:34 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: John Baldwin References: <201104260955.29280.jhb@freebsd.org> <4DB6DA8D.1040802@FreeBSD.org> <201104261146.39731.jhb@freebsd.org> In-Reply-To: <201104261146.39731.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 21:54:44 -0000 John Baldwin wrote: > On Tuesday, April 26, 2011 10:45:33 am Alexander Motin wrote: >> John Baldwin wrote: >>> On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote: >>>> On 26.04.2011 00:21, John Baldwin wrote: >>>>> On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: >>>>>> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: >>>>>>> On 19.04.2011 21:50, John Baldwin wrote: >>>>>>>> I've already had at least one testing report that this fixes the issues with >>>>>>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI >>>>>>>> is enabled as this code re-discovers the original windows and programs them >>>>>>>> correctly. More testing would be good however. >>>>>>> I would like this helped my Acer TM6292 which also has alike problems >>>>>>> with missing PCIe bridge resources, but unluckily it doesn't. >>>>>>> >>>>>>> Here is verbose dmesg when my system uses this dirty hack: >>>>>>> http://people.freebsd.org/~mav/tm6292_pcie.patch >>>>>>> to restore bridges resources to the pre-ACPI state: >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.hacks >>>>>>> >>>>>>> Here is respective `pciconf -lvcb` output: >>>>>>> http://people.freebsd.org/~mav/pciconf.hacks >>>>>>> >>>>>>> Here is dmesg with patches, but without NEW_PCIB: >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib >>>>>>> >>>>>>> Here is dmesg with patches with NEW_PCIB: >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.newpcib >>>>>> Ah, your problem is we pick bad ranges when we alloc fresh resources for your >>>>>> bridges. I am working on making that better for ACPI, but for now you can try >>>>>> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. >>>>>> >>>>>> Although, it looks like it is not being honored currently. Try adding a printf >>>>>> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the >>>>>> type, start, and end of each resource range. >>>>> Actually, try this patch. Then I think you can use the host_mem_start tunable: >>>> I've tried it. With this patch host_mem_start tunable seems like makes >>>> effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are >>>> still not working. >>> Hmmm, I think I need to clear the completely bogus windows when we fail to >>> allocate the initial window. Try this (relative to the previous patches): >> Dmesg changed a bit, but still no luck: >> http://people.freebsd.org/~mav/newpcib/dmesg.next > > Oh, I'm dumb. 'w->base' should be set to 'max_address' and 'w->limit' should > be set to 0 to turn off the bogus windows like this: No luck: http://people.freebsd.org/~mav/newpcib/dmesg.next2 -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Wed Apr 27 15:01:05 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF2C7106566B; Wed, 27 Apr 2011 15:01:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A00A38FC21; Wed, 27 Apr 2011 15:01:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4676F46B43; Wed, 27 Apr 2011 11:01:05 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 795AC8A02C; Wed, 27 Apr 2011 11:01:04 -0400 (EDT) From: John Baldwin To: Alexander Motin Date: Wed, 27 Apr 2011 11:01:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104261146.39731.jhb@freebsd.org> <4DB73F1A.4000009@FreeBSD.org> In-Reply-To: <4DB73F1A.4000009@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104271101.01259.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Apr 2011 11:01:04 -0400 (EDT) Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:01:05 -0000 On Tuesday, April 26, 2011 5:54:34 pm Alexander Motin wrote: > John Baldwin wrote: > > On Tuesday, April 26, 2011 10:45:33 am Alexander Motin wrote: > >> John Baldwin wrote: > >>> On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote: > >>>> On 26.04.2011 00:21, John Baldwin wrote: > >>>>> On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: > >>>>>> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: > >>>>>>> On 19.04.2011 21:50, John Baldwin wrote: > >>>>>>>> I've already had at least one testing report that this fixes the issues with > >>>>>>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI > >>>>>>>> is enabled as this code re-discovers the original windows and programs them > >>>>>>>> correctly. More testing would be good however. > >>>>>>> I would like this helped my Acer TM6292 which also has alike problems > >>>>>>> with missing PCIe bridge resources, but unluckily it doesn't. > >>>>>>> > >>>>>>> Here is verbose dmesg when my system uses this dirty hack: > >>>>>>> http://people.freebsd.org/~mav/tm6292_pcie.patch > >>>>>>> to restore bridges resources to the pre-ACPI state: > >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.hacks > >>>>>>> > >>>>>>> Here is respective `pciconf -lvcb` output: > >>>>>>> http://people.freebsd.org/~mav/pciconf.hacks > >>>>>>> > >>>>>>> Here is dmesg with patches, but without NEW_PCIB: > >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib > >>>>>>> > >>>>>>> Here is dmesg with patches with NEW_PCIB: > >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.newpcib > >>>>>> Ah, your problem is we pick bad ranges when we alloc fresh resources for your > >>>>>> bridges. I am working on making that better for ACPI, but for now you can try > >>>>>> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. > >>>>>> > >>>>>> Although, it looks like it is not being honored currently. Try adding a printf > >>>>>> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the > >>>>>> type, start, and end of each resource range. > >>>>> Actually, try this patch. Then I think you can use the host_mem_start tunable: > >>>> I've tried it. With this patch host_mem_start tunable seems like makes > >>>> effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are > >>>> still not working. > >>> Hmmm, I think I need to clear the completely bogus windows when we fail to > >>> allocate the initial window. Try this (relative to the previous patches): > >> Dmesg changed a bit, but still no luck: > >> http://people.freebsd.org/~mav/newpcib/dmesg.next > > > > Oh, I'm dumb. 'w->base' should be set to 'max_address' and 'w->limit' should > > be set to 0 to turn off the bogus windows like this: > > No luck: > http://people.freebsd.org/~mav/newpcib/dmesg.next2 Ahh, I know what's wrong. I need to force MEMEN and/or IOEN in the bridge's command register when enabling a window. Here is an updated patch relative to pcib_window.patch (so it includes the previous patch to disable bogus windows): --- //depot/projects/pci/sys/dev/pci/pci_pci.c 2011-04-19 17:42:14.000000000 0000 +++ /home/jhb/work/p4/pci/sys/dev/pci/pci_pci.c 2011-04-19 17:42:14.000000000 0000 @@ -60,6 +60,7 @@ static int pcib_resume(device_t dev); static int pcib_power_for_sleep(device_t pcib, device_t dev, int *pstate); +static void pcib_write_windows(struct pcib_softc *sc, int mask); static device_method_t pcib_methods[] = { /* Device interface */ @@ -146,7 +147,20 @@ return (pw->valid && pw->base < pw->limit); } +/* + * XXX: If RF_ACTIVE did not also imply allocate a bus space tag and + * handle for the resource, we could pass RF_ACTIVE up to the PCI bus + * when allocating the resource windows and rely on the PCI bus driver + * to do this for us. + */ static void +pcib_activate_window(struct pcib_softc *sc, int type) +{ + + PCI_ENABLE_IO(device_get_parent(sc->dev), dev, type); +} + +static void pcib_alloc_window(struct pcib_softc *sc, struct pcib_window *w, int type, int flags, pci_addr_t max_address) { @@ -181,8 +195,12 @@ device_printf(sc->dev, "failed to allocate initial %s window: %#jx-%#jx\n", w->name, (uintmax_t)w->base, (uintmax_t)w->limit); + w->base = max_address; + w->limit = 0; + pcib_write_windows(sc, w->mask); return; } + pcib_activate_window(sc, type); error = rman_manage_region(&w->rman, rman_get_start(w->res), rman_get_end(w->res)); @@ -859,7 +877,7 @@ count = roundup2(count, 1ul << w->step); rid = w->reg; w->res = bus_alloc_resource(sc->dev, type, &rid, start, end, - count, flags); + count, flags & ~RF_ACTIVE); if (w->res == NULL) { if (bootverbose) device_printf(sc->dev, @@ -883,6 +901,7 @@ w->res = NULL; return (error); } + pcib_activate_window(sc, type); goto updatewin; } > > > -- > Alexander Motin > -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Apr 27 15:27:37 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3F7B1065672; Wed, 27 Apr 2011 15:27:37 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F25A18FC08; Wed, 27 Apr 2011 15:27:36 +0000 (UTC) Received: by bwz12 with SMTP id 12so2111284bwz.13 for ; Wed, 27 Apr 2011 08:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/xWqVCZmPZIPGYl3bcMVrs1ElihbUPRkeb6hcLGNF1g=; b=vRPx6fIPmxgXYxHti+Rd864C1ygVZCVQ9GBwAIEasUZ7TjTBPp0onXGmrkN4XtK4eY dWzFkuoGAJZRJ/lkkBxa4gzfvg1FVaeFWL3vMvUriZDnPoz51r94icas3yQuiesGEK0Z Z51EFBel0wPDFMzXi3fNYGoX51E7yzVHn8+eM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=duXBsXz8KdL72uApUv+gLQHMjSuTW7gSJMLzbx5teU3P46PuNZhLOLJ5fNGdSN84aB xSdNU8B/+Xq4mf9rgrwoa8TyRU4z2xCFiqd6LuLKn1y4YtnXwlwUYPc1iOXw8Uzrlyad I0yod+UBawn1H+Al8FtP++Frt/RzVuE+rTThk= Received: by 10.204.227.193 with SMTP id jb1mr2122485bkb.157.1303918055625; Wed, 27 Apr 2011 08:27:35 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d11sm493180bka.19.2011.04.27.08.27.33 (version=SSLv3 cipher=OTHER); Wed, 27 Apr 2011 08:27:34 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB835E4.5060300@FreeBSD.org> Date: Wed, 27 Apr 2011 18:27:32 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <201104261146.39731.jhb@freebsd.org> <4DB73F1A.4000009@FreeBSD.org> <201104271101.01259.jhb@freebsd.org> In-Reply-To: <201104271101.01259.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:27:37 -0000 On 27.04.2011 18:01, John Baldwin wrote: > On Tuesday, April 26, 2011 5:54:34 pm Alexander Motin wrote: >> John Baldwin wrote: >>> On Tuesday, April 26, 2011 10:45:33 am Alexander Motin wrote: >>>> John Baldwin wrote: >>>>> On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote: >>>>>> On 26.04.2011 00:21, John Baldwin wrote: >>>>>>> On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: >>>>>>>> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: >>>>>>>>> On 19.04.2011 21:50, John Baldwin wrote: >>>>>>>>>> I've already had at least one testing report that this fixes the issues with >>>>>>>>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI >>>>>>>>>> is enabled as this code re-discovers the original windows and programs them >>>>>>>>>> correctly. More testing would be good however. >>>>>>>>> I would like this helped my Acer TM6292 which also has alike problems >>>>>>>>> with missing PCIe bridge resources, but unluckily it doesn't. >>>>>>>>> >>>>>>>>> Here is verbose dmesg when my system uses this dirty hack: >>>>>>>>> http://people.freebsd.org/~mav/tm6292_pcie.patch >>>>>>>>> to restore bridges resources to the pre-ACPI state: >>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.hacks >>>>>>>>> >>>>>>>>> Here is respective `pciconf -lvcb` output: >>>>>>>>> http://people.freebsd.org/~mav/pciconf.hacks >>>>>>>>> >>>>>>>>> Here is dmesg with patches, but without NEW_PCIB: >>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib >>>>>>>>> >>>>>>>>> Here is dmesg with patches with NEW_PCIB: >>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.newpcib >>>>>>>> Ah, your problem is we pick bad ranges when we alloc fresh resources for your >>>>>>>> bridges. I am working on making that better for ACPI, but for now you can try >>>>>>>> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. >>>>>>>> >>>>>>>> Although, it looks like it is not being honored currently. Try adding a printf >>>>>>>> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the >>>>>>>> type, start, and end of each resource range. >>>>>>> Actually, try this patch. Then I think you can use the host_mem_start tunable: >>>>>> I've tried it. With this patch host_mem_start tunable seems like makes >>>>>> effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are >>>>>> still not working. >>>>> Hmmm, I think I need to clear the completely bogus windows when we fail to >>>>> allocate the initial window. Try this (relative to the previous patches): >>>> Dmesg changed a bit, but still no luck: >>>> http://people.freebsd.org/~mav/newpcib/dmesg.next >>> >>> Oh, I'm dumb. 'w->base' should be set to 'max_address' and 'w->limit' should >>> be set to 0 to turn off the bogus windows like this: >> >> No luck: >> http://people.freebsd.org/~mav/newpcib/dmesg.next2 > > Ahh, I know what's wrong. I need to force MEMEN and/or IOEN in the bridge's > command register when enabling a window. Here is an updated patch relative > to pcib_window.patch (so it includes the previous patch to disable bogus > windows): Hurray! You did it! Congratulations! :) After changing PCI_ENABLE_IO(device_get_parent(sc->dev), dev, type); to PCI_ENABLE_IO(device_get_parent(sc->dev), sc->dev, type); to fix the build I've got working devices: http://people.freebsd.org/~mav/newpcib/dmesg.working By the way, it also works without setting host_mem_start. Just uses different addresses for bge, iwn and the bridges. Thank you! -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Wed Apr 27 19:44:50 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2A30106564A; Wed, 27 Apr 2011 19:44:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6508FC17; Wed, 27 Apr 2011 19:44:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 14A4E46B2D; Wed, 27 Apr 2011 15:44:49 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9E2258A01B; Wed, 27 Apr 2011 15:44:48 -0400 (EDT) From: John Baldwin To: Alexander Motin Date: Wed, 27 Apr 2011 13:32:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104271101.01259.jhb@freebsd.org> <4DB835E4.5060300@FreeBSD.org> In-Reply-To: <4DB835E4.5060300@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104271332.08621.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Apr 2011 15:44:48 -0400 (EDT) Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 19:44:50 -0000 On Wednesday, April 27, 2011 11:27:32 am Alexander Motin wrote: > On 27.04.2011 18:01, John Baldwin wrote: > > On Tuesday, April 26, 2011 5:54:34 pm Alexander Motin wrote: > >> John Baldwin wrote: > >>> On Tuesday, April 26, 2011 10:45:33 am Alexander Motin wrote: > >>>> John Baldwin wrote: > >>>>> On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote: > >>>>>> On 26.04.2011 00:21, John Baldwin wrote: > >>>>>>> On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: > >>>>>>>> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: > >>>>>>>>> On 19.04.2011 21:50, John Baldwin wrote: > >>>>>>>>>> I've already had at least one testing report that this fixes the issues with > >>>>>>>>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI > >>>>>>>>>> is enabled as this code re-discovers the original windows and programs them > >>>>>>>>>> correctly. More testing would be good however. > >>>>>>>>> I would like this helped my Acer TM6292 which also has alike problems > >>>>>>>>> with missing PCIe bridge resources, but unluckily it doesn't. > >>>>>>>>> > >>>>>>>>> Here is verbose dmesg when my system uses this dirty hack: > >>>>>>>>> http://people.freebsd.org/~mav/tm6292_pcie.patch > >>>>>>>>> to restore bridges resources to the pre-ACPI state: > >>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.hacks > >>>>>>>>> > >>>>>>>>> Here is respective `pciconf -lvcb` output: > >>>>>>>>> http://people.freebsd.org/~mav/pciconf.hacks > >>>>>>>>> > >>>>>>>>> Here is dmesg with patches, but without NEW_PCIB: > >>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib > >>>>>>>>> > >>>>>>>>> Here is dmesg with patches with NEW_PCIB: > >>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.newpcib > >>>>>>>> Ah, your problem is we pick bad ranges when we alloc fresh resources for your > >>>>>>>> bridges. I am working on making that better for ACPI, but for now you can try > >>>>>>>> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. > >>>>>>>> > >>>>>>>> Although, it looks like it is not being honored currently. Try adding a printf > >>>>>>>> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the > >>>>>>>> type, start, and end of each resource range. > >>>>>>> Actually, try this patch. Then I think you can use the host_mem_start tunable: > >>>>>> I've tried it. With this patch host_mem_start tunable seems like makes > >>>>>> effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are > >>>>>> still not working. > >>>>> Hmmm, I think I need to clear the completely bogus windows when we fail to > >>>>> allocate the initial window. Try this (relative to the previous patches): > >>>> Dmesg changed a bit, but still no luck: > >>>> http://people.freebsd.org/~mav/newpcib/dmesg.next > >>> > >>> Oh, I'm dumb. 'w->base' should be set to 'max_address' and 'w->limit' should > >>> be set to 0 to turn off the bogus windows like this: > >> > >> No luck: > >> http://people.freebsd.org/~mav/newpcib/dmesg.next2 > > > > Ahh, I know what's wrong. I need to force MEMEN and/or IOEN in the bridge's > > command register when enabling a window. Here is an updated patch relative > > to pcib_window.patch (so it includes the previous patch to disable bogus > > windows): > > Hurray! You did it! Congratulations! :) > > After changing > PCI_ENABLE_IO(device_get_parent(sc->dev), dev, type); > to > PCI_ENABLE_IO(device_get_parent(sc->dev), sc->dev, type); > to fix the build I've got working devices: > http://people.freebsd.org/~mav/newpcib/dmesg.working > > By the way, it also works without setting host_mem_start. Just uses > different addresses for bge, iwn and the bridges. > > Thank you! Great! Barring any objections I'll start committing this. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Apr 28 13:43:37 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9F8106566B; Thu, 28 Apr 2011 13:43:37 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id E3A328FC15; Thu, 28 Apr 2011 13:43:36 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155804.dip.t-dialin.net [91.21.88.4]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id C726B844016; Thu, 28 Apr 2011 15:43:22 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id EE3C61170; Thu, 28 Apr 2011 15:43:19 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p3SDhJjY096529; Thu, 28 Apr 2011 15:43:19 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 28 Apr 2011 15:43:19 +0200 Message-ID: <20110428154319.23661m78gvvdqmsk@webmail.leidinger.net> Date: Thu, 28 Apr 2011 15:43:19 +0200 From: Alexander Leidinger To: David Schultz References: <20110426154645.GA67273@zim.MIT.EDU> In-Reply-To: <20110426154645.GA67273@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: C726B844016.AFE36 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0, required 6, autolearn=disabled) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1304603003.03828@Cx0dsh3ogc8/7bGXybVdBg X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 28 Apr 2011 13:51:25 +0000 Cc: Rui Paulo , "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:43:37 -0000 Quoting David Schultz (from Tue, 26 Apr 2011 11:46:45 -0400): > On Wed, Aug 18, 2010, Rui Paulo wrote: >> Hi, >> I've been chatting with the ICC ex-users and they seem to be ok >> with the removal of the ICC bits from share/mk and other places. >> The reason is that it doesn't work and no one has volunteered to >> fix it for many years. This seems to indicate that the interest in >> ICC is low. >> If there's anyone against this, speak now or forever be silent. :-) > > For what it's worth, I still occasionally use icc for simple > tasks-- mainly as a reference for code generation, since it > produces reasonable output in many cases where gcc does not. > As I recall, making it work required minimal changes... possibly > just making sure __va_list gets defined in _types.h. I have > the following in one of my trees, although this is obviously > not the right fix. It depends if you want to hide the problem on all other compilers or not. I would prefer to not hide the problem. Bye, Alexander. -- Volley Theory: It is better to have lobbed and lost than never to have lobbed at all. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137