Opened 5 years ago
Closed 5 years ago
#38 closed баг (fixed)
USB disconnect
Reported by: | san | Owned by: | andrei |
---|---|---|---|
Priority: | critical | Milestone: | 1 очередь |
Keywords: | Cc: | andrei, AlexLir |
Description
В логах устройства клиент2 довольно часто встречаются такие записи:
Jul 4 08:47:14 kernel: usb 1-2: USB disconnect, device number 6
...
Jul 4 09:30:41 kernel: usb 1-2: USB disconnect, device number 7
...
Jul 4 09:56:34 kernel: usb 1-2: USB disconnect, device number 8
...
Jul 4 10:16:28 kernel: usb 1-2: USB disconnect, device number 9
...
Jul 4 10:33:11 kernel: usb 1-2: USB disconnect, device number 10
...
Рядом с этими записями присутствует 3gd[17863]: sim5320.cpp:164: powering off SIM5320...
Сначала я думал что внезапно произошёл USB disconnect и контроллер по причине того что USB отвалился перезапускает SIM, но Алексей сообщил:
Насколько я помню, такой функции (выключать питание модуля при отключении устройства с шины USB) в устройстве нет. По крайней мене, не помню, чтобы я ее реализовывал. Да и сама эта функция бессмысленна - если плата SAM-3G установлена, то модуль SIM заведомо подключен к шине.
В таком случае возникает вопрос почему контроллер выключает SIM, без видимой причины?
Вот кусок лога вблизи одного из происшествий:
Jul 4 08:30:00 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c7 Jul 4 08:31:06 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c8 Jul 4 08:32:11 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c8 Jul 4 08:33:15 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c7 Jul 4 08:34:20 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c8 Jul 4 08:35:27 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c7 Jul 4 08:36:33 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c7 Jul 4 08:37:40 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c8 Jul 4 08:38:47 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c7 Jul 4 08:39:53 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c8 Jul 4 08:40:58 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c8 Jul 4 08:42:02 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c7 Jul 4 08:42:59 dropbear[18773]: Child connection from 185.232.67.53:46690 Jul 4 08:43:07 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c7 Jul 4 08:43:17 dropbear[18773]: Login attempt for nonexistent user from 185.232.67.53:46690 Jul 4 08:43:20 dropbear[18773]: Client trying multiple usernames from 185.232.67.53:46690 Jul 4 08:43:20 dropbear[18773]: Login attempt for nonexistent user from 185.232.67.53:46690 Jul 4 08:43:28 dropbear[18773]: Client trying multiple usernames from 185.232.67.53:46690 Jul 4 08:43:28 dropbear[18773]: Login attempt for nonexistent user from 185.232.67.53:46690 Jul 4 08:43:33 dropbear[18778]: Child connection from 185.232.67.53:42378 Jul 4 08:43:33 dropbear[18773]: Exit before auth: Exited normally Jul 4 08:43:46 dropbear[18778]: Bad password attempt for 'root' from 185.232.67.53:42378 Jul 4 08:43:48 dropbear[18778]: Client trying multiple usernames from 185.232.67.53:42378 Jul 4 08:43:48 dropbear[18778]: Login attempt for nonexistent user from 185.232.67.53:42378 Jul 4 08:43:50 dropbear[18778]: Login attempt for nonexistent user from 185.232.67.53:42378 Jul 4 08:43:52 dropbear[18778]: Exit before auth: Exited normally Jul 4 08:43:52 dropbear[18779]: Child connection from 185.232.67.53:45110 Jul 4 08:44:01 dropbear[18779]: Login attempt for nonexistent user from 185.232.67.53:45110 Jul 4 08:44:03 dropbear[18779]: Client trying multiple usernames from 185.232.67.53:45110 Jul 4 08:44:03 dropbear[18779]: Login attempt for nonexistent user from 185.232.67.53:45110 Jul 4 08:44:05 dropbear[18779]: Client trying multiple usernames from 185.232.67.53:45110 Jul 4 08:44:05 dropbear[18779]: Login attempt for nonexistent user from 185.232.67.53:45110 Jul 4 08:44:07 dropbear[18779]: Exit before auth: Exited normally Jul 4 08:44:08 dropbear[18780]: Child connection from 185.232.67.53:36009 Jul 4 08:44:12 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c8 Jul 4 08:44:17 dropbear[18780]: Login attempt for nonexistent user from 185.232.67.53:36009 Jul 4 08:44:18 dropbear[18780]: Client trying multiple usernames from 185.232.67.53:36009 Jul 4 08:44:18 dropbear[18780]: Login attempt for nonexistent user from 185.232.67.53:36009 Jul 4 08:44:21 dropbear[18780]: Client trying multiple usernames from 185.232.67.53:36009 Jul 4 08:44:21 dropbear[18780]: Login attempt for nonexistent user from 185.232.67.53:36009 Jul 4 08:44:23 dropbear[18785]: Child connection from 185.232.67.53:54994 Jul 4 08:44:23 dropbear[18780]: Exit before auth: Exited normally Jul 4 08:44:34 dropbear[18785]: Login attempt for nonexistent user from 185.232.67.53:54994 Jul 4 08:44:38 dropbear[18785]: Login attempt for nonexistent user from 185.232.67.53:54994 Jul 4 08:44:41 dropbear[18785]: Client trying multiple usernames from 185.232.67.53:54994 Jul 4 08:44:41 dropbear[18785]: Login attempt for nonexistent user from 185.232.67.53:54994 Jul 4 08:44:44 dropbear[18786]: Child connection from 185.232.67.53:36467 Jul 4 08:44:44 dropbear[18785]: Exit before auth: Exited normally Jul 4 08:45:02 dropbear[18786]: Login attempt for nonexistent user from 185.232.67.53:36467 Jul 4 08:45:08 dropbear[18786]: Client trying multiple usernames from 185.232.67.53:36467 Jul 4 08:45:08 dropbear[18786]: Bad password attempt for 'root' from 185.232.67.53:36467 Jul 4 08:45:12 dropbear[18786]: Client trying multiple usernames from 185.232.67.53:36467 Jul 4 08:45:12 dropbear[18786]: Login attempt for nonexistent user from 185.232.67.53:36467 Jul 4 08:45:17 dropbear[18786]: Exit before auth: Exited normally Jul 4 08:45:17 dropbear[18791]: Child connection from 185.232.67.53:41125 Jul 4 08:45:19 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c7 Jul 4 08:45:28 dropbear[18791]: Login attempt for nonexistent user from 185.232.67.53:41125 Jul 4 08:45:31 dropbear[18791]: Client trying multiple usernames from 185.232.67.53:41125 Jul 4 08:45:31 dropbear[18791]: Login attempt for nonexistent user from 185.232.67.53:41125 Jul 4 08:45:33 dropbear[18791]: Client trying multiple usernames from 185.232.67.53:41125 Jul 4 08:45:33 dropbear[18791]: Login attempt for nonexistent user from 185.232.67.53:41125 Jul 4 08:45:38 dropbear[18791]: Exit before auth: Exited normally Jul 4 08:45:38 dropbear[18792]: Child connection from 185.232.67.53:50434 Jul 4 08:45:47 dropbear[18792]: Login attempt for nonexistent user from 185.232.67.53:50434 Jul 4 08:45:49 dropbear[18792]: Client trying multiple usernames from 185.232.67.53:50434 Jul 4 08:45:49 dropbear[18792]: Login attempt for nonexistent user from 185.232.67.53:50434 Jul 4 08:45:53 dropbear[18792]: Client trying multiple usernames from 185.232.67.53:50434 Jul 4 08:45:53 dropbear[18792]: Login attempt for nonexistent user from 185.232.67.53:50434 Jul 4 08:45:58 dropbear[18792]: Exit before auth: Exited normally Jul 4 08:45:58 dropbear[18793]: Child connection from 185.232.67.53:37539 Jul 4 08:46:24 ntpd[253]: Soliciting pool server 2001:67c:1560:8003::c8 Jul 4 08:46:46 dropbear[18793]: Login attempt for nonexistent user from 185.232.67.53:37539 Jul 4 08:46:49 dropbear[18793]: Client trying multiple usernames from 185.232.67.53:37539 Jul 4 08:46:49 dropbear[18793]: Bad password attempt for 'root' from 185.232.67.53:37539 Jul 4 08:46:50 dropbear[18793]: Client trying multiple usernames from 185.232.67.53:37539 Jul 4 08:46:50 dropbear[18793]: Login attempt for nonexistent user from 185.232.67.53:37539 Jul 4 08:46:51 dropbear[18798]: Child connection from 185.232.67.53:51815 Jul 4 08:46:51 dropbear[18793]: Exit before auth: Exited normally Jul 4 08:46:56 dropbear[18798]: Login attempt for nonexistent user from 185.232.67.53:51815 Jul 4 08:46:57 dropbear[18798]: Login attempt for nonexistent user from 185.232.67.53:51815 Jul 4 08:46:58 dropbear[18798]: Login attempt for nonexistent user from 185.232.67.53:51815 Jul 4 08:46:59 dropbear[18798]: Exit before auth: Exited normally Jul 4 08:46:59 dropbear[18799]: Child connection from 185.232.67.53:34450 Jul 4 08:47:07 dropbear[18799]: Login attempt for nonexistent user from 185.232.67.53:34450 Jul 4 08:47:10 dropbear[18799]: Client trying multiple usernames from 185.232.67.53:34450 Jul 4 08:47:10 dropbear[18799]: Login attempt for nonexistent user from 185.232.67.53:34450 Jul 4 08:47:14 kernel: usb 1-2: USB disconnect, device number 6 Jul 4 08:47:14 kernel: option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 Jul 4 08:47:14 kernel: option 1-2:1.0: device disconnected Jul 4 08:47:14 kernel: option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 Jul 4 08:47:14 kernel: option 1-2:1.1: device disconnected Jul 4 08:47:14 3gd[17863]: sim5320.cpp:164: powering off SIM5320... Jul 4 08:47:14 kernel: option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2 Jul 4 08:47:14 kernel: option 1-2:1.2: device disconnected
Attachments (1)
Change History (23)
comment:1 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
by , 5 years ago
Attachment: | disconnectUSB.txt added |
---|
comment:2 by , 5 years ago
Подобное поведение проявляется на разных устройствах. Лог одного происшествия приложил выше.
Кажется что SIM-ы, которые отваливаются, греются сильнее...
comment:3 by , 5 years ago
Саша выяснил что SIM стабильно отключается при активной передаче данных, если же активно охлаждать его в процессе, то отключения не происходит.
follow-up: 6 comment:4 by , 5 years ago
При тестировании модуля SAM-4G отдельно от устройства выяснилось, что при некоторых условиях SIM может "поддормаживать" несколько секунд, при этом он вообще не отвечает на команды в UART. Затем SIM продолжает работать как ни в чём не бывало.
При подобных условиях в устройстве и наблюдается проблема описанная в тикете.
Таким образом, я предполагаю, что в данном случае сначала по каким-то причинам устройство "пропало" с шины USB (хотя физически модуль оставался подключенным), в результате этого вызов poll() завершился с ошибкой.
Предполагаю что причиной пропадания устройства с шины могло быть это самое "подтормаживание".
Алексей, скажи пожалуйста, если poll() завершился с ошибкой, то контроллер сразу выключает модуль?
comment:5 by , 5 years ago
Priority: | major → critical |
---|
comment:6 by , 5 years ago
Replying to san:
Алексей, скажи пожалуйста, если poll() завершился с ошибкой, то контроллер сразу выключает модуль?
Да.
follow-up: 8 comment:7 by , 5 years ago
Алексей, можешь реализовать такое?:
- если poll() завершился с ошибкой выдать в лог сообщение.
- Выключать SIM не после первой ошибки, а допустим, секунд через 5 (при этом продолжать поллить и надеяться что сим жив)
Думаю, что это поможет в тестировании.
comment:8 by , 5 years ago
Replying to san:
Алексей, можешь реализовать такое?:
- если poll() завершился с ошибкой выдать в лог сообщение.
Могу. Без проблем.
- Выключать SIM не после первой ошибки, а допустим, секунд через 5 (при этом продолжать поллить и надеяться что сим жив)
Нет, не могу. Точнее, могу частично: выключать SIM не сразу - могу, но вот продолжать поллить в эти 5 секунд - не могу (невозможно поллить то, чего нет).
follow-up: 10 comment:9 by , 5 years ago
Нет, не могу
переформулирую:
Есть подозрения что через пару секунд после неудачного poll СИМ оживёт и хочется чтобы контроллер в таком случае продолжил с ним работать не выключая его. А если через 5 секунд не оживёт- тогда уже перезапустить.
Вот так сможешь сделать?
comment:10 by , 5 years ago
Replying to san:
Вот так сможешь сделать?
Да, так можно - через 5 секунд проверить, не появилось ли устройство само, и только если само не появилось, дергать питание.
comment:13 by , 5 years ago
follow-up: 15 comment:14 by , 5 years ago
Удалось выяснить корень проблемы, он оказался совсем в другом месте:
Входной сигнал RESET модуля SIM, через тразистор(инвертер) подключен к PORTB.22 контроллера, в контроллере этот пин подтянут к 1, а на модуле SIM этот сигнал подтянут к 0, получается делитель и на базе транзистора в итоге оказывается напряжение около 0.5 В..(а открывается транзистор при 0.6 В).
В итоге: транзистор закрыт, SIM работает, но при нагреве транзистора(теплом которое выделяет SIM при передаче данных) транзистор открывается и на SIM поступает сигнал reset и он выключается, что приводит к отпаданию USB и так далее.
Алексей, нужно для PORTB.22 включить подтяжку к 0.
comment:15 by , 5 years ago
Replying to san:
Алексей, нужно для PORTB.22 включить подтяжку к 0.
Это решение мне кажется немного странным... Если ты пишешь, что на модуле RESET - это вход, то почему ты предлагаешь на плате SAM5 тоже оставить его входом? Не будет ли логичнее перевести его в режим выхода и установить низкий уровень?
comment:16 by , 5 years ago
Ну насколько я понял, ты его не используешь, поэтому главное чтобы подтяжки к 1 не было.
Не будет ли логичнее перевести его в режим выхода и установить низкий уровень?
Можно и так.
comment:19 by , 5 years ago
Нет ли, случайно, еще каких-то неиспользуемых в работе сигналов с таким же "неопределенным" уровнем?
comment:20 by , 5 years ago
Есть подозрения что через пару секунд после неудачного poll СИМ оживёт и хочется чтобы контроллер в таком случае продолжил с ним работать не выключая его. А если через 5 секунд не оживёт- тогда уже перезапустить.
При резете от транзистора, сим, насколько мы видели выключался, совсем и не оживал.
при некоторых условиях SIM может "поддормаживать" несколько секунд
На модуле в составе устройства, ничего похожего не воспроизводилось пока, только на "голом" модуле наблюдали, но довольно редко (всего раза три, за пару десятков экспериментов)
comment:21 by , 5 years ago
Cc: | added |
---|
Нет ли, случайно, еще каких-то неиспользуемых в работе сигналов с таким же "неопределенным" уровнем?
AlexLir, ответственный за схемотехнику модуля, говорит "вроде бы нет".
comment:22 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
После установки низкого уровня сигнала reset(r160) проблема не воспроизводится.
В представленном фрагменте лога перед записью "powering off SIM5320..." не выведено никаких сообщений, уточняющих причину. Я посмотрел код - в нем есть единственное место, где выполняется выключение модуля без предварительного вывода дополнительного сообщения - когда поллинг /dev/ttyUSB2 вернул ошибку. Таким образом, я предполагаю, что в данном случае сначала по каким-то причинам устройство "пропало" с шины USB (хотя физически модуль оставался подключенным), в результате этого вызов poll() завершился с ошибкой.
Насколько я понимаю, ложное "пропадание" устройства с шины - аппаратная проблема. Предполагаю, что имеет место проблема с напряжением питания модуля SIM на плате SAM-3G. Также нельзя исключить проблемы с самой шиной USB (лишние конденсаторы, дефектная защита и т.п.), что приводит к неустойчивой видимости устройства хостом.