So with the script we are able to re-create the panic on one of our systems. Which is good because I was not yet able to extract anything from the uploaded dump (using makedumpfile to convert from kdump_flat format seems to fail finding an end marker).
Generally from the data seen so far all point to a race between disabling a qeth device and accessing debugfs. Since tear down of network device structures is handled asynchronously there is a chance that this might be racing with the access to debug data. This is something that is generally known to upstream but did not receive that much attention either. Access to debugfs should be rather limited to, as its name indicates, debug use. In that light, the question is whether this really should be treated release critical. Trying to get this race free might turn into a bigger task and at the same time should not be something any customer should run into during normal operation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797367 Title: Ubuntu 18.04.1 - [s390x] Kernel panic while stressing network bonding To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1797367/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
