On 05/01/2017 at 10:58 PM, Alan Stern wrote: > On Wed, 26 Apr 2017, Andreas Hartmann wrote: > >> On 04/24/2017 at 10:39 PM Alan Stern wrote: >>> On Sun, 23 Apr 2017, Andreas Hartmann wrote: >>> >>>> Am 23.04.2017 um 18:09 schrieb Alan Stern: >>>>> On Sat, 22 Apr 2017, Andreas Hartmann wrote: >>>>> >>>>>>> In the meanwhile, I see another problem. The SCSI residue value is >>>>>>> getting overwritten when new firmware is sent to the device. Like I said >>>>>>> before, it's amazing this driver has ever worked. >>>>>> >>>>>> It depends on how you define "worked" ... >>>>> >>>>> How well _did_ it work in the past? >>>> >>>> As you already could see it: sometimes it has been working, sometimes >>>> not. It's been just chance. I was hoping to get it fixed this way. >>>> >>>> Some time ago, there was a OS driver provided by the manufacturer (?) >>>> (keucr), which worked without any problem (for me). But this driver was >>>> removed in 3.17 [1] and replaced by this one. This driver _never_ worked >>>> reliably. >>> >>> Ah. >>> >>>> I applied this new patch, too and attached the newly created debugs. But >>>> first of all: you are great! The loading of the SD card now works as >>>> expected! This is covered by the logfiles usb-ene-2*. It contains the >>>> physical removing w/o loading the filesystem before (i.e. w/o mount / >>>> unmount and remove procedure by software before) >>> >>> Well, the log does show that the patch wasn't quite correct. Below is >>> an updated version. >>> >>>> The second pair of logfiles usb-ene-3* covers a *new* problem during >>>> removing of SD cards via software after mount / umount. The problem is, >>>> that on removing it via GUI, suddenly *3* device entries appear, which >>>> could be activated (the same as the initial entry). After a few seconds, >>>> 2 of them disappeared again and one stays. This happens with two >>>> different SD cards here, another card doesn't show this problem. >>>> >>>> I would be very glad if you could fix this hopefully last issue, too :-) >>>> (if it is a problem at all). >>> >>> It's possible that the updated patch will help with all those >>> notifications. At least, the sense data should now be correct. >>> >>> As for the 3 device entries, I'm not sure where to look for them in >>> your logs. >> >> The remove part should start in usb-ene-3.log.gz with >> >> [ 4261.261188] *** thread awakened > > Starting from that point, the log file shows four apparently successful > writes, followed by what looks like a re-scan of the device and a bunch > of reads. Could it be that the rescan is responsible for those log entries, which can be seen after removal? A normal removal works like this: click on remove and after a few seconds (stating, that the device is ready to be removed now) the device entry disappears. In this case, it's working like this: Click on remove. Then always 3 device entries appear (stating, that the device could be removed now) and shortly after, there are two entries, each of them claiming that there are two actions for this device (opening with filemanager or with some other application). Some time later, one of those two entries disappear. With the resulting entry, the device can be reopened again (exactly the same entry as on initially plugged in card). >From my point of view, the device never got disabled - if it would have been disabled, it wouldn't be possible to reload it again after removing (by click) without replugging it. > >> In usb-ene-3.pcapng.gz it should start around package 2925. > > That is indeed where the disconnect first appears. > >> But to be honest - I'm missing some URB packages in the pcapng-file >> which are reported in the log file: Between package 2924 and 2925 are >> about 8s difference. I can't find this difference in the logfile. Is it >> possible that there are some URBs not being sent out? > > No, your files are correct. The last READ command finishes at > timestamp 4261.990022 in the log file (entry 2924 in the pcap file). > Everything after that is ALLOW MEDIUM REMOVAL, REQUEST SENSE, and TEST > UNIT READY until timestamp 4269.794577 (when the disconnect occurs), > and for those commands the driver does not perform any communication > with the device. > > Which for TEST UNIT READY, at least, is undoubtedly a bug. That > command should return a failure if the card has been removed, and > obviously it can't do that if it doesn't check with the device to see > whether the card is still present. > > There's still no indication of three extra device entries anywhere. > > Alan Stern > Thanks, kind regards, Andreas -- 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
