From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 24 17:17:44 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7017016A420 for ; Fri, 24 Aug 2007 17:17:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 3622413C47E for ; Fri, 24 Aug 2007 17:17:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8k) with ESMTP id 205083177-1834499 for multiple; Fri, 24 Aug 2007 13:17:28 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7OHHFvB030448; Fri, 24 Aug 2007 13:17:16 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Fri, 24 Aug 2007 12:41:38 -0400 User-Agent: KMail/1.9.6 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> <46CE1ABC.2090008@root.org> In-Reply-To: <46CE1ABC.2090008@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708241241.39187.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 24 Aug 2007 13:17:16 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4053/Fri Aug 24 11:41:12 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, William Grzybowski Subject: Re: msk dev problem with acpi X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2007 17:17:44 -0000 On Thursday 23 August 2007 07:39:40 pm Nate Lawson wrote: > William Grzybowski wrote: > > On 8/21/07, *William Grzybowski* > > wrote: > > > > On 8/21/07, *Nate Lawson* > wrote: > > > > Sean Bruno wrote: > > > William Grzybowski wrote: > > >> Hi! > > >> > > >> I'm having a problem with my marvell yukon ethernet when i boot my > > >> -CURRENT > > >> with the ACPI enable, it goes fine when acpi is off... > > >> I already tried to talk with the msk driver developer and he > > has now idea > > >> why it is happening and told me to try something here... > > >> > > >> dmesg error: > > >> mskc0: irq 16 at > > device 0.0 > > >> on pci2 > > >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > >> mskc0: unknown device: id=0x00, rev=0x00 > > >> device_attach: mskc0 attach returned 6 > > >> > > >> the card: > > >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab > > rev=0x14 > > >> hdr=0x00 > > >> vendor = 'Marvell Semiconductor (Was: Galileo > > Technology Ltd)' > > >> device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' > > >> class = network > > >> subclass = ethernet > > >> > > >> I am also attaching the acpidump and dmesg , > > >> If it can't be a apci isue, please, let me know. > > >> > > > I don't see any attachments in this email. Can you try > > resending to the > > > list? > > > > > > > Attachments that are too big are stripped. Please post a URL to the > > acpidump instead. > > > > -Nate > > > > > > It has just ~30kb, anyway, i am posting the links... > > http://www.inf.ufpr.br/wg06/acpi.gz > > > > http://www.inf.ufpr.br/wg06/dmesg.gz > > > > > > > > > > Hi, i was testing a verbose boot with acpi and without acpi, i noted a > > "requested unsupported memory range" with acpi... > > > > verbose dmesg with acpi: > > mskc0: irq 16 at device 0.0 on pci2 > > pcib1: mskc0 requested unsupported memory range 0-0xffffffff (decoding > > 0-0, 0-0) > > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000 > > mskc0: unknown device: id=0xff, rev=0x0f > > > > and without acpi: > > mskc0: port 0x2000-0x20ff mem > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 > > mskc0: MSI count : 2 > > mskc0: attempting to allocate 2 MSI vectors (2 supported) > > > > Is that relevant? Maybe a issue in the msk driver allocation and not in > > acpi? > > Should I send all the verbose boots with and without acpi? > > > > Thanks, bye. > > I looked at the dmesg and ASL more carefully. It appears that PCI0 is > the only bus described in the ASL. Every device except mskc0 is on > pci0, so they all work. Yes, the ASL doesn't descend into the bridges. However, since disabling ACPI gives resources to the msk0 device it means that the BIOS is writing values into the BAR's for the bridge and the mskc0 device during POST, but that some _REG or _INI routine during ACPI enabling is clearing those BAR's for some reason. > --- > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 28.0 on pci0 > pci2: on pcib1 > mskc0: irq 16 at device 0.0 on pci2 > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > mskc0: unknown device: id=0xff, rev=0x0f > device_attach: mskc0 attach returned 6 > --- > > At this point, pci0 has a bunch of resources set via the _CRS method on > Device (PCI0). However, since there is no definition for pcib1, there > are no resources to assign to pcib1 and thus mskc0. Actually, we are too dumb to do that (on my list, but low). Right now Host-PCI bridges just try to alloc anything that's free, but with some tunables to limit the range. So the _CRS for the host bridges doesn't matter for how FreeBSD currently does things. > --- > pcib2: irq 17 at device 28.1 on pci0 > pci3: on pcib2 > pci3: at device 0.0 (no driver attached) > pcib3: irq 18 at device 28.2 on pci0 > pci4: on pcib3 > --- > > This is interesting. It appears to be a second ethernet adapter and > another PCI-PCI bridge that is empty? Yep. > So the question is what to do in the first case -- it seems easiest that > if a bridge has no resources, just pass everything up to the parent. Is > that what you're recommending, John? Well, sorta. The bridge needs to allocate resources and then hand them down to its children, but while this simple case is doable, the harder case is when you have multiple devices and no bridge resources, or you have bridge resources that aren't enough for all the devices you have, etc. Really fixing this requires that we do an early pass assigning resources to busses before any "leaf" drivers probe (but after all the bridges have probed), but for that we really need the multi-pass new-bus stuff. > But it's not clear who is erasing > the boot-time BARs in the acpi case. There is no method that appears to > reference pcib1 unless writing directly to its config space. It would > take a lot of analysis to figure that out statically, but should be easy > at runtime by just hacking in some printfs. Yeah, it's not obvious. I wonder if it's caused by a power reset? There is that \_SB_.PHRS routine (or whatever it's called) that seems to manage powering up and down devices? I noticed during _INI that if none of the _OSI stuff works (though we should be succeeding the _OSI("Linux") call) it appears to power off something (I think). Also, there are places that write into the config space of the bridges like RP01 (the parent for mskc0) (but below the BARs) when certain GPE's fire. Perhaps one of those registers causes a reset of that device, or perhaps one of them is actually part of a power management capability, etc. -- John Baldwin