On Wed, Nov 08, 2017 at 08:53:34PM +0200, Lars Noodén wrote:
> The hardware is an EdgeRouter PoE and the crash can be triggered
> consistently with the following (or possibly any other ipv4 address)
> line in ksh for cnmac2. cnmac0 and cmnac1 seem unable to cause the
> crash. cnmac3 is not found.
Below I am quoting a message I got from visa@ back in June when I
reported the same problem in private.
I don't have access to a EdgeRouter PoE anymore so I could never
test these diffs. Could you test them?
visa@ wrote to me:
On Thu, Jun 08, 2017 at 01:03:41PM +0200, Stefan Sperling wrote:
> Hi Visa,
>
> On an EdgeRouter PoE I am seeing an issue where the cnmac2 interface does
> not attach a PHY, and 'ifconfig cnmac2 up' crashes the box.
>
> This happens with both 6.1 and -current (see below).
>
> Is this expected?
Yes, the internal port connected to the builtin switch does not work.
> Is it just that the PHY is not supported yet?
Very likely a new driver is needed. Another question is how the control
interface of the switch chip is connected to the main SoC.
The MDIO register that cnmac(4) tries to use is clearly wrong as no PHY
is found. Such a register is not even mentioned in the ubnt_e101.dts
file in Ubiquiti's GPL distribution.
> # sh /etc/netstart cnmac2
>
> Trap cause = 13 Frame 0x980000000e5eba18
> Trap PC 0xffffffff813d5a9c RA 0xffffffff813d59cc fault 0x22898e75d0
> 0xffffffff813d5a80 (6,9001180008001060,60,e) ra 0xffffffff813d59cc sp
> 0x980000000e5ebb70, sz 0
> 0xffffffff813d5980 (6,9001180008001060,60,e) ra 0xffffffff813d5b98 sp
> 0x980000000e5ebb70, sz 48
> 0xffffffff813d5b88 (6,9001180008001060,60,e) ra 0x0 sp 0x980000000e5ebba0,
> sz 0
> User-level: pid 33307
> stopped on non ddb fault
> Stopped at 0xffffffff813d5a9c: teq v1,zero
This could happen because of a division by zero in
cn30xxgmx_rgmii_speed(). Could you try the (ugly) fix below?
A prebuilt kernel with the fix is in cvs:~visa/bsd.speedfix .
Index: arch/octeon/dev/cn30xxgmx.c
===================================================================
RCS file: src/sys/arch/octeon/dev/cn30xxgmx.c,v
retrieving revision 1.34
diff -u -p -r1.34 cn30xxgmx.c
--- arch/octeon/dev/cn30xxgmx.c 2 May 2017 13:26:49 -0000 1.34
+++ arch/octeon/dev/cn30xxgmx.c 8 Jun 2017 14:36:57 -0000
@@ -853,10 +853,8 @@ cn30xxgmx_rgmii_speed(struct cn30xxgmx_p
baudrate = IF_Mbps(100);
break;
case RXN_RX_INBND_SPEED_125:
- baudrate = IF_Gbps(1);
- break;
default:
- baudrate = 0/* XXX */;
+ baudrate = IF_Gbps(1);
break;
}
ifp->if_baudrate = baudrate;
Because the switch port is not usable anyway, perhaps device probing
should skip it. Does the following patch work correctly on the router?
cvs:~visa/bsd.probefix is a kernel with the patch.
I do not have an ERPoe-5 myself.
Index: arch/octeon/dev/cn30xxsmi.c
===================================================================
RCS file: src/sys/arch/octeon/dev/cn30xxsmi.c,v
retrieving revision 1.4
diff -u -p -r1.4 cn30xxsmi.c
--- arch/octeon/dev/cn30xxsmi.c 2 May 2017 13:26:49 -0000 1.4
+++ arch/octeon/dev/cn30xxsmi.c 8 Jun 2017 14:43:36 -0000
@@ -181,6 +181,11 @@ cn30xxsmi_get_phy(int phandle, int port,
switch (octeon_boot_info->board_type) {
case BOARD_TYPE_UBIQUITI_E100:
+ /* XXX Skip the switch port on ERPoe-5.
+ * XXX There is no driver for it. */
+ if (port > 1 && octeon_boot_info->board_rev_major == 1)
+ return ENOENT;
+
if (port > 2)
return ENOENT;
reg = 7 - port;
