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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
