Сбои в работе hotplug2 при загрузке TL-MR3020

[DmitryVS]

Здравствуйте,
хочу спросить совета, где искать корневую причину одного неприятного глюка. Имеется коробочка TL-RM3020 с USB-хабом. К последнему подключен 3G-модем. Спонтанно, при загрузке OpenWRT, случается какой-то сбой и устройства ttyUSB в системе не появляются. При этом я наблюдаю в списке процессов лишнюю копию hotplug2 и три процесса hotplug-call, причём один из них грузит процессор на 100%. Вот так примерно выглядит ps после неудачной загрузки:

  PID USER       VSZ STAT COMMAND
......
  611 root       884 S    /sbin/hotplug2 --override --persistent --set-rules-file /etc/hotplug2.rules --set-coldplug-cmd /sbin/udevtrigger --max-children 1
  619 root       868 S    /sbin/hotplug2 --override --persistent --set-rules-file /etc/hotplug2.rules --set-coldplug-cmd /sbin/udevtrigger --max-children 1
......
 1194 root      1524 S    {hotplug-call} /bin/sh /sbin/hotplug-call block
 1217 root      1560 S    {hotplug-call} /bin/sh /sbin/hotplug-call block
 1223 root      1560 R    {hotplug-call} /bin/sh /sbin/hotplug-call block
......

Здесь процессор кушает PID 1223. Никакой системы я найти не смог, то загрузится нормально, то нет. По логам usb-modeswitch как будто бы отрабатывает:

Sep  8 20:25:07 Swift user.notice usb-modeswitch: 1-0:1.0: Manufacturer=Linux_3.3.8_ehci_hcd Product=Generic_Platform_EHCI_Controller Serial=ehci-platform
Sep  8 20:25:07 Swift user.notice usb-modeswitch: 1-1:1.0: Manufacturer=? Product=USB_2.0_Hub Serial=?
Sep  8 20:25:08 Swift user.notice usb-modeswitch: 1-1.3:1.0: Manufacturer=HUAWEI Product=HUAWEI_Mobile Serial=?
Sep  8 20:25:08 Swift user.notice usb-modeswitch: 1-1.3:1.0: Selecting /etc/usb_modeswitch.d/12d1:14fe for mode switching
Sep  8 20:25:08 Swift syslog.notice usb_modeswitch: switching device 12d1:14fe on 001/003
Sep  8 20:25:08 Swift kern.info kernel: [   38.140000] usb 1-1.3: USB disconnect, device number 3
......
Sep  8 20:25:13 Swift kern.info kernel: [   42.740000] usb 1-1.3: new high-speed USB device number 5 using ehci-platform
Sep  8 20:25:13 Swift kern.info kernel: [   42.870000] option 1-1.3:1.0: GSM modem (1-port) converter detected
Sep  8 20:25:13 Swift kern.info kernel: [   42.870000] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
Sep  8 20:25:13 Swift kern.info kernel: [   42.880000] option 1-1.3:1.2: GSM modem (1-port) converter detected
Sep  8 20:25:13 Swift kern.info kernel: [   42.890000] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1
Sep  8 20:25:13 Swift kern.info kernel: [   42.890000] option 1-1.3:1.3: GSM modem (1-port) converter detected
Sep  8 20:25:13 Swift kern.info kernel: [   42.900000] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
Sep  8 20:25:13 Swift kern.info kernel: [   42.910000] scsi3 : usb-storage 1-1.3:1.4
Sep  8 20:25:13 Swift kern.info kernel: [   42.910000] scsi4 : usb-storage 1-1.3:1.5
Sep  8 20:25:14 Swift kern.notice kernel: [   43.910000] scsi 3:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
Sep  8 20:25:14 Swift kern.notice kernel: [   43.920000] scsi 4:0:0:0: Direct-Access     HUAWEI   SD Storage       2.31 PQ: 0 ANSI: 2
Sep  8 20:25:14 Swift kern.notice kernel: [   43.940000] sd 4:0:0:0: [sda] Attached SCSI removable disk
......
Sep  8 20:25:38 Swift user.notice usb-modeswitch: 1-1.3:1.1: Manufacturer=HUAWEI Product=HUAWEI_Mobile Serial=?
Sep  8 20:25:38 Swift user.notice usb-modeswitch: 1-1.4:1.0: Manufacturer=? Product=USB_DISK_2.0 Serial=070C35210CC0DC28

Но вот ls /dev/ttyUSB* после кривой загрузки внезапно выдаёт пустое место. Может кто сталкивался с подобным поведением hotplug2? С чего это он беситься начинает?

PS: "А вот и он, больной зуб!" https://dev.openwrt.org/ticket/12765 Хм... тикет открыт год назад и как-то грустно там всё. Пора заказывать бубен.

[paulerr]

А если без USBхаба - эффекты остаются?

[DmitryVS]

Сообщение от paulerr

А если без USBхаба - эффекты остаются?

Хабу отцепить непросто, он у меня впаян по самое не балуйся. Пробовал вытаскивать из него USB-флешку - никакой разницы. Глюк возникает непосредственно на этапе создания ttyUSB устройств модема. Смешно, что ядро весело рапортует "GSM modem ... now attached to ttyUSBx" и после этого в /dev устройства напрочь отсутствуют.

killall hotplug2 вызывает, собственно, их прибитие, но остаются висеть три hotplug-call (один так и грузит систему). После этого в системе появляются первые два из трёх портов модема.

kill <PID грузящего систему hotplug-call> прибивает его, а все остальные самовыпиливаются, остаётся один первый ждущий hotplug2. Все порты модема после этого появляются в системе.

Я делаю вывод, что косячит сам hotplug. Что вызывает залипание hotplug-call на последнем из трёх портов не ясно. Драйвер портов тоже получается не при чём, т.к. у людей процесс hotplug-call block залипал на чём угодно вплоть до создания свопа.

Что с этим делать, хрен его знает.
Update:
Ха, /bin/sh /sbin/hotplug-call block это же скрипт, допёрло до меня! Обвешиваем его выдачей диагностики в лог и видим, что останавливается оно на вложенном вызове /etc/hotplug.d/block/10-swap! Проблема, в том, что процесс жрущий процессор это нифига не сам hotplug-call. С таким PID он не вызывался, если моему логу верить. А номер больше последнего вызванного hotplug-call'а. Подозреваю, что это уже 10-swap что-то дёргает неудачно. Буду теперь его ковырять.

[DmitryVS]

В общем, я устал наблюдать спонтанные глюки hotplug2 зависящие от фазы луны и от количества строчек для записи диагностики в лог, которые я добавлял в его скрипты в разных местах. То ли там гонка устраивается, то ли просто руки из задницы у авторов (что первого не исключает), суть одна: стабильно это не работает. Видимо, разбираться со старыми глюками разработчикам не охота, поэтому они просто выкинули hotplug2 из системы и заменили его другим механизмом. Я пошёл по пути наименьшего сопротивления и тоже его выкинул, т.е. перешёл с релиза на транк. Проблема решена.
Вывод: Если у вас странно (иногда или постоянно) ведёт себя hotplug2, в системе возникает две его копии, да ещё дочерний процесс загружает систему на 100%, то проще всего полностью от него избавиться. Переходите со своей сборки на транк. Если вам повезёт и не напоретесь на другой косяк, то проблема будет решена. У меня сейчас собран r39180. Пока сбоев не обнаружено.