From owner-svn-src-all@FreeBSD.ORG Wed Jun 27 12:22:48 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC4C010657AB; Wed, 27 Jun 2012 12:22:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD9EB8FC12; Wed, 27 Jun 2012 12:22:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C3090B922; Wed, 27 Jun 2012 08:22:47 -0400 (EDT) From: John Baldwin To: Marius Strobl Date: Wed, 27 Jun 2012 07:47:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201206131504.q5DF4opt031336@svn.freebsd.org> <201206251424.24621.jhb@freebsd.org> <20120626211445.GB63893@alchemy.franken.de> In-Reply-To: <20120626211445.GB63893@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206270747.37859.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 08:22:47 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r237008 - head/sys/dev/pci X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:22:49 -0000 On Tuesday, June 26, 2012 5:14:45 pm Marius Strobl wrote: > Yes, it does but switching to positive decoding nevertheless is > problematic in this case. According to the PCI 2.3 specification, > a child wanting its addresses to be decoded subtractively needs > to provide special DEVSEL# behavior. It seems that it should work > for a bridge to actually positively decoding such transactions, > but I'm not familiar with the physical layer of PCI and thus not > sure. On the other hand, both the PCI-ISA and PCI-PCI bridges > in question are ALi/ULi crap and based on fun I had with their > chips in the past, I also wouldn't be surprised their again being > a magic bit in the configuration space needing to be set to make > this work. Unfortunately, I don't have a datasheet for this > M5249 PCI-PCI bridge. If we'd implement a tunable for changing > the decoding of subtractive bridges, the way to go would seem to > be to have it off by default in order to preserve pre-NEW_PCIB/ > r237008 as at this time it's unknown how many bridges are > affected. If you'd want to keep the new/current behavior by > default, introducing something like a PCIB_SUBTRACTIVE_FORCED > flag along a PCI_QUIRK_SUB_FORCED quirk in addition to a > tuneable defaulting to on probably would be a good idea. Hmm. I'm fine with your original change going in then. I am not really sure what the right way to handle this is, and just leaving the windows alone on subtractive bridges is probably safest. -- John Baldwin