Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Am 30.09.21 um 22:03 schrieb Hans van Kranenburg:
Hi spi, Salvatore,
On 8/5/21 1:58 PM, s...@gmxpro.de wrote:
In preparation for the bug report for upstream I did some more
investigation.
The kernel panic also occurs without bonding interfaces but needs much
more time to happen. With a bonding interface it happens within some
seconds. Without bonding interfaces it needs like a minute with the
network discovery being re-launched for 2 or 3 times. The kernel panic
is still the same about the bnx2 driver.
In the constellation without a bonding interface the kernel panic only
occurs if
- opnsense as a domU is running (this domU bounds all bridged interfaces
as default gateway for all networks)
Just FWIW, I'm seeing this bug-mail-thread now, and it rings a bell.
I spent some time in the past to debug crashing BCM5719 (4x1G) nics in
HP DL360 G8/9 series servers. In this case, the firmware inside the nic
crashed, so the symptoms were different. This happened only when having
a Xen domU active as router, which was routing incoming traffic packets
(from outside the box) back to the outside again.
02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.3 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
Also, 2x 1G were bonded, I use openvswitch with LACP for that.
The symptoms are obviously different, mine looked like this:
tg3 :02:00.2 eth1: transmit timed out, resetting
tg3 :02:00.2 eth1: 0x: 0x165714e4, 0x00100546, 0x0201,
0x00800010
tg3 :02:00.2 eth1: 0x0010: 0x92b3000c, 0x, 0x92b4000c,
0x
tg3 :02:00.2 eth1: 0x0020: 0x92b5000c, 0x, 0x,
0x22be103c
tg3 :02:00.2 eth1: 0x7000: 0x0808, 0x, 0x,
0x4cd8
tg3 :02:00.2 eth1: 0x7010: 0xdbbd2b97, 0x010080f3, 0x00d70081,
0x03008200
tg3 :02:00.2 eth1: 0x7020: 0x, 0x, 0x0406,
0x10004000
tg3 :02:00.2 eth1: 0x7030: 0x0002, 0x4cdc, 0x001f,
0x
tg3 :02:00.2 eth1: 0: Host status block
[0001:0070:(:0563:):(:0094)]
tg3 :02:00.2 eth1: 0: NAPI info
[0070:0070:(016a:0094:01ff)::(068c:::)]
tg3 :02:00.2 eth1: 1: Host status block
[0001:0083:(::):(015b:)]
tg3 :02:00.2 eth1: 1: NAPI info
[0051:0051:(::01ff):0124:(0124:0124::)]
tg3 :02:00.2 eth1: 2: Host status block
[0001:00d8:(0e96::):(:)]
tg3 :02:00.2 eth1: 2: NAPI info
[00a4:00a4:(::01ff):0e5b:(065b:065b::)]
tg3 :02:00.2 eth1: 3: Host status block
[0001:0013:(::):(:)]
tg3 :02:00.2 eth1: 3: NAPI info
[00f8:00f8:(::01ff):072f:(072f:072f::)]
tg3 :02:00.2 eth1: 4: Host status block
[0001:009c:(::0736):(:)]
tg3 :02:00.2 eth1: 4: NAPI info
[007c:007c:(::01ff):0716:(0716:0716::)]
tg3 :02:00.2: tg3_stop_block timed out, ofs=1400 enable_bit=2
tg3 :02:00.2: tg3_stop_block timed out, ofs=c00 enable_bit=2
tg3 :02:00.2 eth1: Link is down
tg3 :02:00.2 eth1: Link is up at 1000 Mbps, full duplex
tg3 :02:00.2 eth1: Flow control is off for TX and off for RX
tg3 :02:00.2 eth1: EEE is disabled
- sysctl parameter net.bridge.bridge-nf-call-ip6tables is set to 0.
If both conditions are not met no kernel panic oaccurs.
What I found out in the end is that using `ethtool -K $iface tso off` is
a workaround to not make it trigger some obscure bug inside the nic that
makes it crash.
So, I think my actual suggestion would be, even while it does not look
like the same thing, but it's still Broadcom stuff which can have
*cough* weird issues... if you can reliably reproduce the problem, then
can you try setting tso off on the physical interfaces in dom0 and try
again? In Dutch we say "nooit geschoten altijd mis".
The next time I do maintenance I'll rerun the tests and set "ethtool -K
$iface tso off". "ethtool -K ${int} tx off" is alreday configured on the
server and I also tried tso off and others as well but didn't pay
attention to this bug at that time - as said the kernel panic doesn't
occur immediately but only after some minutes.
In German it is "wer nicht wagt, der nicht gewinnt" ;-)
Other IPv6 related sysctl parameters are set on dom0 like
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
The layer2-iptables settings are
net.bridge.bridge-nf-call-ip6tables = 0 ***
Do you recall what your setting for net.bridge.bridge-nf-call-ip6tables was?
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 0
As said, if I don't
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Did you got any response on your reporting upstream? No, not yet. Troubleshooting took quite some time and in the meantime there is a new upstream kernel version available. So I need to rerun all tests again. As this is a productive server I can only shutdown the server every now and then on weekends. Cheers, Sebastian
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Hi spi, Salvatore, On 8/5/21 1:58 PM, s...@gmxpro.de wrote: > > In preparation for the bug report for upstream I did some more > investigation. > > The kernel panic also occurs without bonding interfaces but needs much > more time to happen. With a bonding interface it happens within some > seconds. Without bonding interfaces it needs like a minute with the > network discovery being re-launched for 2 or 3 times. The kernel panic > is still the same about the bnx2 driver. > > In the constellation without a bonding interface the kernel panic only > occurs if > - opnsense as a domU is running (this domU bounds all bridged interfaces > as default gateway for all networks) Just FWIW, I'm seeing this bug-mail-thread now, and it rings a bell. I spent some time in the past to debug crashing BCM5719 (4x1G) nics in HP DL360 G8/9 series servers. In this case, the firmware inside the nic crashed, so the symptoms were different. This happened only when having a Xen domU active as router, which was routing incoming traffic packets (from outside the box) back to the outside again. 02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.3 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) Also, 2x 1G were bonded, I use openvswitch with LACP for that. The symptoms are obviously different, mine looked like this: tg3 :02:00.2 eth1: transmit timed out, resetting tg3 :02:00.2 eth1: 0x: 0x165714e4, 0x00100546, 0x0201, 0x00800010 tg3 :02:00.2 eth1: 0x0010: 0x92b3000c, 0x, 0x92b4000c, 0x tg3 :02:00.2 eth1: 0x0020: 0x92b5000c, 0x, 0x, 0x22be103c tg3 :02:00.2 eth1: 0x7000: 0x0808, 0x, 0x, 0x4cd8 tg3 :02:00.2 eth1: 0x7010: 0xdbbd2b97, 0x010080f3, 0x00d70081, 0x03008200 tg3 :02:00.2 eth1: 0x7020: 0x, 0x, 0x0406, 0x10004000 tg3 :02:00.2 eth1: 0x7030: 0x0002, 0x4cdc, 0x001f, 0x tg3 :02:00.2 eth1: 0: Host status block [0001:0070:(:0563:):(:0094)] tg3 :02:00.2 eth1: 0: NAPI info [0070:0070:(016a:0094:01ff)::(068c:::)] tg3 :02:00.2 eth1: 1: Host status block [0001:0083:(::):(015b:)] tg3 :02:00.2 eth1: 1: NAPI info [0051:0051:(::01ff):0124:(0124:0124::)] tg3 :02:00.2 eth1: 2: Host status block [0001:00d8:(0e96::):(:)] tg3 :02:00.2 eth1: 2: NAPI info [00a4:00a4:(::01ff):0e5b:(065b:065b::)] tg3 :02:00.2 eth1: 3: Host status block [0001:0013:(::):(:)] tg3 :02:00.2 eth1: 3: NAPI info [00f8:00f8:(::01ff):072f:(072f:072f::)] tg3 :02:00.2 eth1: 4: Host status block [0001:009c:(::0736):(:)] tg3 :02:00.2 eth1: 4: NAPI info [007c:007c:(::01ff):0716:(0716:0716::)] tg3 :02:00.2: tg3_stop_block timed out, ofs=1400 enable_bit=2 tg3 :02:00.2: tg3_stop_block timed out, ofs=c00 enable_bit=2 tg3 :02:00.2 eth1: Link is down tg3 :02:00.2 eth1: Link is up at 1000 Mbps, full duplex tg3 :02:00.2 eth1: Flow control is off for TX and off for RX tg3 :02:00.2 eth1: EEE is disabled > - sysctl parameter net.bridge.bridge-nf-call-ip6tables is set to 0. > > If both conditions are not met no kernel panic oaccurs. What I found out in the end is that using `ethtool -K $iface tso off` is a workaround to not make it trigger some obscure bug inside the nic that makes it crash. So, I think my actual suggestion would be, even while it does not look like the same thing, but it's still Broadcom stuff which can have *cough* weird issues... if you can reliably reproduce the problem, then can you try setting tso off on the physical interfaces in dom0 and try again? In Dutch we say "nooit geschoten altijd mis". > Other IPv6 related sysctl parameters are set on dom0 like > net.ipv6.conf.all.disable_ipv6 = 1 > net.ipv6.conf.default.disable_ipv6 = 1 > net.ipv6.conf.lo.disable_ipv6 = 1 > > > The layer2-iptables settings are > net.bridge.bridge-nf-call-ip6tables = 0 *** > > > net.bridge.bridge-nf-call-iptables = 1 > > > net.bridge.bridge-nf-call-arptables = 0 > > > > > As said, if I don't set the one marked with *** to 0 there is no kernel > panic. > > I wonder if this still is a kernel issue but still wouldn't expect a > kernel panic to happen. > > Cheers, > spi > Have fun, Hans
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Hi, On Thu, Aug 05, 2021 at 01:58:50PM +0200, s...@gmxpro.de wrote: > > In preparation for the bug report for upstream I did some more > investigation. > > The kernel panic also occurs without bonding interfaces but needs much > more time to happen. With a bonding interface it happens within some > seconds. Without bonding interfaces it needs like a minute with the > network discovery being re-launched for 2 or 3 times. The kernel panic > is still the same about the bnx2 driver. > > In the constellation without a bonding interface the kernel panic only > occurs if > - opnsense as a domU is running (this domU bounds all bridged interfaces > as default gateway for all networks) > - sysctl parameter net.bridge.bridge-nf-call-ip6tables is set to 0. > > If both conditions are not met no kernel panic oaccurs. > > Other IPv6 related sysctl parameters are set on dom0 like > net.ipv6.conf.all.disable_ipv6 = 1 > net.ipv6.conf.default.disable_ipv6 = 1 > net.ipv6.conf.lo.disable_ipv6 = 1 > > > The layer2-iptables settings are > net.bridge.bridge-nf-call-ip6tables = 0 *** > > > net.bridge.bridge-nf-call-iptables = 1 > > > net.bridge.bridge-nf-call-arptables = 0 > > > > > As said, if I don't set the one marked with *** to 0 there is no kernel > panic. > > I wonder if this still is a kernel issue but still wouldn't expect a > kernel panic to happen. Did you got any response on your reporting upstream? Regards, Salvatore
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
In preparation for the bug report for upstream I did some more investigation. The kernel panic also occurs without bonding interfaces but needs much more time to happen. With a bonding interface it happens within some seconds. Without bonding interfaces it needs like a minute with the network discovery being re-launched for 2 or 3 times. The kernel panic is still the same about the bnx2 driver. In the constellation without a bonding interface the kernel panic only occurs if - opnsense as a domU is running (this domU bounds all bridged interfaces as default gateway for all networks) - sysctl parameter net.bridge.bridge-nf-call-ip6tables is set to 0. If both conditions are not met no kernel panic oaccurs. Other IPv6 related sysctl parameters are set on dom0 like net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 The layer2-iptables settings are net.bridge.bridge-nf-call-ip6tables = 0 *** net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-arptables = 0 As said, if I don't set the one marked with *** to 0 there is no kernel panic. I wonder if this still is a kernel issue but still wouldn't expect a kernel panic to happen. Cheers, spi
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Hi, On Sat, Jul 17, 2021 at 08:32:42PM +0200, s...@gmxpro.de wrote: > > So, did some more testing. > > 1) Tried two different ports for binding interface on the 4-port-NIC: > again kernel panic > > 2) Compiled mainline 5.14-rc1 (2021-07-11) kernel from kernel.org: again > kernel panic with either two ports on the 4-port-NIC > > > 3) Added another 2-port-NIC into server: > 06:01.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet > Controller (Copper) (rev 03) > > 06:01.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet > Controller (Copper) (rev 03) > > driver: e1000 > version: 7.3.21-k8-NAPI > > > When configuring a two port bonding interface on this Intel NIC there is > no kernel panic neither with 5.14-rc1 nor 4.19.0-17-amd64. > > > For me it seems there is an issue with the bnx2 driver used for the > Broadcom Limited NetXtreme II BCM5709 Gigabit Ethernet (rev 20). So sorry to not coming back to this earlier. Now that you were able to reproduce the very same with mainline, can you report the issue to upstream? cripts/get_maintainer.pl would suggst the following: Rasesh Mody (supporter:BROADCOM BNX2 GIGABIT ETHERNET DRIVER) gr-linux-nic-...@marvell.com (supporter:BROADCOM BNX2 GIGABIT ETHERNET DRIVER) "David S. Miller" (maintainer:NETWORKING DRIVERS) Jakub Kicinski (maintainer:NETWORKING DRIVERS) Ariel Elior (supporter:BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER) Sudarsana Kalluru (supporter:BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER) gr-everest-linux...@marvell.com (supporter:BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER) net...@vger.kernel.org (open list:BROADCOM BNX2 GIGABIT ETHERNET DRIVER) linux-ker...@vger.kernel.org (open list) Please keep ideally directly the Debian bug ideally in the loop. Regards, Salvatore
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
So, did some more testing. 1) Tried two different ports for binding interface on the 4-port-NIC: again kernel panic 2) Compiled mainline 5.14-rc1 (2021-07-11) kernel from kernel.org: again kernel panic with either two ports on the 4-port-NIC 3) Added another 2-port-NIC into server: 06:01.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 03) 06:01.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 03) driver: e1000 version: 7.3.21-k8-NAPI When configuring a two port bonding interface on this Intel NIC there is no kernel panic neither with 5.14-rc1 nor 4.19.0-17-amd64. For me it seems there is an issue with the bnx2 driver used for the Broadcom Limited NetXtreme II BCM5709 Gigabit Ethernet (rev 20). Cheers, spi
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
One thing I forgot to ask in the previous message: you have 4 interfaces: did you check if you trigger the issue if you change the two interfaces you want to bond? Just to double-check. Regards, Salvatore
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Hi, On Tue, Jul 13, 2021 at 03:26:22PM +0200, s...@gmxpro.de wrote: > > > > > thanks for confirming this as well, so adding a found version. Next > > step would be to check the latest 5.10.y upstream version. If it's an > > issue there, next to report it upstream. > > > > Just to understand that correctly - shall I wait for the next update for > the kernel in buster-backports and try that one? > > I tried 5.10.40-1~bpo10+1 amd64 which is currently the latest one in > buster-backports. Actually I was targetting at something else (but apart that if you can fetch the unstable's kernel then you can verify as well 5.10.46-1): I meant to verify directly upstream's mainline and latest 5.10.y form upstream. How to do that, we tried to document in https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-kernel-org-package If you find the issue is still present in the most current version, my aim was that we can report it upstream as issue. One further aspect is: If you find an earlier version you known to be non-broken with the setup, bisecting could lead to the introducing commit which introduces the issue, and so enlight some further more. Does this help so far? Regards, Salvatore
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
thanks for confirming this as well, so adding a found version. Next step would be to check the latest 5.10.y upstream version. If it's an issue there, next to report it upstream. Just to understand that correctly - shall I wait for the next update for the kernel in buster-backports and try that one? I tried 5.10.40-1~bpo10+1 amd64 which is currently the latest one in buster-backports. spi
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Control: found -1 5.10.40-1 Hi, On Sat, Jul 10, 2021 at 06:40:08PM +0200, s...@gmxpro.de wrote: > > > > > Can you reproduce the issue with recent kernel from unstable or > > buster-backports? > > > > Tried with linux-image-5.10.0-0.bpo.7-amd64 (5.10.40-1~bpo10+1 amd64) > from buster-backports. > > Same issue - kernel panic with bonded interfaces. > > Current workaround for me is to run without bonding. thanks for confirming this as well, so adding a found version. Next step would be to check the latest 5.10.y upstream version. If it's an issue there, next to report it upstream. Regards, Salvatore
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Can you reproduce the issue with recent kernel from unstable or buster-backports? Tried with linux-image-5.10.0-0.bpo.7-amd64 (5.10.40-1~bpo10+1 amd64) from buster-backports. Same issue - kernel panic with bonded interfaces. Current workaround for me is to run without bonding. Cheers, spi
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
From the above description one thin is not fully clear to me, so aksing specifically: Is this a regression introduced with the 4.19.194-1 upload or can you reproduce the issue earlier? I had no spontaneous reboots within the last years so yes, the issue seems to got introduced with one of the recent kernels in the last few months. If a new regression introduced, can you possibly bisect to the introducing commit? Can you reproduce the issue with recent kernel from unstable or buster-backports? I'm going to try a more recent kernel from backports or unstable to see if issue still persist. As I this issue only pops up while using bonding interfaces on a multiport GBE NIC I wonder if there is "just" a configuration issue with the bonding interfaces. Cheers spi
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Control: tags -1 + moreinfo On Sat, Jul 03, 2021 at 05:26:04PM +0200, s...@gmxpro.de wrote: > Package: src:linux > Version: 4.19.194-1 > Severity: important > > > > -- Package-specific info: > ** Version: > Linux version 4.19.0-17-amd64 (debian-ker...@lists.debian.org) (gcc > version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.194-1 (2021-06-10) > > ** Command line: > placeholder root=/dev/mapper/srvxen04-root ro console=ttyS0,115200n8 > console=tty0 intel_iommu=on nomodeset net.ifnames=1 biosdevname=0 > > ** Not tainted > > ** Kernel log: > [ 39.592859] vif vif-1-0 vif-fw2-OAM: renamed from vif1.0 > [ 39.620827] vif vif-1-3 vif-fw2-FE: renamed from vif1.3 > [ 39.648849] vif vif-1-2 vif-fw2-DMZ0: renamed from vif1.2 > [ 39.676964] vif vif-1-6 vif-fw2-TEST: renamed from vif1.6 > [ 39.712828] vif vif-1-8 vif-fw2-HOME: renamed from vif1.8 > [ 39.796755] brLAN: port 2(vif-fw2-LAN) entered blocking state > [ 39.802908] brLAN: port 2(vif-fw2-LAN) entered disabled state > [ 39.809479] device vif-fw2-LAN entered promiscuous mode > [ 39.815267] brOAM: port 2(vif-fw2-OAM) entered blocking state > [ 39.821493] brOAM: port 2(vif-fw2-OAM) entered disabled state > [ 39.827692] device vif-fw2-OAM entered promiscuous mode > [ 39.833365] brWLAN: port 2(vif-fw2-WLAN) entered blocking state > [ 39.839769] brWLAN: port 2(vif-fw2-WLAN) entered disabled state > [ 39.846161] device vif-fw2-WLAN entered promiscuous mode > [ 39.851967] brDMZ0: port 2(vif-fw2-DMZ0) entered blocking state > [ 39.858295] brDMZ0: port 2(vif-fw2-DMZ0) entered disabled state > [ 39.864659] device vif-fw2-DMZ0 entered promiscuous mode > [ 39.874675] brFE: port 2(vif-fw2-FE) entered blocking state > [ 39.880621] brFE: port 2(vif-fw2-FE) entered disabled state > [ 39.886968] device vif-fw2-FE entered promiscuous mode > [ 39.893906] brRLAN: port 2(vif-fw2-RLAN) entered blocking state > [ 39.900254] brRLAN: port 2(vif-fw2-RLAN) entered disabled state > [ 39.907304] device vif-fw2-RLAN entered promiscuous mode > [ 39.915348] brTEST: port 2(vif-fw2-TEST) entered blocking state > [ 39.921718] brTEST: port 2(vif-fw2-TEST) entered disabled state > [ 39.928290] device vif-fw2-TEST entered promiscuous mode > [ 39.934666] brBE: port 2(vif-fw2-BE) entered blocking state > [ 39.940616] brBE: port 2(vif-fw2-BE) entered disabled state > [ 39.946814] device vif-fw2-BE entered promiscuous mode > [ 39.953792] brHOME: port 2(vif-fw2-HOME) entered blocking state > [ 39.960107] brHOME: port 2(vif-fw2-HOME) entered disabled state > [ 39.966581] device vif-fw2-HOME entered promiscuous mode > [ 42.160336] xen-blkback: backend/vbd/1/51712: using 1 queues, > protocol 1 (x86_64-abi) > [ 42.353338] vif vif-1-0 vif-fw2-OAM: Guest Rx ready > [ 42.358612] brOAM: port 2(vif-fw2-OAM) entered blocking state > [ 42.364733] brOAM: port 2(vif-fw2-OAM) entered forwarding state > [ 42.378050] vif vif-1-1 vif-fw2-LAN: Guest Rx ready > [ 42.383309] brLAN: port 2(vif-fw2-LAN) entered blocking state > [ 42.389427] brLAN: port 2(vif-fw2-LAN) entered forwarding state > [ 42.428330] vif vif-1-2 vif-fw2-DMZ0: Guest Rx ready > [ 42.433682] brDMZ0: port 2(vif-fw2-DMZ0) entered blocking state > [ 42.440053] brDMZ0: port 2(vif-fw2-DMZ0) entered forwarding state > [ 42.448264] vif vif-1-3 vif-fw2-FE: Guest Rx ready > [ 42.453429] brFE: port 2(vif-fw2-FE) entered blocking state > [ 42.459409] brFE: port 2(vif-fw2-FE) entered forwarding state > [ 42.467498] vif vif-1-4 vif-fw2-BE: Guest Rx ready > [ 42.472669] brBE: port 2(vif-fw2-BE) entered blocking state > [ 42.478647] brBE: port 2(vif-fw2-BE) entered forwarding state > [ 42.486688] vif vif-1-5 vif-fw2-WLAN: Guest Rx ready > [ 42.492049] brWLAN: port 2(vif-fw2-WLAN) entered blocking state > [ 42.498370] brWLAN: port 2(vif-fw2-WLAN) entered forwarding state > [ 42.506575] vif vif-1-6 vif-fw2-TEST: Guest Rx ready > [ 42.511964] brTEST: port 2(vif-fw2-TEST) entered blocking state > [ 42.518364] brTEST: port 2(vif-fw2-TEST) entered forwarding state > [ 42.526458] vif vif-1-7 vif-fw2-RLAN: Guest Rx ready > [ 42.531790] brRLAN: port 2(vif-fw2-RLAN) entered blocking state > [ 42.538105] brRLAN: port 2(vif-fw2-RLAN) entered forwarding state > [ 42.546365] vif vif-1-8 vif-fw2-HOME: Guest Rx ready > [ 42.551699] brHOME: port 2(vif-fw2-HOME) entered blocking state > [ 42.557990] brHOME: port 2(vif-fw2-HOME) entered forwarding state > [ 52.749924] brBE: port 2(vif-fw2-BE) entered disabled state > [ 52.857180] vif vif-1-4 vif-fw2-BE: Guest Rx ready > [ 52.862389] brBE: port 2(vif-fw2-BE) entered blocking state > [ 52.868356] brBE: port 2(vif-fw2-BE) entered forwarding state > [ 53.011574] vif vif-1-4 vif-fw2-BE: Guest Rx ready > [ 53.011597] NOHZ: local_softirq_pending 08 > [ 53.145228] vif vif-1-3 vif-fw2-FE: Guest Rx ready > [ 53.253183] vif vif-1-3 vif-fw2-FE: Guest Rx ready > [ 53.253214] NOHZ: local_softirq_pending 08 >
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Without bonding 2 interfaces there is no kernel panic so far. spi
Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709
Package: src:linux Version: 4.19.194-1 Severity: important -- Package-specific info: ** Version: Linux version 4.19.0-17-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.194-1 (2021-06-10) ** Command line: placeholder root=/dev/mapper/srvxen04-root ro console=ttyS0,115200n8 console=tty0 intel_iommu=on nomodeset net.ifnames=1 biosdevname=0 ** Not tainted ** Kernel log: [ 39.592859] vif vif-1-0 vif-fw2-OAM: renamed from vif1.0 [ 39.620827] vif vif-1-3 vif-fw2-FE: renamed from vif1.3 [ 39.648849] vif vif-1-2 vif-fw2-DMZ0: renamed from vif1.2 [ 39.676964] vif vif-1-6 vif-fw2-TEST: renamed from vif1.6 [ 39.712828] vif vif-1-8 vif-fw2-HOME: renamed from vif1.8 [ 39.796755] brLAN: port 2(vif-fw2-LAN) entered blocking state [ 39.802908] brLAN: port 2(vif-fw2-LAN) entered disabled state [ 39.809479] device vif-fw2-LAN entered promiscuous mode [ 39.815267] brOAM: port 2(vif-fw2-OAM) entered blocking state [ 39.821493] brOAM: port 2(vif-fw2-OAM) entered disabled state [ 39.827692] device vif-fw2-OAM entered promiscuous mode [ 39.833365] brWLAN: port 2(vif-fw2-WLAN) entered blocking state [ 39.839769] brWLAN: port 2(vif-fw2-WLAN) entered disabled state [ 39.846161] device vif-fw2-WLAN entered promiscuous mode [ 39.851967] brDMZ0: port 2(vif-fw2-DMZ0) entered blocking state [ 39.858295] brDMZ0: port 2(vif-fw2-DMZ0) entered disabled state [ 39.864659] device vif-fw2-DMZ0 entered promiscuous mode [ 39.874675] brFE: port 2(vif-fw2-FE) entered blocking state [ 39.880621] brFE: port 2(vif-fw2-FE) entered disabled state [ 39.886968] device vif-fw2-FE entered promiscuous mode [ 39.893906] brRLAN: port 2(vif-fw2-RLAN) entered blocking state [ 39.900254] brRLAN: port 2(vif-fw2-RLAN) entered disabled state [ 39.907304] device vif-fw2-RLAN entered promiscuous mode [ 39.915348] brTEST: port 2(vif-fw2-TEST) entered blocking state [ 39.921718] brTEST: port 2(vif-fw2-TEST) entered disabled state [ 39.928290] device vif-fw2-TEST entered promiscuous mode [ 39.934666] brBE: port 2(vif-fw2-BE) entered blocking state [ 39.940616] brBE: port 2(vif-fw2-BE) entered disabled state [ 39.946814] device vif-fw2-BE entered promiscuous mode [ 39.953792] brHOME: port 2(vif-fw2-HOME) entered blocking state [ 39.960107] brHOME: port 2(vif-fw2-HOME) entered disabled state [ 39.966581] device vif-fw2-HOME entered promiscuous mode [ 42.160336] xen-blkback: backend/vbd/1/51712: using 1 queues, protocol 1 (x86_64-abi) [ 42.353338] vif vif-1-0 vif-fw2-OAM: Guest Rx ready [ 42.358612] brOAM: port 2(vif-fw2-OAM) entered blocking state [ 42.364733] brOAM: port 2(vif-fw2-OAM) entered forwarding state [ 42.378050] vif vif-1-1 vif-fw2-LAN: Guest Rx ready [ 42.383309] brLAN: port 2(vif-fw2-LAN) entered blocking state [ 42.389427] brLAN: port 2(vif-fw2-LAN) entered forwarding state [ 42.428330] vif vif-1-2 vif-fw2-DMZ0: Guest Rx ready [ 42.433682] brDMZ0: port 2(vif-fw2-DMZ0) entered blocking state [ 42.440053] brDMZ0: port 2(vif-fw2-DMZ0) entered forwarding state [ 42.448264] vif vif-1-3 vif-fw2-FE: Guest Rx ready [ 42.453429] brFE: port 2(vif-fw2-FE) entered blocking state [ 42.459409] brFE: port 2(vif-fw2-FE) entered forwarding state [ 42.467498] vif vif-1-4 vif-fw2-BE: Guest Rx ready [ 42.472669] brBE: port 2(vif-fw2-BE) entered blocking state [ 42.478647] brBE: port 2(vif-fw2-BE) entered forwarding state [ 42.486688] vif vif-1-5 vif-fw2-WLAN: Guest Rx ready [ 42.492049] brWLAN: port 2(vif-fw2-WLAN) entered blocking state [ 42.498370] brWLAN: port 2(vif-fw2-WLAN) entered forwarding state [ 42.506575] vif vif-1-6 vif-fw2-TEST: Guest Rx ready [ 42.511964] brTEST: port 2(vif-fw2-TEST) entered blocking state [ 42.518364] brTEST: port 2(vif-fw2-TEST) entered forwarding state [ 42.526458] vif vif-1-7 vif-fw2-RLAN: Guest Rx ready [ 42.531790] brRLAN: port 2(vif-fw2-RLAN) entered blocking state [ 42.538105] brRLAN: port 2(vif-fw2-RLAN) entered forwarding state [ 42.546365] vif vif-1-8 vif-fw2-HOME: Guest Rx ready [ 42.551699] brHOME: port 2(vif-fw2-HOME) entered blocking state [ 42.557990] brHOME: port 2(vif-fw2-HOME) entered forwarding state [ 52.749924] brBE: port 2(vif-fw2-BE) entered disabled state [ 52.857180] vif vif-1-4 vif-fw2-BE: Guest Rx ready [ 52.862389] brBE: port 2(vif-fw2-BE) entered blocking state [ 52.868356] brBE: port 2(vif-fw2-BE) entered forwarding state [ 53.011574] vif vif-1-4 vif-fw2-BE: Guest Rx ready [ 53.011597] NOHZ: local_softirq_pending 08 [ 53.145228] vif vif-1-3 vif-fw2-FE: Guest Rx ready [ 53.253183] vif vif-1-3 vif-fw2-FE: Guest Rx ready [ 53.253214] NOHZ: local_softirq_pending 08 [ 53.377074] vif vif-1-8 vif-fw2-HOME: Guest Rx ready [ 53.493773] vif vif-1-8 vif-fw2-HOME: Guest Rx ready [ 53.493792] NOHZ: local_softirq_pending 08 [ 53.648414] vif vif-1-0 vif-fw2-OAM: Guest Rx ready [ 53.761142] vif vif-1-0 vif-fw2-OAM: Guest Rx ready [
