Не могу вспомнить когда это случилось первый раз, но похоже мой Xiaomi Mi4c взял привычку отключаться при остаточном заряде 20-30%. В произвольный момент, когда батарея показывает ниже 40% телефон вдруг решает что заряд около нуля и штатно выключается.
На графике батареи видно что с примерно 25% батарея мгновенно "разрядилась" до нуля, а после повторного включения телефона отработала еще несколько часов. Причем повторилась старая проблема с продолжающимся разрядом батареи при подключенном зарядном. Калибровка батареи не помогла - я пробовал полностью разрядить батарею, потом зарядить до 100%, калибровать, разрядить до нуля и снова зарядить до 100%.
В интернете встречаются упоминания, что такое поведение не редкость даже у новых телефонов: произвольное отключение телефона происходит при заряде батареи 20-60%. Похоже это связано с проблемами в прошивке (сейчас у меня установлен CyanogenMod 13.1 от Team Superluminal), т.к. у меня эту проблема появилась относительно недавно и скорее всего связана с последним обновлением прошивки в начале этого года.
Зайдя на форум team superluminal узнал, что теперь они предлагают LineageOS 14.1 для Mi4c - нужно будет попробовать эту прошивку при случае.
Обновлено 5/09/2017: Проблема с внезапным отключением решилась обновлением прошивки до LineageOS 14.1.
Заметки о Linux, системном администрировании, программировании, электронике и не только
16 июня 2017
Xiaomi Mi4c внезапно отключается при заряде батареи 20-30%
01 июня 2017
Разрядился телефон будучи подключенный к зарядному устройству
Не первый раз замечаю что мой Xiaomi Mi4c, подключенный перед сном к зарядному устройству (остаточный заряд 20-30%), к утру разряжается почти до нуля или совсем отключается.
Сегодня утром аккумулятор показывал 2% заряд и я сделал скриншот
Перед подключением зарядного было больше 20% заряда, но после отключения экрана телефон не уснул. Зарядное устройство и кабель - родные.
Похоже из-за какой-то проблемы в прошике телефон клинит и он начинает расходовать больше, чем дает зарядное. Либо в добавок из-за нагрева ограничивается заряд и поэтому его не хватает, чтобы скомпенсировать повышенный расход энергии.
Сегодня утром аккумулятор показывал 2% заряд и я сделал скриншот
Перед подключением зарядного было больше 20% заряда, но после отключения экрана телефон не уснул. Зарядное устройство и кабель - родные.
Похоже из-за какой-то проблемы в прошике телефон клинит и он начинает расходовать больше, чем дает зарядное. Либо в добавок из-за нагрева ограничивается заряд и поэтому его не хватает, чтобы скомпенсировать повышенный расход энергии.
30 мая 2017
Спустя год заметил что отвалился IPv6 на сервере
В процессе прикручивания сертификата Let's Encrypt к своему сайту обнаружил что он более недоступен по IPv6 извне. Причем судя по статистике траффика в панели управления сервером это произошло еще в июне 2016. Сервер имеет IPv4/IPv6 стек и последний был настроен по принципу "пусть будет". А сейчас при валидации домена Let's Encrypt не может соединиться на IPv6 адрес сайта и проверка не проходит.
Доступность сервера по IPv4 проверяется в nagios из дома, а вот проверку доступности IPv6 пришлось добавить в виде костыля (нет у меня другого сервера с IPv6):
Похоже что-то изменилось в маршрутизации у хостера, т.к. ipv6 адрес шлюза пингуется, а вот дальше него - тишина.
Посмотрю что завтра ответит тех. поддержка Hetzner.
UPDATE 31/05/2017
Ответ из техподдержки:
Доступность сервера по IPv4 проверяется в nagios из дома, а вот проверку доступности IPv6 пришлось добавить в виде костыля (нет у меня другого сервера с IPv6):
command['check_ipv6']=/usr/lib/nagios/plugins/check_http -6 -H google.com
Похоже что-то изменилось в маршрутизации у хостера, т.к. ipv6 адрес шлюза пингуется, а вот дальше него - тишина.
$ ip -6 a
1: lo: <loopback> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <broadcast> mtu 1500 qlen 1000
inet6 2a01:4f8:d13:2742::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21c:14ff:fe01:1dba/64 scope link
valid_lft forever preferred_lft forever
$ ip -6 r
2a01:4f8:d13:2742::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
default via 2a01:4f8:d13:2742::1 dev eth0 metric 1024
$ ip -6 neigh
fe80::3285:a9ff:fea4:1ff7 dev eth0 lladdr 30:85:a9:a4:1f:f7 router STALE
2a01:4f8:d13:2742::1 dev eth0 lladdr 30:85:a9:a4:1f:f7 router STALE
$ ping6 -c 5 2a01:4f8:d13:2742::1
PING 2a01:4f8:d13:2742::1(2a01:4f8:d13:2742::1) 56 data bytes
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=1 ttl=64 time=0.281 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=2 ttl=64 time=0.284 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=3 ttl=64 time=0.250 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=4 ttl=64 time=0.223 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=5 ttl=64 time=0.148 ms
--- 2a01:4f8:d13:2742::1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.148/0.237/0.284/0.050 ms
$ ping6 -c5 ipv6.google.com
PING ipv6.google.com(waw02s06-in-x0e.1e100.net) 56 data bytes
--- ipv6.google.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4033ms
Посмотрю что завтра ответит тех. поддержка Hetzner.
UPDATE 31/05/2017
Ответ из техподдержки:
Thanks for trying a reboot first. We've now rechecked the routing of your IPv6-net and we were able to find an issue, which we fixed directly and your server is now back online using the mentioned IPv6.IPv6 снова работает и мне удалось установить сертификат Let's Encrypt для моего сайта.
Обновление BIOS на Dell Latitude E6430
Этот пост ориентирован на технически грамотную аудиторию. Если вы не обладаете необходимыми навыками - не пытайтесь повторить описанное. Я не несу никакой ответственности за ваши ошибки или возможный ущерб, возникший в следствии попытки повторить описанное.
После публикации информации об уязвимости в Intel AMT CVE-2017-5689 (INTEL-SA-00075) отправился на сайт Dell проверить апдейты. На тот момент обновление прошивки для моего Latitude E6430 еще не было выпущено, но в планах значилось начало июня.
На днях проверил обновления еще раз - уже доступна прошивка A21 с исправлением уязвимости. Последний раз обновлял BIOS в ноутбуке сразу после покупки и потому там установлена старая версия A16.
Для обновления скачиваю все доступные прошивки от A16 до A21, которые предназначены для Latitude E6430 (A16, A17, A18, A20, A21) и создаю загрузочный образ FreeDOS, содержащий в себе скачанные прошивки (загрузочный образ можно скачать тут).
Убедидесь что ваша флешка видна в системе как /dev/sdb. В противном случае рискуете затереть системный диск!
Несколько команд для скачивания образа и заливки на флешку:
$ wget http://www.tataranovich.com/public/dell/{e6430_bios_update.img.gz,MD5SUMS}
$ md5sum -c MD5SUMS
$ gunzip e6430_bios_update.img.gz
$ sudo dd if=e6430_bios_update.img of=/dev/sdb
Не продолжайте обновление, если не совпадает контрольная сумма для образа диска!
Далее можно продолжать обновление по аналогии.
Посколько в installation guide для прошивки нет ничего про запрет сквозного обновления, то для ноутбука жены (у нее тоже Latitude E6430) выбрал вариант обновления с версии A16 до A21. Весь процесс обновления занял минут 5 и завершился без ошибок.
А вот с моим ноутбуком такой финт не прошел. На этапе обновления "Sending Intel(R) Management Engine Firmware Update" произошла ошибка "ME FW Update Failed: Internal error: FWU_Buffer". После этого обновление продолжилось и завершилось без ошибок.
Я пробовал гуглить ошибку, но нашел только что ее исправили в обновлении A17. Накатываю прошивку версии A17 - обновилось без проблем. Потом настает очередь A18, A20 и снова A21. В этот раз обновление "Management Engine Firmware" прошло без ошибок.
До обновления версия Intel Management Engine Firmware была 8.1.40.1416, а после установки прошивки A21 стала 8.1.71.3608.
Кстати еще нашел утилиту mei-amt-check для проверки версии AMT:
$ git clone https://github.com/mjg59/mei-amt-check.git $ cd mei-amt-check $ make $ sudo ./mei-amt-check Intel AMT is present AMT is unprovisioned
Этот пост ориентирован на технически грамотную аудиторию. Если вы не обладаете необходимыми навыками - не пытайтесь повторить описанное. Я не несу никакой ответственности за ваши ошибки или возможный ущерб, возникший в следствии попытки повторить описанное.
22 мая 2017
Произвольная скорость порта с Prolific PL2303 в Linux
Тут описаны мои попытки разобраться в настройку нестандартной скорости порта 74880 бит/с используя usb-to-serial конвертор prolific pl2303. Похоже в linux модуль ядра pl2303 реализует только стандартные скорости для передачи данных: 9600, 14400, 28800 и т.д. Но скорость 74880 не входит в этот список и драйвер хотя и принимает настройку через anybaud, но ничего при этом не изменяется.
Я нашел в сети два патча для pl2303, которые решают проблему задания произвольной скорости порта в linux. Первый патч меняет формулу расчета делителя частоты, а второй патч использует эту формулу для любой скорости, не входящей в список поддерживаемых драйвером. Соответственно для стандартных скоростей ничего поменяться не должно.
Чтобы не возиться с установкой модуля в linux я подготовил репозитарий с версией для dkms
После выполнения этой команды dkms должен собрать и установить обновленную версию модуля pl2303 и загрузить его в систему. Теперь можно задать произвольную скорость (например через anybaud, которая есть в том же репозитарии):
Я нашел в сети два патча для pl2303, которые решают проблему задания произвольной скорости порта в linux. Первый патч меняет формулу расчета делителя частоты, а второй патч использует эту формулу для любой скорости, не входящей в список поддерживаемых драйвером. Соответственно для стандартных скоростей ничего поменяться не должно.
Чтобы не возиться с установкой модуля в linux я подготовил репозитарий с версией для dkms
sudo apt-get update sudo apt-get install linux-headers-$(uname -r) dkms wget -O pl2303-dkms.tar.gz https://github.com/tataranovich/pl2303/archive/master.tar.gz tar -xzf pl2303-dkms.tar.gz cd pl2303-master sudo make install
После выполнения этой команды dkms должен собрать и установить обновленную версию модуля pl2303 и загрузить его в систему. Теперь можно задать произвольную скорость (например через anybaud, которая есть в том же репозитарии):
cd pl2303-master ./anybaud /dev/ttyUSB0 74880 Changed successfully.
21 мая 2017
Скорость порта 74880 бит/с в Prolific PL2303
Собираю датчик качества воздуха (температура, относительная влажность и содержание углекислоты) на базе esp8266, который будет интегрирован с системой мониторинга. Сейчас у меня esp8266 есть только в виде модуля ESP-01 (выводы модуля vcc, gnd, ch_en, reset, gpio0, gpio2, rx, tx), но уже заказал модуль в варианте ESP-12S.
На ESP-01 выведены только два gpio, но и те доступны с ограничениями. Оба этих вывода участвуют в выборе режима запуска модуля
Соответственно gpio0/gpio2 желательно не использовать на модуле ESP-01, но поскольку особого выбора не было, то для подключения датчика температуры и влажности DHT22 (AM2302) я использовал gpio2. Чтобы подключить датчик углекислоты mh-z19 мне нужно использовать uart (выводы rx/tx) и после этого для программирования модуля его придется извлекать. Перед подключением датчика проверяю что выдается в uart помимо отладочных сообщений прошивки.
Подключаю конвертер на базе Prolific PL2303, который я использую для связи с компьютеров и настраиваю порт /dev/ttyUSB0 на скорость 115200 бод:
После этого жму reset и вижу "мусор" перед первой строчкой, которую выдает прошивка.
Скорее всего это лог встроенного загрузчика, но который передается на другой скорости (не 115200). Попробовал несколько вариантов 9600, 38400, 57600, но разборчивого текста так и не получилось.
После гугления я выяснил что лог загрузчика передается на нестандартной скорости 74880 бод и потому я вижу "мусор" в терминале. Пробую переключить порт на 74880:
Облом, не дает задать произвольную скорость, но при этом в linux уже давно есть возможность задавать произвольную скорость для последовательных портов. Нашел простую утилитку anybaud.c, которая позволяет выставить произвольную скорость. Компилирую ее и пробую выставить настройку:
Хотя команда и прошла без ошибок, но лучше не стало
Сообщения прошивки превратились в мусор, но сообщения загрузчика текстом не стали.
Загрузил Windows 7 в VirtualBox, пробросил pl2303 в виртуальную машину и попробовал подключиться к порту через Putty
Сначала подумал, что это проблемы из-за эмуляции USB в VirtualBox, но переключение скорости порта в Putty на 115200 опровергает эту теорию
Гугление приносит результат - для поддержки скорости 74880 бод нужно добавить настройку в реестр:
После импорта в реестр перезагрузил виртуальную машину и снова попробовал подключиться к порту к Putty. На этот раз все сработало и появились сообшения загрузчика
Забегая вперед скажу, что я уже нашел способ как пропатчить pl2303 в linux, но напишу об этом в следующий раз.
Обновлено 22/05/2017: описал способ пропатчить модуль ядра pl2303 в linux для поддержки произвольной скорости передачи данных.
![]() |
| ESP8266 ESP-01 |
![]() |
| ESP8266 ESP-12S |
| Mode | gpio0 | gpio2 | gpio15 |
|---|---|---|---|
| UART Download Mode (Programming) | 0 | 1 | 0 |
| Flash Startup (Normal) | 1 | 1 | 0 |
| SD-Card Boot | 0 | 0 | 1 |
Соответственно gpio0/gpio2 желательно не использовать на модуле ESP-01, но поскольку особого выбора не было, то для подключения датчика температуры и влажности DHT22 (AM2302) я использовал gpio2. Чтобы подключить датчик углекислоты mh-z19 мне нужно использовать uart (выводы rx/tx) и после этого для программирования модуля его придется извлекать. Перед подключением датчика проверяю что выдается в uart помимо отладочных сообщений прошивки.
Подключаю конвертер на базе Prolific PL2303, который я использую для связи с компьютеров и настраиваю порт /dev/ttyUSB0 на скорость 115200 бод:
$ stty -F /dev/ttyUSB0 115200 raw $ cat /dev/ttyUSB0
После этого жму reset и вижу "мусор" перед первой строчкой, которую выдает прошивка.
![]() |
| ESP8266 UART 115200 bps |
Скорее всего это лог встроенного загрузчика, но который передается на другой скорости (не 115200). Попробовал несколько вариантов 9600, 38400, 57600, но разборчивого текста так и не получилось.
После гугления я выяснил что лог загрузчика передается на нестандартной скорости 74880 бод и потому я вижу "мусор" в терминале. Пробую переключить порт на 74880:
$ stty -F /dev/ttyUSB0 74880 stty: invalid argument ‘74880’ Try 'stty --help' for more information.
Облом, не дает задать произвольную скорость, но при этом в linux уже давно есть возможность задавать произвольную скорость для последовательных портов. Нашел простую утилитку anybaud.c, которая позволяет выставить произвольную скорость. Компилирую ее и пробую выставить настройку:
$ wget -O anybaud.c https://gist.githubusercontent.com/peterhurley/fbace59b55d87306a5b8/raw/5017e43f9fde34e9ac37ab2c3fd35b5ca3c3e73f/anybaud.c $ gcc -static -o anybaud anybaud.c $ ./anybaud /dev/ttyUSB0 74880 /dev/ttyUSB0 speed changed to 74880 baud
Хотя команда и прошла без ошибок, но лучше не стало
![]() |
| ESP8266 UART 74880 bps |
Загрузил Windows 7 в VirtualBox, пробросил pl2303 в виртуальную машину и попробовал подключиться к порту через Putty
![]() |
| ESP8266 UART 74880 bps в Putty |
Сначала подумал, что это проблемы из-за эмуляции USB в VirtualBox, но переключение скорости порта в Putty на 115200 опровергает эту теорию
![]() |
| ESP8266 UART 115200 bps в Putty |
REGEDIT4 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Ser2pl] "ExtBaudrate"="74880,2147485264"
После импорта в реестр перезагрузил виртуальную машину и снова попробовал подключиться к порту к Putty. На этот раз все сработало и появились сообшения загрузчика
![]() |
| ESP8266 UART 74880 bps в Putty после патча реестра |
Обновлено 22/05/2017: описал способ пропатчить модуль ядра pl2303 в linux для поддержки произвольной скорости передачи данных.
17 мая 2017
Изменения в моем репозитории: Ubuntu Zesty
Добавил поддержку Ubuntu Zesty 17.04 в свой репозиторий и удалил Ubuntu Precise по причине окончания поддержки последнего.
Пакеты для midnight commander (stable и nightly) уже добавлены для Ubuntu Zesty.
Сейчас список поддерживаемых дистрибутивов и архитектур выглядит так:
Debian: wheezy (i386, amd64, armel, armhf), jessie (i386, amd64, armel, armhf, arm64), stretch (i386, amd64), sid (i386, amd64)
Ubuntu: trusty (i386, amd64, armhf, arm64), xenial (i386, amd64), yakkety (i386, amd64), zesty (i386, amd64)
С покупкой raspberry pi 3 планирую добавить полноценный хост для сборки пакетов под архитектуры armel, armhf и arm64. Сейчас пакеты под эти архитектуры собираются в qemu и скорость сборки достаточно медленная.
Начал тестировать jenkins-debian-glue и думать над реорганизацией структуры репозитория. В теперешнем виде пакеты для debian и ubuntu находятся в одной иерархии и к примеру добавление raspbian дает конфликт по именам относительно debian.
Пакеты для midnight commander (stable и nightly) уже добавлены для Ubuntu Zesty.
Сейчас список поддерживаемых дистрибутивов и архитектур выглядит так:
Debian: wheezy (i386, amd64, armel, armhf), jessie (i386, amd64, armel, armhf, arm64), stretch (i386, amd64), sid (i386, amd64)
Ubuntu: trusty (i386, amd64, armhf, arm64), xenial (i386, amd64), yakkety (i386, amd64), zesty (i386, amd64)
С покупкой raspberry pi 3 планирую добавить полноценный хост для сборки пакетов под архитектуры armel, armhf и arm64. Сейчас пакеты под эти архитектуры собираются в qemu и скорость сборки достаточно медленная.
Начал тестировать jenkins-debian-glue и думать над реорганизацией структуры репозитория. В теперешнем виде пакеты для debian и ubuntu находятся в одной иерархии и к примеру добавление raspbian дает конфликт по именам относительно debian.
Подписаться на:
Сообщения (Atom)








