Bug 1211985

Summary: kernel: RTNL: assertion failed at net/core/dev.c (2879)
Product: [openSUSE] openSUSE Tumbleweed Reporter: Michael Hirmke <opensuse>
Component: KernelAssignee: openSUSE Kernel Bugs <kernel-bugs>
Status: NEW --- QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P5 - None    
Version: Current   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE Tumbleweed   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: stack trace
stack trace 2

Description Michael Hirmke 2023-06-04 18:08:13 UTC
Created attachment 867393 [details]
stack trace

openSUSE Tumbleweed 20230601
Linux 6.3.4-1-default

kernel stack trace:
kernel: RTNL: assertion failed at net/core/dev.c (2879)

see log

There was nothing special going on, when this happened. The akonadiserver message 3 minutes before was the latest, before the crash occurred.
Afterwards the igb net device was gone.
After a reboot everything seems to work again.
Comment 1 Michael Hirmke 2023-06-04 18:30:28 UTC
Similar crash already happend once:

Mai 29 10:16:22 client kernel: pcieport 0000:00:07.2: PME: Spurious native interrupt!
Mai 29 10:16:22 client kernel: ------------[ cut here ]------------
Mai 29 10:16:22 client kernel: RTNL: assertion failed at net/core/dev.c (2877)
Mai 29 10:16:22 client kernel: WARNING: CPU: 3 PID: 28355 at net/core/dev.c:2877 netif_set_real_num_tx_queues+0x1e7/0x200

In this case, the device war still available afterwards.

This was with kernel 6.3.2-1-default.

See log.

At least four times since Mai 07 I got

Mai 29 10:16:22 client kernel: pcieport 0000:00:07.2: PME: Spurious native interrupt!
Mai 29 20:46:51 client kernel: pcieport 0000:00:07.2: PME: Spurious native interrupt!
Mai 30 06:12:35 client kernel: pcieport 0000:00:07.2: PME: Spurious native interrupt!
Mai 30 07:41:06 client kernel: pcieport 0000:00:07.2: PME: Spurious native interrupt!

So the problems seem to have started with kernel 6.3.2-1-default.
Comment 2 Michael Hirmke 2023-06-04 18:30:49 UTC
Created attachment 867394 [details]
stack trace 2
Comment 3 Michael Hirmke 2023-06-09 10:47:21 UTC
The concrete reason was a dying switch.
But I can reproduce the crash just by unplugging the lan cable from the new switch.
The notebook is connected via thunderbolt to a thunderbolt box and this box is connected via lan cable with the switch. Unplugging the thunderbolt cable from either the notebook or the thunderbolt box doesn't lead to the crash, but unplugging the lan cable from the thunderbolt box or the switch leads to it.
Comment 4 Michael Hirmke 2023-06-21 19:44:30 UTC
No one?