Marvell 88E8038 PCI-E controller doesn't appear as device with acpi enabled

[John Baldwin]

On Monday 17 November 2008 01:20:43 pm Daniel Levine wrote:
> It doesn't work on NetBSD either, though, nor Open, Dragonfly, etc. Is
> this bug common to all BSD flavors? Is there any workaround?

Yes.  It's more a missing feature than a bug strictly speaking.  It's the same 
exact problem as PNP OS=YES.  Basically, *BSD still depend on the BIOS to do 
most of the resource allocation for devices.

> On 11/17/08, John Baldwin <jhb at freebsd.org> wrote:
> > On Monday 17 November 2008 10:30:00 am Daniel Levine wrote:
> >> On my Acer Aspire 3680-2633, the Marvell ethernet controller, which
> >> appears like so under Linux lspci:
> >>
> >> 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8038
> >> PCI-E Fast Ethernet Controller (rev 14)
> >>
> >> Does not show up at all with acpi enabled - no msk0 in ifconfig -a, no
> >> device in /dev, nothing. With acpi disabled, it appears and works
> >> fine. This is the case under both FreeBSD 6.4 and 7.0, as well as
> >> OpenBSD 4.4 and NetBSD 4.0.1.
> >>
> >> The acpidump output is available here:
> >>
> >> http://www.mediafire.com/?g4zin4s99b1
> >>
> >> If MediaFire isn't cooperating, notify me and I'll upload again somewhere
> > else.
> >>
> >> I've also attached the outputs of dmesg with acpi enabled and
> >> disabled, and the output of 'sysctl hw.acpi'. Hopefully those will be
> >> of some help.
> >>
> >> Also, a brief note - the reason all the filesystems are showing as
> >> unclean in dmesg-noacpi.txt is that my (FreeBSD 6.4) system panicked
> >> when I removed my USB stick. I've heard this was a known bug in beta
> >> versions of 7.0, but haven't heard of it happening in 6.4; I'm not
> >> sure if it's that bug again, or just a further result of my ACPI
> >> messing up.
> >
> > Your devices are there, they just can't allocate resources.  This is more 
of
> > a
> > FreeBSD bug in that we don't support fully allocating I/O port and memio
> > resources for PCI devices from scratch, at least we don't handle 
allocating
> > resources from scratch for devices behind PCI-PCI bridges.
> >
> > --
> > John Baldwin
> >
> 



-- 
John Baldwin