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