I'm working on a project at the office where I have to enable the earlyprintk so that I can see the crashes at boot. So far so good, I've added earlyprintk=mydriver ... in the command line + some custom platform settings and I can see now the messages printed at boot.
...mydriver is a custom (the SoC) serial driver which is registered as the earlyprintk driver and does the driver setup at boot time.
However, the issue here is that I can see earlyprintk sending the logs, and when the log timestamp reaches 4,1 seconds, I see again the whole dmesg printed from timestamp 0.
So basically the normal console doesn't resume the printing where the earlyprink left off, but does a complete kernel buffer printing.
So far I couldn't find a way to solve this issue, any help much appreciated.
Thanks & Regards
mdaniel.
Related
Let me start off with the components used:
GPIO extension board to connect the raspberry pi to components
Bme280
Pi 3B
Problem description:
This problem was intermittent at first. We were receiving reading and the error occured out of nowhere, made adjustment to the sensor(taking out and putting it back in) which solved it but when we touch the sensor the error showed up again.
We decided to change the sensor and the problem turned from intermittent to persistent. Now we have this as permanent issue.
We removed the package for BME280 and SmBus2 and decided to reinstall it again.
RPI Bme280: https://pypi.org/project/RPi.bme280/
I followed this BME280 installation guide, however when prompting for 'i2cdetect -y 1' there were lines but no number showing up.
What has been confirmed so far:
Patching up of circuits was fine, tested with my lecturer pi and it
works fine.
Codes is fine, we even use the sample code provided by RPi.bme280
I2c was enabled everytime
Please help me because I am really lost. I needa submit this by next week so any help is appreciated.
Problem pic --> Picture of the problem
I've tried to respond, but there is a few pitfalls in SMBus and i2c, so to break the question into smaller bits I've quoted your original message with an indent. The response is provided beneath.
This problem was intermittent at first. We were receiving reading and the error occurred out of nowhere, made adjustment to the sensor(taking out and putting it back in) which solved it but when we touch the sensor the error showed up again.
I locked onto the statement, "Touched the sensor". Is there a chance the BME280 experienced an ESD discharge? And therefore is now partially or fully broken?
Are you using an ESD safe room? or at least ESD bracelet. You will not notice small ESD discharges, and for small electronics even a sub 1000V discharge can cause damage instantly or over time. (Fundamentals of Electrostatic Discarge - incompliancemag.com)
I followed this BME280 installation guide, however when prompting for 'i2cdetect -y 1' there were lines but no number showing up.
The I2Cdetect -y 1
Will send a ReadBit message to each possible slave 0-127. Then listens for the ACK on the slave address.
The message is very simple, but does the trick for detecting working i2c slaves.
As you stated there is no "Lines", i would suggest the slave either has issues responding, if the BME280 has the correct 3v3+GND supplied.
As another possability, could you redo this step dtparam=i2c_arm=on,i2c_baudrate=400000
(Set the baudrate way down to 10000 /10k. Should this solve the issue and you need higher bandwidth, attempt on "50000 /50k" or "100000 /100k") This is just to eliminate the possibility the slave cannot opperate on this high frequency. 400k Baudrate for SMBus is high for a prototype/testing scenario. Very small amounts of interference can corrupt the data over SDA.
Another possibility is the Sink-Current which i've learned the hard way is not the same on i2c and SMBus over i2c.
Is you Pull-up resistor appropriate for the limited sink-current?
The SMBus specifies a minimum sink current of 100µA, and a maximum of 350µA, compared to 3mA for the I²C bus (Ampere=Voltage/Resistance Ohm).
Now to the Software issue.
From your supplied picture on imgur.
File "newcodes_''''''''''''''.py" line 2, in
Your compiler cannot find "bme" where you attempt to import bme280. Reference/path issue?
This can be the cause for other issues further into the code calls.
I don't know what SW you are writing the code in, but if there is an option to insert a breakpoint and run a debug build. I would suggest starting there :)
Alright I have resolved the issue, I changed the wire from jumper wire to hard wire. Thank you guys for your response. I appreciate all of them :D
I'm setting and reading different values of the temperature threshold. I set it by echoing the value to the following file:
/sys/devices/virtual/thermal/thermal_zoneN/trip_point_X_temp
It works fine but how do I verify the behavior through logs? Is there any specific log in the output of dmesg that could be useful or states the threshold has been modified? I'm trying to read through demsg output but I don't think I was able to find something relevant, though given the amount of the output, I might have missed something (is there any specific log that I should be looking for instead?)
Other things I tried:
Ran thermal-engine in adb shell, I get read sensor info form file failed
Ran udevadm monitor but I don't see any events
Using this as a reference
My MacBook spontaneously wakes up from sleep mode with high fan activity.
I want to do a investigate this in RTC or power settings? Or by strace-ing of processes, etc (using some process/kernel magic!).
Hint: It is probably managed by "rtcwake".
I am not even sure if this is a scheduled task, or from a WiFi wakeup, or something else.
I don't want guesses about what usually causes this in Mojave, etc. Instead:
I need to do a systematic investigation on this on my MacOS (Mojave). Linux-related answers are also appreciated.
This is about system standby, sleep-mode, suspended mode. (Note that this is not about standup and wakeup of individual processes. The whole laptop turns on spontaneously.)
Reading the log file is the best way to debug the problem.
So, try this command in your Terminal to fetch the system logs,
this will tell you "wake up" history.
log show --style syslog | fgrep "Wake reason: EC.LidOpen"
To see the wake reason:
For macOS Sierra, Mojave, Catalina, and newer
log show |grep -i "Wake reason"
Or for MacOS El Capitan, Yosemite, Mavericks, and older
syslog |grep -i "Wake reason"
This will look like:
MacBookPro kernel[0] : Wake reason = OHC1
MacBookPro kernel[0] : Wake reason = PWRB
MacBookPro kernel[0] : Wake reason = EHC2
MacBookPro kernel[0] : Wake reason = OHC1
So what do these wake reason codes mean?
OHC: stands for Open Host Controller, is usually USB or Firewire. If you see OHC1 or OHC2 it is almost certainly an external USB keyboard or mouse that has woken up the machine.
EHC: standing for Enhanced Host Controller, is another USB interface, but can also be wireless devices and bluetooth since they are also on the USB bus of a Mac.
USB: a USB device woke the machine up
LID0: this is literally the lid of your MacBook or MacBook Pro when you open the lid the machine wakes up from sleep.
PWRB: PWRB stands for Power Button, which is the physical power button on your Mac
RTC: Real Time Clock Alarm, is generally from wake-on-demand services like when you schedule sleep and wake on a Mac via the Energy Saver control panel. It can also be from launchd setting, user applications, backups, and other scheduled events.
There may be some other codes (like PCI, GEGE, etc) but the above are the ones that most people will encounter in the system logs. Once you find out these codes, you can really narrow down what is causing your Mac to wake up from sleep seemingly at random.
Hope this will help :)
This answer is based on Linux, so it might not apply strictly to Mac.
To determine whether rtcwake is responsible for your MacOS wakeups, you could replace the executable (in my Ubutnu it is /usr/sbin/rtcwake) with a wrapper script that leaves a sign of rtcwake having run, e.g.
$ cd /usr/sbin/rtcwake
$ sudo mv rtcwake rtcwake_orig
and then write script /usr/sbin/rtcwake containing
#!/bin/bash
touch $HOME/rtcwake_ran
/usr/sbin/rtcwake_orig
Variants of the script would depend on your shell.
In particular, in the last line you would possibly run rtcwake in some alternative way, so as to not own the process (nohup / disown).
See https://unix.stackexchange.com/questions/152310/how-to-correctly-start-an-application-from-a-shell
To inspect possible causes of wakeup, you can check various relevant logs, at /var/log.
E.g., syslog*, acpi*.
See also https://unix.stackexchange.com/questions/83036/where-is-the-log-for-acpi-events
Do you have wakeonlan?
Here I am documenting my systematic approach. It is loosely based on, and initiated by, the answer by #vijay-rajpurohit, which is in turn based on comment by #Robert #1431720 . Note that the final result is particular to my MacOS machine, based on the logs shown below. It will be different in your MacOS.
In first attempt, I first checked the logs using: log show --style syslog | grep ... but it is taking too long. I accidentally checked /var/log/wifi.log after exploring the /var/log/ (I am also curious about /var/log/powermanagement/*.asl).
This turned out to be most useful:
cat /var/log/wifi.log|grep -i "Wake reason"
Then found this line: (note the EC. bit)
Thu Apr 23 22:41:32.359 Info: <airportd[219]> _systemWokenByWiFi: System wake reason: <EC.ARPT>, was woken by WiFi
Then googled for EC.ARPT, I found the following commands:
pmset -g log Useful stats about "Total Sleep/Wakes since boot".
pmset -g assertions This turned out to show the full answer to this question:
2020-04-24 02:23:38 +0100
Assertion status system-wide:
BackgroundTask 1
ApplePushServiceTask 0
UserIsActive 1
PreventUserIdleDisplaySleep 0
PreventSystemSleep 0
ExternalMedia 0
PreventUserIdleSystemSleep 0
NetworkClientActive 0
Listed by owning process:
pid 111(hidd): [0x0000200a000986a9] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle.4295010950.3"
pid 85(apsd): [0x0003b830000b90bd] 00:00:10 ApplePushServiceTask named: "com.apple.apsd-waitingformessages-push.apple.com"
Kernel Assertions: 0x100=MAGICWAKE
id=504 level=255 0x100=MAGICWAKE mod=24/04/2020, 01:57 description=en0 owner=en0
Idle sleep preventers: IODisplayWrangler
In short, in a systematic approach, I explored the following keywords based on the logs, and googled each :
EC.ARPT (example link)
iohideventsystem (example link)
MAGICWAKE (example link)
ApplePushServiceTask (see below)
Most informative item emerged from the output of pmset -g assertions. For example ApplePushServiceTask in the following line:
pid 85(apsd): [0x0003b830000b90bd] 00:00:10 ApplePushServiceTask named: "com.apple.apsd-waitingformessages-push.apple.com"
The solution that seems to work in my particular case (not a general solution) was to disable :
/System/Library/LaunchDaemons/com.apple.apsd.plist using launchctl. But this cannot be done until you do a csrutil disable in the safe mode. I don't write instructions here because it need caution and you need to enable it later.
(to be updated)
I think the ouput of the command dmesg should be the subset of the file /var/log/dmesg.
But when I am debugging,the segmentation fault information can only be seen in the output of the command dmesg.
What is the difference between them ?
The kernel message buffer is a ring buffer with limited space - when new messages arrive old may get dropped.
dmesg outputs the current buffer.
Normally /var/log/dmesg is filled directly after boot, so that the boot messages do not get lost.
I'm running an embedded Linux board with a console only (no graphical environment) based on the i.MX6 and a custom Yocto build.
I'm trying to stop the screen from shutting off after 15 minutes of inactivity. I think the correct way to do this is to pass consoleblank=0 to the boot arguments, which I have done. The problem is that when I do
cat /sys/module/kernel/parameters/consoleblank
I get 900. The results of cat /proc/cmdline are:
console=ttymxc0,115200 root=/dev/mmcblk0p2 rootwait rw consoleblank=0
Does anyone know where else that parameter could be set?
Thanks
Marlon
To avoid a console blank after a period of time, there's two things to change:
consoleblank=0 as kernel parameter as you mentioned
disable terminal blanking with: setterm -blank 0 -powerdown 0
The value that you see in proc, I suspect that in the boot process the setterm parameters are set, that will change consoleblank parameter, to be sure about this, you can make a simple test:
setterm -blank 600
cat /sys/module/kernel/parameters/consoleblank
# This must be 600
setterm -blank 0
cat /sys/module/kernel/parameters/consoleblank
# This must be 0
You can see additional info in this question: https://unix.stackexchange.com/questions/8056/disable-screen-blanking-on-text-console
I know this is a super old question, but I recently ran into a very similar problem and discovered that the 15 minute blanking timeout was being caused by Qt. If you're running any Qt programs, that's likely the source of the problem.
There is a function in Qt's source called setTTYCursor. If you look at the code in the linked file, it disables the blanking by setting the timeout to 0 when the Qt app loads, and then when it exits, it changes the blanking to a 15 minute timeout. After it does this, /sys/module/kernel/parameters/consoleblank reports a value of 900, regardless of what you initially supplied with the kernel command line. I spent a lot of time questioning my sanity before figuring out that Qt was changing this behind my back.
You can bypass this bizarre behavior by setting an environment variable prior to launching the Qt application:
export QT_QPA_PRESERVE_CONSOLE_STATE=1