------- Comment From kieni...@de.ibm.com 2018-10-24 06:09 EDT------- (In reply to comment #22) > 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.
The debugfs, despite its name, is mounted by default in every linux image at /sys/kernel/debug. The officially supported dbginfo.sh script from s390tools collects data from this debugfs filesystem, therefore we do not agree that it is for debug purposes only. We are using dbginfo for collecting diagnostic data on any kind of userspace or kernel errors concurrently on a running image. -- 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
