On Mon, 17 Nov 2014, Андрей Аладьев wrote: > See https://bugzilla.kernel.org/show_bug.cgi?id=88341 > > 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". Part of the reason it is so big is because you had another USB storage device attached (a card reader?), and the output for the two devices is all interspersed. The log shows that the device stopped working after about 8.4 GB had been transferred (the exact number of bytes is 8485085696). The system reset the flash drive and tried writing again. The second write also failed, and there was another reset. After that, the errors started to occur. > 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". > > How can I provide more detailed information about this problem? The problem is not in usb-storage, but in the SCSI and block layers. They are not reacting properly to the multiple resets. > 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. As you say, this has no connection with the host controller. You may be able to provoke the problem more quickly if you issue the "dd" command with a "seek=" argument that makes it skip the first 8.4 GB or so of the flash drive. But tracking down the actual cause of the problem will not be easy. Can you try running 3.18-rc5? Maybe it will work better. I'm having problems of my own with the 3.17.y kernels, but the problems seem to be fixed in the 3.18-rc series. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
