msk dev problem with acpi

Fri Aug 24 10:17:44 PDT 2007

On Thursday 23 August 2007 07:39:40 pm Nate Lawson wrote:
> William Grzybowski wrote:
> > On 8/21/07, *William Grzybowski* <william88 at gmail.com
> > <mailto:william88 at gmail.com>> wrote:
> > 
> >     On 8/21/07, *Nate Lawson* <nate at root.org <mailto:nate at 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 at 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.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: <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.

-- 
John Baldwin