msk dev problem with acpi

[Nate Lawson]

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.

---
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.

---
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?

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