Date: Fri, 24 Aug 2007 18:30:59 -0300 From: "William Grzybowski" <william88@gmail.com> To: "John Baldwin" <jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi Message-ID: <632825b40708241430u31f4eebbm671958abb5ec258c@mail.gmail.com> In-Reply-To: <200708241241.39187.jhb@freebsd.org> References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> <46CE1ABC.2090008@root.org> <200708241241.39187.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/24/07, John Baldwin <jhb@freebsd.org> wrote: > > On Thursday 23 August 2007 07:39:40 pm Nate Lawson wrote: > > William Grzybowski wrote: > > > On 8/21/07, *William Grzybowski* <william88@gmail.com > > > <mailto:william88@gmail.com>> wrote: > > > > > > On 8/21/07, *Nate Lawson* <nate@root.org <mailto:nate@root.org>> > 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: <Marvell Yukon 88E8038 Gigabit Ethernet> 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/acpi.gz>; > > > http://www.inf.ufpr.br/wg06/dmesg.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: <Marvell Yukon 88E8038 Gigabit Ethernet> irq 16 at device 0.0on > 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: <Marvell Yukon 88E8038 Gigabit Ethernet> 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: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 > > pci0: <ACPI PCI bus> on pcib0 > > pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0 > > pci2: <ACPI PCI bus> on pcib1 > > mskc0: <Marvell Yukon 88E8038 Gigabit Ethernet> 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: <ACPI PCI-PCI bridge> irq 17 at device 28.1 on pci0 > > pci3: <ACPI PCI bus> on pcib2 > > pci3: <network, ethernet> at device 0.0 (no driver attached) > > pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0 > > pci4: <ACPI PCI bus> 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. If I am wrong, tell me, but for what i can understand is it: When the system boots it keeps probing the devices and fulling the resources on pci bridge 0, but actually freebsd can't handle it and keep it going on a second pci bridge bar, is that right or a sorta of it? Well, there is anyway to pass trough it discarding some useless devices to use this bar "BAR" just for useful devices while you guys can't implement it? Thanks, bye. -- > John Baldwin > -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?632825b40708241430u31f4eebbm671958abb5ec258c>