Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
On 3/19/19 11:17 AM, Florian Fainelli wrote:
On 3/19/19 11:14 AM, Christian Lamparter wrote:
Cc: Florian. I hope you don't mind.
On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
on an IPQ4019-based device, I can get basic connectivity either manually,
or with a "standard" UCI definition of the "lan" bridge[2].
(I'm aware that this is not "production" code and expect "challenges".)
[...]
This unfortunately results in a kernel panic when trying to add to the
bridge.
Bridge br-lan initially set up with "default" UCI config[2]
Full serial log available[4]
ip link add link wan0 name wan0.100 type vlan id 100
ip link set wan0 up
ip link set wan0.100 up
ip link set wan0.100 master br-lan
(kernel panics)
I've traced this to passing of a null pointer to br_vlan_enabled()
with the diagnostic patch shown in [5]
Yes, this shouldn't crash. I think Florian has already a patch for this
upstream [6].
Right, this specific commit omitted two key details which were that:
- not all drivers support port_vlan_{add,del}
- not all drivers support programming VID 0
This is fixed upstream with d6af21a4fb5fff2f6640feb011902212e658414d
("net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()")
commit 061f6a505ac33659eab007731c0f6374df39ab55
Author: Florian Fainelli
Date: Wed Feb 20 14:35:39 2019 -0800
net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
That should help with the NPEs since it now checks whenever the
bridge_dev is valid or not.
[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
[6]
Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
Cc: Florian. I hope you don't mind.
On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
> Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
> on an IPQ4019-based device, I can get basic connectivity either manually,
> or with a "standard" UCI definition of the "lan" bridge[2].
>
> (I'm aware that this is not "production" code and expect "challenges".)
>
> However, I'm puzzled as how to manage VLANs and tagging, even using
> `ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).
>
> It appears that the qca8k driver doesn't support `bridge` VLAN-related
> commands. Checking the source doesn't show implementation of the
> `port_vlan_*` functions described in the Linux DSA doc[3].
>
>
> Setting aside my suspicion that a port-based VLAN approach seems
> unlikely to be able to handle trunking of VLANs, I tried adding a
> sub-interface of one of the otherwise unused phy interfaces (renamed
> in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").
At first glance, I think you are running into what's described in section
"Design limitations" of DSA in [3]:"
- inability to configure specific VLAN IDs / trunking VLANs between switches
when using a cascaded setup". (Sadly there isn't a link to a possible
patch or discussion so I don't know the state of it).
However...
> This unfortunately results in a kernel panic when trying to add to the
> bridge.
>
> Bridge br-lan initially set up with "default" UCI config[2]
>
> Full serial log available[4]
>
>ip link add link wan0 name wan0.100 type vlan id 100
>ip link set wan0 up
>ip link set wan0.100 up
>ip link set wan0.100 master br-lan
>(kernel panics)
>
>
> I've traced this to passing of a null pointer to br_vlan_enabled()
> with the diagnostic patch shown in [5]
Yes, this shouldn't crash. I think Florian has already a patch for this
upstream [6].
commit 061f6a505ac33659eab007731c0f6374df39ab55
Author: Florian Fainelli
Date: Wed Feb 20 14:35:39 2019 -0800
net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
That should help with the NPEs since it now checks whenever the
bridge_dev is valid or not.
[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
[6]
Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
On 3/19/19 11:14 AM, Christian Lamparter wrote:
> Cc: Florian. I hope you don't mind.
>
> On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:
>> Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
>> on an IPQ4019-based device, I can get basic connectivity either manually,
>> or with a "standard" UCI definition of the "lan" bridge[2].
>>
>> (I'm aware that this is not "production" code and expect "challenges".)
>>
>> However, I'm puzzled as how to manage VLANs and tagging, even using
>> `ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).
>>
>> It appears that the qca8k driver doesn't support `bridge` VLAN-related
>> commands. Checking the source doesn't show implementation of the
>> `port_vlan_*` functions described in the Linux DSA doc[3].
>>
>>
>> Setting aside my suspicion that a port-based VLAN approach seems
>> unlikely to be able to handle trunking of VLANs, I tried adding a
>> sub-interface of one of the otherwise unused phy interfaces (renamed
>> in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").
>
> At first glance, I think you are running into what's described in section
> "Design limitations" of DSA in [3]:"
> - inability to configure specific VLAN IDs / trunking VLANs between switches
> when using a cascaded setup". (Sadly there isn't a link to a possible
> patch or discussion so I don't know the state of it).
>
> However...
>
>> This unfortunately results in a kernel panic when trying to add to the
>> bridge.
>>
>> Bridge br-lan initially set up with "default" UCI config[2]
>>
>> Full serial log available[4]
>>
>>ip link add link wan0 name wan0.100 type vlan id 100
>>ip link set wan0 up
>>ip link set wan0.100 up
>>ip link set wan0.100 master br-lan
>>(kernel panics)
>>
>>
>> I've traced this to passing of a null pointer to br_vlan_enabled()
>> with the diagnostic patch shown in [5]
>
> Yes, this shouldn't crash. I think Florian has already a patch for this
> upstream [6].
Right, this specific commit omitted two key details which were that:
- not all drivers support port_vlan_{add,del}
- not all drivers support programming VID 0
This is fixed upstream with d6af21a4fb5fff2f6640feb011902212e658414d
("net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()")
>
> commit 061f6a505ac33659eab007731c0f6374df39ab55
> Author: Florian Fainelli
> Date: Wed Feb 20 14:35:39 2019 -0800
>
> net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
>
> That should help with the NPEs since it now checks whenever the
> bridge_dev is valid or not.
>
> [3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
> [6]
Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
Hi Jeff, sounds a bit like https://www.spinics.net/lists/netdev/msg552100.html Regards, Vincent Wiemann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge
Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
on an IPQ4019-based device, I can get basic connectivity either manually,
or with a "standard" UCI definition of the "lan" bridge[2].
(I'm aware that this is not "production" code and expect "challenges".)
However, I'm puzzled as how to manage VLANs and tagging, even using
`ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).
It appears that the qca8k driver doesn't support `bridge` VLAN-related
commands. Checking the source doesn't show implementation of the
`port_vlan_*` functions described in the Linux DSA doc[3].
Setting aside my suspicion that a port-based VLAN approach seems
unlikely to be able to handle trunking of VLANs, I tried adding a
sub-interface of one of the otherwise unused phy interfaces (renamed
in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").
This unfortunately results in a kernel panic when trying to add to the
bridge.
Bridge br-lan initially set up with "default" UCI config[2]
Full serial log available[4]
ip link add link wan0 name wan0.100 type vlan id 100
ip link set wan0 up
ip link set wan0.100 up
ip link set wan0.100 master br-lan
(kernel panics)
I've traced this to passing of a null pointer to br_vlan_enabled()
with the diagnostic patch shown in [5]
root@OpenWrt:/# ip link add link wan0 name wan0.100 type vlan id 100
root@OpenWrt:/# ip link set wan0 up
[ 104.994191] qca8k c00.switch wan0: configuring for phy/ link mode
[ 104.994465] IPv6: ADDRCONF(NETDEV_UP): wan0: link is not ready
[ 104.07] IPv6: ADDRCONF(NETDEV_UP): wan0.100: link is not ready
root@OpenWrt:/# [ 106.086762] qca8k c00.switch wan0: Link is Up -
1Gbps/Full - flow control off
[ 106.087172] IPv6: ADDRCONF(NETDEV_CHANGE): wan0: link becomes ready
[ 106.095911] IPv6: ADDRCONF(NETDEV_CHANGE): wan0.100: link becomes ready
root@OpenWrt:/# ip link set wan0.100 up
root@OpenWrt:/# ip link set wan0.100 master br-lan
[ 125.304300] br-lan: port 8(wan0.100) entered blocking state
[ 125.304384] br-lan: port 8(wan0.100) entered disabled state
[ 125.309269] device wan0.100 entered promiscuous mode
[ 125.314262] device wan0 entered promiscuous mode
[ 125.320068] VLAN: dsa_port_vlan_add(dsa_port *dp: ecf2e7af)
[ 125.324073] VLAN: net_device->name: wan0
[ 125.329413] VLAN: (port) index: 5, name: wan0, type: 3
[ 125.333529] VLAN: ds->index: 0
[ 125.338499] [ cut here ]
[ 125.341532] WARNING: CPU: 2 PID: 2722 at net/bridge/br_vlan.c:756
br_vlan_enabled+0x28/0x38
[ 125.346320] VLAN: br_vlan_enabled( (null))
Examining earlier in the log, the call to br_vlan_enabled()
is passed a pointer to a valid net_device for other interfaces.
As I've got a running device on the bench with which I can test
things, I'm willing to dig into this further either for diagnostics or
for testing. Please let me know how I can further help.
Jeff
[1]
$ git log -1 --pretty=fuller $(git merge-base HEAD master)
commit b61495409b
Author: Tony Ambardar
AuthorDate: Thu Dec 13 23:49:32 2018 -0800
Commit: Hans Dedecker
CommitDate: Thu Mar 14 22:55:06 2019 +0100
Cherry-picked from staging/chunkeey:
9b3a3a9cdf ipq40xx: include ipq40xx-ized qca8k version
5272a018b9 ipq40xx: fix NPE related to bogus use of fixed phy
e3946c85a6 ipq40xx: extend DT mdio node to be more accessible
273ffef2d8 ipq40xx: add ipqess ethernet driver
9b34795310 ipq40xx: add resets for individual MAC1-5 and PSGMII
f1042e1b15 ipq40xx: decouple mdio-ipq40xx and ar40xx
e34265ecf1 phytool: add phytool utility
[2]
config interface 'lan'
option type 'bridge'
option ifname 'lan1 lan2 lan3 lan4'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
[4] https://gist.github.com/jeffsf/21109ff71a9041ebe4bd452d9cc0ddce
[5]
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -753,6 +753,8 @@ bool br_vlan_enabled(const struct net_de
{
struct net_bridge *br = netdev_priv(dev);
+ WARN(!(dev), "VLAN: br_vlan_enabled(%p)\n", ((void *)dev));
+
return !!br->vlan_enabled;
}
EXPORT_SYMBOL_GPL(br_vlan_enabled);
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,6 +255,11 @@ int dsa_port_vlan_add(struct dsa_port *d
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
+ pr_notice("VLAN: dsa_port_vlan_add(dsa_port *dp: %p)\n", ((void *)dp));
+ pr_notice("VLAN: net_device->name: %s\n", dp->master->name);
+ pr_notice("VLAN: (port) index: %d, name: %s, type: %i\n",
dp->index, dp->name, dp->type);
+ pr_notice("VLAN: ds->index: %d\n", dp->ds->index);
+
if (br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listin
