Linux: Обнаружено пониженное напряжение! (0x00050005) спам dmesg на новом ядре 4.14.30-v7+

Уведомление ядра о пониженном напряжении является новым, но порог и механизм обнаружения не изменились. Теперь вы осознаете тот факт, что ваш Pi недостаточно питается для возложенной на него нагрузки. Это плохо сказывается на производительности и потенциально вредно для стабильности системы.

Я могу сказать из множества тестов и измерений с помощью мультиметра, что 99% «типичных» источников питания USB (зарядные устройства для телефонов, зарядные устройства для гаджетов, блоки питания и т. д.) либо не обеспечивают заявленные усилители, либо падают напряжение. перебор. Или оба. Даже если сам блок питания выдает стабильные 5В при 2-2,5амперах, часто напряжение на конце кабеля слишком сильно падало из-за слишком тонких проводов.

Я хорошо осведомлен о работе блока питания RPi. Но в том-то и дело, что:

• Этого не произошло с более ранним ядром, так почему вы думаете, что это улучшение?
  (Значок вспышки был хорош и достаточно раздражающим!)
• Рассылать спам сообщениями ядра (и всеми другими связанными буферами) с повторяющимися сообщениями на устройстве, которое раньше отлично работало в этих условиях, теперь может привести к чрезмерному износу SD-карты и более сложной отладке, поскольку более старые и более релевантные сообщения ядра получают FIFO. d в конце концов.
• Текущий уровень crit даже не учитывает настройки $ printk и продолжает рассылать спам даже после установки dmesg -n 1 или использования sysctl -w '1 1 1 1' . Так что AFAICT, это не критично , не соответствует стандартному поведению * nix и не дает никаких улучшений.

Этого не произошло с более ранним ядром, так почему вы думаете, что это улучшение?
(Значок вспышки был хорош и достаточно раздражающим!)

Это происходило, вы просто не замечали, что это было. У безголовых пользователей ранее не было автоматического уведомления о том, что произошло пониженное напряжение, полагаясь на ручной запрос прошивки, чтобы выяснить, что это так. Кроме того, KERN_CRIT — это «возникло критическое состояние, подобное серьезному аппаратному или программному сбою», и это соответствующий уровень журнала для состояния, которое может вызвать нестабильность системы.

Обратите внимание, что Pi не гарантирует правильную работу, когда напряжение питания на плате меньше 4,63 В, что (в пределах +-10%), что является точкой, в которой отображается значок, и в новый отчет будет добавлено сообщение журнал. Обратите внимание, что это не означает, что ВАШ конкретный Pi перестанет работать, просто напряжение достаточно низкое, и могут возникнуть проблемы. Если вы получаете сообщения в журнале, значит напряжение падает ниже 4,63, и существует риск нестабильности системы. То, что вы на самом деле не видели никакой стабильности системы, не означает, что риска нет.

Я не уверен, что есть возможность отключить предупреждение, но, честно говоря, это было бы похоже на наклеивание ленты на сигнальную лампу двигателя вашего автомобиля. Хорошо, вы не можете видеть неприятную яркую сигнальную лампочку, но вы рискуете взорвать двигатель.

Давайте, ребята! Я уверен, вы понимаете, что я имел в виду.

Это происходило, вы просто не замечали, что это было.

Я замечал каждый раз, когда на моем экране мигала яркая желтая вспышка, но в то время (до этой проблемы) обычно только тогда, когда процессор был под нагрузкой. Теперь на нем ничего не запущено, а журнал ядра залит чем-то, над чем я больше не властен. В этом проблема. И вы до сих пор не рассмотрели вопрос, почему нельзя настроить это свойство с помощью стандартного инструмента sysctl , предназначенного именно для этого.

Я использую эту конкретную конфигурацию почти 2 года без перерыва и без каких-либо проблем, с которыми я не мог справиться, до этого последнего обновления. Только, как говорится, "чувак, это твой блок питания, возьми новый". Это точно не может быть вашей новой маркетинговой стратегией!? Я много знаю об оборудовании, особенно о встроенном оборудовании, поэтому мне интересно, как остальная часть сообщества почувствует или отреагирует на это, когда узнает.

Так что ясно, что это не является чем-то критическим , и должно требовать не более одного уведомления в журнале ядра (или в зависимости от того, что вам кажется подходящим). Опять же, дело в том, что в своем нынешнем состоянии он рассылает спам любой другой проблеме. Поэтому, как бы вы ни гордились этим улучшением , это просто плохое решение, по крайней мере, с этической точки зрения.

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

@E3V3A

Поэтому, как бы вы ни гордились этим улучшением, это просто плохое решение, по крайней мере, с этической точки зрения.

ИМХО это отличное решение с любой точки зрения.
Представьте себе безголовый пи, на котором вы никогда не увидите проклятого освещения, вы никогда не узнаете, что у вас есть проблемы с питанием, пока не станет слишком поздно или если вы не запустите vcgencmd get_throttled , что вы не запустите, если не подозреваете проблемы с питанием/теплом.

Благодаря этому я обнаружил на своем безголовом пи2, что его блок питания (дешевая китайская хрень) потерял немного сока и больше не мог обеспечить 5v при большой нагрузке (все было в порядке в течение ~ 1 года), и я смог заменить его перед чем-то случилось плохое.

IMO, это большое улучшение, поскольку оно улучшает связь между ядром <-> vc4 и предоставляет предупреждение пользователю.

Вся ваша болтовня про "этику" здесь не имеет смысла.

Так что ясно, что это не является чем-то критическим,

Насколько я знаю (по крайней мере, в мире серверов) проблемы с питанием _являются_ критическими.
Существуют серверы (например, DELL), которые отказываются загружаться, если бюджет мощности ниже расчетного значения BIOS/UEFI.
Если программное обеспечение предупреждает о проблеме с оборудованием, нужно как можно скорее решить эту чертову проблему с оборудованием. Период.

Люди здесь - инженеры, которые проектируют и поддерживают пис, держу пари, они знают, каковы требования к мощности ...

Если вас не устраивает спам в журнале, узнайте, как фильтровать определенные сообщения системного журнала на основе содержимого сообщения,
да, вы можете сделать это и многое другое с помощью rsyslog.

Теперь на нем ничего не запущено, а журнал ядра залит чем-то, над чем я больше не властен

@ E3V3A У тебя отстойное питание, и ты должен это исправить (и свой образ мыслей). На вас, как и на многих других пользователей RPi, влияет явление, называемое падением напряжения. Замените кабель между вашей платой и блоком питания или получите официальный блок питания RPi, и все готово.

Вы даже страдаете от нестабильности и до сих пор не понимаете, что у вас аппаратная проблема? Так же, как этот парень здесь: https://github.com/bamarni/pi64/issues/66

Блоки питания также проявляют эффекты старения, и падение напряжения под нагрузкой является одним из многих симптомов.

@асава

Вся ваша болтовня про "этику" здесь не имеет смысла.

Да, ты прав. Это вообще не место здесь. Это только отражает мое разочарование бесполезными ответами от ваших коллег, я могу только предположить.

@ТомасКайзер

Интересно, что вы ссылаетесь именно на эту проблему, потому что парень конкретно говорит:

Я использую pi3 с «официальным» блоком питания на 2,5 А. Никаких проблем с другими сборками / SD-картами.

а затем продолжает говорить, что:

Пытаясь различными способами уменьшить «нагрузку» на пи, одним из моих решений было создание файла подкачки. Это решило проблему,

Так что это просто показывает, как вы, ребята, любите отмахиваться от любых проблем с помощью общего ответа:
«Твое питание отстой, и ты должен исправить это (и свой образ мыслей)».

Итак, да, тогда имеет смысл мигать этой вспышкой пониженного напряжения каждые несколько секунд, потому что если вы это сделаете, независимо от того, какие проблемы у людей, вы всегда можете вернуться к этому, повторить предложение выше и закрыть проблему. Я бы закрыл эту проблему с помощью потенциального тега: «Мы знаем это лучше, и мы знаем больше о вашем блоке питания и кабеле, который вы используете, чем вы».

Таким образом, для будущих продаж RPi всем было бы намного лучше, если бы вы просто встроили свой волшебный источник питания прямо в устройство, таким образом, больше никогда не будет проблем и жалоб, и вы могли бы сэкономить 1000 человеко-часов работы из-за все эти вопросы, связанные с блоком питания.

Затем Нострадамус предсказал еще в 1500-х годах, что через несколько месяцев будет буря новых проблем, связанных с отказами SD-карт из-за чрезмерного износа и неудачных операций записи на SD ... не говоря уже о накладных расходах на производительность для рассылки спама /var/log/ .

В заключение, единственное серьезное решение для меня (и для вас), похоже, состоит в том, чтобы вернуться к ядру 4.9, и все снова будут счастливы.

@ E3V3A E3V3A Просто чтобы быть уверенным: что напечатано на вашем блоке питания? 4,63В или что-то с 5? Если напечатано 5, понимаете ли вы, что что-то не так, когда устройство, которое будет питаться от этой настройки, сообщает о менее 4,63 В уже без какой-либо нагрузки ? Можете ли вы представить, как низкое напряжение упадет с некоторой нагрузкой или некоторыми периферийными устройствами USB, которым также требуется немного энергии?

Как вы думаете, устройства, которым требуется питание 5 В, работают правильно, когда вы обеспечиваете только 4 В?

В заключение, единственное серьезное решение для меня (и для вас), похоже, состоит в том, чтобы вернуться к ядру 4.9, и все снова будут счастливы.

Просто создайте /etc/rsyslog.d/ignore-underpowering.conf с :msg, contains, "oltage" ~ , и вы сможете наслаждаться нестабильной системой даже с ядром 4.14 :)

Кстати: только что нашел. Существуют SBC, позволяющие осуществлять постоянный контроль входного напряжения. Здесь вы можете увидеть блок питания, который вначале обеспечивал 5,25 В после примерно 1,5 лет постоянной работы: https://forum.armbian.com/topic/5699-how-to-provide-and-interpret-debug-output .

@ТомасКайзер
Я отредактировал файлы конфигурации rsyslog.d , как вы упомянули в /etc/rsyslog.conf по умолчанию с вкладками и без них, например:

:msg, contains, "oltage" ~

Действительно, это удаляет журналы, связанные с напряжением, из файлов /var/log/*.log . :+1:
Но, по-видимому, dmesg , который использует /dev/kmsg и /proc/kmsg , кажется независимым от настроек syslogd и rsyslogd и, таким образом, по-прежнему показывает все записи о пониженном напряжении, как и раньше, с dmesg -e -x . Но я думаю, я могу жить с этим.

Что касается входного напряжения, я удивлен, что детектор может измерять напряжение с точностью до второго десятичного знака 4.63 , но нет возможности прочитать его из /sys. Что это вообще такое? Как и что на самом деле измеряет прибор, когда напряжение ниже этого порога?

В любом случае я сообщу, как только у меня будут значения. В процессе всего этого расследования я, к сожалению, обнаружил множество других неприятных сюрпризов, связанных с этим обновлением. Всевозможные вещи, такие как перезапись конфигураций ALSA, запуск сервисов, которые никогда раньше не запускались, автоматический запуск apt upgrade и т. д. :(

Что касается входного напряжения, я удивлен, что детектор может измерять напряжение с точностью до второго десятичного знака 4,63, но нет возможности прочитать его из /sys. Что это вообще такое? Как и что на самом деле измеряет прибор, когда напряжение ниже этого порога?

Это встроенный порог, реализованный новым PMIC на 3B+ и использующий дискретные компоненты на старых платах — мы знаем только, с какой стороны порога находится напряжение.

Что касается ваших других комментариев по поводу обновления 4.14, это довольно большой шаг по сравнению с 4.9, поэтому я ожидаю некоторых довольно очевидных изменений. Также обратите внимание, что подавляющее большинство изменений относится к основному ядру, а не к Raspberry Pi. Однако автоматически запускать apt update не имеет смысла. Это никогда не должно происходить по умолчанию, и я, конечно, не видел этого ни в одном тестировании (у нас тестировалась версия 4.14 в течение нескольких месяцев или около того).

Однако автоматически запускать apt update не имеет смысла.

Неа.

# cat /etc/cron.daily/apt-compat
...
exec /usr/lib/apt/apt.systemd.daily

# Then in:
# cat /usr/lib/apt/apt.systemd.daily

#!/bin/sh
#set -e
#
# This file understands the following apt configuration variables:
# Values here are the default.
# Create /etc/apt/apt.conf.d/10periodic file to set your preference.
#
...
#
#  APT::Periodic::Enable "1";
#  - Enable the update/upgrade script (0=disable)
...
#  APT::Periodic::Download-Upgradeable-Packages-Debdelta "1";
#  - Use debdelta-upgrade to download updates if available (0=disable)
...

Вы можете видеть это здесь:

# Check for APT services:
# systemctl --all |grep apt-

apt-daily-upgrade.service   loaded    inactive dead      Daily apt upgrade and clean activities
apt-daily.service           loaded    inactive dead      Daily apt download activities
apt-daily-upgrade.timer     loaded    active   waiting   Daily apt upgrade and clean activities                              
apt-daily.timer             loaded    active   waiting   Daily apt download activities

Так что, возможно, он ничего не делает, но он все еще работает каждый день.
Я нашел это, посмотрев в /var/log/daemon.log :

systemd[1]: Starting Daily apt upgrade and clean activities...
systemd[1]: Started Daily apt upgrade and clean activities.
systemd[1]: apt-daily-upgrade.timer: Adding 28min 11.764106s random time.
systemd[1]: apt-daily-upgrade.timer: Adding 19min 6.283733s random time.
systemd[1]: Stopped Daily apt upgrade and clean activities.
systemd[1]: Stopped Daily apt download activities.

дальше не исследовал...

Действительно, это удаляет журналы, связанные с напряжением, из файлов /var/log/*.log.

Я не могу поверить, что вы действительно сделали это вместо того, чтобы решить проблему. Знаете ли вы, что превратили свой Pi в устройство с частотой 600 МГц, игнорируя проблемы с пониженным напряжением? Вы все время работаете с ограничением частоты, и, судя по вашему описанию, ваш блок питания, скорее всего, скоро умрет (поскольку в чем причина того, что сейчас происходит пониженное напряжение даже без нагрузки?)

@ТомасКайзер

Я не могу поверить, что вы действительно сделали это вместо того, чтобы решить проблему.

Проблем не было, пока я не обновился этим ядром!

Так что да, возможно, мой блок питания не идеален и дрянной, но в том-то и дело, что он работал на полной скорости, при средней нагрузке, а все остальное работало более-менее нормально до вашего ядра . Я до сих пор не могу поверить, что вы выпустили это дерьмовое обновление ядра до того, как должным образом протестировали его или получили больше отзывов от сообщества. (Теперь меня уже ждет очередное обновление ядра.) Я уже потратил несколько дней, пытаясь восстановить и исправить все ошибки и проблемы, возникшие в результате этого, и, похоже, мне еще предстоит пройти долгий путь. На самом деле, в этот момент я просто хотел бы понизить рейтинг! К сожалению, на данный момент я не вижу простого способа сделать это. Так что большое спасибо.

И с чего вы взяли, что эта установка намного надежнее?
В прошлый раз, когда я проверял, конденсаторы ненадежны и не очень точны, если только вы не поместите туда конденсаторы военного класса (Radio Shack;).

Так что, если вы действительно используете APX803-46 , тогда существует диапазон V_th : 4.56 4.63 4.70 . Это, по-видимому, хорошо известная проблема, и она хорошо задокументирована здесь . Там предлагают вместо этого использовать APX803-44 с диапазоном: 4.31 4.38 4.45 , и ни у кого не было бы проблем! Одна из основных проблем с вашим дизайном сформулирована так:

Схема входной мощности находится за пределами того, что мы можем контролировать. Такая конструкция вынуждает предприятия создавать, а клиентов приобретать блоки питания, не соответствующие отраслевым стандартам. Причина, по которой некоторые другие адаптеры питания не испытывают этой проблемы, заключается в том, что они обеспечивают опасно высокое напряжение, не соответствующее стандартам. В наших тестах по этой проблеме мы обнаружили, что блоки питания обеспечивают до 5,7 В в открытом состоянии и 5,5 В при нагрузке 0,5 А. Они могут сжечь чувствительную USB-электронику, не имеющую встроенной защиты.

Итак, теперь, пожалуйста, избавьте нас от всех оправданий PSU и верните ядро ​​и прошивку, чтобы они были немного более приемлемыми.

Один из способов сделать это — использовать более широкую постоянную времени для пониженного напряжения. Т.е. среднее напряжение за минуту что ли.

И да, я упоминал об этом раньше, в другом месте. Пожалуйста, предоставьте правильный CHANGELOG для ваших выпусков ядра, чтобы люди не попали в эту ловушку. Было бы здорово иметь возможность использовать apt-get changelog raspberrypi-kernel , но в качестве оправдания мне сказали, что вы не поддерживаете его. Но тогда вы всегда можете задокументировать это в другом месте... На GitHub есть вики-страницы, которые вы знаете!

Так что да, возможно, мой блок питания не идеален и дрянной, но в том-то и дело, что он работал на полной скорости

Неа. Кажется, вы полагаетесь на «стандарты Linux», например

/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

чего вы не можете сделать на Raspberry Pi, так как он содержит фиктивные значения. Когда вы работаете с пониженным напряжением, прошивка ограничивает частоту до 600 МГц, в то время как cpuinfo_cur_freq сообщает вам только нерелевантное число (900 МГц на RPi 2, 1200 МГц на RPI 3 и 1400 МГц на RPi 3+). В настоящее время единственный способ проверить наличие проблемы

vcgencmd measure_clock arm | awk -F"=" '{printf ("%0.0f",$2/1000000); }'

Конечно, вы не одиноки. Особенно безголовые пользователи не понимают, что они все время работают на максимальной частоте 600 МГц :) См., например, https://github.com/bamarni/pi64/issues/4#issuecomment -291425512

cpuinfo_cur_freq - это часы HW (не из ядра) и, кажется, дают тот же результат, что и vcgencmd measure_clock .

Результат следующих 600 или 1200?

sysbench --test=cpu --cpu-max-prime=5000 --num-threads=4 run && vcgencmd measure_clock arm | awk -F"=" '{printf ("%0.0f",$2/1000000); }'

Проблем не было, пока я не обновился с вашим ядром!

Да, ваш Пи был недонапряжен. Тот факт, что не было внешних признаков коррупции и т.п., не отменяет этого факта. Все, что ядро ​​делает по-другому, это СООБЩАЕТ о проблеме. Проблема, которая, возможно, всегда была там, ранее незамеченной.

К вашему сведению, ТКайзер не является сотрудником РПФ, это не «его» ядро. Он хорошо информированный член сообщества, пытающийся помочь вам. Я единственный сотрудник, который сейчас комментирует эту тему.

@JamesH65

Да, ваш Пи был недонапряжен.

Я не утверждаю, что раньше не было проблемы с пониженным напряжением, но я утверждаю, что других проблем у меня не было вообще до этого обновления с 4.9.80, кроме очень редкой (раз в несколько дней) проблемы #2510, которые я разместил и которые до сих пор не рассмотрены, даже если кажется, что это было несколько лет назад.

Прямо перед этим была проблема с недостаточным напряжением, но она была под нагрузкой и отображалась максимум каждые несколько минут. Теперь он появляется каждые несколько секунд ни при какой другой нагрузке, кроме той, что обеспечивается самим обновлением, и при отключенной звуковой карте USB. Я также утверждаю, что когда я в последний раз проверял частоту процессора, вероятно,> 6 месяцев назад, она работала на частоте 1200. Таким образом, для этой проблемы совершенно неуместно неоднократно просить меня опубликовать текущую скорость, поскольку ОП уже заявляет, что я быть задушенным.

Итак, да, я также пытаюсь помочь, сообщая о своих выводах здесь. Но мне уже надоели эти разговоры о блоке питания. Это ужасно дорогой козел отпущения, как ни посмотри. Вы допустили ошибку дизайна, и мы должны жить с этим. Мы по-прежнему любим наши RPi3, и когда они работают, они работают. Мой работал до этого обновления.

Моя самая большая ошибка заключалась в том, что я сначала не проверил все вопросы здесь, прежде чем вслепую обновлять. (Потому что раньше все шло хорошо.)

Отрицание, как говорится, не просто река в Египте.

Вы кажетесь умным, знающим человеком, но вы не можете смириться с тем фактом, что все остальные в этом посте на самом деле пытаются вам помочь - считайте это вмешательством. Уменьшая мощность вашего Pi, вы ограничиваете его производительность и ежедневно рискуете повредить его. @ThomasKaiser пытается сказать вам, что регулирование частоты управляется прошивкой без ведома регулятора ЦП, поэтому, если вы не используете vcgencmd measure_freq arm , вы не получите точного представления о тактовой частоте ARM.

Вы правильно указали, что сообщения ядра слишком часты, и мы готовим патч, чтобы ограничить частоту - начальное сообщение сразу, когда оно впервые появляется (и после долгого перерыва), тогда было бы неплохо периодические дайджесты с подсчетом - но кроме этого мы не планируем менять этот механизм, потому что считаем его важным сервисом для наших пользователей.

с отключенной звуковой картой USB

Итак, эта «звуковая карта» питается от Pi, или почему вы упомянули об этом? Знаете ли вы, насколько низкое напряжение допускается для периферийных устройств USB в соответствии со спецификациями для этого типа устройств? 4,4В или 4,75В?

если вы не используете vcgencmd measure_freq arm , вы не получите точного представления о тактовой частоте ARM.

@pelwell, есть ли шанс исправить это и заставить ядро ​​​​в любом случае сообщать о реальных тактовых частотах?

Насколько нам известно, в силовой схеме нет ошибки проектирования. Вы цитируете стороннего поставщика блоков питания, который утверждает, что это так. Конечно, они продают блок питания конкурента, поэтому явно предвзяты!

Использование блока питания Raspberry Pi не показывает никаких проблем с блоком питания ни при каких обстоятельствах, которые, по словам этих людей, являются проблемами. Тем не менее, мы будем покупать их блок питания для тестирования, потому что нам нравится быть тщательным. Это может занять некоторое время, так как они не доставляются в Великобританию.

@pelwell

дросселирование частоты управляется прошивкой без ведома регулятора процессора,

Я и представить себе не мог, что это так. Спасибо за разъяснения. КСТАТИ. Почему было решено сделать именно так?

@ТомасКайзер

почему вы упоминаете об этом?

К вашему сведению, подключен он или нет, приблизительная постоянная времени между ошибками пониженного напряжения теперь составляет ~ 2 минуты, независимо от наличия звуковой карты USB. Это небольшое улучшение по сравнению со вчерашним ~30 сек. перед удалением уже упомянутого сервисного наворота.

Я хотел бы сделать точные измерения на плате для моих напряжений. Не подскажете, где на плате делать замеры? Судя по схемам выше, есть несколько контрольных точек.

Why was it decided to be done this way?

Архитектура SoC означает, что VC4 в основном отвечает за такие вещи. Так было с Pi1. Google процесс загрузки Pi для деталей.

дросселирование частоты управляется прошивкой без ведома регулятора процессора,

Я и представить себе не мог, что это так. Спасибо за разъяснения. КСТАТИ. Почему было решено сделать именно так?

Идея состоит в том, что ARM, скорее всего, выйдет из строя из-за перегрева или недостаточного напряжения раньше, чем VPU, поэтому VPU имеет автономное управление часами. ARM могут делать запросы, но VPU имеет право вето, которое не подлежит обсуждению по соображениям безопасности.

Это все еще оставляет вопрос о том, почему драйвер cpufreq не информируется о дросселировании, что сводится к выбору в дизайне интерфейса почтового ящика для возврата ранее запрошенной частоты, а не фактической частоты после дросселирования - в противном случае он может получить сбивает с толку, если кажется, что запросы игнорируются. Существует новый вызов почтового ящика, который фактически измеряет часы, но драйвер cpufreq его не использует. Неясно (не читая больше кода), какой (если таковой имеется) эффект, возвращающий фактические, а не ожидаемые часы, будет иметь на платформе cpufreq.

Не подскажете, где на плате делать замеры?

Я бы использовал контакты 4 и 6 на заголовке GPIO. И в случае, если ваша звуковая карта USB питается от Pi (вы отказались отвечать на этот вопрос сейчас во второй раз), вы также можете использовать USB-измеритель мощности на одном из USB-портов, чтобы получить представление о том, как там падает низкое напряжение (4,75 В). это наименьшее допустимое значение для большинства периферийных устройств USB). Но обычно эти вещи не так точны.

@pelwell Не могли бы вы указать мне свойство почтового ящика, которое возвращает фактически измеренные часы?

См. https://github.com/raspberrypi/firmware/issues/956#issuecomment-374323390 .

@ТомасКайзер

если ваша звуковая карта USB питается от Pi

Я думал, что это очевидно. Кроме того, глядя на несколько других проблем, а также из моего собственного опыта, кажется, что RPi не очень довольны использованием USB-концентраторов, поскольку он уже встроен.

Кроме того, AFAICR, более низкое напряжение для USB2 составляет -0,6, что означает 4.40 V .

Я считаю, что это очень зависит от типа используемого концентратора.

Мы являемся довольно крупным пользователем Raspberry Pi в нашей робототехнической компании, и последние несколько дней мы сталкиваемся с последствиями этой проблемы. Вот краткое изложение событий, за которым следует вывод:

Присоединился новый сотрудник, настроил свой собственный raspberry-pi с последним мартовским образом и, работая с подключенным Teensy 3.2, продолжал обнаруживать прерывания последовательной связи USB. Этого не произошло при подключении того же teensy к более старому PI с более старой версией ОС. При сортировке обнаружены события «Обнаружено пониженное напряжение» в журнале сообщений, а также «Не удалось установить DTR/RTS», соответствующие разорванным соединениям.

Затем последовало несколько дней устранения неполадок. Вот что мы нашли:

1. Другой PI (отличный от приведенного выше), который нормально работал в течение года без подключенных периферийных устройств, и красный индикатор никогда не мигал, при обновлении до последней версии ОС начал показывать «Ошибки пониженного напряжения» и красный индикатор мигает всякий раз, когда активность диска была выполнено . На самом деле, даже вызов «dmesg» заставит мигать красный свет, в результате чего событие будет записано в журнал.

2. Я просмотрел эту тему и другие и протестировал ситуацию с железным источником питания: USB-блок питания с конденсатором 1 F на линиях питания и встроенным монитором напряжения и тока USB (да, 1F, а не 1 мкФ). Показание напряжения составило 5,02 В и никогда не опускалось ниже 4,95 В. Даже при этом красный свет будет мигать всякий раз, когда выполняется какая-либо активность диска, например, выдача команды «ls». Никакие периферийные устройства не были подключены, загрузка процессора была близка к нулю. Нет никаких шансов, что входное напряжение КОГДА-ЛИБО опустилось ниже 4,65 В хотя бы на микросекунду, но красный свет все еще мигал.

3. Мы создали совершенно новую SD-карту с декабрьским образом и использовали ее для загрузки точно такого же PI с той же настройкой блока питания. И вот, красная ссылка НИКОГДА не мигает, даже после подключения 4 Teensys к портам USB и выполнения всех видов интенсивной работы с диском.

Вывод один: изменения с декабря по март включают не только дополнительную регистрацию пониженного напряжения, но и способ считывания и проверки напряжения другой. Либо есть ошибка, либо для теста используется какая-то другая точка напряжения на плате, а не входное напряжение источника.

Что ж, схема на Pi3B явно не меняется между версиями ядра, и это та часть, которая фактически выполняет обнаружение. Насколько я знаю, напряжение, при котором он обнаруживает, запрограммировано (не может быть установлено в ПО), все, что делает ПО, это считывает, сработала ли схема (и зажигает светодиод? Не уверен в этом). У 3B+ есть новый чип питания, который теперь выполняет обнаружение, но вы заявили, что он работает уже год, так что, предположительно, это Pi3B.

Вам действительно нужно проверить напряжение на самом Pi — кто знает, какое падение напряжения происходит в устройстве USB и по кабелю между ним и Pi. Я, конечно, видел большие потери, просто используя короткие удлинители USB или переключатели в кабеле.

Сегодня я проводил тестирование на 3B+, используя настольный блок питания. Мне пришлось снизить подачу до 4,72, прежде чем появился значок питания, принимая во внимание потери в кабеле, которые кажутся правильными. Другого сообщения я не видел. Устройство бездействовало на рабочем столе.

@evthree Пожалуйста, подтвердите, какая модель Pi демонстрирует проблему - я не сталкивался с этим раньше.

В верхней части платы написано «Raspberry PI 3 Model B V1.2», а ниже — «(c) Raspberry PI 2015».

На нашем тестовом стенде мы убедились, что все остальное, кроме версии ОС, было одинаковым между двумя тестами, включая тот же PI, тот же источник питания, на нем не работало программное обеспечение, но поведение красного индикатора изменилось. Если бы была добавлена ​​только регистрация пониженного напряжения, то с чего бы красная лампочка изменила свое поведение? И почему USB-соединения обрываются одновременно с событиями регистрации?

Что-то еще определенно происходит, кроме дополнительного ведения журнала. Я убежден, что была введена какая-то трудно обнаруживаемая ошибка, я искренне надеюсь, что кто-то ее ищет.

Я сейчас. Еще одна вещь - пожалуйста, опубликуйте вывод из vcgencmd otpdump , просто чтобы убедиться, что все добавлено, как и должно быть.

Я бы рекомендовал подключить прицел к контактам 4 и 6 GPIO (+5V/GND) и
установка триггера заднего фронта примерно на 4,8 В. Из моего опыта это
наиболее точный способ определить, произошло ли состояние пониженного напряжения.

Мультиметры слишком медленные, чтобы уловить кратковременные провалы напряжения, и если вы
хотите проверить, работает ли обнаружение пониженного напряжения на RPi
правильное использование прицела - единственный надежный способ.

March OS, та, в которой обнаружена проблема:
pi@raspi4 :~ $ cat /etc/debian_version
9.4
pi@raspi4 :~ $ vcgencmd otp_dump
08:00000000
09:00000000
10:00000000
11:00000000
12:00000000
13:00000000
14:00000000
15:00000000
16:00280000
17:1020000а
18:1020000а
19:ффффффф
20:ффффффф
21:ффффффф
22:ффффффф
23:ффффффф
24:ффффффф
25:ффффффф
26:ффффффф
27:00002727
28:3786с562
29:c8793a9d
30:00a02082
31:00000000
32:00000000
33:00000000
34:00000000
35:00000000
36:00000000
37:00000000
38:00000000
39:00000000
40:00000000
41:00000000
42:00000000
43:00000000
44:00000000
45:00000000
46:00000000
47:00000000
48:00000000
49:00000000
50:00000000
51:00000000
52:00000000
53:00000000
54:00000000
55:00000000
56:00000000
57:00000000
58:00000000
59:00000000
60:00000000
61:00000000
62:00000000
63:00000000
64:00000000
65:00000000
66:00000000
пи@распи4 :~

Декабрьская ОС, не проявляющая проблемы:
pi@raspberrypi :~ $ cat /etc/debian_version
9.1
pi@raspberrypi :~ $ vcgencmd otp_dump
08:00000000
09:00000000
10:00000000
11:00000000
12:00000000
13:00000000
14:00000000
15:00000000
16:00280000
17:1020000а
18:1020000а
19:ффффффф
20:ффффффф
21:ффффффф
22:ффффффф
23:ффффффф
24:ффффффф
25:ффффффф
26:ффффффф
27:00002727
28:3786с562
29:c8793a9d
30:00a02082
31:00000000
32:00000000
33:00000000
34:00000000
35:00000000
36:00000000
37:00000000
38:00000000
39:00000000
40:00000000
41:00000000
42:00000000
43:00000000
44:00000000
45:00000000
46:00000000
47:00000000
48:00000000
49:00000000
50:00000000
51:00000000
52:00000000
53:00000000
54:00000000
55:00000000
56:00000000
57:00000000
58:00000000
59:00000000
60:00000000
61:00000000
62:00000000
63:00000000
64:00000000
65:00000000
66:00000000

AFAICR, нижнее напряжение для USB2 составляет -0,6, что означает 4,40 В.

Только для «маломощных» устройств, которым требуется менее 100 мА. Поскольку теперь вы подтвердили, что используете USB-устройство с питанием от хоста (я все время спрашивал о питании, а не о том, есть ли между ними другой концентратор - некоторые из немногих аудиоустройств, которые я знаю, имеют собственный блок питания), нижний предел составляет 4,75 В.

В любом случае: судя по отчету @evthree , проблема также связана с ThreadX с закрытым исходным кодом (прошивка AKA), влияющей на всю эту проблему. Пора перестать терять время ;)

@evthree Я хотел бы локализовать проблему в ядре или прошивке.

1. На рабочем образе от декабря (возможно, вы захотите клонировать карту, чтобы сэкономить время позже), обновите прошивку, оставив ядро ​​без изменений:

pi<strong i="9">@raspberrypi</strong>:~$ sudo SKIP_KERNEL=1 rpi-update

Посмотрите, не сломано ли это.

1. На другой карте установите/клонируйте последний образ и понизьте прошивку до той, что была в декабрьском образе:

pi<strong i="15">@raspberrypi</strong>:~$ sudo SKIP_KERNEL=1 rpi-update a6b3e85

Проверьте, работает ли это.

С программированием Дональда Дака в прошивке, неудивительно, что люди злятся!

Если вы уже спамили журнал ядра с помощью msg1 , то спамьте с помощью msg2 , иначе спамите с помощью msg1 еще раз!

    if (new_uv != old_uv) {
        if (new_uv)
            pr_crit("Under-voltage detected! (0x%08x)\n", *value);
        else
            pr_info("Voltage normalised (0x%08x)\n", *value);
}

Итак, поскольку разработчики rpi здесь не хотят слушать сообщество , мы должны решить эту проблему самостоятельно.

Чтобы отключить дросселирование и спам

Чтобы полностью отключить спам в журнале dmesg или ядра, вы можете поместить это в сценарий оболочки или непосредственно из командной строки в фоновом режиме. Это также приведет к ускорению механизма дросселирования, но вы вернетесь к работе в основном на частоте 1200 МГц. Пока без каких-либо заметных побочных эффектов, за исключением очень небольшого увеличения загрузки процессора. Однако это не удалит вспышку , так как кажется, что она управляется независимо от видеоядра (VC4). Но вы должны иметь возможность удалить его с помощью: avoid_warnings=2 , который отключает наложения предупреждений и разрешает продолжение турбо-режима.

while true; do vcgencmd get_throttled 0xff >/dev/null; done &

Сначала я пытался быть любезным, добавляя sleep(), но, поскольку прошивка с закрытым исходным кодом никогда не бывает приятной, она не имела должного эффекта, пока цикл не стал неограниченным. Использование c-code было бы проще контролировать выполнение.

Следующие варианты обойти это:

• Запишите вышеприведенное как программу переменного тока
• Попробуйте обойти саму команду vcgencmd для большей эффективности
• Напишите модуль ядра, который заменяет или обертывает используемые методы спама.
• Напишите бинарный патч прошивки, который полностью отключит чтение вывода GPIO от перенапряжения.
• Аппаратно взломайте контакт непосредственно на печатной плате. (Должно быть достаточно легко найти и сделать.)

Вы неправильно поняли код драйвера прошивки - old_uv и new_uv фактически являются логическими значениями, а сравнение действует как детектор фронта - одно сообщение для нарастающего фронта, другое для спадающего фронта.

Мы так мало слушали сообщество, что вчера я ни разу не модифицировал драйвер, чтобы добавить ограничение скорости, потратил некоторое время на тестирование, а затем сегодня создал PR.

О, подождите, вот оно. Похоже, мы все-таки послушались.

https://github.com/raspberrypi/linux/pull/2520

И прежде чем обвинять людей в программировании DD, вероятно, лучше понять, что делает код, прежде чем выставлять себя дураком. Помните, люди, которых вы, кажется, так сильно хотите разозлить, — это люди, которые ВАМ нужны, чтобы все исправить.

С моей точки зрения есть 2 варианта использования:
1) Регулируемый источник питания
2) Нерегулируемый источник питания

Случай 1. Текущее поведение ведения журнала полезно для поиска правильных параметров во время выполнения.
Случай 2: Поскольку у пользователя нет возможности сменить блок питания во время работы, такое пинг-понговое поведение между обнаруженным пониженным напряжением и «нормализованным» не помогает. Достаточно напечатать номер только один раз, потому что от предоставленной мощности лучше не станет.

Вот мое предложение:
Добавьте параметр DT или ядра для переключения между следующими режимами:
a - текущее поведение журнала ядра
b - сохранить липкие биты и добавить новые сообщения ядра только в том случае, если новый липкий бит был добавлен

Просто мои два цента

@lategoodbye Я не согласен со случаем 2: если ваш блок питания «заведомо исправен», но у вас есть плохо работающее периферийное устройство, подключенное либо через разъем GPIO, либо через USB-порт, наличие журнала с отметками времени (хотя и с ограничением скорости) позволяет вам выяснить, какое периферийное устройство / состояние использования вызывает пониженное напряжение.

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

@lategoodbye
Ваше предложение прекрасно! Наверное, единственный, который может удовлетворить всех. Я также был бы очень рад, если бы это было добавлено в качестве параметра boot/config.txt или cmdline. Но я явно израсходовал здесь все свои хорошие очки Кармы, так что, возможно, некоторые другие люди тоже могут присоединиться?

@P33M
Несогласие с одним из случаев нецелесообразно, если имеется и другой случай.
(Эта ветка уже стала воплощением всевозможных разногласий на всех уровнях.)
Итак, как вы предлагаете двигаться вперед с этим?

@JamesH65
PR 2520 , возможно, полезен для ванили, но кажется излишним, поскольку для этого у нас уже должны быть элементы sysctl . Следующее должно выполнить то же самое:

sudo sysctl -w kernel.printk_devkmsg=ratelimit
sudo sysctl -w kernel.printk_ratelimit=300
sudo sysctl -w kernel.printk_ratelimit_burst=3

Я использую слово «должен» здесь, потому что, как я упоминал в предыдущем посте, кажется, что они игнорируются, поэтому, если этот PR снова активирует их, это здорово.

Другая проблема с этим PR заключается в том, что он, вероятно, также блокирует все другие сообщения журнала ядра. Именно поэтому я бы проголосовал за предложение Стефана.

PR не использует ванильное ведение журнала скорости - он использует собственный интервал (5 минут) и пакет (3), поэтому на него не влияют настройки ведения журнала скорости ядра (хотя он использует тот же код ведения журнала скорости).

Он был объединен, я сомневаюсь, что у меня будет время внести еще какие-либо изменения. Много других важных дел. Однако мы рассмотрим PR из других источников.

Я пытаюсь лучше понять PR-код raspberrypi.c и то, как он взаимодействует с ядром, sysfs и логами, но не могу найти, куда он идет. Я не вижу никаких следов этого кода ни в kernel.img, ни в каких-либо модулях или библиотеках, даже если:

# cat /lib/modules/4.14.34-v7+/modules.builtin |grep rasp
kernel/drivers/firmware/raspberrypi.ko

Однако ни этого файла, ни его кода нигде нет. Так где же он прячется?

• Что нужно, чтобы написать оверлей DT для реализации предложений Стефана? @lategoodbye

Добавление наложения/параметра тривиально. Расширение драйвера для его поддержки немного больше работы, но не намного. Причина, по которой этого не было сделано, заключается в том, что мы не убеждены, что это разумное изменение — я думаю, что это посылает неверный сигнал, что проблема заключается в управлении предупреждениями, хотя на самом деле проблема заключается в неадекватной системе подачи энергии.

Подобная настройка функций часто выполняется с использованием параметра модуля. Дерево устройств в основном используется для описания оборудования.

Может быть, что-то вроде этого:

static bool rpi_firmware_uvlog = true;
module_param_named(uvlog, rpi_firmware_uvlog, bool, 0600);
MODULE_PARM_DESC(uvlog, "Enable logging of Under-voltage [default=true]");

Мой взгляд на то, должно ли быть легко отключать охранников, таков: пусть люди ходят по канату через Ниагарский водопад, если они этого хотят. Тем не менее, мы должны сделать все возможное, чтобы информировать о связанных с этим опасностях.
Возможно, жирное предупреждение в probe():

    if (!rpi_firmware_ovlog)
        pr_warning("Under-voltage logging has been disabled. This is not recommended etc. etc.\n")

Если мы будем блокировать подобные действия, мы можем оказаться на пути духа хакеров/создателей, и я думаю, что это было бы печально.

Редактировать: овлог -> увлог

Я думаю, что отключить защитные устройства ВСЕГДА должно быть сложно. В противном случае это сделают люди, и это создаст нам больше проблем, чем мы хотим решить. Например, вам нужны всевозможные лицензии, чтобы перебраться через Ниагарский водопад. Люди все еще могут это сделать, это просто PITA, чтобы организовать. Программное обеспечение безопасности находится в той же лодке. Люди могут это сделать - весь исходный код доступен для изменения по своему усмотрению, но я не считаю, что мы должны упрощать это.

Вот как это будет происходить.

Случайный пользователь получает предупреждение о напряжении.
Google
Смотрите, что ему нужен лучший источник питания.
Не могу получить сразу, поэтому выясняет, как проигнорировать сообщение
Устанавливает легко изменяемый параметр модуля, чтобы игнорировать предупреждение.
2 недели спустя SD-карта повреждается, происходит какая-то случайная ошибка USB или какая-то другая проблема, связанная с питанием.
Посты на форуме. Не упоминает, что он отключил предупреждения.
Много времени люди тратят на то, чтобы найти проблему, которая должна была быть очевидной с самого начала.

@JamesH65 :
Моя аналогия с натянутым канатом Ниагарского водопада оказалась наиболее подходящей для объяснения того, почему должно быть сложно обойти проверки безопасности :-)

Что касается сложности обхода, то я не учел, насколько легко компилировать ядро ​​в наши дни. Информация с практическими рекомендациями легко доступна, и это довольно быстро сделать на самом Pi, по сравнению с ночной работой, как это было раньше.

Что касается того, что вы устраняете неполадки в аргументе форума, мне не приходило в голову, что это может быть проблемой, но я просматриваю только несколько форумов и не помогаю людям с проблемами повреждения SD-карты, поэтому я действительно не стал бы т знаю.

Я вижу, что есть новый выпуск Raspbian, в котором есть журнал пониженного напряжения, что, вероятно, означает, что пакет ядра Debian также был обновлен.
Мне будет интересно посмотреть, как это будет развиваться в течение следующих недель.

Не так давно я узнал, что на это влияет сечение силового кабеля, а не только номинал блока питания. Я думаю, было бы неплохо сделать примечание об этом в разделе «Электропитание» в документации.

Всегда очень поучительно видеть, насколько мы разные в этой философии «сделай сам — взломай свое собственное устройство».

AFAICR RPi был основан на идеологии сделать крутое HW доступным для широкой публики, включая детей. Так же, как ребенок с молотком, ножом или огнем рано узнает, как легко что-то разрушить или обжечься, это не должно мешать нам позволять детям использовать эти самые основные инструменты жизни. Или затрудняет их использование и изучение. Так что IMO и в этом конкретном случае я просто не понимаю, как параметр командной строки, полученный из надлежащей документации (со всеми вышеперечисленными предупреждениями), возможно, усугубит ситуацию, чем для людей, пытающихся принудительно подать дополнительное напряжение на свои RPis, используя например, гораздо более опасный метод резервного питания USB или двойное питание из разных источников. Не говоря уже о том, как легко злоупотреблять GPIO. Таким образом, я считаю приведенные выше аргументы в пользу «усложнения» реализации исключительно неубедительными.

В качестве примечания для тех, кто случайно наткнулся на эту тему. Я только что добавил опцию boot config.txt : avoid_warnings=2 и, боже мой, наконец весь этот мусор ядра/dmesg исчез! Кроме того, кажется, что устройство работает более плавно. Да, он дросселирован до 600 МГц, что, я думаю, связано с прошивкой, но уже работает лучше. Мне все еще нужно провести некоторые надлежащие тесты производительности, но я действительно думаю, что когда эти сообщения включены, производительность снижается. Реакция ввода-вывода кажется более нервной и запаздывающей, в то время как журналы ядра забиты спамом. (Примечание. Я все еще на 4.4.14.30, а не на 4.14.34, где были некоторые исправления sysfs и журналов.) Однако загадочно то, почему vcgencmd get_throttle возвращает 0x0 , когда явно устройство задушен. -- [РЕДАКТИРОВАТЬ] Эта опция также отключает дросселирование, поэтому обычный регулятор процессора ядра по требованию (?) работает как надо.

И, конечно же, у нас есть очень занимательная аналогия с автомобилем. Сегодня все автомобили используют CAN BUS, и большинство (даже очень старых) имеют доступ к ODB2, который можно использовать для всех видов диагностики, в том числе для отключения различных сигнальных ламп. Вы можете использовать свой собственный ключ ODB2 BT за 12 долларов и отключить все предупреждения на своем телефоне. И любой, у кого была Audi, VW или BMW, также знает, что некоторые из этих сигнальных ламп двигателя загораются абсолютно ни по какой другой причине, кроме как для раздражения, чтобы попросить владельца отвезти машину в их собственные сервисные центры для проверки через какое-то Х. миль и заставить вас вкладывать дополнительные $$$ продавцам. (Стратегия очень похожа на покупку волшебного блока питания RPi Foundation 5,4 В / 2,5 А.)

Я действительно думаю, что производительность снижается, когда эти сообщения включены. Реакция ввода-вывода кажется более нервной и запаздывающей, в то время как журналы ядра забиты спамом.

То есть вы не только пытаетесь питать свой Pi наихудшим способом, но и запускаете SD-карту из ада? :)

Стандартный интервал фиксации ext4 составляет 5 секунд. Поэтому, когда вы действительно видите, что ваша система тормозит из-за какой-то смехотворной активности диска каждые 5 секунд, вам следует серьезно подумать о замене SD-карты. Производительность произвольного ввода-вывода важна, если вы страдаете от таких проблем, подавляющее большинство SD-карт здесь в значительной степени отстой, поэтому важно покупать только SD-карты, совместимые с A1 или A2 (последний пост этой темы содержит цифры для SanDisk карточки формата А1). Они работают на порядок выше, чем обычные SD-карты. Случайный ввод-вывод с небольшими размерами блоков (запись некоторого содержимого журнала) может выполняться в 100–500 раз быстрее.

Но учитывая то, как вы пытаетесь не улучшить свою ситуацию с недостатком власти, скорее всего, вы заинтересованы только в том, чтобы замаскировать и эту другую проблему? Добавление commit=600 к /etc/fstab сделает эту работу.

Если вы заинтересованы в диагностике проблемы:

sudo apt install sysstat
sudo iostat 10

(следите за процентом %iowait , так как он говорит вам, насколько вся ваша система застряла в IO)

К вашему сведению: это копия/вставка выдержки из спецификаций USB 2.0:

• Функции с низким энергопотреблением должны быть способны работать с входными напряжениями VBUS от4.40 V , измеряется на конце кабеля со штекером.

• Мощные функции должны быть способны работать в режиме малой мощности (одна единица нагрузки) свходное напряжение всего 4.40 V , чтобы его можно было обнаружить и перечислить даже при подключении к концентратору с питанием от шины. Они также должны быть способны работать на полной мощности (до пяти единиц нагрузки) при напряжении VBUS 4,75 В, измеренном на входном конце кабеля с вилкой.

Требования к источнику и потребителю питания для различных классов устройств могут быть упрощены введением концепции единичной нагрузки. Единичная нагрузка определяется как 100 мА. Количество единичных нагрузок, которое может потреблять устройство, является абсолютным максимумом, а не средним значением с течением времени. Устройство может быть как маломощным на одну единицу нагрузки, так и мощным, потребляющим до пяти единиц нагрузки. Все устройства по умолчанию работают с низким энергопотреблением. Переход на большую мощность осуществляется под программным управлением. Программное обеспечение отвечает за обеспечение адекватной мощности, прежде чем позволить устройствам потреблять большую мощность.

Мои измерения:

# Voltage across GPIO pins 4 & 6
Under no load:      4.86 V
Under CPU load:     4.46 V

# Voltage @ PSU:    
Under no load:      5.30 V @ ~300 mA
Under CPU load:     5.40 V @ ~950 mA  <-- I have a good PSU!

# Voltage with no load:
@ PP1/2 : 4.92 V
@ PP35  : 4.89 V
@ PP7   : 4.86 V

# Voltage with CPU load:
@ PP1/2 : 4.64 V
@ PP35  : 4.60 V
@ PP7   : 4.58 V

ЗАМЕТКА:
Все тесты проводились со следующими подключенными периферийными устройствами USB:

Bus 001 Device 005: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter    # USB Sound Card
Bus 001 Device 004: ID 05af:0906 Jing-Mold Enterprise Co., Ltd              # Wireless Keyboard

Стрессовая нагрузка ЦП выполнялась с помощью:
for ((i=0; i<$(nproc --all); i++)); do nice yes >/dev/null & done

Теперь это указывает на то, что либо у меня действительно дерьмовый кабель / соединение (на конце RPi), либо что-то еще не так внутри. Это также объясняет эффект пинг-понга предупреждения о пониженном напряжении, потому что он так близок к порогу 4.63 V .

И моя «SD-карта из ада» отлично справляется со скоростью чтения 20 МБ/с и записью ~8 МБ/с... без каких-либо взломов производительности устройства чтения SD-карт.

И моя «SD-карта из ада» отлично справляется со скоростью чтения 20 МБ/с и записью ~8 МБ/с... без каких-либо взломов производительности устройства чтения SD-карт.

Вы никогда не нажимаете на URL-адреса и не следуете предложениям, верно? :)

Вы говорите о последовательной производительности, которая на 99% не имеет отношения к SBC (они имеют значение для цифровых камер и видеомагнитофонов и таких «потоковых» вариантов использования). Что действительно важно с SBC, так это случайный ввод-вывод, и здесь SD-карты, которые показывают смехотворные последовательные записи ~ 8 МБ / с, обычно чертовски медленны со случайным вводом-выводом. Мы видели, что такие карты работают всего 2 IOPS (операции ввода-вывода в секунду) с шаблонами доступа 16K. В то время как хорошие карты с рейтингом A1 работают в 250-500 раз быстрее! Все дело в IOPS, а МБ/с несколько не имеет значения.

https://forum.armbian.com/topic/954-sd-card-performance/?page=3&tab=comments#comment -49811

И еще раз: используйте iostat 10 параллельно и смотрите процент %iowait и количество записанных данных. Если это постоянно высокое значение, ваша SD-карта нуждается в замене.

Мне очень грустно видеть, что вы ведете себя так невежественно и даже активно продвигаете такие странные идеи, как установка avoid_warnings=2 . Я надеюсь, что люди из RPi уберут эту возможность со следующим обновлением прошивки, поскольку, как ясно видно, это ужасная идея увеличивать усилия поддержки без каких-либо причин...

Итак... похоже, вы нашли свою проблему @E3V3A

Теперь это указывает на то, что либо у меня действительно дерьмовый кабель / соединение (на конце RPi), либо что-то еще не так внутри. Это также объясняет эффект пинг-понга предупреждения о пониженном напряжении, потому что он так близок к порогу 4,63 В.

У вас есть разные типы кабелей для тестирования? У вас есть другие платы RPi для тестирования?

Мне очень грустно видеть, что вы ведете себя так невежественно и даже активно продвигаете такие странные идеи, как установка Avoid_warnings=2. Я надеюсь, что люди из RPi уберут эту возможность со следующим обновлением прошивки, поскольку, как ясно видно, это ужасная идея увеличивать усилия поддержки без каких-либо причин...

Быстро взглянул на код, который имеет дело с «avoid_warnings», все это немного странно и сложно для понимания, но я подозреваю, что вы правы, это не должно останавливать регистрацию проблем с низким напряжением. Что он должен сделать, так это остановить отображение предупреждений (молния), но по-прежнему вести журнал. Дома обсудим.

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

Вы просто описали средний кабель Micro USB. Они никогда не предназначались для передачи более 500 мА, что в значительной степени объясняет, почему питание через Micro USB представляет собой такой беспорядок, если пользователи не тратят дополнительные деньги на блок питания высшего качества с фиксированным кабелем, показывающим низкое сопротивление (блоки питания с фиксированным кабелем должны обеспечивать заявленное напряжение на стороне разъема, поэтому сопротивление кабеля уже учтено.Это имеет огромное значение по сравнению с ситуацией с USB-блоком питания и отдельным кабелем Micro USB)

Я знаю, что вы не посещаете ссылки, а встроенную таблицу:

Следующая ссылка в понятной форме описывает ситуацию/проблемы падения напряжения со средними кабелями Micro USB (обычно с линиями электропередач с рейтингом 26 или даже 28 AWG): https://www.cnx-software.com/2017/04/ 27/выбор-микро-usb-кабеля-для-питания-платы-разработки-или-зарядки-телефонов/

@ТомасКайзер

Во-первых, я хотел бы дополнить вас за ваши огромные усилия, направленные на то, чтобы помочь и убедить нас всех и выше. Хотя меня часто раздражают ваши предложения, я очень ценю их! Возможно, именно потому, что вы способны привести достойные доказательства, даже если вы явно не согласны с большей частью моей собственной идеологии. :) Также спасибо за этот кабельный стол.

Вы никогда не нажимаете на URL-адреса и не следуете предложениям, верно?

Слепое нажатие на URL не означает, что я не следую обоснованным советам и предложениям или не принимаю их. Я очень хорошо знаю о плохих (и поддельных) SD-картах, и это было уже давно. Однако мое повседневное использование очень редко требует такой высокой производительности, как вы предлагаете. Повседневный способ, которым я использую свой RPi, просто не требует такой высокой скорости ввода-вывода R/W. Поэтому до тех пор, пока мне не понадобится более высокая производительность или не начнут появляться серьезные ошибки, я буду продолжать использовать то, что у меня есть. Если вы хотите отправить мне SD-карту за 100 евро, пожалуйста, сделайте это.

... установка avoid_warnings=2 . Я надеюсь, что ребята из RPi уберут эту возможность со следующим обновлением прошивки.

Это должно быть самое идиотское предложение, которое я когда-либо слышал от вас. Это противоречит всем неписаным правилам и фундаментальной природе проектов «сделай сам». Если люди хотят управлять своим HW (или автомобилями) до тех пор, пока они не затормозят, они должны быть в состоянии сделать это без того, чтобы кто-то вроде вас указывал на них пальцем за то, что они «глупые». Если бы вы, ребята, потратили хотя бы часть времени на исправление ошибок и проблем, вместо того, чтобы спорить с ними и людьми, сообщающими о них, мы были бы намного лучше, и не с серийными бомбардировками сломанных обновлений.

Как я сказал выше, тысячи людей используют свои Pi для всевозможных небольших проектов и поддерживают их в рабочем состоянии, пока им не придет в голову эта замечательная идея обновить, просто чтобы узнать, что все дерьмо вырвалось на свободу. Рядом каждый раз!
Люди, с которыми я разговаривал в сообществе MagicMirror, все согласны в одном:
If your MM is working, never, ever update the firmware or kernel!

Нижняя линия. Для тех, кто использует PiHole или какое-либо другое приложение для отображения, это не имеет большого значения. Но когда кто-то интегрировал множество периферийных устройств, таких как распознавание лиц, распознавание голоса, облачный API, внешние датчики, такие как PIR, ультразвук, обнаружение света, ИК-пульт дистанционного управления, внешние элементы управления GPIO и различные USB-устройства, такие как SDR, все на одном устройстве , то ваши сломанные обновления уже не так забавны. Вы делаете это один или два раза, а затем говорите: «Я больше никогда не буду это обновлять». .

@JamesH65

Я подозреваю, что вы правы, это не должно останавливать регистрацию проблем с низким напряжением. Что он должен сделать, так это остановить отображение предупреждений (молния), но по-прежнему вести журнал.

Ваши рассуждения очень пугают, особенно если учесть, что вы являетесь частью фонда RPi! Будете ли вы лучше спать по ночам, если знаете, что моя SD-карта заполняется повторяющимися логами по моему собственному выбору? Я думаю, что вы стали очень предвзятым, и я просто не вижу и не слышу никаких веских доводов в пользу выполнения того, что вы предлагаете ТЗ. Что именно вы надеетесь получить, делая это?

Вот бесплатное предложение по заработку денег от меня:
В вашей следующей итерации любого будущего Raspberry Pi N (4?) вы должны убедиться, что:

1. Используйте разъемы 3A USB-C
2. Соответствовать стандартам USB
3. Включите соединительный кабель с низкими потерями
4. Включите волшебный источник питания, если устройство не соответствует (2).
5. Включите наиболее подходящую SD-карту
6. Включите работающую встроенную звуковую карту с MIC/AUX

Каждый из них сам по себе сэкономит вам массу времени и денег, поскольку вы сможете направить все свои текущие усилия на продажи, маркетинг, разработку и производство, а не спорить.

Просто дайте нам всем знать, когда это произойдет, потому что это будет день, когда я перестану обновлять и покупать ваше аппаратное обеспечение навсегда.

@jakemagee

У вас есть разные типы кабелей для тестирования?

Да, на самом деле, я только сегодня попробовал с другим кабелем, но улучшение было минимальным, но явно заметным.

# Voltage with no load:
@ PP1/2 : 5.00 V
@ PP35  : 4.98 V
@ PP7   : 4.93 V

# Voltage with CPU load:
@ PP1/2 : 4.68 V
@ PP35  : 4.64 V
@ PP7   : 4.58 V

Если люди хотят управлять своим HW (или автомобилями) до тех пор, пока они не затормозят, они должны быть в состоянии сделать это без того, чтобы кто-то вроде вас указывал на них пальцем.

Если бы эти люди не открывали проблемы со службой поддержки и не считали, что они должны винить программное обеспечение в проблемах с оборудованием, все было бы хорошо. Но они это делают и сообщают о различных ненужных результатах своих слабых приключений как о «жучках», тратящих впустую свое и чужое время.

Я участвую в проекте с открытым исходным кодом, посвященном всем видам SBC (кроме Raspberries). Подавляющее большинство «проблем с программным обеспечением», которые возникают у людей, на самом деле

• недостаточная мощность (затрагивает почти только те платы с Micro USB - те, у которых есть бочкообразные разъемы, где пользователям приходилось покупать хороший блок питания с фиксированным кабелем , обычно не затрагиваются)
• что-то пошло не так с SD-картами (мы могли бы устранить многие из этих проблем, просто порекомендовав Etcher больше и обучая пользователей через motd , если они запускают дрянную SD-карту, мы автоматически тестируем карту при первой загрузке) )

Умение различать эти проблемы с оборудованием и реальные проблемы имеет важное значение, если вы хотите тратить время на проблемы с программным обеспечением, а не просто иметь дело с невежеством (как у вас - я действительно не могу поверить, что вы все еще отказываетесь исправить свою ситуацию с недостаточной мощностью) . Итак, теперь, когда ведется регистрация пониженного напряжения, было бы фатально, если бы пользователи могли замаскировать это, поскольку, как мы видим из вас, их даже поощряют делать это...

Поскольку вы, кажется, любите использовать неподходящее оборудование (будь то питание или хранилище), я уже рекомендовал добавить commit=600 к /etc/fstab , чтобы смягчить дрянную производительность случайного ввода-вывода вашей SD-карты (серьезно: если несколько строк журнала каждые несколько секунд приводят к задержке системы, или вы боитесь ведения журнала в целом, это отличная идея, также резко снижающая износ флэш-носителей - «мой» дистрибутив для этой цели реализует log2ram запись содержимого журнала обратно на «диск» просто каждый час по умолчанию)

Я не хочу путаться в этом очень длинном обсуждении, но FWIW я скажу, что я наткнулся на него в поисках способа подавить сообщения ядра из консоли (по моему опыту, это усугубило плохие проблемы, поскольку я я пытаюсь сортировать вещи и завершать работу, но сообщения печатаются прямо поверх файлов в моем редакторе и т. д.), и есть несколько способов сделать это, например, dmesg -n 1 см.
https://superuser.com/questions/351387/how-to-stop-kernel-messages-from-flooding-my-console#answer -351402
В предыдущем комментарии предполагалось, что это не работает, но, похоже, для моих целей это работало нормально (например, на RPi 3 B+ сообщения ядра не выводились на мою консоль, хотя они все еще появляются в выводе dmesg )

У меня такая же проблема. Я использовал зарядное устройство 5V 2A и залил dmesg

Обнаружено пониженное напряжение! (0x00050005)
Напряжение нормализовано (0x00000000)

Итак, я купил модуль конвертера DC-DC (понижаю напряжение с 12В до 5В) hy196_0815.

Ошибки не исчезли. Далее меняю кабель mircorusb (от huawei P9 lite) и думаю на этом все.
RPI 3 B+ работает до сих пор 12 часов, и ошибок в dmesg не появлялось.
Так что хороший кабель очень важен.

Your reasoning is very scary, especially considering you are part of the RPi foundation! Will you sleep better at night if you know that my SD card is getting filled up by repeated logs, all by my own choice? I think you have become very biased and I just don't see or hear any valid reasoning for doing what TK and you are suggesting. What exactly do you hope to gain by doing this?

Here is a free money making suggestion from me:
In your next iteration of any future Raspberry Pi N (4?) you should make sure to:

Use 3A USB-C connectors
Conform to the USB standards
Include a low loss connector cable
Include the magic power supply if the device doesn't comply with (2).
Include the best suitable SD card
Include a working built in soundcard with MIC/AUX
Each one of those alone, will save you tons of time and money since you will be able to put all your current efforts into sales, marketing, development and production, instead of arguing.

Just let us all know when this will happen, because that will be the day I will stop updating and buying your HW, permanently.

Спасибо за совет фонду, который продал 19 миллионов устройств, полностью изменил рынок SBC, выделил миллионы фунтов на образование из прибыли. Я уверен, что ваш совет полностью изменит наш бизнес. Ниже я указал, где ваш совет на самом деле не принесет больше денег.

Проблема здесь в том, что у вас есть мнение, и вы не хотите признать, что это мнение неверно. Что, на мой взгляд, так и есть. Не страшно, просто мнение отличное от вашего. Вы также не желаете решать свою вечную проблему с пониженным напряжением, из-за которой все сообщения исчезнут, по причинам, которые до сих пор неясны.

Теперь мы добавили запись скорости в сообщения. Это ограничивает до трех сообщений каждые 5 минут. Если ваш журнал ПО-ПРЕЖНЕМУ заполняется сообщениями, ИСПРАВЬТЕ ЧЕРТОВУ ЭЛЕКТРОПИТАНИЕ! ЭТО НЕДОСТАТОЧНО! Я не могу понять, что в этом сложного для понимания.

Пункты в ответ на некоторые из вышеперечисленных, фактически не раскрывая, что на самом деле будет на Pi4.

Стандарты USB. SoC имеет встроенное USB-устройство, которое, к сожалению, немного дрянное, но мы ничего не можем с этим поделать, но с ARM FiQ мы заставили его работать очень хорошо. Микросхема концентратора, которая также обеспечивает Ethernet, совместима с USB.

Нет смысла предоставлять SD-карту, блок питания, кабель и т. д., потому что тогда каждый покупатель Pi каждый раз будет получать полный комплект, а не всем это нужно. Это также сделало бы цену заголовка слишком высокой. Все это ужасные идеи. Вы можете купить комплекты со всем этим, хотя.....

SOC также содержит приличную звуковую систему, которая выводится через HDMI, что подходит подавляющему большинству людей. Опять же, нет смысла делать Pi более дорогим для всех с функцией, которой пользуются лишь немногие. Вы попали в ту же ловушку, что и при ведении журнала, — думая, что ваш вариант использования является важным, тогда как на самом деле вы всего лишь один из многих миллионов пользователей. Потребности многих перевешивают потребности немногих.

Что касается экономии денег - смысл входа в dmesg для малой мощности именно для этого - чтобы уменьшить проблемы с поддержкой!

Что касается денег на маркетинг, разработку, производство - у нас их предостаточно.

Итак, я еду по дороге на своем двухлетнем БМВ. Это далеко не топовые модели, но и не бюджетные. Это отличная машина, и вот уже 2 года она возит меня туда-сюда на работу, на выходные, а иногда и в длительные поездки. Поскольку я не собираюсь использовать его для ежедневных гонок по Европе на максимальной скорости по автобану, он отлично служил мне и до сих пор отлично справился со своей задачей.

Однако однажды загорелся сервисный индикатор, указывая на то, что пришло время отвезти машину на техосмотр через 1000 миль. Так как к зиме она вот-вот покатается и я решаю отдать ее на предосеннее обслуживание. Я делаю так, и механик говорит, что все в порядке, но обновил систему и сбросил сервисный индикатор. Все хорошо.

Так как дороги здесь могут стать ледяными, я решаю вернуть свои зимние шины, которые я использовал с прошлого года, и после того, как я это делаю, внезапно загорается аварийная сигнальная лампа критического двигателя! Я в замешательстве, так как я только что вернулся из сервиса! Я звоню механику и рассказываю ему о своей проблеме. Он спрашивает, не изменился ли я с тех пор, как посетил его на прошлой неделе. Я сказал, что нет, просто надел зимние шины, которые я использовал в прошлом году. Он говорит: «О, какие они?», и я отвечаю: «Ну, я нашел эти стандартные зимние шины Bridegstone Winter и решил, что мне не нужно тратить дополнительные деньги на те специальные зимние шины BWM High-Performance, которые вы продаете. " Он отвечает: «О, это все объясняет! Вы используете дерьмовые шины, а мы только что внедрили в машину систему обнаружения и предупреждения, которая определяет, используете ли вы не наши нестандартные шины». Поэтому я говорю: «А, хорошо. Спасибо за объяснение ситуации, но я оставлю шины, которые у меня уже есть, еще на один сезон, так как в прошлом году они отлично работали».

На следующий день я еду по шоссе, пытаясь обогнать более медленный грузовик. Разгоняюсь до 1200 Hm/h
[1200 гектометров = 120 км], и когда я стою рядом с грузовиком, мой двигатель внезапно перестает разгоняться.
и двигатель и машина внезапно остановили меня на скорости 600 Нм/ч. В тот же самый момент свет в салоне начинает мигать каждые несколько секунд, почти ослепляя меня в осенних сумерках, в то время как критический свет двигателя делает то же самое. Я чуть не столкнулся лоб в лоб из-за этого эпизода, и решаю позвонить моему старому коллеге мистеру Феррари и объяснить ему это.

На следующий день я иду к нему в гараж, где у него есть анализатор ODB2. Он объясняет, что проблема не в самой машине и не в шинах, а в новом обновлении программного обеспечения автомобиля. Но что он может отключить его. Поэтому я решил отключить эти опасные (и теперь бесполезные) предупреждения о моих неоригинальных шинах. Я счастливо уезжаю в закат... или я так думаю!

Затем я въезжаю в тучу комаров, и мое лобовое стекло разбито. Я включаю гадюки, только чтобы найти
что одна из щеток стеклоочистителя немного изношена. Я делаю себе мысленную пометку исправить это в следующий раз, когда у меня будет
шанс. Но прежде чем я даже дойду до конца этой мысли. Внезапно из среднего отсека заднего сиденья выскакивает чертик из коробки, как подпружиненная пуля, и кричит: «У ВАС ДЕРЬМОВЫЕ ШИНЫ!! ЗАМЕНИТЕ ИХ И ПОСЛУШАЙТЕ МЕНЯ!» в моем правом ухе. Я сворачиваю с дороги в грязное поле и решаю, что вложение денег в такую ​​компанию не стоит шин, на которых она стоит. Я возвращаюсь автостопом в реальность сверхконкурентной встроенной вселенной IoT и нахожу себе Tesla, которая может использовать любые доступные шины, источники питания и может двигаться при любом течении или по любой дороге с любой скоростью, которую вы пожелаете.

Наконец-то мир!

Вышеприведенный отрывок основан на реальной истории и будет написан в готовящейся к изданию книге «Как большие маленькие компании становятся жадными и дерзкими, а затем их заменяют».

Дерзкий? Или просто правильно? Я выхожу.