[thomasschaefer]

I observe that some of my modems which worked fine in the correct coexistence of option and qmi-wwan in past now have conflicts with this modules.

e.g. the K5005

Code: Select all

20471.295201] usb 5-1.4.4: New USB device found, idVendor=12d1, idProduct=14c8
[20471.295211] usb 5-1.4.4: New USB device strings: Mfr=4, Product=3, SerialNumber=0
[20471.295217] usb 5-1.4.4: Product: Vodafone Mobile Broadband (Huawei) 
[20471.295222] usb 5-1.4.4: Manufacturer: Vodafone Group (Huawei) 
[20471.298621] usb-storage 5-1.4.4:1.5: USB Mass Storage device detected
[20471.299007] scsi host6: usb-storage 5-1.4.4:1.5
[20471.299433] usb-storage 5-1.4.4:1.6: USB Mass Storage device detected
[20471.299749] scsi host7: usb-storage 5-1.4.4:1.6
[20472.297642] scsi 6:0:0:0: CD-ROM            Vodafone CD ROM (Huawei)  2.31 PQ: 0 ANSI: 0
[20472.298171] scsi 6:0:0:0: Attached scsi generic sg2 type 5
[20472.298293] scsi 7:0:0:0: Direct-Access     Vodafone Storage (Huawei) 2.31 PQ: 0 ANSI: 2
[20472.299029] sd 7:0:0:0: Attached scsi generic sg3 type 0
[20472.302009] sd 7:0:0:0: [sdc] Attached SCSI removable disk
[20473.074566] usbcore: registered new interface driver usbserial
[20473.074634] usbcore: registered new interface driver usbserial_generic
[20473.074689] usbserial: USB Serial support registered for generic
[20473.086709] usbcore: registered new interface driver option
[20473.086791] usbserial: USB Serial support registered for GSM modem (1-port)
[20473.087222] option 5-1.4.4:1.0: GSM modem (1-port) converter detected
[20473.089586] usb 5-1.4.4: GSM modem (1-port) converter now attached to ttyUSB0
[20473.089689] option 5-1.4.4:1.1: GSM modem (1-port) converter detected
[20473.090082] usb 5-1.4.4: GSM modem (1-port) converter now attached to ttyUSB1
[20473.090166] option 5-1.4.4:1.2: GSM modem (1-port) converter detected
[20473.090523] usb 5-1.4.4: GSM modem (1-port) converter now attached to ttyUSB2
[20473.108803] option 5-1.4.4:1.3: GSM modem (1-port) converter detected
[20473.109202] option 5-1.4.4:1.4: GSM modem (1-port) converter detected
[20473.109605] usb 5-1.4.4: GSM modem (1-port) converter now attached to ttyUSB4
[20473.185542] usbcore: registered new interface driver cdc_wdm
[20473.202955] usbcore: registered new interface driver qmi_wwan
[20473.232411] sr 6:0:0:0: [sr0] scsi-1 drive
[20473.232426] cdrom: Uniform CD-ROM driver Revision: 3.20
[20473.233922] sr 6:0:0:0: Attached scsi CD-ROM sr0

bmork told me to check:

cat /sys/bus/usb-serial/drivers/option1/new_id
12d1 14c8 ff

My question in now: Which program does this?

Is it udev or usb_modeswitch, where can I change / stop this behaviour?

Removing the modules and adding manually is no good permanent solution.

Code: Select all

[21295.531135] usbcore: registered new interface driver option
[21295.531189] usbserial: USB Serial support registered for GSM modem (1-port)
[21295.531510] option 5-1.4.4:1.0: GSM modem (1-port) converter detected
[21295.531840] usb 5-1.4.4: GSM modem (1-port) converter now attached to ttyUSB0
[21295.531901] option 5-1.4.4:1.1: GSM modem (1-port) converter detected
[21295.534270] usb 5-1.4.4: GSM modem (1-port) converter now attached to ttyUSB1
[21295.534358] option 5-1.4.4:1.2: GSM modem (1-port) converter detected
[21295.534804] usb 5-1.4.4: GSM modem (1-port) converter now attached to ttyUSB2
[21299.110953] qmi_wwan 5-1.4.4:1.3: cdc-wdm0: USB WDM device
[21299.112442] qmi_wwan 5-1.4.4:1.3 wwan0: register 'qmi_wwan' at usb-0000:00:1d.7-1.4.4, WWAN/QMI device, 5e:8b:b7:d5:3d:f8
[21299.112642] usbcore: registered new interface driver qmi_wwan

Before I am blaming my distributor I would like to know the reason.

Regards,
Thomas

[LOM]

:

cat /sys/bus/usb-serial/drivers/option1/new_id
12d1 14c8 ff

My question in now: Which program does this?

Is it udev or usb_modeswitch, where can I change / stop this behaviour?

Enable logging in /etc/usb_modeswitch.conf , the log will tell you if it is usb_modeswitch doing it.

What have you changed since "the past" when it worked?

[thomasschaefer]

:

cat /sys/bus/usb-serial/drivers/option1/new_id
12d1 14c8 ff

My question in now: Which program does this?

Is it udev or usb_modeswitch, where can I change / stop this behaviour?

Enable logging in /etc/usb_modeswitch.conf , the log will tell you if it is usb_modeswitch doing it.

What have you changed since "the past" when it worked?

Code: Select all

cat /sys/bus/usb-serial/drivers/option1/new_id 

should stay empty while loading the option module




I made a distribution update(Opensuse 13.2 to 42.1) and the things are getting worse. But I have seen the problem also on manjaro.

The option driver has smart adjustments within the kernel code for a lot of devices. They work fine.

But now somebody (probably from "upstream" , because more than one distributions behave so) has decided to use the hammer-method "option for all" independent of the fact if it disturbing or not.

And it must be outside the kernel because the kernel itself loads and binds option correctly.

This is a step backwards for 4 years.


Thomas

[LOM]

But now somebody (probably from "upstream" , because more than one distributions behave so) has decided to use the hammer-method "option for all" independent of the fact if it disturbing or not.

And it must be outside the kernel because the kernel itself loads and binds option correctly.

This is a step backwards for 4 years.


Thomas

Then I assume that usb_modeswitch is not to blame for it and I wish people would stop doing that. (Hi Bjorn )

usb_modeswitch has since long ago, as a service for the user, loaded the option driver and does it in two different ways:

1. will check if option has bound to any interface of "user defined" class, if not willl modeprobe option. This takes care of the case where option was not loaded in memory.

2. will after a short period check again for driver binding and if no binding will use the new_id function to bind option to the interfaces. This takes care of the case where option is loaded in memory but the device is not in the option drivers list of supported usb id's.
This forced binding will only take place if binding in 1 above fails.

A good test btw is to disable modeswitching in /etc/usb_modeswitch.conf and replug the dongle.
Confirm that it now is in install mode, then run a manual usb_modeswitch command.
This will only switch the dongle but will not do any driver loading.
If there still is an entry in new_id then it is for sure not from usb_modeswitch.

[Josh]

usb_modeswitch (the dispatcher script) waits for any driver to bind automatically. If that does not happen, it'll try to bind the option driver.

This can be disabled per device by adding the "NoDriverLoading=1" option to the respective config file.

Note that Ubuntu has forked the dispatcher so I can't vouch for their's.

[thomasschaefer]

I switched logging on.

sh...

I can't reproduce the problem.

Regards,
Thomas

[Josh]

With the original dispatcher, you can check if there is a file /var/lib/usb_modeswitch/bind_list.

If the dispatcher tries to driver-bind a device for the first time, it will add it to this list.

[thomasschaefer]

There is such a file, the content at the moment is:

Code: Select all

19d2:0326
12d1:1506
19d2:1018
19d2:0039
12d1:14c8

For the moment it works.

Thank you for the help to investigate the problem.

Thomas

[LOM]

I can't reproduce the problem.

but you could easily reproduce the problem previously, right?
So what have you changed or what have you updated? An udev update?

[thomasschaefer]

I am not sure how often.

udev (210) and usb_modeswitch(2.2.5) was not updated since the failed/good case.



How long does the dispatcher wait?
It did happen on a very slow machine. (intel atom)




I am sorry for the false alarm.

Thomas

[Josh]

It's still possible that the alarm is not false. Of course the speed of the respective machine is always a factor if it's given a certain amount of time to complete a certain task.

The dispatcher script waits for 1.5 seconds. However, once the dispatcher did the driver binding for the first time and the bind_list is appended with the new device, the initinal sh script takes over the driver binding from then on.
The reason for this mechanism: after a warm boot of the machine, the modem would still be in modem mode so that no mode-switching would take place - but the modem would cease working if the driver is not bound again ...

So /lib/udev/usb_modeswitch is responsible for the binding of the driver. I just had a look: that part may require improvement. The respective udev rule looks for interface 0 only, and the driver check in /lib/udev/usb_modeswitch looks for ttyUSB specifically. Likely not very good.

[LOM]

The reason for this mechanism: after a warm boot of the machine, the modem would still be in modem mode so that no mode-switching would take place - but the modem would cease working if the driver is not bound again ...

Hmm,,
The service usb_modeswitch does for the user regarding driver loading starts to get a bit messy now with all the components needed and their compatibility with udev and usb power management.

Why do we care so much about "after switching"?
Wouldn't it be better for us (and for you in particular) if there was an udev rule file for all the switched usb id's where udev handled their action(s)?

[Josh]

LOM, I agree regarding "messy".

The reason for all this is somewhat historical. At a time when I received lots of reports about new devices and device IDs, I found myself constantly repeating the suggestion to add the new device IDs to the option driver via "new_id" after switching. At some point I decided to append an automatic facility to do just that.

Back then, there were mainly PPP devices around. I'm aware that this situation has changed and that Network Manager is a lot more clever now.

Bottom line: I'm not opposed to dropping the whole thing ...