FS#74082 - [usb_modeswitch] 2.6.1-2 does not work. Downgrade (to 2.6.1-1) is a workaround.

Attached to Project: Arch Linux
Opened by regid (regid1) - Thursday, 10 March 2022, 02:15 GMT
Last edited by David Thurstenson (thurstylark) - Friday, 11 March 2022, 12:26 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I file the bug here because it is seen with 2.6.1-2. My understanding is that -2 has only arch modifications, possibly only within the compilation
environment. I see the problem with linux 5.16.12.arch1-1. And, possibly with previous versions too. usbutils version is 014-2.

The problem is that the package does not cause a mode switch. Or, more precisely, it may be doing something. But surely not completing its work as expected. Which renders it unusable.
With 2.6.1-1, I get
# journalctl -b /usr/bin/usb_modeswitch
usb_modeswitch[505]: switch device 12d1:1f01 on 003/002
# lsusb | grep 12d1
Bus 003 Device 005: ID 12d1:14dc Huawei Technologies Co., Ltd. E3372 LTE/UMTS/GSM HiLink Modem/Networkcard
# ls /var/log/usb_modswitch*
/var/log/usb_modeswitch_3-4
Where with 2.6.1-2,
# journalctl -b /usr/bin/usb_modeswitch
-- No entries --
# lsusb | grep 12d1
Bus 003 Device 002: ID 12d1:1f01 Huawei Technologies Co., Ltd. E353/E3131 (Mass storage mode)
# ls -l /var/log/usb_modswitch*
ls: cannot access '/var/log/usb_modeswitch*': No such file or directory

It should be stated that my device could be apparently broken in a unique way. But it is, and has been, always working with 2.6.1-1, and possibly with older versions. I reported it, a long time ago, at the upstream forum. And was answered it
looks a kernel issue. Therefore, I hope that brokenness is irrelevant.
For completeness, this possibly unique, brokenness is:

sr 6:0:0:0: [sr1] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
sr 6:0:0:0: [sr1] tag#0 Sense Key : Medium Error [current]
sr 6:0:0:0: [sr1] tag#0 Add. Sense: Unrecovered read error
sr 6:0:0:0: [sr1] tag#0 CDB: Read(10) 28 00 00 00 ff fc 00 00 02 00
critical medium error, dev sr1, sector 262128 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
sr 6:0:0:0: [sr1] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
sr 6:0:0:0: [sr1] tag#0 Sense Key : Medium Error [current]
sr 6:0:0:0: [sr1] tag#0 Add. Sense: Unrecovered read error
sr 6:0:0:0: [sr1] tag#0 CDB: Read(10) 28 00 00 00 fe 80 00 00 3c 00
critical medium error, dev sr1, sector 260608 op 0x0:(READ) flags 0x84700 phys_seg 3 prio class 0
sr 6:0:0:0: [sr1] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
sr 6:0:0:0: [sr1] tag#0 Sense Key : Medium Error [current]
sr 6:0:0:0: [sr1] tag#0 Add. Sense: Unrecovered read error
sr 6:0:0:0: [sr1] tag#0 CDB: Read(10) 28 00 00 00 fe bc 00 00 04 00
critical medium error, dev sr1, sector 260848 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
sr 6:0:0:0: [sr1] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
sr 6:0:0:0: [sr1] tag#0 Sense Key : Medium Error [current]
sr 6:0:0:0: [sr1] tag#0 Add. Sense: Unrecovered read error
sr 6:0:0:0: [sr1] tag#0 CDB: Read(10) 28 00 00 00 fe 80 00 00 02 00
critical medium error, dev sr1, sector 260608 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Buffer I/O error on dev sr1, logical block 32576, async page read
sr 6:0:0:0: [sr1] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
sr 6:0:0:0: [sr1] tag#0 Sense Key : Medium Error [current]
sr 6:0:0:0: [sr1] tag#0 Add. Sense: Unrecovered read error
sr 6:0:0:0: [sr1] tag#0 CDB: Read(10) 28 00 00 00 ff fa 00 00 02 00
critical medium error, dev sr1, sector 262120 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0

Additional info:
* package version(s): 2.6.1-2, compared to 2.6.1-1.
* config and/or log files etc: Default config.
For completeness, what I think is irrelevance for the issue at hand is attached at the end of the description.
* link to upstream bug report, if any: Not that I know of. I think it is arch specific.

Steps to reproduce:
I have a suitable hardware. It is probably much harder, if not practically impossible, without it.
1) Start with a working 2.6.1-1.
2) As per upstream suggestions, set /etc/usb_modeswitch:EnableLogging=1 . It is set to 0 by default.
3) Cold boot. That is, power off. And turn the machine on. I think a cold boot is a must, because, otherwise, the usb device might not required to be modeswitched in all circumstances to function properly.
cp /var/log/usb_modeswitch_<device> /root/usb_modeswitch_<device>.1
rm /var/log/usb_modeswitch_<device>
## Removing the log file is to make sure a new one is created. Initially,
## I erroneously thought the -1 log file is also the -2 file. And then
## noticed, that with -2 no log file was created. So the -1 just kept in
## place.
4) Record the lsusb line of the device, after the package terminated as
expected. Also, observe, as root, the output of
journalctl -b /usr/bin/usb_modeswitch at that time.
5) upgrade 2.6.1-1 to 2.6.1-2.
6) Another cold boot.
7) As in step #4 above, run the lsusb and the journalctl commands. Compare
the output to the previous one.
Was /var/log/usb_modeswitch_<device> created?
This task depends upon

Closed by  David Thurstenson (thurstylark)
Friday, 11 March 2022, 12:26 GMT
Reason for closing:  Fixed
Additional comments about closing:  usb_modeswitch 2.6.1-3
Comment by regid (regid1) - Friday, 11 March 2022, 10:51 GMT
-3, that is 2.6.1-3, is working.

If I got it correctly, difference from -2 is the addition of
/usr/lib/systemd/system/usb_modeswitch@.service.
-3 has it. -1 had it too. -2 did not.
In PKGBUILD terms, the changes are:

5c5
< pkgrel=2
---
> pkgrel=3
12c12
< makedepends=('gcc' 'make')
---
> makedepends=('gcc' 'make' 'systemd')

Which is
https://github.com/archlinux/svntogit-community/commit/a275633b0ad7fc67b92512845fef0dafd0d235b8#diff-37538beb61ff63edebbf735dfcf39e5d732f49183d6beb097169d971875ca422L5-R5 .

More details about it are at https://bugs.archlinux.org/task/66762

Loading...