Atheros813x is detected and appears to be loaded correctly, but no connection is possible

Feedback Hardware
1

Hello folks,

I’ve got an HP Mini 110 I’ve installed Haiku on and well it seems to generally be working really well, the ethernet connection is a no-go at the moment.

The ethernet controller is correctly identified, I can see the adapter in ifconfig, and I don’t see any obvious errors in the systemlog (though Haiku is new to me), yet I am unable to actually connect to anything. I’ve tried several different networks and cables thinking maybe there was a physical problem, but had no luck there either.

I’m wondering if such issues are known (I couldn’t find any situations like this).

You can see the systemlog and some other details in the terminal output I’ve uploaded as a text file: http://muezza.ca/f/haiku_syslog.txt

Thanks :slight_smile:

2

The Broadcom 43xx WiFi driver is a known issue
https://dev.haiku-os.org/ticket/6474
Wired network should be working. I have the same laptop myself.

3

Yes, but this is about atheros813x driver. This is the only known issue https://dev.haiku-os.org/ticket/16978

4

Just a quick note, I wanted to eliminate a hardware problem so I booted a live linux CD just now and had no issues.

Here is what I’m seeing in the UI if it’s helpful at all:


5

The one ticket @Diver linked to does not appear to be the problem you are having. Actually I don’t see any errors in your syslog (related to this.)

It is very strange that the network is not working for you, when it is for @vidrep on the same hardware… Could you try a nightly build instead?

6

My Mini 110 is using an NVIDIA MCP79 Ethernet and Broadcom BCM4312 WiFi. So, apparently different hardware on the same HP laptop.

7

No change in behaviour under hrev55602.

8

Maybe try installing FreeBSD and see if works there? If it does that would probably rule out the driver itself.

Also, I’m not sure where the best place is to look, but you might see if there any log messages occurring when you try to insert the cable. Does the port itself have any lights on it and do they illuminate as expected?

9

I know this thread is a few years old now, and while I don’t like to necrobump, I am facing the same problem on a HP mini 110 (or I think it’s a 110). It’s an E1-1500 based computer that was donated to me and I’m trying to find a good light OS to run on it.

In my case the atheros interface is detected by the kernel but I don’t see it in ifconfig (beta5). But the PHY isn’t working. The kernel log is spammed with phy read and write timeouts, reloading EEPROM timeouts, and finally “attaching PHYs failed” and the device gets unreserved.

my_photo-15
my_photo-151920×1080 294 KB

10

my_photo-16
my_photo-161920×1080 225 KB

11

Might want to open a ticket at https://dev.haiku-os.org with the full system log

12

Great, thanks. Ticket opened: #19190 (Atheros AR8152 V2.0 PHY errors) – Haiku

1 Like
13

4294967288 Tx FIFO : 4294967288 Rx FIFO

This just seems like an absurdly high/impossible value for the size of a FIFO.

4294967288 bytes would be ~4096 MiB

Maybe there is no FIFO or it’s being detected/setup incorrectly?

ASPM L0s/L1 enabled

Is it possible the ethernet interface hardware is dropping into a low-power state and Haiku is failing to wake it up again and re-initialize it as needed?

Perhaps forcing it to stay in L0 or at least not enabling ASPM for it would “fix” the problem.

ASPM (Wikipedia)

Question

Inquire about X10SAE BIOS options - What is ASPM mode L0/L0s/L1/L0sL1

Answer

L0 – All PCI Express transactions and other operations are enabled.

L0s – A low resume latency, energy saving “standby” state.

L1 – Higher latency, lower power “standby” state (optional).

L0sL1 - Activate both L0s and L1 support.
^ link

P.S.

Does FreeBSD correctly identify your hardware as an Atheros 8152 V2.0? Is there any way to tell if it ever enters a lower power state?

It looks like “phy write timeout” messages could originate from these three function calls (if_alc.c):

https://cgit.freebsd.org/src/tree/sys/dev/alc/if_alc.c?h=releng/14.1

static uint32_t
alc_mii_writereg_813x(struct alc_softc *sc, int phy, int reg, int val)

static uint32_t
alc_mii_writereg_816x(struct alc_softc *sc, int phy, int reg, int val)
{

static uint32_t
alc_miiext_writereg(struct alc_softc *sc, int devaddr, int reg, int val)

And “phy read timeout” from these two:

static uint32_t
alc_mii_readreg_813x(struct alc_softc *sc, int phy, int reg)

static uint32_t
alc_mii_readreg_816x(struct alc_softc *sc, int phy, int reg)
1 Like
14

Incidentally:

FreeBSD 14.1R – /sys/dev/alc/if_alc.c

1144 KERN: [atheros813x] (alc) attaching PHYs failed
3129 KERN: [atheros813x] (alc) attaching PHYs failed
4946 KERN: [atheros813x] (alc) attaching PHYs failed
6773 KERN: [atheros813x] (alc) attaching PHYs failed
syslog.txt on Ticket #19190 – Attachment – Haiku

This message appears in the FreeBSD driver inside of

static int alc_attach(device_t dev)

in this section

    /* Set up MII bus. */
	error = mii_attach(dev, &sc->alc_miibus, ifp, alc_mediachange,
	    alc_mediastatus, BMSR_DEFCAPMASK, sc->alc_phyaddr, MII_OFFSET_ANY,
	    MIIF_DOPAUSE);
	if (error != 0) {
		device_printf(dev, "attaching PHYs failed\n");
		goto fail;
	}

	ether_ifattach(ifp, sc->alc_eaddr);

which jumps past all the other device attach code to:

fail:
	if (error != 0)
		alc_detach(dev);

	return (error);

So if device attachment fails, it is immediately detached!

And inside of

static int alc_detach(device_t dev)

The interface’s PHY will be powered down.

I would speculate that something could be wonky in the FreeBSD network compatibility layers…