I've just bought a new cheap USB flash called "X-G USB 64GB" (http://goo.gl/EkZEdu) and it is able to make a kernel panic. 1. Compile kernel with CONFIG_USB_STORAGE_DEBUG=y 2. Insert flash into USB 2.0 or 3.0 jack ID 1908:1320 GEMBIRD PhotoFrame PF-15-1 3. Run "dd if=/dev/zero of=/dev/sdb bs=1M" 4. After copying about 9.1 Gb: *** thread sleeping usb-storage: Error in queuecommand_lck: us->srb = ffff88008f23e300 usb-storage: Error ... ... *** thread awakened Full log is very big ~80 Mb. See attached "messages.tar.xz". 5. Run "kill -9 pid", wait for 1 minute and remove flash from jack. 6. Kernel panic appears. I've saved vmcore of this panic. See attached "crash-log.txt". I've made such test with several usb host controllers: Intel Corporation 6 Series/C200 Series Chipset Family Etron Technology, Inc. EJ168 ASMedia Technology Inc. ASM1042 SuperSpeed Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 It looks like this problem is not connected with controller. I don't know whether flash is broken, but anyway broken flash should not be able to break kernel. Maybe this bug is connected with https://bugzilla.kernel.org/show_bug.cgi?id=70781, but I could not found any "xhci" messages in my log.
Created attachment 157831 [details] messages.tar.xz
Created attachment 157841 [details] crash-log.txt
On Mon, Nov 17, 2014 at 10:33:40AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=88341 > > Bug ID: 88341 > Summary: Error in queuecommand_lck: us->srb from > usb_stor_control_thread Please send to the linux-usb@vger.kernel.org mailing list.
Actually looks like a block layer bug. Your device went away, and the kernel eventually got bored of it but spewed errors in the process
This bug can't be reproduced today. Please resolve it.