Можно начать с воспроизведения этой же проблемы на самом свежем ядре. Для убунты качай пакеты здесь: https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.20.3/. Тебе нужно *generic* ядро под amd64.

Только ничего не делайте!

Режимы работы устройства не переключить через «Настройки»? Снимок что там «есть» можете предоставить? Логины, номера, IMEI или что-либо другое не нужно. Можно только описание на что влияют «Настройки». Если только возможно подключение прописать, то да — не поможет.

Повторюсь на всякий случай — пока ничего не пытайтесь там переключить.

если для «этого CDROM-привода» создать отдельное правило udev — это могло бы остановить эти бесконечные попытки? (к сожалению по рукой подобных устройств нет)

если для «этого CDROM-привода» создать отдельное правило udev — это могло бы остановить эти бесконечные попытки? (к сожалению по рукой подобных устройств нет)

Думаю да. Но, ИМХО, это неправильный способ.

Если настоящими сидюками не пользуешься, попробуй просто удалить (переместить куда-нибудь) /lib/udev/rules.d/60-cdrom_id.rules

Это в 99% вина косячных правил systemd-udev и systemd который пытается отработать какой-то ненужный бред - залочить на время какой-то системдешной шняги (автомонтирования?) сидюк в девайсе, где никакого сидюка вообще нет и лочить просто нечего.

не этот, так другой другой «костыль» всё равно делать надо будет. :(

вообще не понятно, почему эта проблема наблюдается. что там не так с этим «приводом», почему он так «раздражает» систему...

вообще не понятно, почему эта проблема наблюдается. что там не так с этим «приводом», почему он так «раздражает» систему...

Эмуляторы сидюков в модемах могут не уметь во всякие расширения которые нужны обычным сидюкам. Ну потому что нет никакого сидюка у которого можно менять скорость там или детектить тип поверхности, задвижки, которую можно залочить, задвинуть или выдвинуть и пр. Win10 от такого вообще помирает с концами (в венде вообще сплошное веселье с USB - c комбинированными USB девайсами, Windows OS Descriptors, 0xEE, etc.). Системда почему-то полагает, что все сидюки одинаковые и умничает. А модем не умеет. Системда думает что сидюк поломан, перезапускает его, и всё по новой.

думает что сидюк поломан, перезапускает его, и всё по новой.

да так понятно :)

просто ранее все «имитации CDROM*» (модемы/флешки/андроид устройства в «режимах»/может «кого-то» забыл) вполне принимались...

Win10 от такого вообще помирает с концами (в венде вообще сплошное веселье с USB - c комбинированными USB

вот это да! прям сенсация — я Windows 10 «видел издалека», но «старые винды» все эти «многослойные» USB-устройства принимали спокойно... или просто устройства попроще были.

Вопрос к производителям: зачем так сложно «упрощать»? и на какие OC оно ориентировано (Windows10, Linux, ... )

просто ранее все «имитации CDROM*» (модемы/флешки/андроид устройства в «режимах»/может «кого-то» забыл) вполне принимались...

Обычно на неиспользуемые функции USB Mass Storage Class вешаются заглушки, которые ничего не делают, просто OK возвращают. Видимо, производитель твоего модема поленился или просто накосячил.

вот это да! прям сенсация — я Windows 10 «видел издалека», но «старые винды» все эти «многослойные» USB-устройства принимали спокойно... или просто устройства попроще были.

Не, там фишка в том, что чтобы венда не падала при втыкании USB девайса нужно особое шаманство. А поддержка composite device в венде ещё и через жопу сделана - не как в линуксе - есть Interface Descriptor - на него драйвер и вешается, Много Interface Descriptor'ов в одном девайсе - ну загрузит оно несколько драйверов и выставит несколько девайсов в /dev/. А в венде всё сложнее - там composite device driver отдельный нужен, который крив и при шаге в сторону от того, что он ожидает, всё это с грохотом падает. Разумеется почти все производители на венде и тестируют свои девайсы и драйвера, так что встретится с падениями венды можно только если ты сам эти USB девайсы делаешь. Но если делаешь, то сваять USB свисток который будет наглухо ронять любую венду при втыкании - ваще не проблема.

спасибо за разъяснения: с точки зрения пользователя «в винде всё работает», естественно «что» там в действительности и «как» пользователь может только предполагать.

(модем не у меня, я не ТС)

Если настоящими сидюками не пользуешься, попробуй просто удалить (переместить куда-нибудь) /lib/udev/rules.d/60-cdrom_id.rules

Переименовал на old.60-cdrom_id.rules

Не помогло

Также ребутнулся

Переименовал на old.60-cdrom_id.rules

Тебе его удалить из этой директории надо, а не переименовать. Он всё равно будет выполняться, если присутствует.

Тебе его удалить из этой директории надо, а не переименовать. Он всё равно будет выполняться, если присутствует.

Ок, перемещено в ~ и перезагружено - проблема прежняя.

Ты ядро то попробовал самое свежее? С ним всё тоже точно так же?

Только что попробовал - проблема прежняя.

Вообще я бы рассмотрел любой костыль, лишь бы работало.

Значит ещё в каких-то рулесах udev на srXX срабатывает.

Кстати, мне помагало лет десять назад. Накостылил тогда скрипт, который при втыкании модема, извлекал его каждый раз. Но я тогда не знал про modeswitch, так что второй вариант разумеется правильнее.

Только что попробовал - проблема прежняя.

Можем попробовать посмотреть что происходит в ядре.

Нужно установить systemtap. Для ubuntu гуглится такая инструкция: https://wiki.ubuntu.com/Kernel/Systemtap. У меня не ubuntu, так что не знаю насколько она верная. Нужно поставить сам systemtap, плюс заголовочные файлы и debuginfo от работающего ядра.

Нужно создать sr.stp с таким содержимым:

probe kernel.function("sr_check_events").call {
        printf("***** sr_check_events() CALL BEGIN *****\n");
        printf("sr_check_events() args: %s\n", $$parms);
        printf("sr_check_events() bt:\n");
        print_backtrace();
        printf("***** sr_check_events() CALL END *****\n\n");
}

probe kernel.statement("sr_check_events@drivers/scsi/sr.c+14") {
        printf("sr_check_events()+14 locals: %s\n\n", $$locals);
}

probe kernel.statement("sr_check_events@drivers/scsi/sr.c+43") {
        printf("sr_check_events()+43 locals: %s\n", $$locals);
        printf("sr_check_events()+43 sshdr: %s\n\n", $sshdr$);
}

probe kernel.function("sr_check_events").return {
        printf("***** sr_check_events() RET BEGIN *****\n");
        printf("sr_check_events() ret: %s\n", $$return);
        printf("***** sr_check_events() RET END *****\n\n");
}

Затем запустить этот скрипт:

stap -v sr.stp 2>&1 | tee sr-stap.log

Лог куда-нибудь запостить.

Привет, так а в чём заключается решение?

Привет.

Фактически я забил и делаю в баш профайле eject на смонтированный привод от модема.

Единственное что... я так и не решил проблему с отловом передёрнутого устройства.

я так и не решил проблему с отловом передёрнутого устройства.

речь о модеме или приводе в модеме?