On Sat, 2014-11-29 at 12:20 +0100, Tomas Pospisek wrote: [...] > 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. I think we can't generically tell what other modes might be available. > After that nothing more happens. Did you expect the phone to be switched to MTP mode? Or is that controlled only by the phone? > 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. No new device has appeared. > 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? Device enumeration and matching devices to drivers is all done in-kernel. (Userland can override device/driver matching to some extent, but rarely does.) udev is responsible for loading driver modules, creating device nodes under /dev, and so on. It can also run arbitrary commands, which could include triggering a mode switch if possible. > 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. And is that what you expected to happen automatically (after 3)? It is hard to understand why it didn't happen then but only after reloading the driver. Perhaps the phone's USB mass storage implementation doesn't work if the usb-storage driver probes it too soon after it's attached. This might need a workaround in the driver. > 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 It's the kernel; 'reportbug kernel' should work. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less.
Attachment:
signature.asc
Description: This is a digitally signed message part