From owner-freebsd-current Sun Mar 31 2:59:46 2002 Delivered-To: freebsd-current@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id BC63A37B419; Sun, 31 Mar 2002 02:59:42 -0800 (PST) Received: from pool0047.cvx22-bradley.dialup.earthlink.net ([209.179.198.47] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16rd3l-000713-00; Sun, 31 Mar 2002 02:59:41 -0800 Message-ID: <3CA6EC01.2878918B@mindspring.com> Date: Sun, 31 Mar 2002 02:59:13 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Alfred Perlstein , scott_long@btc.adaptec.com, mark_salyzyn@adaptec.com, obrien@freebsd.org, current@freebsd.org Subject: Re: asr can not map memory? References: <200203311012.g2VACOc04299@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > Yeah, you do. I fully understood _that_ context; I think Mike > > was talking about other context. It's pretty clear to me that > > ranges ought to be per bridge chipset, rather than global... I > > thought that that was what the option was working around: that > > they were not. > > I can't imagine how you came to this conclusion. You won't get it from > reading the code, or from understanding how PCI works. Maybe you need > sleep too. I got it from assuming that reading the code didn't tell me how the code was supposed to work, because if it had, then this would never had been a discussion, because the code would always do the right thing. 8-). My 1.0 copy of the PCI-PCI bridge documentation doesn't say that what Alfred's system is doing is bad; maybe it's just outdated. > The problem is twofold: > > - The code is broken, it fails to take into account both prefetched and > non-prefetched bridge mappings. It also appears to miscompute the > start of one of the attempted range accesses. Cool... this is the bug description I was fishing for here. > - There is anecdotal evidence that some bridges pass ranges other than > those advertised in their mappings, so even if the first problem is > resolved, enforcing correctness may result in occasional lossage. This sounds like a job for a "panic: anecdotal is real!" that Alfred could jam into the code, since he has the magic hardware. > And, since you ask, the whole reason behind having this code in the > first place is that we need to be able to correctly assign resources for > devices behind bridges. Yeah; it was the "it not doing it for Alfred's weird hardware" thing that threw me off. 8-) 8-). > I got run over by a car last time I worked on this code. Time for > someone else to pick it up. Oh yeah, we're *all* going to jump on hacking that code, now that you told us it's cursed! }B^D. Alfred, since you have the hardware that can (maybe) prove the anedote real, and can demonstrably show that Mike's problem #1 is fixed, once it's fixed... care to brave the curse? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message