Comment 6 for bug 1652132

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.