On Fri, 21 Apr 2017, Andreas Hartmann wrote: > > Same here. So the reason usb_stor_set_xfer_buf() wasn't working is > > because it never got called! > > > > Knowing that, it's easy to see where the bug is. It's a completely > > different issue from the bad DMA problem. In fact, I'm surprised that > > this driver ever worked at all. > > > > Please try the patch below. (You can remove the usb_stor_set_xfer_buf > > patch.) > > > Sadly it doesn't work at all (I removed the SD-Card to stop the log entries ...): > > > Apr 21 19:35:23 notebook2 kernel: usb 1-1.1: new high-speed USB device number 4 using ehci-pci > Apr 21 19:35:23 notebook2 kernel: usb 1-1.1: New USB device found, idVendor=0cf2, idProduct=6250 > Apr 21 19:35:23 notebook2 kernel: usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 > Apr 21 19:35:23 notebook2 kernel: usb 1-1.1: Product: UB6250 > Apr 21 19:35:23 notebook2 kernel: usb 1-1.1: Manufacturer: ENE Flash > Apr 21 19:35:23 notebook2 kernel: usb 1-1.1: SerialNumber: 606569746801 > Apr 21 19:35:23 notebook2 kernel: ums_eneub6250 1-1.1:1.0: USB Mass Storage device detected > Apr 21 19:35:23 notebook2 kernel: scsi host6: usb-storage 1-1.1:1.0 > Apr 21 19:35:23 notebook2 mtp-probe[2349]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1" > Apr 21 19:35:23 notebook2 mtp-probe[2349]: bus: 1, device: 4 was not an MTP device > Apr 21 19:35:24 notebook2 kernel: usb 1-1.1: direct-loading ene-ub6250/sd_init1.bin > Apr 21 19:35:24 notebook2 kernel: usb 1-1.1: direct-loading ene-ub6250/sd_init2.bin > Apr 21 19:35:24 notebook2 kernel: scsi 6:0:0:0: Direct-Access USB2.0 CardReader 0100 PQ: 0 ANSI: 2 At least the INQUIRY data is now correct. The patch is partially working. > Apr 21 19:35:24 notebook2 kernel: sd 6:0:0:0: [sdb] 3985408 512-byte logical blocks: (2.04 GB/1.90 GiB) > Apr 21 19:35:24 notebook2 kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0 > Apr 21 19:35:24 notebook2 kernel: sd 6:0:0:0: [sdb] Write Protect is off > Apr 21 19:35:24 notebook2 kernel: sd 6:0:0:0: [sdb] Mode Sense: 0b 00 00 08 > Apr 21 19:35:24 notebook2 kernel: sd 6:0:0:0: [sdb] No Caching mode page found > Apr 21 19:35:24 notebook2 kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through > Apr 21 19:35:24 notebook2 kernel: usb 1-1.1: reset high-speed USB device number 4 using ehci-pci > Apr 21 19:35:24 notebook2 kernel: usb 1-1.1: reset high-speed USB device number 4 using ehci-pci > Apr 21 19:35:25 notebook2 kernel: usb 1-1.1: reset high-speed USB device number 4 using ehci-pci > Apr 21 19:35:25 notebook2 kernel: usb 1-1.1: reset high-speed USB device number 4 using ehci-pci It's hard to see why all those resets are occurring. Can you run this test again and capture a usbmon trace? Just one will be enough. And at the same time, please enable kernel debugging for the driver. Before starting the test, do: modprobe ums_eneub6250 echo 'module ums_eneub6250 =p' >/sys/kernel/debug/dynamic_debug/control dmesg -C You can unplug the device shortly after those resets begin; it's not important to have a lot of repeats of the same thing. Then after the test, collect the output from the dmesg command instead of the contents of the kernel log file. 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
