It looks to me that a reset on a USB device from an atomic context occurred, causing __usb_queue_reset_device to be executed from a worker thread but this got hung for some reason. The fstat stressor was being run at the time, and that also locks up. So my current hunch is that this may have been triggered by a USB device issue and then it snarls up causing subsequent hangs. Can this test be re-run to see if this fails again. My expectation is that it won't because its not a stress-ng specific triggered issue.
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1652132 Title: Call trace when testing fstat stressor on ppc64el with virtual keyboard and mouse present Status in Stress-ng: New Status in linux package in Ubuntu: Confirmed Bug description: Ubuntu 16.04.1 Kernel = 4.4.0-53-generic-74-Ubuntu ppc64le When running the stress-ng "fstat" stressor, it is trying to access the USB bus and giving a call trace and locking up any further USB activity (lsusb hangs). This only seems to occur so far on openpower(Firestone and Garrison) where there is a virtual USB keyboard and mouse built into the BMC. From lsusb(before crashing): Bus 001 Device 004: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard and Mouse Another openpower server(Briggs) has no virtual usb devices and does not experience the failure. Please see attached kern.log and dmesg output for further details. To manage notifications about this bug go to: https://bugs.launchpad.net/stress-ng/+bug/1652132/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
