From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 23:39:47 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 425BF16A417 for ; Thu, 23 Aug 2007 23:39:47 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 18B7E13C457 for ; Thu, 23 Aug 2007 23:39:46 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 22775 invoked from network); 23 Aug 2007 23:39:48 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 23 Aug 2007 23:39:48 -0000 Message-ID: <46CE1ABC.2090008@root.org> Date: Thu, 23 Aug 2007 16:39:40 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: William Grzybowski References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <46CB2097.5000706@miralink.com> <46CB28AF.5080506@root.org> <632825b40708211116g1c11612aj86163495e6a32e97@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> In-Reply-To: <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org 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: Thu, 23 Aug 2007 23:39:47 -0000 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. --- 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. --- 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? 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? 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. -Nate