[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upgrading to jessie broke usb_storage on a mode switched device



So, since there hasn't been any reaction to this, let me try to ask a
few additional questions, that might help me to find out where to dig next:

Am 27.11.2014 um 18:53 schrieb Tomas Pospisek:
> Am 27.11.2014 um 17:12 schrieb Thomas Goirand:
>> On 11/27/2014 09:28 PM, Tomas Pospisek wrote:
>>> Hello,
>>>
>>> after upgrading to jessie(-with systemd) connecting my mobile to the
>>> latop as a usb storage device stopped working.
>>>
>>> I do have to "rmmod usb_storage && modprobe usb_storage" in order for
>>> the usb storage devices to become visible every time.
>>>
>>> What is the suggested procedure from here on short of filing a bug
>>> against "general"? I do not have an idea which component between
>>> systemd/udev/usb_modeswitch/the kernel/or other is at fault here, if
>>> even it's the fault of a single package at all. Where does the bug
>>> belong to? Is this more appropriate for debian-user?
>>
>> This sounds like an udev/systemd issue. Do you have any kind of logs to
>> provide? Does "dmesg" says something? Anything in the syslog^W systemd
>> journal?
> 
> Yes, /var/log/messages looks like this:
> 
> Nov 27 13:46:41 hier kernel: [28652.975203] usb 4-1.1: new high-speed USB device number 26 using ehci-pci
> Nov 27 13:46:41 hier kernel: [28653.068821] usb 4-1.1: New USB device found, idVendor=12d1, idProduct=1037
> Nov 27 13:46:41 hier kernel: [28653.068831] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4
> Nov 27 13:46:41 hier kernel: [28653.068836] usb 4-1.1: Product: Android
> Nov 27 13:46:41 hier kernel: [28653.068840] usb 4-1.1: Manufacturer: Android
> Nov 27 13:46:41 hier kernel: [28653.068844] usb 4-1.1: SerialNumber: 4C8BEFBC3276
> Nov 27 13:46:41 hier kernel: [28653.069822] usb-storage 4-1.1:1.0: USB Mass Storage device detected
> Nov 27 13:46:41 hier kernel: [28653.070344] scsi15 : usb-storage 4-1.1:1.0
> Nov 27 13:46:41 hier mtp-probe: checking bus 4, device 26: "/sys/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.1"
> Nov 27 13:46:41 hier mtp-probe: bus: 4, device: 26 was not an MTP device
> Nov 27 13:46:42 hier usb_modeswitch: switch device 12d1:1037 on 004/026
> 
> And that's that. Now when I do "rmmod usb_storage && modprobe usb_storage" the log continues like this:
> 
> Nov 27 13:46:55 hier kernel: [28666.858764] usbcore: deregistering interface driver usb-storage
> Nov 27 13:47:01 hier kernel: [28672.635113] usb-storage 4-1.1:1.0: USB Mass Storage device detected
> Nov 27 13:47:01 hier kernel: [28672.635615] scsi16 : usb-storage 4-1.1:1.0
> Nov 27 13:47:01 hier kernel: [28672.635915] usbcore: registered new interface driver usb-storage
> Nov 27 13:47:02 hier kernel: [28673.633832] scsi 16:0:0:0: Direct-Access     Linux    File-CD Gadget   0000 PQ: 0 ANSI: 2
> Nov 27 13:47:02 hier kernel: [28673.634382] scsi 16:0:0:1: Direct-Access     Linux    File-CD Gadget   0000 PQ: 0 ANSI: 2
> Nov 27 13:47:02 hier kernel: [28673.634813] scsi 16:0:0:2: CD-ROM            Linux    File-CD Gadget   0000 PQ: 0 ANSI: 2
> Nov 27 13:47:02 hier kernel: [28673.636127] sd 16:0:0:0: Attached scsi generic sg2 type 0
> Nov 27 13:47:02 hier kernel: [28673.636856] sd 16:0:0:1: Attached scsi generic sg3 type 0
> Nov 27 13:47:02 hier kernel: [28673.637294] sd 16:0:0:0: [sdb] Attached SCSI removable disk
> Nov 27 13:47:02 hier kernel: [28673.640180] sr1: scsi3-mmc drive: 0x/0x caddy
> Nov 27 13:47:02 hier kernel: [28673.641721] sr 16:0:0:2: Attached scsi generic sg4 type 5
> Nov 27 13:47:02 hier kernel: [28673.642690] sd 16:0:0:1: [sdc] Attached SCSI removable disk
> Nov 27 13:47:11 hier kernel: [28682.358352] sd 16:0:0:0: [sdb] 2310144 512-byte logical blocks: (1.18 GB/1.10 GiB)
> Nov 27 13:47:11 hier kernel: [28682.363018]  sdb:
> Nov 27 13:47:13 hier kernel: [28684.404459] sd 16:0:0:1: [sdc] 62333952 512-byte logical blocks: (31.9 GB/29.7 GiB)
> Nov 27 13:47:13 hier kernel: [28684.411152]  sdc: sdc1
> Nov 27 13:47:23 hier kernel: [28695.050516] FAT-fs (sdc1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
> Nov 27 13:47:23 hier kernel: [28695.075737] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

So in these logs we see that:

1. when I plug in my smartphone
2. the kernel tells me he has noticed it and correctly reports the
   newly discovered device to the log
3. also the usb-storage module reports that it is seeing a new storage
   device on the USB bus. Also correct.
4a. next the mtp-probe reports that the new device is not a MTP device.
    Which is not really totally correct, because the device *is* a MTP
    device, but it only hasn't been mode-switched to that mode of
    operation. But maybe that's just semantical hair splitting on my
    part, and does not matter here - I don't know.

After that nothing more happens.

Now when I do "rmmod usb_storage && modprobe usb_storage" then
everything runs exactly like it did before, except, that:

4b. in this case mtp-probe apparently doesn't have a look on the newly
    appeared device.
5. instead usbcore tells me that it
   "registered new interface driver usb-storage"
6. and subsequently some part (which one?) of the system scans
   the available SCSI devices
7. and then some part (which one?) of the system has a look at the
   newly discovered SCSI device and then
8. makes the SCSI device known and available to the user as /dev/sdb*

Now my question:

Q: Who in the Linux ecosystem is responsible for triggering or
   preventing usbcore as in 4b. to have a look at the USB devices?

Is that someone udev?

To me it appears that once 4b. is done, that triggers the next cascade
of actions, which ultimately leads to the device on the USB bus being
registered as a block device under /dev/sdb.

All of this is of course speculation without any knowledge of how stuff
works in reality, so could be pure imagination.

My working hypothesis is that once I know the answer to the Q: above,
I'll know the culprit and will either/or/and be able to dig further or
report a bug against it.

?
*t


Reply to: