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