On Sat, 6 May 2017, Andreas Hartmann wrote: > Am 06.05.2017 um 17:16 schrieb Alan Stern: > > On Fri, 5 May 2017, Andreas Hartmann wrote: > > > >>> Ah, I see. The card reader disconnects itself from the USB bus when > >>> there is no card inserted. This means you shouldn't even need to write > >>> to /sys/block/sdb/device/delete; after unmounting all you have to do is > >>> remove the card. Then the device manager should see that it is gone. > >> > >> I tested this situation with the driver from 4.4.x, too, with two > > > > Did you apply my patches to the 4.4.x driver? If not, can you try > > doing the same thing with the patches installed? > > I will try w/ 4.4.x. But I suspect that I'm seeing the rescans here, too. But lets see. > > Unpatched 4.8.x doesn't show any rescans, too. See the attached trace, containing only the remove part. > > > May 06 17:48:47 notebook2 kernel: usb 1-1.1: new high-speed USB device number 4 using ehci-pci > May 06 17:48:47 notebook2 kernel: usb 1-1.1: New USB device found, idVendor=0cf2, idProduct=6250 > May 06 17:48:47 notebook2 kernel: usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 > May 06 17:48:47 notebook2 kernel: usb 1-1.1: Product: UB6250 > May 06 17:48:47 notebook2 kernel: usb 1-1.1: Manufacturer: ENE Flash > May 06 17:48:47 notebook2 kernel: usb 1-1.1: SerialNumber: 606569746801 > May 06 17:48:47 notebook2 kernel: ums_eneub6250 1-1.1:1.0: USB Mass Storage device detected > May 06 17:48:47 notebook2 kernel: scsi host6: usb-storage 1-1.1:1.0 > May 06 17:48:47 notebook2 mtp-probe[3759]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1" > May 06 17:48:47 notebook2 mtp-probe[3759]: bus: 1, device: 4 was not an MTP device > May 06 17:48:48 notebook2 kernel: scsi host6: scsi scan: INQUIRY result too short (5), using 36 > May 06 17:48:48 notebook2 kernel: scsi 6:0:0:0: Direct-Access PQ: 0 ANSI: 0 > May 06 17:48:48 notebook2 kernel: sd 6:0:0:0: [sdb] 3985408 512-byte logical blocks: (2.04 GB/1.90 GiB) > May 06 17:48:48 notebook2 kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0 > May 06 17:48:48 notebook2 kernel: sd 6:0:0:0: [sdb] Write Protect is off > May 06 17:48:48 notebook2 kernel: sd 6:0:0:0: [sdb] Mode Sense: 0b 00 00 08 > May 06 17:48:48 notebook2 kernel: sd 6:0:0:0: [sdb] No Caching mode page found > May 06 17:48:48 notebook2 kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through > May 06 17:48:48 notebook2 kernel: sdb: sdb1 > May 06 17:48:48 notebook2 kernel: sd 6:0:0:0: [sdb] Attached SCSI disk > May 06 17:48:52 notebook2 kernel: REISERFS (device sdb1): found reiserfs format "3.6" with standard journal > May 06 17:48:52 notebook2 kernel: REISERFS (device sdb1): using ordered data mode > May 06 17:48:52 notebook2 kernel: reiserfs: using flush barriers > May 06 17:48:52 notebook2 kernel: REISERFS (device sdb1): journal params: device sdb1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 > May 06 17:48:52 notebook2 kernel: REISERFS (device sdb1): checking transaction log (sdb1) > May 06 17:48:52 notebook2 kernel: REISERFS (device sdb1): Using r5 hash to sort names > May 06 17:48:52 notebook2 udisksd[1751]: Mounted /dev/sdb1 at /run/media/andreas/59c9a0c1-30c7-4be9-b739-73187d586e08 on behalf of uid 1000 > May 06 17:50:04 notebook2 udisksd[1751]: Cleaning up mount point /run/media/andreas/59c9a0c1-30c7-4be9-b739-73187d586e08 (device 8:17 is not mounted) > May 06 17:50:05 notebook2 udisksd[1751]: Unmounted /dev/sdb1 on behalf of uid 1000 > May 06 17:50:24 notebook2 kernel: usb 1-1.1: USB disconnect, device number 4 Yes, no rescans. For future tests, usbmon traces won't be useful. The patches don't make any difference to the USB traffic (other than fixing that original issue involving non-DMA-able memory). Instead they change the communication between the driver and the SCSI core. USB_STORAGE_DEBUG will be most useful for tracking this. > >> different SD cards. One of the sdcard has a fat FS, the other one reiserfs. > >> > >> The card with the fat fs didn't show any USB traffic while clicking on remove. > >> The GUI just stated, that the SD card could be removed now. > >> > >> The card with the reiserfs did show some USB traffic during unmount > >> (most probably closing the FS). This part can be seen in the attached trace. > >> > >> But it doesn't contain any rescan. And therefore, the behavior, which can > >> be seen in the GUI device manager, is completely normal as expected. > > > > Does this mean you suspect my patches are somehow responsible for the > > rescans? > > Yes :-) > > >> I attached a trace containing the same action with the unchanged > >> driver from 4.4.x > > > > By "unchanged" you mean with no patches, right? > > Yes > > >> Packages 1-92: Initialization of USB trace > >> Packages 93-284: Clicking on remove device (device was mounted before): > >> May 05 15:11:56 notebook2 udisksd[1795]: Cleaning up mount point /run/media/andreas/59c9a0c1-30c7-4be9-b739-73187d586e08 (device 8:17 is not mounted) > >> May 05 15:11:57 notebook2 udisksd[1795]: Unmounted /dev/sdb1 on behalf of uid 1000 > >> > >> Packages 285-332: > >> May 05 15:12:17 notebook2 kernel: usb 1-1.1: USB disconnect, device number 8 > >> > >> > >> => There can't be seen any rescan. > > > > True. But the rescans could be caused by some other change to the > > kernel between 4.4 and 4.10. > > I'm using 4.9.x (because of LTS). Okay. Still, we're talking about two separate sets of changes: the patches and the kernel versions. We need to verify which is responsible. So what happens with the patches applied to 4.8.x? > > The way to find out is to try various > > kernels with the patches applied to the driver. > > > > Incidentally, do you have any idea why your usbmon capture includes > > duplicates of every packet starting from 93? > > Most probably because I selected usbmon1-3. This trace now only used usbmon1. > The duplicates should be gone now. Yes, it's better. 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
