> Date: Wed, 23 Jul 2025 20:06:38 +0200 > From: Peter Hessler <phess...@theapt.org> > > I just got a new-to-me server, and are trying out various parts of it. > While I have zero intentions of using the bge(4) nic, it gives me this > error when I give it commands. > > bge0: APE lock 0 request failed! request = 0x8400[0x1000], status = > 0x8420[0x0001] > bge0: APE lock 0 request failed! request = 0x8400[0x1000], status = > 0x8420[0x0001] > bge0: APE lock 0 request failed! request = 0x8400[0x1000], status = > 0x8420[0x0001] > bge0: APE lock 0 request failed! request = 0x8400[0x1000], status = > 0x8420[0x0001] > bge0: APE lock 0 request failed! request = 0x8400[0x1000], status = > 0x8420[0x0001]
The joys of Dell "value-add" firmware ;). To get a sense of what the APE is, the following article provides some insights: https://www.devever.net/~hl/ortega The TLDR is that APE is what steals packets and feeds them to the BCM. I think it is running even when the machine is powered off. Our bge(4) driver makes some attempt to be nice to the APE and properly share the PHY such that APE can continue to steal packets. For some reason this fails. Could be that they changed the firmware interface. Or maybe there is a subtle bug in our driver. > The /etc/hostname.bge0 is trivial: > inet autoconf > inet6 autoconf > inet6 -temporary > up > > And both address families get an address, IPv4 and IPv6 work just fine > after a moment. I'm not able to do a speed-test, but can get decent > throughput on it, ~320Mbps from a wifi client. The APE probably brings up the PHY and puts it in a usable state. So things work. But you probably can't reconfigure the PHY, i.e. if you wanted to do run at 100baseTX. > Full dmesg is attached. > > > -- > The truth of a proposition has nothing to do with its credibility. > And vice versa. > > [2:text/plain Show Save:dmesg.txt (20kB)] >
