Atom Board ACPI API MOPNV10J failing since 9.1

[David Shane Holden]

On 01/14/14 08:23, John Baldwin wrote:
>
> It's a resource conflict in the BIOS-assigned resources.
>
> It would be really handy if you could get the output of 'devinfo -u'
>  and 'devinfo -rv' when it works, and a verbose dmesg when it is
> broken.
>

So, I've been trying to understand what exactly is causing this, but
since I'm no expert hopefully it makes sense to you.  There appears to
be a couple of issues here.

I've uploaded a 'failed' and 'working' directory with diffs between
them. The only thing I've changed between the two is to switch the
chipset from IDE to AHCI in the BIOS and booting into a 10.0-RC5 install.

https://googledrive.com/host/0B0OQnKtejJEMRTJCYlNyWnRLaW8/

The few things that I've noticed is that in IDE mode, the MAC address on
the re0 interface seems to get munged.  Even after switching it back to
AHCI mode and hard resetting the machine the MAC will sometimes stick to
the interface and the only way to get it to reset is to set the BIOS
jumper on the motherboard.  The way it munges it is somewhat interesting
too.

munged: ef:27:ad:09:ef:48
munged: ff:be:03:de:ff:be
munged: 00:be:0e:de:f6:be
actual: 00:27:0e:09:f6:48

-re0: Chip rev. 0x5c800000
-re0: MAC rev. 0x00200000
+re0: Chip rev. 0x28000000
+re0: MAC rev. 0x00100000

This here seems very unusual, which might be the root cause of the MAC
problem. 0x5c800000 maps to RL_HWREV_8411B while 0x28000000 maps to
RL_HWREV_8168D. So I'm guessing the driver is trying to use the card as
if it's an 8411.  It'll continue to somewhat work if it doesn't roll a
multicast mac but it's still spotty.

I don't see how this would cause all the pcib allocation failures though
that are in the dmesg output.  You mention that it's a resource conflict
in the BIOS, but I'm not seeing where it could be.  Could these
allocation failures also explain why my Atheros card doesn't get
assigned an irq?

I'm all for chalking this up to a subpar BIOS that ships with this
board, but if it might be a problem in FreeBSD that could rear its ugly
head somewhere else I'd like to help track down what's causing it.  I'll
try to find some time to test a Debian live CD and see how Linux handles
it tomorrow.