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