Linux: Di bawah tegangan terdeteksi! (0x00050005) mengirim spam dmesg pada kernel baru 4.14.30-v7+

Notifikasi kernel di bawah voltase baru, tetapi ambang batas dan mekanisme deteksi tidak berubah. Anda sekarang disadarkan akan fakta bahwa Pi Anda tidak cukup bertenaga untuk beban yang diletakkan di atasnya. Ini buruk untuk kinerja dan berpotensi membahayakan stabilitas sistem.

Saya dapat mengetahui dari banyak pengujian dan pengukuran dengan multimeter, bahwa 99% dari catu daya USB "khas" (pengisi daya telepon, pengisi daya gadget, bank daya, dll.) tidak memasok ampli yang diiklankan, atau voltase turun. terlalu banyak. Atau keduanya. Bahkan jika catu daya itu sendiri menghasilkan 5V yang stabil pada 2-2.5amps, seringkali tegangan di ujung kabel turun terlalu banyak karena kabel yang terlalu tipis.

Saya sangat menyadari cara kerja catu daya RPi. Tapi faktanya adalah:

• Itu tidak terjadi dengan kernel sebelumnya, jadi apa yang membuat Anda berpikir ini adalah peningkatan?
  (Ikon flash bagus dan cukup mengganggu!)
• Mengirim pesan kernel spam (dan semua buffer terkait lainnya) dengan pesan berulang pada perangkat yang telah terbukti berfungsi dengan baik dalam kondisi tersebut sebelumnya, sekarang mempertaruhkan keausan kartu SD yang berlebihan dan debugging yang lebih sulit karena pesan kernel yang lebih lama dan lebih relevan mendapatkan FIFO' d keluar akhirnya.
• Level crit saat ini bahkan tidak menghormati pengaturan printk dan terus melakukan spam bahkan setelah menyetel dmesg -n 1 atau menggunakan sysctl -w '1 1 1 1' . Jadi AFAICT, ini tidak kritis , atau sesuai dengan perilaku standar *nix, dan tidak memberikan peningkatan apa pun.

Itu tidak terjadi dengan kernel sebelumnya, jadi apa yang membuat Anda berpikir ini adalah peningkatan?
(Ikon flash bagus dan cukup mengganggu!)

Itu terjadi, Anda hanya tidak menyadarinya. Pengguna tanpa kepala sebelumnya tidak memiliki pemberitahuan otomatis bahwa tegangan rendah telah terjadi, mengandalkan permintaan firmware secara manual untuk mengetahui bahwa inilah masalahnya. Selain itu, KERN_CRIT adalah "Kondisi kritis terjadi seperti kegagalan perangkat keras/lunak yang serius" dan begitu juga tingkat log yang sesuai untuk kondisi yang mungkin menyebabkan ketidakstabilan sistem.

Perhatikan bahwa Pi tidak dijamin untuk bekerja dengan benar ketika catu daya di papan kurang dari 4.63v yang (dalam +-10%) yang merupakan titik di mana Ikon ditampilkan, dan pelaporan baru akan menambahkan pesan ke log. Catatan, itu tidak berarti bahwa Pi tertentu ANDA akan berhenti bekerja, hanya saja tegangannya cukup rendah sehingga mungkin ada masalah. Jika Anda mendapatkan pesan di log, maka tegangan IS turun di bawah 4,63, dan ada risiko ketidakstabilan sistem. Hanya karena Anda belum benar-benar melihat stabilitas sistem, bukan berarti risikonya tidak ada.

Saya tidak yakin bahwa ada opsi untuk menonaktifkan peringatan, tetapi tbh, itu seperti memasang selotip di atas lampu peringatan mesin mobil Anda. OK, Anda tidak dapat melihat lampu peringatan terang yang buruk, tetapi Anda berisiko mesin meledak.

Ayolah teman-teman! Saya yakin Anda tahu apa yang saya maksud.

Itu terjadi, Anda hanya tidak menyadarinya.

Saya perhatikan setiap kali flash kuning cerah berkedip di layar saya, tetapi pada saat itu (sebelum masalah ini) biasanya hanya ketika prosesor sedang dimuat. Sekarang tidak ada yang berjalan di atasnya, dan log kernel dibanjiri untuk sesuatu yang tidak lagi saya kendalikan. Itulah masalahnya. Dan Anda masih belum mengatasi masalah mengapa tidak mungkin untuk menyesuaikan properti itu dengan alat sysctl standar yang dimaksudkan untuk itu.

Saya telah menjalankan konfigurasi khusus ini selama hampir 2 tahun tanpa henti dan tanpa masalah apa pun yang tidak dapat saya tangani, hingga pembaruan terakhir ini. Hanya, untuk diberitahu, "Bung itu catu daya Anda, dapatkan yang baru." Itu pasti tidak bisa menjadi strategi pemasaran baru Anda!? Kebetulan saya tahu banyak tentang perangkat keras, terutama perangkat keras yang disematkan, jadi saya bertanya-tanya bagaimana perasaan atau tanggapan komunitas lainnya terhadap hal ini, begitu mereka mengetahuinya.

Jadi jelas ini bukan sesuatu yang kritis dari jarak jauh , dan harus menjamin paling banyak satu pemberitahuan di log kernel (atau mana pun yang menurut Anda cocok). Intinya lagi, adalah bahwa dalam keadaan saat ini, itu adalah spamming masalah lain dari keberadaan. Jadi tidak peduli seberapa bangga Anda telah membuat perbaikan ini, itu hanyalah keputusan yang buruk, setidaknya dari sudut pandang etis.

Salah satu solusi dapat mengatur batas waktu pada kesalahan itu.

@E3V3A

Jadi tidak peduli seberapa bangga Anda telah melakukan perbaikan ini, itu hanyalah keputusan yang buruk, setidaknya dari sudut pandang etis.

IMHO ini adalah keputusan yang bagus dari sudut pandang apa pun.
Bayangkan pi tanpa kepala di mana Anda tidak akan pernah melihat pencahayaan sialan itu, Anda tidak akan pernah tahu Anda memiliki masalah daya sampai terlambat atau kecuali Anda menjalankan vcgencmd get_throttled , yang tidak akan Anda jalankan kecuali jika Anda sudah curiga masalah listrik/termal.

Berkat ini, saya menemukan di pi2 tanpa kepala saya bahwa PSU (omong kosong Cina murah) kehilangan beberapa jus dan tidak lagi dapat memberikan 5v di bawah beban berat (tidak apa-apa selama ~ 1 tahun), dan saya dapat menggantinya sebelum sesuatu buruk terjadi.

IMO ini adalah peningkatan besar karena meningkatkan komunikasi kernel<->vc4 dan memberikan peringatan kepada pengguna.

Semua ocehan Anda tentang "etika" tidak masuk akal di sini.

Jadi jelas ini bukan sesuatu yang kritis,

Masalah daya AFAIK (setidaknya di dunia server) _dianggap kritis.
Ada server (mis. DELL) yang akan menolak untuk boot jika anggaran daya di bawah yang dibutuhkan oleh BIOS/UEFI.
Jika peringatan perangkat lunak tentang masalah perangkat keras, seseorang harus memperbaiki masalah hw sialan itu secepatnya. Periode.

Orang-orang di sini adalah insinyur yang merancang dan mendukung pis, saya yakin mereka tahu apa kebutuhan daya ...

Jika Anda tidak puas dengan log spam - pelajari cara memfilter pesan syslog tertentu berdasarkan konten pesan,
ya, Anda dapat melakukannya dan banyak lagi dengan rsyslog.

Sekarang tidak ada yang berjalan di atasnya, dan log kernel dibanjiri untuk sesuatu yang tidak lagi saya kendalikan

@E3V3A Powering Anda payah dan Anda harus memperbaikinya (dan cara berpikir Anda). Anda terpengaruh seperti banyak pengguna RPi lainnya oleh fenomena yang disebut penurunan tegangan. Ganti kabel antara papan Anda dan PSU atau dapatkan PSU RPi resmi dan selesai.

Anda bahkan menderita ketidakstabilan dan masih tidak mengerti bahwa Anda memiliki masalah perangkat keras? Sama seperti orang ini di sini: https://github.com/bamarni/pi64/issues/66

PSU juga menunjukkan efek penuaan dan penurunan tegangan di bawah beban adalah salah satu dari banyak gejala.

@asavah

Semua ocehan Anda tentang "etika" tidak masuk akal di sini.

Ya kau benar. Itu sama sekali bukan milik di sini. Itu hanya mencerminkan rasa frustrasi saya atas jawaban yang tidak berguna dari apa yang hanya dapat saya asumsikan sebagai kolega Anda.

@ThomasKaiser

Sangat menarik bahwa Anda merujuk pada masalah yang tepat itu, karena pria itu secara khusus mengatakan:

Saya menggunakan pi3 dengan catu daya 2.5A "resmi". Tidak ada masalah dengan build / kartu SD lainnya.

dan kemudian melanjutkan mengatakan bahwa:

Saat mencoba berbagai cara untuk mengurangi "stres" pada pi, salah satu solusi saya adalah membuat file swap. Ini memperbaiki masalah,

Jadi itu hanya menunjukkan betapa kalian suka mengabaikan masalah apa pun dengan jawaban umum:
"Kekuatanmu payah dan kamu harus memperbaiki ini (dan cara berpikirmu)."

Jadi, ya, maka masuk akal untuk mengedipkan flash bertegangan rendah itu setiap beberapa detik, karena jika Anda melakukannya, apa pun masalah yang dimiliki orang, Anda selalu dapat merujuk kembali ke sana dan mengulangi kalimat di atas dan menutup masalah. Saya akan menutup masalah ini dengan calon tag "Kami tahu lebih baik dan kami tahu lebih banyak tentang PSU Anda dan kabel yang Anda gunakan, daripada yang Anda lakukan."

Jadi untuk penjualan RPi di masa depan, semua orang akan jauh lebih baik jika Anda hanya membangun catu daya ajaib Anda langsung ke perangkat, dengan begitu tidak akan pernah ada lagi masalah dan keluhan dan Anda dapat menghemat 1000 jam kerja karena semua masalah terkait PSU ini.

Kemudian Nostradamus, meramalkan kembali pada tahun 1500-an bahwa beberapa bulan dari sekarang, akan ada badai masalah baru mengenai kegagalan kartu SD karena keausan yang berlebihan dan penulisan SD yang gagal... belum lagi overhead kinerja untuk spamming /var/log/ .

Kesimpulannya, satu-satunya solusi serius bagi saya (dan Anda) tampaknya adalah kembali ke kernel 4.9 dan semua orang akan senang lagi.

@E3V3A Hanya untuk memastikan: Apa yang tercetak di PSU Anda? 4.63V atau sesuatu dengan 5? Jika ada 5 yang dicetak apakah Anda mendapatkan bahwa ada yang salah ketika perangkat yang akan ditenagai oleh pengaturan ini melaporkan kurang dari 4.63V sudah tanpa beban sama sekali ? Dapatkah Anda bayangkan seberapa rendah tegangan akan turun dengan beberapa beban yang diterapkan atau beberapa periferal USB yang juga membutuhkan jus?

Apakah menurut Anda perangkat yang memiliki kebutuhan daya 5V berfungsi dengan baik saat Anda hanya menyediakan 4V?

Kesimpulannya, satu-satunya solusi serius bagi saya (dan Anda) tampaknya adalah kembali ke kernel 4.9 dan semua orang akan senang lagi.

Cukup buat /etc/rsyslog.d/ignore-underpowering.conf dengan :msg, contains, "oltage" ~ dan Anda dapat menikmati sistem yang tidak stabil bahkan dengan kernel 4.14 :)

BTW: Baru saja menemukannya. Ada SBC yang memungkinkan pemantauan tegangan input konstan. Apa yang dapat Anda lihat di sini adalah PSU yang menyediakan 5.25V di awal setelah sekitar 1,5 tahun operasi konstan: https://forum.armbian.com/topic/5699-how-to-provide-and-interpret-debug-output /?do=findComment&comment=44210 -- DC-IN turun serendah 4.2V dengan beberapa beban ringan (papan ini juga memiliki PMIC yang baik dan baterai besar serta sirkuit daya menggunakan konverter boost untuk menyediakan voltase yang stabil ke semua subsistem, USB dan SATA termasuk)

@ThomasKaiser
Saya mengedit file konfigurasi rsyslog.d seperti yang Anda sebutkan di /etc/rsyslog.conf default dengan dan tanpa tab, seperti ini:

:msg, contains, "oltage" ~

Memang ini menghapus log terkait tegangan dari file /var/log/*.log . :+1:
Tetapi tampaknya dmesg yang menggunakan /dev/kmsg dan /proc/kmsg , tampaknya tidak tergantung pada pengaturan syslogd dan rsyslogd , dan dengan demikian masih menampilkan semua entri tegangan rendah seperti sebelumnya dengan dmesg -e -x . Tapi kurasa aku bisa hidup dengan itu.

Mengenai tegangan input, saya terkejut bahwa detektor dapat mengukur tegangan ke desimal kedua 4.63 , tetapi tidak ada cara untuk membacanya dari /sys. Apa itu semua? Bagaimana dan apa yang sebenarnya diukur perangkat ketika voltase lebih rendah dari ambang batas itu?

Either way saya akan melaporkan kembali, setelah saya memiliki nilai-nilai. Dalam proses semua penyelidikan ini sayangnya saya menemukan berbagai kejutan tidak menyenangkan lainnya yang datang dari pembaruan ini. Segala macam hal, seperti menimpa konfigurasi ALSA, memulai layanan yang tidak pernah dijalankan sebelumnya, menjalankan apt upgrade secara otomatis, dll. :(

Mengenai tegangan input, saya terkejut bahwa detektor mampu mengukur tegangan ke desimal kedua 4,63, tetapi tidak ada cara untuk membacanya dari /sys. Apa itu semua? Bagaimana dan apa yang sebenarnya diukur perangkat ketika voltase lebih rendah dari ambang batas itu?

Ini adalah ambang batas terprogram, diimplementasikan oleh PMIC baru pada 3B+ dan menggunakan komponen terpisah pada papan lama - kami hanya tahu sisi ambang mana yang tegangannya.

Berkenaan dengan Anda komentar lain pada pembaruan 4.14, ini adalah langkah yang cukup besar dari 4.9, jadi saya mengharapkan beberapa perubahan yang cukup jelas. Perhatikan juga bahwa sebagian besar perubahan berasal dari kernel hulu, bukan Raspberry Pi. Namun, menjalankan pembaruan apt secara otomatis tidak masuk akal. Itu seharusnya tidak pernah terjadi secara default, dan saya pasti tidak melihatnya dalam pengujian apa pun (kami telah menguji 4.14 selama beberapa bulan atau lebih).

Namun, menjalankan pembaruan apt secara otomatis tidak masuk akal.

Tidak.

# 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)
...

Anda dapat melihatnya di sini:

# 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

Jadi mungkin saja tidak melakukan apa-apa, tetapi masih berjalan setiap hari.
Saya menemukan ini dengan melihat di /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.

Saya belum menyelidiki lebih lanjut ...

Memang ini menghapus log terkait tegangan dari file /var/log/*.log.

Saya tidak percaya bahwa Anda benar-benar melakukan ini alih-alih memperbaiki masalah. Apakah Anda sadar bahwa Anda mengubah Pi Anda menjadi perangkat 600 MHz dengan mengabaikan masalah tegangan rendah Anda? Anda menjalankan frekuensi yang dibatasi sepanjang waktu dan berdasarkan deskripsi Anda, PSU Anda kemungkinan besar akan segera mati (karena apa alasan tegangan di bawah sekarang terjadi bahkan tanpa beban sama sekali?)

@ThomasKaiser

Saya tidak percaya bahwa Anda benar-benar melakukan ini alih-alih memperbaiki masalah.

Tidak ada masalah sampai saya memperbarui dengan kernel ini!

Jadi ya, mungkin catu daya saya tidak ideal dan jelek, tetapi faktanya adalah catu daya itu berjalan dengan kecepatan penuh, pada beban sedang dan yang lainnya berfungsi kurang lebih baik sebelum kernel Anda push . Saya masih tidak percaya Anda mendorong pembaruan Kernel jelek itu sebelum pengujian yang tepat atau mendapatkan lebih banyak umpan balik komunitas. (Sekarang saya sudah memiliki pembaruan kernel lain yang menunggu.) Saya telah menghabiskan waktu berhari-hari untuk mencoba memperbaiki dan memperbaiki semua kembung dan masalah yang diakibatkannya, dan sepertinya masih ada jalan panjang. Sebenarnya, pada titik ini saya hanya ingin menurunkan versi! Sayangnya saya tidak melihat cara mudah untuk melakukan ini, pada saat ini. Jadi terima kasih banyak.

Dan apa yang membuat Anda berpikir bahwa pengaturan ini jauh lebih andal?
Terakhir kali saya memeriksa, kapasitor keduanya tidak dapat diandalkan dan tidak terlalu tepat, kecuali jika Anda memasukkan topi kelas militer (Radio Shack ;) di sana.

Jadi jika benar Anda menggunakan APX803-46 , maka ada rentang V_th dari: 4.56 4.63 4.70 . Ini tampaknya merupakan masalah yang terkenal dan didokumentasikan dengan baik di sini . Di sana mereka mengusulkan bahwa Anda seharusnya menggunakan APX803-44 sebagai gantinya, dengan kisaran: 4.31 4.38 4.45 , dan tidak ada yang akan memiliki masalah! Salah satu masalah utama dengan desain Anda, dinyatakan seperti ini:

Desain rangkaian input daya berada di luar batas yang dapat kita kendalikan. Desain ini memaksa bisnis untuk membuat dan pelanggan untuk membeli pasokan listrik yang tidak sesuai dengan standar industri. Alasan beberapa adaptor daya lain tidak mengalami masalah ini adalah karena mereka memberikan tegangan tinggi yang berbahaya yang bukan merupakan keluhan standar. Dalam pengujian kami untuk masalah ini, kami menemukan catu daya menghasilkan hingga 5.7Vopen dan 5.5V dengan beban 0.5A. Ini mungkin menggoreng elektronik USB sensitif yang tidak memiliki perlindungan bawaan.

Jadi, sekarang tolong lepaskan kami semua alasan PSU, dan kembalikan kernel & firmware agar sedikit lebih menerima.

Salah satu cara Anda bisa melakukan ini, adalah dengan menggunakan konstanta waktu yang lebih luas untuk tegangan di bawah. Yaitu rata-rata tegangan selama satu menit atau sesuatu.

Dan ya, saya telah menyebutkannya sebelumnya, di tempat lain. Harap berikan CHANGELOG yang tepat untuk rilis kernel Anda, sehingga orang tidak harus jatuh ke dalam perangkap ini. Mampu menggunakan apt-get changelog raspberrypi-kernel akan sangat bagus, tetapi saya diberitahu sebagai alasan bahwa itu tidak dikelola oleh Anda. Tapi kemudian Anda selalu dapat mendokumentasikannya di tempat lain... GitHub memiliki halaman Wiki lho!

Jadi ya, mungkin catu daya saya tidak ideal dan jelek, tetapi faktanya adalah catu daya saya berjalan dengan kecepatan penuh

Tidak. Sepertinya Anda mengandalkan 'standar Linux' seperti

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

yang tidak dapat Anda lakukan di Raspberry Pi karena mengandung nilai palsu. Saat Anda menjalankan undervolted, firmware membatasi frekuensi hingga 600 MHz sementara cpuinfo_cur_freq hanya memberi tahu Anda nomor yang tidak relevan (900 MHz pada RPi 2, 1200 MHz pada RPI 3 dan 1400 MHz pada RPi 3+). Satu-satunya cara untuk memeriksa masalahnya adalah saat ini

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

Tentu saja Anda tidak sendirian. Terutama pengguna tanpa kepala tidak mengerti bahwa mereka berjalan pada 600 MHz max sepanjang waktu :) Lihat misalnya https://github.com/bamarni/pi64/issues/4#issuecomment -291425512

cpuinfo_cur_freq adalah jam HW, (bukan dari kernel) dan tampaknya memberikan hasil yang sama dengan vcgencmd measure_clock .

Apakah hasil dari 600 atau 1200 berikut?

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

Tidak ada masalah sampai saya memperbarui kernel Anda!

Ya ada, Pi Anda undervolted. Fakta bahwa tidak ada tanda-tanda lahiriah dari korupsi dll tidak meniadakan fakta itu. Semua kernel melakukan hal yang berbeda adalah MELAPORKAN masalah. Masalah yang mungkin selalu ada, yang sebelumnya tidak disadari.

Sekedar FYI, TKaiser bukan karyawan RPF, bukan kernel 'miliknya'. Dia adalah anggota komunitas yang berpengetahuan luas yang mencoba membantu Anda. Saya satu-satunya karyawan yang saat ini mengomentari utas ini.

@JamesH65

Ya ada, Pi Anda undervolted.

Saya tidak berargumen bahwa tidak ada masalah tegangan rendah sebelumnya, tetapi saya berpendapat bahwa saya tidak memiliki masalah lain sama sekali sebelum pembaruan dari 4.9.80 ini, kecuali masalah yang sangat sesekali (setiap beberapa hari) #2510, yang saya posting dan yang masih belum ditangani meskipun tampaknya dari beberapa tahun yang lalu.

Ada masalah di bawah tegangan sebelumnya, tapi itu di bawah beban dan menunjukkan paling banyak setiap beberapa menit. Sekarang ini ditampilkan setiap beberapa detik tanpa beban selain yang disediakan oleh pembaruan itu sendiri, dan dengan kartu suara USB terputus. Saya juga berpendapat bahwa ketika saya terakhir memeriksa frekuensi CPU, mungkin> 6 bulan yang lalu itu berjalan pada 1200. Jadi sama sekali tidak relevan untuk masalah ini, berulang kali meminta saya untuk memposting kecepatan saat ini, karena OP sudah menyatakan bahwa saya sedang dicekik.

Jadi, ya, saya juga mencoba membantu, dengan melaporkan temuan saya di sini. Tapi, saya sekarang cukup muak dengan diskusi tentang PSU ini. Ini adalah kambing hitam yang sangat mahal, tidak peduli bagaimana Anda melihatnya. Anda membuat kesalahan desain, dan kami harus menerimanya. Kami masih menyukai RPi3 kami, dan ketika itu berhasil, itu berhasil. Milik saya berfungsi, hingga pembaruan ini.

Kesalahan terbesar saya adalah tidak terlebih dahulu memeriksa semua masalah di sini, sebelum memperbarui secara membabi buta. (Karena itu berjalan dengan baik sebelumnya.)

Penolakan, seperti yang mereka katakan, bukan hanya sungai di Mesir.

Anda tampak seperti orang yang cerdas dan berpengetahuan luas, namun Anda tidak dapat melupakan kenyataan bahwa semua orang di pos ini sebenarnya mencoba membantu Anda - anggap ini sebagai intervensi. Dengan melemahkan Pi Anda, Anda membatasi kinerjanya dan mengambil risiko korupsi setiap hari. @ThomasKaiser mencoba memberi tahu Anda bahwa pembatasan frekuensi dikelola oleh firmware tanpa sepengetahuan gubernur CPU, jadi kecuali Anda menggunakan vcgencmd measure_freq arm Anda tidak mendapatkan gambaran akurat tentang kecepatan clock ARM.

Anda telah mengemukakan poin yang valid bahwa pesan kernel terlalu sering, dan kami sedang menyiapkan tambalan untuk membatasi laju - pesan awal segera ketika pertama kali terjadi (dan setelah jeda yang lama), maka intisari berkala dengan hitungan akan menyenangkan - tetapi selain itu kami tidak memiliki rencana untuk mengubah mekanisme ini karena kami menganggapnya sebagai layanan penting bagi pengguna kami.

dengan kartu suara USB terputus

Jadi 'kartu suara' ini ditenagai oleh Pi atau mengapa Anda menyebutkan ini? Tahukah Anda seberapa rendah tegangan yang diperbolehkan untuk turun untuk periferal USB sesuai dengan spesifikasi untuk jenis perangkat ini? 4.4V atau 4.75V?

kecuali Anda menggunakan vcgencmd measure_freq arm Anda tidak mendapatkan gambaran akurat tentang kecepatan clock ARM.

@pelwell adakah kesempatan untuk memperbaikinya juga dan untuk mendapatkan kernel yang melaporkan kecepatan jam sebenarnya?

Sejauh yang kami ketahui, tidak ada kesalahan desain dalam rangkaian daya. Anda mengutip pemasok catu daya pihak ketiga yang mengklaim ada. Tentu saja, mereka menjual catu daya pesaing sehingga jelas bias!

Menggunakan catu daya Raspberry Pi menunjukkan TIDAK ADA masalah dengan catu daya dalam keadaan apa pun yang diklaim orang-orang ini sebagai masalah. Namun, kami akan membeli catu daya mereka untuk menguji, karena kami ingin teliti. Mungkin butuh beberapa saat karena mereka tidak mengirim ke Inggris.

@pelwell

pelambatan frekuensi dikelola oleh firmware tanpa sepengetahuan gubernur CPU,

Saya tidak bisa membayangkan hal ini terjadi. Terima kasih telah mengklarifikasi. OMONG-OMONG. Mengapa diputuskan untuk dilakukan dengan cara ini?

@ThomasKaiser

mengapa Anda menyebutkan ini?

Sekadar informasi, terhubung atau tidak, perkiraan waktu konstan antara kesalahan di bawah tegangan sekarang ~2 menit, terlepas dari keberadaan kartu suara USB. Ini sedikit peningkatan dari kemarin ~30 detik. sebelum menghapus layanan yang telah disebutkan mengasapi.

Saya ingin membuat pengukuran yang akurat di papan untuk voltase saya. Dapatkah Anda menunjukkan saya di mana pada PCB untuk melakukan pengukuran? Dari skema di atas, tampaknya ada beberapa titik uji.

Why was it decided to be done this way?

Arsitektur SoC berarti VC4 pada dasarnya bertanggung jawab atas hal semacam itu. Sudah seperti itu sejak Pi1. Google proses boot Pi untuk detailnya.

pelambatan frekuensi dikelola oleh firmware tanpa sepengetahuan gubernur CPU,

Saya tidak bisa membayangkan hal ini terjadi. Terima kasih telah mengklarifikasi. OMONG-OMONG. Mengapa diputuskan untuk dilakukan dengan cara ini?

Idenya adalah bahwa ARM kemungkinan akan crash karena overheating atau undervolting sebelum VPU melakukannya, sehingga VPU memiliki kontrol otomatis terhadap jam. ARM dapat mengajukan permintaan, tetapi VPU memiliki hak veto - yang tidak dapat dinegosiasikan untuk alasan keamanan.

Itu masih menyisakan pertanyaan mengapa driver cpufreq tidak diberitahu tentang pelambatan, yang bermuara pada pilihan dalam desain antarmuka kotak surat untuk mengembalikan frekuensi yang diminta sebelumnya daripada frekuensi pasca-pelambatan yang sebenarnya - jika tidak, itu bisa didapat membingungkan jika tampaknya permintaan diabaikan. Ada panggilan kotak surat baru yang sebenarnya akan mengukur jam, tetapi driver cpufreq tidak menggunakannya. Tidak jelas (tanpa membaca lebih banyak kode) apa (jika ada) efek mengembalikan jam aktual daripada yang diharapkan pada kerangka cpufreq.

Dapatkah Anda menunjukkan saya di mana pada PCB untuk melakukan pengukuran?

Saya akan menggunakan pin 4 dan 6 pada header GPIO. Dan jika kartu suara USB Anda ditenagai oleh Pi (Anda menolak untuk menjawab pertanyaan ini sekarang untuk kedua kalinya), Anda juga dapat menggunakan powermeter USB di salah satu port USB untuk mengetahui seberapa rendah tegangan turun di sana (4,75V menjadi jumlah terendah yang dapat ditoleransi untuk sebagian besar periferal USB). Tetapi hal-hal itu biasanya tidak begitu tepat.

@pelwell Bisakah Anda mengarahkan saya ke properti kotak surat yang mengembalikan jam yang sebenarnya diukur?

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

@ThomasKaiser

jika kartu suara USB Anda ditenagai oleh Pi

Saya pikir itu sudah jelas. Juga melihat beberapa masalah lain, dan juga dari pengalaman saya sendiri, tampaknya RPi tidak terlalu senang menggunakan hub USB, karena sudah ada yang terpasang.

Juga, AFAICR, tegangan yang lebih rendah untuk USB2 adalah -0.6 yang berarti 4.40 V .

Saya percaya itu sangat tergantung pada jenis hub yang digunakan.

Kami adalah pengguna Raspberry Pi yang agak besar di perusahaan robotika kami, dan kami telah menangani dampak dari masalah ini selama beberapa hari terakhir. Berikut rangkuman acara dilanjutkan dengan kesimpulan:

Karyawan baru bergabung, menyiapkan raspberry-pi-nya sendiri dengan gambar terbaru dari bulan Maret, dan saat bekerja dengan Teensy 3.2 yang terhubung, terus menemukan putus komunikasi serial USB. Ini tidak terjadi saat menghubungkan PI yang sama ke PI yang lebih lama dengan versi OS yang lebih lama. Triaging menemukan peristiwa "Tegangan kurang terdeteksi" di log pesan, bersama dengan "Gagal menyetel DTR/RTS" terkait dengan koneksi yang terputus.

Beberapa hari pemecahan masalah diikuti. Inilah yang kami temukan:

1. PI lain (berbeda dari yang di atas) yang telah bekerja dengan baik selama satu tahun tanpa periferal yang terhubung dan lampu merah tidak pernah berkedip, ketika ditingkatkan ke OS terbaru mulai menunjukkan "Kesalahan tegangan rendah" dan lampu merah berkedip setiap kali aktivitas disk terjadi dilakukan . Bahkan memanggil "dmesg" akan menyebabkan lampu merah berkedip, menyebabkan suatu peristiwa ditulis ke log.

2. Saya membaca utas ini dan lainnya, dan menguji dengan situasi catu daya berlapis besi: Bank daya USB, dengan kapasitor 1 F melintasi jalur suplai, dan monitor tegangan dan arus USB inline (ya 1F, bukan 1uF). Pembacaan tegangan adalah 5.02V, dan tidak pernah turun di bawah 4.95V. Bahkan dengan ini, lampu merah akan berkedip setiap kali aktivitas disk dilakukan, seperti mengeluarkan perintah "ls". Tidak ada periferal yang terhubung, penggunaan CPU mendekati nol. TIDAK ADA kemungkinan tegangan input PERNAH turun di bawah 4.65V bahkan untuk mikro-detik, namun lampu merah tetap menyala.

3. Kami membuat kartu SD baru dengan gambar dari bulan Desember, dan menggunakannya untuk mem-boot PI yang sama persis, menggunakan pengaturan catu daya yang sama. Lihatlah, tautan merah TIDAK PERNAH berkedip, bahkan setelah menghubungkan 4 Teensys ke port USB, dan melakukan semua jenis aktivitas hard disk.

Hanya ada satu kesimpulan: Perubahan dari Desember ke Maret tidak hanya mencakup pencatatan tambahan untuk tegangan rendah, tetapi cara tegangan dibaca dan diuji berbeda. Entah ada bug, atau titik tegangan lain di papan sedang digunakan untuk pengujian, bukan tegangan sumber input.

Nah, sirkuit pada Pi3B jelas tidak berubah di antara versi kernel, dan bagian itulah yang sebenarnya melakukan deteksi. AFAIK, tegangan yang terdeteksi adalah bawaan (tidak dapat diatur dalam SW), semua yang dilakukan SW adalah membaca apakah sirkuit telah menyala, (dan menyalakan LED? tidak yakin tentang itu). 3B+ memang memiliki chip daya baru yang sekarang melakukan deteksi, tetapi Anda telah menyatakan bahwa ini sudah berjalan satu tahun sehingga mungkin menjadi Pi3B.

Anda benar-benar perlu menguji tegangan pada Pi itu sendiri - siapa yang tahu jenis penurunan apa yang terjadi pada perangkat tegangan USB dan kabel antara itu dan Pi. Saya tentu saja melihat kerugian besar hanya dengan menggunakan ekstensi USB pendek, atau sakelar di kabel.

Saya telah melakukan pengujian hari ini pada 3B+, menggunakan catu daya desktop. Saya harus menurunkan suplai ke 4,72 sebelum ikon daya muncul, dengan mempertimbangkan kerugian kabel yang tampaknya benar. Saya tidak melihat pesan apa pun sebaliknya. Perangkat menganggur di desktop.

@evthree Harap konfirmasi model Pi mana yang menunjukkan masalah - ini bukan sesuatu yang pernah saya temui sebelumnya.

Bagian atas papan bertuliskan "Raspberry PI 3 Model B V1.2", di bawahnya "(c) Raspberry PI 2015."

Di tempat pengujian kami, kami memastikan bahwa semua yang lain kecuali versi OS sama di antara dua pengujian, termasuk PI yang sama ini, catu daya yang sama, tidak ada perangkat lunak yang berjalan di atasnya, namun perilaku lampu merah telah berubah. Jika hanya logging di bawah tegangan yang ditambahkan, lalu mengapa lampu merah mengubah perilakunya? Dan mengapa koneksi USB putus secara bersamaan dengan peristiwa logging?

Sesuatu yang lain pasti terjadi selain hanya logging tambahan. Saya yakin ada beberapa bug yang sulit dideteksi yang telah diperkenalkan, saya sangat berharap seseorang mencarinya.

Saya sekarang. Satu hal lagi - harap posting output dari vcgencmd otpdump , hanya untuk memastikan bahwa semua sudah ditambahkan.

Saya akan merekomendasikan menghubungkan ruang lingkup ke GPIO pin 4 dan 6 (+5V/GND) dan
menyetel pemicu tepi jatuh sekitar 4.8V. Dari pengalaman saya itu
cara yang paling akurat untuk menentukan apakah kondisi undervoltage terjadi.

Multimeter terlalu lambat untuk menangkap penurunan tegangan pendek dan jika Anda
ingin memeriksa apakah deteksi undervoltage pada RPi berfungsi
benar menggunakan ruang lingkup adalah satu-satunya cara yang dapat diandalkan.

March OS, yang menunjukkan masalah:
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:1020000a
18:1020000a
19:ffffffff
20:ffffffff
21:ffffffff
22:ffffffff
23:ffffffff
24:ffffffff
25:ffffffff
26:ffffffff
27:00002727
28:3786c562
29:c8793a9d
30:00a02082
31:00000000
32:00000000
33:00000000
34:00000000
35:00000000
36:00000000
37.00000000
3800000000
39000000000
40:00000000
4100000000
42:00000000
43:00000000
44:00000000
45:00000000
4600000000
47.00000000
48:00000000
49:00000000
50:00000000
51.00000000
5200000000
53.00000000
5400000000
55:00000000
5600000000
57.00000000
5800000000
59.00000000
60:00000000
61.00000000
62:000000000
63:000000000
64:00000000
65:00000000
6600000000
pi@raspi4 :~

OS Desember, tidak menunjukkan masalah:
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:1020000a
18:1020000a
19:ffffffff
20:ffffffff
21:ffffffff
22:ffffffff
23:ffffffff
24:ffffffff
25:ffffffff
26:ffffffff
27:00002727
28:3786c562
29:c8793a9d
30:00a02082
31:00000000
32:00000000
33:00000000
34:00000000
35:00000000
36:00000000
37.00000000
3800000000
39000000000
40:00000000
4100000000
42:00000000
43:00000000
44:00000000
45:00000000
4600000000
47.00000000
48:00000000
49:00000000
50:00000000
51.00000000
5200000000
53.00000000
5400000000
55:00000000
5600000000
57.00000000
5800000000
59.00000000
60:00000000
61.00000000
62:000000000
63:000000000
64:00000000
65:00000000
6600000000

AFAICR, tegangan yang lebih rendah untuk USB2 adalah -0,6 yang berarti 4,40 V

Hanya untuk perangkat 'daya rendah' ​​yang membutuhkan kurang dari 100mA. Karena Anda sekarang mengonfirmasi bahwa Anda menggunakan perangkat USB bertenaga host (saya bertanya tentang menyalakan sepanjang waktu dan bukan apakah ada hub lain di antaranya - beberapa dari beberapa perangkat Audio yang saya tahu memiliki PSU sendiri) batas bawah adalah 4.75V.

Bagaimanapun: berdasarkan laporan @evthree tampaknya ada masalah yang juga terkait dengan sumber tertutup ThreadX (firmware AKA) yang memengaruhi seluruh masalah ini. Saatnya berhenti membuang-buang waktu ;)

@evthree Saya ingin mengisolasi masalah ke kernel atau firmware.

1. Pada gambar yang berfungsi mulai Desember (Anda mungkin ingin mengkloning kartu untuk menghemat waktu nanti), perbarui firmware, biarkan kernel tidak berubah:

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

Lihat apakah itu rusak.

1. Pada kartu yang berbeda, instal/kloning gambar terbaru dan turunkan versi firmware menjadi sama dengan yang dikirimkan pada gambar Desember:

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

Periksa apakah itu berhasil.

Dengan firmware pemrograman Donald Duck seperti ini , tidak heran orang-orang kesal!

Jika sudah spam log kernel dengan msg1 , kemudian spam dengan msg2 , yang lain spam dengan msg1 lagi!

    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);
}

Jadi karena rpi devs di sini, tidak mau mendengarkan komunitas , kita harus menyelesaikannya sendiri.

Untuk menonaktifkan pembatasan & spam

Untuk sepenuhnya menonaktifkan dmesg atau log kernel agar tidak terkena spam, Anda dapat meletakkan ini di skrip shell atau langsung dari baris perintah, di latar belakang. Ini juga akan memacu mekanisme pelambatan, tetapi akan membuat Anda kembali berjalan sebagian besar pada 1200 MHz. Sejauh ini tanpa efek samping yang mencolok, kecuali sedikit peningkatan penggunaan cpu. Namun, itu tidak akan menghapus flash , karena tampaknya dikendalikan secara independen oleh inti video (VC4). Tetapi Anda harus dapat menghapusnya dengan: avoid_warnings=2 yang menonaktifkan overlay peringatan dan memungkinkan mode turbo lanjutan.

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

Pada awalnya saya mencoba untuk bersikap baik, dengan meletakkan sleep() di sana, tetapi karena firmware sumber tertutup tidak pernah bagus, itu tidak memberikan efek yang tepat sampai loop tidak terbatas. Menggunakan c-code akan lebih mudah untuk mengontrol eksekusi.

Opsi selanjutnya untuk mengatasi ini, adalah:

• Tulis di atas sebagai program ac
• Cobalah untuk menghindari perintah vcgencmd itu sendiri untuk efisiensi yang lebih baik
• Tulis modul kernel yang menggantikan atau membungkus metode spam yang digunakan
• Tulis patch firmware biner yang menonaktifkan pembacaan pin GPIO tegangan berlebih sama sekali.
• Perangkat keras meretas pin langsung pada PCB. (Harus cukup mudah ditemukan dan dilakukan.)

Anda telah salah memahami kode driver firmware - old_uv dan new_uv secara efektif adalah boolean, dan perbandingan bertindak sebagai pendeteksi tepi - satu pesan untuk tepi naik, yang lain untuk tepi jatuh.

Kami tidak terlalu mendengarkan komunitas sehingga kemarin saya tidak memodifikasi driver untuk menambahkan pembatasan kecepatan, meluangkan waktu untuk menguji, dan kemudian membuat PR hari ini.

Oh, tunggu, ini dia. Sepertinya kita memang mendengarkan.

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

Dan sebelum menuduh orang memprogram DD, mungkin yang terbaik adalah memahami apa yang dilakukan kode tersebut sebelum menyemburkan dan membuat diri Anda terlihat bodoh. Ingat, orang-orang yang tampaknya sangat ingin Anda marahi adalah orang-orang yang ANDA butuhkan untuk memperbaiki keadaan.

Dari sudut pandang saya ada 2 kasus penggunaan:
1) Catu daya yang dapat disesuaikan
2) Catu daya yang tidak dapat disesuaikan

Kasus 1: Perilaku logging saat ini berguna untuk menemukan pengaturan yang benar saat runtime.
Kasus 2: Karena pengguna tidak memiliki kesempatan untuk mengubah PSU selama runtime, perilaku ping-pong antara tegangan rendah yang terdeteksi dan "dinormalisasi" ini tidak membantu. Cukup untuk mencetak masalah hanya sekali, karena daya yang diberikan tidak akan menjadi lebih baik.

Berikut saran saya:
Tambahkan parameter DT atau kernel untuk beralih di antara mode berikut:
a - perilaku log kernel saat ini
b - simpan bit lengket dan hanya tambahkan pesan kernel baru jika bit lengket baru telah ditambahkan

Hanya dua sen saya

@lategoodbye Saya tidak setuju dengan Kasus 2: jika catu daya Anda "dikenal baik" namun Anda memiliki periferal yang terhubung baik melalui header GPIO atau port USB, memiliki log cap waktu (walaupun ratelimited) memungkinkan Anda untuk mengetahui periferal/kondisi penggunaan mana menyebabkan undervoltage.

Komponen dapat gagal dalam layanan, jadi ini adalah bantuan diagnostik yang berguna.

@lategoodbye
Saran Anda bagus! Mungkin satu-satunya yang bisa memuaskan semua orang. Saya juga akan sangat senang melihat ini ditambahkan sebagai parameter boot/config.txt atau cmdline. Tapi saya jelas telah menggunakan semua poin Karma baik saya di sini, jadi mungkin beberapa orang lain juga bisa ikut campur?

@P33M
Tidak setuju dengan salah satu kasus tidak membantu, jika kasus lain juga tersedia.
(Utas ini telah menjadi lambang dari segala macam ketidaksepakatan, di semua tingkatan.)
Jadi bagaimana Anda menyarankan untuk bergerak maju dengan ini?

@JamesH65
PR 2520 mungkin vanilla membantu, tetapi tampaknya berlebihan karena kita seharusnya sudah memiliki item sysctl untuk itu. Berikut ini harus mencapai hal yang sama persis:

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

Saya menggunakan kata, "harus" di sini, karena seperti yang saya sebutkan di posting sebelumnya, sepertinya ini diabaikan, jadi jika PR itu mengaktifkannya lagi, itu bagus.

Masalah lain dengan PR itu , adalah bahwa hal itu mungkin juga akan mencekik semua pesan log kernel lainnya . Itu juga mengapa saya akan memilih saran Stefan.

PR tidak menggunakan logging tingkat vanilla - ini menggunakan intervalnya sendiri (5 menit) dan burst (3) jadi tidak terpengaruh oleh pengaturan logging tingkat kernel (meskipun menggunakan kode logging tingkat yang sama)

Sudah digabungkan, saya ragu saya akan punya waktu untuk membuat perubahan lagi., Banyak hal penting yang harus dilakukan. Kami akan mempertimbangkan PR dari tempat lain namun.

Saya mencoba untuk lebih memahami kode PR raspberrypi.c dan bagaimana ia berinteraksi dengan kernel, sysfs, dan log, tetapi saya tidak dapat menemukannya. Saya tidak dapat melihat jejak kode ini di kernel.img atau di modul mana pun, atau pustaka, bahkan jika:

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

Namun, file ini atau kodenya tidak dapat ditemukan. Jadi di mana itu bersembunyi?

• Apa yang diperlukan untuk menulis overlay DT untuk mengimplementasikan saran Stefan? @lategoodbye

Overlay/parameter sepele untuk ditambahkan. Memperluas driver untuk mendukungnya sedikit lebih berhasil, tetapi tidak banyak. Alasan mengapa hal itu belum dilakukan adalah karena kami tidak yakin ini adalah perubahan yang masuk akal - saya pikir itu mengirimkan pesan yang salah, bahwa masalahnya adalah mengelola peringatan, padahal sebenarnya masalahnya adalah sistem pengiriman daya yang tidak memadai.

Tweaking fitur seperti ini sering dilakukan dengan menggunakan parameter modul. Device Tree terutama digunakan untuk menggambarkan perangkat keras.

Mungkin seperti ini:

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]");

Pendapat saya apakah mudah atau tidak untuk menonaktifkan penjaga keamanan adalah: biarkan orang berjalan di atas tali melintasi Air Terjun Niagara jika mereka mau. Kita harus melakukan yang terbaik untuk menginformasikan bahaya yang terlibat.
Mungkin peringatan gemuk di probe():

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

Jika kita memblokir tindakan seperti ini, kita mungkin menemukan diri kita menghalangi semangat peretas/pembuat dan saya pikir itu akan menyedihkan.

Sunting: ovlog -> uvlog

Saya pikir menonaktifkan penjaga keamanan harus SELALU sulit. Kalau tidak, orang akan melakukannya, dan itu akan menyebabkan lebih banyak masalah daripada yang ingin kita tangani. Misalnya, Anda memerlukan segala macam lisensi untuk dapat melintasi air terjun Niagara. Orang masih bisa melakukannya, itu hanya PITA untuk mengatur. Perangkat lunak keamanan ada di kapal yang sama. Orang bisa melakukannya - semua sumber tersedia untuk mengubah isi hati Anda, tapi saya tidak percaya kita harus membuatnya mudah.

Begini caranya.

Pengguna acak mendapat peringatan voltase.
Google
Lihat bahwa dia membutuhkan catu daya yang lebih baik.
Tidak bisa langsung mendapatkannya, jadi cari tahu cara mengabaikan pesannya
Menyetel parameter modul yang mudah diubah untuk mengabaikan peringatan.
2 minggu kemudian, kartu SD rusak, beberapa kesalahan USB acak terjadi, atau masalah terkait daya lainnya
Posting di forum. Tidak menyebutkan dia menonaktifkan peringatan.
Banyak waktu yang dihabiskan oleh orang-orang yang mencoba menemukan masalah yang seharusnya sudah jelas sejak awal.

@JamesH65 :
Analogi tali jatuh Niagara saya ternyata paling baik digunakan untuk mengapa harus sulit untuk menghindari pemeriksaan keamanan :-)

Mengenai betapa sulitnya untuk menghindarinya, saya telah gagal memperhitungkan betapa mudahnya mengkompilasi kernel akhir-akhir ini. Informasi Howto sudah tersedia dan cukup cepat untuk melakukannya di Pi itu sendiri, dibandingkan dengan pekerjaan semalam dulu.

Adapun pemecahan masalah Anda pada argumen forum, tidak terlintas dalam pikiran saya bahwa itu bisa menjadi masalah, tapi saya hanya memindai beberapa forum dan tidak terlibat dalam membantu orang dengan masalah korupsi kartu SD jadi saya benar-benar akan' tidak tahu.

Saya melihat ada Raspbian baru yang memiliki logging di bawah tegangan ini, yang mungkin berarti bahwa paket kernel Debian telah diperbarui juga.
Saya akan menarik untuk melihat bagaimana ini berjalan selama beberapa minggu ke depan.

Belum lama ini saya mengetahui bahwa pengukur kabel daya memainkan faktor dalam hal ini, tidak hanya peringkat catu daya. Catatan tentang ini di bagian Catu daya di Dokumentasi saya pikir akan bagus.

Itu selalu sangat mencerahkan untuk melihat bagaimana kami sangat berbeda dalam filosofi hack-your-own-device DIY ini.

AFAICR RPi didasarkan pada ideologi membuat HW keren mudah diakses oleh masyarakat umum, termasuk anak-anak. Jadi sama seperti seorang anak dengan palu, pisau, atau api akan belajar sejak dini betapa mudahnya menghancurkan sesuatu, atau terbakar, itu seharusnya tidak menghalangi kita untuk mengizinkan anak-anak menggunakan alat kehidupan yang paling dasar itu. Atau mempersulit mereka untuk menggunakan dan mempelajarinya. Jadi IMO dan dalam kasus khusus ini, saya sama sekali tidak melihat bagaimana opsi cmdline yang diperoleh dari dokumentasi yang tepat (dengan semua peringatan di atas dan di luar) mungkin akan memperburuk ini, daripada bagi orang yang mencoba memaksa memberi tegangan ekstra ke RP mereka, menggunakan misalnya metode back-powering USB yang jauh lebih berbahaya , atau pengumpanan ganda dari sumber yang berbeda. Belum lagi betapa mudahnya menyalahgunakan GPIO. Jadi saya menemukan argumen di atas untuk "membuatnya lebih sulit" untuk diterapkan, sebagai sangat timpang.

Sebagai catatan tambahan, bagi siapa pun yang kebetulan menemukan utas ini. Saya baru saja menambahkan opsi boot config.txt : avoid_warnings=2 dan astaga, akhirnya semua sampah kernel/dmesg itu hilang! Selain itu tampaknya perangkat berjalan lebih lancar. Ya, itu dibatasi hingga 600 MHz, yang saya kira oleh firmware, tetapi sudah berjalan lebih baik. Saya masih harus melakukan beberapa tes kinerja yang tepat, tetapi saya benar-benar berpikir ada hit kinerja, ketika pesan-pesan itu diaktifkan. Reaksi IO tampak lebih gelisah dan lamban sementara log kernel di-spam. (NB. Saya masih menggunakan 4.4.14.30 dan belum menggunakan 4.14.34, di mana ada beberapa perbaikan sysfs dan log.) Namun, yang misterius adalah mengapa vcgencmd get_throttle kembali 0x0 , padahal perangkatnya jelas dicekik. -- [EDIT] Opsi itu juga mematikan pelambatan, sehingga kernel ondemand normal (?) CPU gubernur berfungsi sebagaimana mestinya.

Dan tentu saja kita memiliki analogi mobil yang sangat menghibur. Saat ini semua mobil menggunakan CAN BUS dan sebagian besar (bahkan yang sangat tua) memiliki akses ODB2 yang dapat digunakan untuk semua jenis diagnostik, termasuk untuk menonaktifkan berbagai lampu peringatan. Anda dapat menggunakan dongle ODB2 BT $12 Anda sendiri dan menonaktifkan peringatan apa pun dengan telepon Anda sendiri. Dan siapa pun yang pernah memiliki Audi, VW, atau BMW juga tahu bahwa beberapa lampu peringatan mesin itu menyala tanpa alasan lain selain gangguan, untuk meminta pemiliknya membawa mobil ke pusat layanan mereka sendiri untuk pemeriksaan setelah beberapa X. mil dan memaksa Anda untuk memompa ekstra $$$ untuk vendor. (Strategi yang sangat mirip dengan harus membeli catu daya 5.4V/2.5A dari yayasan RPi.)

Saya benar-benar berpikir ada hit kinerja, ketika pesan-pesan itu diaktifkan. Reaksi IO tampak lebih gelisah dan lamban sementara log kernel di-spam.

Jadi Anda tidak hanya mencoba memberi daya pada Pi Anda dengan cara yang paling buruk, tetapi juga mengeluarkan kartu SD dari neraka? :)

Interval komit standar ext4 adalah 5 detik. Jadi, ketika Anda benar-benar melihat sistem Anda tertinggal yang disebabkan oleh beberapa aktivitas disk yang menggelikan setiap 5 detik, Anda harus mempertimbangkan dengan serius untuk mengganti kartu SD Anda. Kinerja IO acak penting jika Anda mengalami masalah seperti itu, sebagian besar kartu SD cukup buruk di sini, itulah sebabnya penting untuk hanya membeli kartu SD yang sesuai dengan A1 atau A2 lagi (postingan terakhir dari utas ini berisi angka untuk SanDisk kartu A1). Ini melakukan besaran yang lebih tinggi dibandingkan dengan kartu SD rata-rata. IO acak dengan ukuran blok kecil (menulis beberapa konten log) bisa 100 hingga 500 kali lebih cepat.

Tapi mengingat bagaimana Anda mencoba untuk tidak memperbaiki situasi underpowering Anda, kemungkinan besar Anda hanya tertarik untuk menyamarkan masalah lain ini juga? Menambahkan commit=600 ke /etc/fstab akan berhasil.

Jika Anda tertarik untuk mendiagnosis masalah:

sudo apt install sysstat
sudo iostat 10

(perhatikan persentase %iowait karena ini memberi tahu Anda seberapa banyak seluruh sistem Anda terjebak di IO)

FYI: Ini adalah kutipan copy/paste dari spesifikasi USB 2.0:

• Fungsi daya rendah harus mampu beroperasi dengan tegangan input VBUS serendah4.40 V , diukur pada ujung steker kabel.

• Fungsi daya tinggi harus mampu beroperasi dalam mode daya rendah (beban satu unit) dengantegangan input serendah 4.40 V , sehingga dapat dideteksi dan dihitung bahkan ketika dicolokkan ke hub buspowered. Mereka juga harus mampu beroperasi dengan daya penuh (hingga lima unit beban) dengan tegangan VBUS 4,75 V, diukur pada ujung steker hulu kabel.

Persyaratan sumber daya dan wastafel dari kelas perangkat yang berbeda dapat disederhanakan dengan pengenalan konsep beban unit. Satuan beban didefinisikan sebagai 100 mA. Jumlah beban unit yang dapat ditarik oleh perangkat adalah maksimum absolut, bukan rata-rata dari waktu ke waktu. Perangkat dapat berupa daya rendah pada satu unit beban atau daya tinggi, mengkonsumsi hingga lima unit beban. Semua perangkat default ke daya rendah. Transisi ke daya tinggi berada di bawah kendali perangkat lunak. Perangkat lunak bertanggung jawab untuk memastikan tersedianya daya yang memadai sebelum mengizinkan perangkat menggunakan daya tinggi.

Pengukuran saya:

# 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

CATATAN:
Semua pengujian didasarkan pada periferal USB yang terhubung berikut ini:

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

Beban stres CPU dilakukan dengan:
for ((i=0; i<$(nproc --all); i++)); do nice yes >/dev/null & done

Sekarang ini menunjukkan bahwa saya memiliki kabel/koneksi yang benar-benar buruk (di ujung RPi) atau ada sesuatu yang salah secara internal. Ini juga menjelaskan efek ping-pong peringatan tegangan rendah, karena sangat dekat dengan ambang batas 4.63 V .

Dan "kartu SD dari neraka" saya baik-baik saja membaca 20MB/dtk dan menulis ~8 MB/dtk... tanpa peretasan kinerja pembaca kartu SD.

Dan "kartu SD dari neraka" saya baik-baik saja membaca 20MB/dtk dan menulis ~8 MB/dtk... tanpa peretasan kinerja pembaca kartu SD.

Anda tidak pernah mengklik URL dan tidak mengikuti saran, bukan? :)

Anda berbicara tentang kinerja berurutan yang 99% tidak relevan dengan SBC (mereka penting dengan kamera digital dan perekam video dan kasus penggunaan 'streaming' semacam itu). Yang benar-benar penting dengan SBC adalah IO acak dan di sini kartu SD yang menunjukkan penulisan sekuensial ~8MB/s yang menggelikan biasanya sangat lambat dengan IO acak. Kami telah melihat kartu seperti itu menjadi lambat seperti 2 IOPS (Operasi IO per detik) dengan pola akses 16K. Sementara kartu berperingkat A1 yang bagus 250 hingga 500 kali lebih cepat! Ini semua tentang IOPS dan MB/s agak tidak relevan.

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

Dan juga lagi: Gunakan iostat 10 secara paralel dan perhatikan persentase %iowait dan jumlah data yang ditulis. Jika ini terus-menerus tinggi, kartu SD Anda perlu diganti.

Itu membuat saya sangat sedih melihat Anda bersikap bodoh dan bahkan secara aktif mempromosikan ide-ide aneh seperti mengatur avoid_warnings=2 . Saya harap orang-orang RPi akan menghapus kemampuan ini dengan pembaruan firmware berikutnya karena seperti yang dapat dilihat dengan jelas, itu adalah ide yang mengerikan untuk meningkatkan upaya dukungan tanpa alasan ...

Jadi... sepertinya Anda menemukan masalah Anda @E3V3A

Sekarang ini menunjukkan bahwa saya memiliki kabel/koneksi yang benar-benar buruk (di ujung RPi) atau ada sesuatu yang salah secara internal. Ini juga menjelaskan efek ping-pong peringatan di bawah tegangan, karena sangat dekat dengan ambang 4,63 V.

Apakah Anda memiliki berbagai jenis kabel untuk diuji? Apakah Anda memiliki papan RPi lain untuk diuji?

Itu membuat saya sangat sedih melihat Anda bersikap bodoh dan bahkan secara aktif mempromosikan ide-ide aneh seperti mengatur avoid_warnings=2. Saya harap orang-orang RPi akan menghapus kemampuan ini dengan pembaruan firmware berikutnya karena seperti yang dapat dilihat dengan jelas, itu adalah ide yang mengerikan untuk meningkatkan upaya dukungan tanpa alasan ...

Melihat sekilas kode yang berhubungan dengan "avoid_warnings", semuanya agak aneh dan sulit untuk diikuti, tetapi saya rasa Anda benar, yang seharusnya tidak menghentikan pencatatan masalah tegangan rendah. Yang harus dilakukan adalah menghentikan tampilan peringatan (petir), tetapi tetap melakukan logging. Kami akan membahas di rumah.

Sekarang ini menunjukkan bahwa saya memiliki kabel yang sangat buruk

Anda cukup menjelaskan rata- rata kabel Micro USB di luar sana. Mereka tidak pernah dimaksudkan untuk membawa lebih dari 500 mA yang cukup banyak menjelaskan mengapa menyalakan melalui Micro USB sangat berantakan jika pengguna tidak menghabiskan uang ekstra untuk PSU kualitas ekstra dengan kabel tetap menunjukkan resistansi rendah (PSU dengan kabel tetap harus menyediakan tegangan yang diiklankan di sisi konektor sehingga resistansi kabel sudah diperhitungkan. Ini membuat perbedaan besar dibandingkan dengan situasi dengan PSU USB dan kabel Micro USB terpisah)

Saya tahu Anda tidak mengunjungi tautan sebagai tabel yang disematkan:

Tautan berikut memberikan dengan cara yang mudah-mudahan dapat dimengerti situasi/tantangan penurunan tegangan dengan kabel Micro USB rata-rata (biasanya memiliki saluran listrik dengan peringkat 26 atau bahkan 28 AWG): https://www.cnx-software.com/2017/04/ 27/memilih-kabel-mikro-usb-untuk-papan pengembangan-daya-atau-telepon pengisi daya/

@ThomasKaiser

Pertama saya ingin melengkapi Anda, atas upaya besar Anda dalam mencoba membantu dan meyakinkan kami untuk semua dan di atas. Meskipun, saya sering terganggu oleh saran Anda, saya sangat menghargainya! Mungkin, hanya karena Anda dapat berdebat dengan bukti yang layak bahkan jika Anda jelas-jelas tidak setuju dengan sebagian besar ideologi saya sendiri. :) Juga, terima kasih untuk meja kabel itu.

Anda tidak pernah mengklik URL dan tidak mengikuti saran, bukan?

Mengklik URL secara membabi buta tidak berarti saya tidak mengikuti atau menerima saran dan saran yang beralasan. Saya sangat menyadari kartu SD yang buruk (dan palsu) di luar sana, dan sudah lama sekali. Namun, penggunaan sehari-hari saya sangat jarang membutuhkan kinerja tinggi seperti yang Anda sarankan. Cara sehari-hari saya menggunakan RPi saya sama sekali tidak memerlukan jenis kecepatan IO R/W yang tinggi. Jadi sampai saya membutuhkan kinerja yang lebih baik atau mulai melihat kesalahan serius, saya akan terus menggunakan apa yang saya miliki. Jika Anda ingin mengirimi saya kartu SD 100 EUR, silakan.

...mengatur avoid_warnings=2 . Saya harap orang-orang RPi akan menghapus kemampuan ini dengan pembaruan firmware berikutnya.

Ini pasti saran paling bodoh yang pernah saya lihat dari Anda sejauh ini. Ini bertentangan dengan semua aturan tidak tertulis - dan sifat dasar proyek DIY. Jika orang ingin menjalankan HW (atau mobil) mereka sampai mereka mengerem, mereka harus dapat melakukannya tanpa seseorang seperti Anda menuding mereka karena "bodoh". Jika kalian telah menghabiskan sebagian kecil dari waktu untuk benar-benar memperbaiki bug dan masalah, daripada berdebat melawan mereka dan orang-orang yang melaporkannya, kami akan jauh lebih baik, dan tidak dengan pemboman serial pembaruan yang rusak.

Seperti yang saya katakan di atas, ribuan orang menggunakan Pi mereka untuk semua jenis proyek kecil, dan membuat mereka tetap berjalan seperti itu, sampai mereka mendapatkan ide bagus ini untuk diperbarui, hanya untuk mengetahui bahwa semuanya berantakan. Dekat setiap saat!
Orang-orang yang saya ajak bicara di komunitas MagicMirror semuanya menyetujui satu hal:
If your MM is working, never, ever update the firmware or kernel!

Garis bawah. Untuk seseorang yang menjalankan PiHole atau aplikasi tampilan lainnya, itu tidak terlalu menjadi masalah. Tetapi ketika seseorang telah mengintegrasikan banyak periferal seperti pengenalan wajah, pengenalan suara, Cloud API, sensor eksternal seperti PIR, Ultrasonics, deteksi cahaya, remote IR, kontrol GPIO eksternal, dan berbagai perangkat USB, seperti SDR, semua di perangkat yang sama , maka pembaruan Anda yang rusak tidak lagi menyenangkan. Anda melakukannya sekali atau dua kali, lalu Anda berkata, "Saya tidak akan pernah memperbarui ini lagi." .

@JamesH65

Saya kira Anda benar, itu seharusnya tidak menghentikan pencatatan masalah tegangan rendah. Yang harus dilakukan adalah menghentikan tampilan peringatan (petir), tetapi tetap melakukan logging.

Alasan Anda sangat menakutkan, terutama mengingat Anda adalah bagian dari yayasan RPi! Apakah Anda akan tidur lebih nyenyak di malam hari jika Anda tahu bahwa kartu SD saya terisi oleh log berulang, semua karena pilihan saya sendiri? Saya pikir Anda menjadi sangat bias dan saya tidak melihat atau mendengar alasan yang valid untuk melakukan apa yang TK dan Anda sarankan. Apa sebenarnya yang Anda harapkan untuk diperoleh dengan melakukan ini?

Berikut ini adalah saran menghasilkan uang gratis dari saya:
Dalam iterasi berikutnya dari Raspberry Pi N (4?), Anda harus memastikan untuk:

1. Gunakan konektor USB-C 3A
2. Sesuai dengan standar USB
3. Sertakan kabel konektor low loss
4. Sertakan catu daya ajaib jika perangkat tidak sesuai dengan (2).
5. Sertakan kartu SD yang paling sesuai
6. Sertakan kartu suara internal yang berfungsi dengan MIC/AUX

Masing-masing dari mereka sendiri, akan menghemat banyak waktu dan uang karena Anda akan dapat menempatkan semua upaya Anda saat ini ke dalam penjualan, pemasaran, pengembangan dan produksi, daripada berdebat.

Beri tahu kami semua kapan ini akan terjadi, karena pada hari itulah saya akan berhenti memperbarui dan membeli HW Anda, secara permanen.

@jakemagee

Apakah Anda memiliki berbagai jenis kabel untuk diuji?

Ya, sebenarnya, saya baru saja mencoba hari ini dengan kabel lain, tetapi peningkatannya minimal tetapi terlihat jelas.

# 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

Jika orang ingin menjalankan HW (atau mobil) mereka sampai mereka mengerem, mereka harus dapat melakukannya tanpa seseorang seperti Anda menunjuk jari ke arah mereka

Jika orang-orang itu tidak mau membuka masalah dukungan dan percaya bahwa mereka harus menyalahkan perangkat lunak untuk masalah perangkat keras mereka, semuanya akan baik-baik saja. Tetapi mereka melakukan dan melaporkan berbagai hasil yang tidak perlu dari petualangan mereka yang kurang bertenaga sebagai 'serangga' yang membuang waktu mereka sendiri dan orang lain.

Saya berkontribusi pada proyek sumber terbuka yang menangani semua jenis SBC (kecuali Raspberry). Sebagian besar 'masalah perangkat lunak' yang dimiliki orang adalah kenyataan

• underpowering (hampir hanya mempengaruhi papan dengan Micro USB -- papan dengan colokan barel di mana pengguna harus membeli PSU yang bagus dengan kabel tetap biasanya tidak terpengaruh)
• ada yang salah dengan kartu SD (kami dapat menghilangkan banyak masalah ini dengan hanya merekomendasikan Etcher lagi dan dengan mengedukasi pengguna melalui motd jika mereka kehabisan kartu SD yang jelek, kami membandingkan kartu pada saat boot pertama secara otomatis )

Mampu membedakan antara masalah perangkat keras dan masalah nyata sangat penting jika Anda ingin menghabiskan waktu untuk masalah perangkat lunak dan tidak hanya berurusan dengan ketidaktahuan (seperti milik Anda -- saya benar-benar tidak percaya Anda masih menolak untuk memperbaiki situasi Anda yang kurang bertenaga) . Jadi sekarang pencatatan undervoltage sudah dilakukan, akan berakibat fatal jika pengguna dapat menyamar ini karena seperti yang dapat kita lihat dari Anda, mereka bahkan didorong untuk melakukannya...

Karena Anda sepertinya suka menggunakan perangkat keras yang tidak sesuai (baik itu menyalakan atau menyimpan), saya sudah merekomendasikan menambahkan commit=600 ke /etc/fstab mengurangi kinerja IO acak yang buruk dari kartu SD Anda (serius: jika beberapa baris log setiap beberapa detik menghasilkan sistem yang lamban atau Anda takut masuk secara umum ini adalah ide bagus juga secara drastis mengurangi keausan pada media flash -- distro 'saya' untuk tujuan ini menerapkan log2ram menulis konten log kembali ke 'disk' saja setiap jam secara default)

Saya tidak ingin terlibat dalam diskusi yang sangat panjang ini, tetapi FWIW saya akan mengatakan bahwa saya sengaja menemukannya mencari cara untuk menekan pesan kernel dari konsol (dalam pengalaman saya ini telah membuat masalah buruk menjadi lebih buruk karena saya Saya mencoba melakukan triase dan mematikan tetapi mendapatkan pesan yang dicetak tepat di atas file di editor saya, dll.) dan ada beberapa cara untuk melakukan ini, seperti dmesg -n 1 see
https://superuser.com/questions/351387/how-to-stop-kernel-messages-from-flooding-my-console#answer -351402
Komentar sebelumnya menyarankan bahwa ini tidak berfungsi, tetapi tampaknya berfungsi dengan baik untuk tujuan saya (yaitu pada RPi 3 B+ itu menghentikan pesan kernel agar tidak dicetak ke konsol saya meskipun masih muncul di output dmesg )

Saya memiliki masalah yang sama. Saya menggunakan pengisi daya 5V 2A dan dmesg kebanjiran

Di bawah tegangan terdeteksi! (0x00050005)
Tegangan dinormalisasi (0x00000000)

Jadi saya membeli convertert Modul DC-DC (saya menurunkan tegangan dari 12V ke 5V) hy196_0815.

Kesalahan tidak hilang. Selanjutnya saya mengganti mircorusb cabel (Dari huawei P9 lite) dan saya pikir itu saja.
RPI 3 B+ berjalan sampai sekarang 12 jam, dan kesalahan tidak muncul di dmesg.
Jadi kabel yang baik sangat penting.

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.

Terima kasih atas sarannya, kepada Yayasan yang menjual 19 juta perangkat, benar-benar mengubah pasar SBC, memberikan jutaan pound untuk pendidikan dari keuntungan. Saya yakin saran Anda akan benar-benar mengubah bisnis kami. Saya telah memberikan petunjuk di mana saran Anda tidak akan benar-benar menghasilkan lebih banyak uang di bawah ini.

Masalahnya di sini, adalah Anda memiliki pendapat dan tidak mau menerima pendapat itu salah. Yang menurut saya, itu. Tidak menakutkan, hanya pendapat yang berbeda dengan Anda. Anda juga tidak mau memperbaiki masalah tegangan rendah Anda, yang akan membuat semua pesan hilang, untuk alasan yang masih belum jelas.

Kami sekarang telah menambahkan pencatatan tarif ke pesan. Ini membatasi hingga tiga pesan setiap 5 menit. Jika log Anda MASIH terisi dengan pesan FIX THE DAMN POWER SUPPLY! ITU TIDAK BENAR! Saya tidak bisa mengerti apa yang begitu sulit untuk dipahami tentang itu.

Poin sebagai jawaban atas beberapa hal di atas, tanpa benar-benar memberikan apa yang sebenarnya dimiliki Pi4 di dalamnya.

standar USB. SoC memiliki perangkat USB inbuilt, yang sayangnya sedikit omong kosong tetapi kami tidak dapat berbuat apa-apa tentang itu, tetapi dengan ARM FiQ kami telah membuatnya bekerja dengan cukup baik. Chip hub, yang juga menyediakan ethernet, kompatibel dengan USB.

Tidak ada gunanya menyediakan kartu SD, catu daya, kabel, dll, karena setiap pembeli Pi juga akan mendapatkan satu set lengkap setiap saat, dan tidak semua orang menginginkannya. Itu juga akan membuat harga headline terlalu mahal. Itu semua adalah ide yang mengerikan. Anda dapat membeli kit dengan semua yang ada di dalamnya. . . . . .

SOC juga berisi sistem suara yang layak yang dihasilkan melalui HDMI yang bagi sebagian besar orang baik-baik saja. Sekali lagi, tidak ada gunanya membuat Pi lebih mahal untuk semua orang, dengan fitur yang hanya digunakan beberapa orang. Anda jatuh ke dalam perangkap yang sama dengan pemikiran Anda tentang logging - berpikir kasus penggunaan Anda adalah yang penting, di mana sebenarnya Anda hanyalah salah satu dari jutaan pengguna. Kebutuhan banyak orang melebihi kebutuhan segelintir orang.

Adapun menghemat uang - titik masuk dmesg untuk daya rendah ada untuk itu - untuk mengurangi masalah dukungan!

Adapun uang untuk pemasaran, pengembangan, produksi - kami punya banyak.

Jadi saya mengemudi di jalan dengan BMW saya yang berumur 2 tahun. Ini jauh dari model kinerja top-of-the-line mereka, tetapi bukan yang low-end. Ini adalah mobil yang hebat dan telah membawa saya bolak-balik untuk bekerja, jalan-jalan di akhir pekan, dan sesekali tur panjang, selama 2 tahun. Karena, saya tidak bermaksud untuk mengambilnya untuk kecepatan tertinggi setiap hari di seluruh Eropa dengan autobahn, itu telah melayani saya dengan sempurna dan melakukan pekerjaan dengan baik sejauh ini.

Namun, suatu hari lampu servis menyala, menunjukkan bahwa sudah waktunya untuk membawa mobil masuk untuk pemeriksaan servis 1000 mil. Jadi sejak musim dingin itu hanya akan bergulir dan saya memutuskan untuk menerimanya untuk layanan pra-musim gugur. Saya melakukannya dan mekanik mengatakan semuanya beres, tetapi telah memperbarui sistem dan mengatur ulang indikator layanan. Semuanya bagus.

Karena jalanan di sini bisa menjadi dingin, saya memutuskan untuk memasang kembali ban musim dingin yang saya gunakan dari tahun lalu, dan setelah saya melakukannya, tiba-tiba lampu peringatan darurat Engine yang kritis menyala! Saya bingung, karena saya baru saja mendapatkannya kembali dari layanan! Saya menelepon mekanik dan menceritakan masalah saya. Dia bertanya apakah saya membuat perubahan sejak mengunjunginya minggu lalu. Saya berkata, tidak juga, pakai saja ban musim dingin yang saya gunakan tahun lalu. Dia berkata, "Oh! Apa jenisnya?", jadi saya menjawab, "Yah, saya menemukan ban musim dingin Bridegstone standar ini, dan memutuskan bahwa saya tidak perlu mengeluarkan uang ekstra untuk membeli ban musim dingin berperforma tinggi BWM khusus yang Anda jual. " Dia menjawab: "Oh, itu menjelaskannya! Anda menggunakan ban jelek, dan kami baru saja menerapkan sistem deteksi dan peringatan ke dalam mobil, yang mendeteksi jika Anda tidak menggunakan ban kustom kami." Jadi saya berkata, "Ah, baiklah. Terima kasih telah menjelaskan situasinya, tetapi saya akan menyimpan ban yang sudah saya miliki untuk musim berikutnya, karena ban tersebut bekerja dengan baik tahun lalu."

Keesokan harinya, saya mengemudi di jalan raya, mencoba melewati truk yang lebih lambat. Saya mempercepat hingga 1200 Hm/jam
[1200 Hekto-meter = 120 Km], dan saat saya berada di samping truk, tiba-tiba mesin saya berhenti berakselerasi
dan mesin dan mobil tiba-tiba membuat saya berhenti di kecepatan 600 Hm/jam. Pada saat yang sama, lampu kompartemen bagian dalam mulai berkedip setiap beberapa detik, hampir membutakan saya di senja musim gugur, sementara lampu engine kritis melakukan hal yang sama. Saya hampir mengalami tabrakan langsung karena episode ini, dan memutuskan untuk memanggil rekan lama saya Mr.Ferrari, dan menjelaskannya kepadanya.

Hari berikutnya saya pergi ke garasinya di mana dia memiliki penganalisis ODB2. Dia menjelaskan bahwa bukan mobil itu sendiri, atau ban yang menjadi masalah, tetapi pembaruan baru untuk perangkat lunak mobil. Tapi dia bisa menonaktifkannya. Jadi saya memutuskan untuk menonaktifkan peringatan berbahaya (dan sekarang tidak berguna) ini tentang ban non-OEM saya. Aku pergi berkuda dengan gembira menuju matahari terbenam...atau begitulah!

Lalu saya berkendara ke awan nyamuk, dan kaca depan saya ditanduk. Saya menyalakan ular beludak, hanya untuk menemukan
bahwa salah satu bilah penghapus agak aus. Saya membuat catatan mental untuk diri saya sendiri untuk memperbaikinya lain kali saya memiliki
peluang. Tetapi bahkan sebelum saya sampai pada akhir pemikiran itu. Tiba-tiba dari kompartemen tengah kursi belakang, sebuah jack-in-the-box muncul seperti peluru pegas, dan berteriak, "ANDA PUNYA BAN SHIT!! GANTI MEREKA DAN DENGARKAN AKU!" di telinga kananku. Saya membelok dari jalan ke ladang yang kotor dan memutuskan bahwa memasukkan uang saya ke perusahaan semacam itu tidak sebanding dengan ban yang digunakannya. Saya menumpang kembali ke realitas dunia IoT tertanam yang sangat kompetitif dan menemukan diri saya sebagai Tesla, yang dapat menggunakan ban apa pun yang tersedia, sumber daya, dan dapat berjalan pada arus apa pun atau di jalan apa pun dengan kecepatan apa pun yang Anda inginkan.

Damai akhirnya!

Kutipan di atas didasarkan pada kisah nyata, dan akan ditulis dalam buku yang akan datang, "Betapa besar perusahaan kecil menjadi serakah dan sombong, dan kemudian digantikan."

Sombong? Atau benar saja? Saya keluar.