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
Related
Using uClinux we have one of two flash devices installed, a 1GB flash or a 2GB flash.
The only way I can think of solving this is to somehow get the device ID - which is down the in the device driver code, for me that is in:
drivers/mtd/devices/m25p80.c
I have been using the command mtdinfo (which comes from mtdutils binaries, derived from mtdinfo.c/h). There is various information stored in here about the flash partitions including flash type 'nor' eraseblock size '65536', etc. But nothing that I can identify the chip with.
Its not very clear to me how I can get information from "driver-land" into "user-land". I am looking at trying to extend the mtdinfo command to print more information but there are many layers...
What is the best way to achieve this?
At the moment, I have found no easy way to do this without code changes. However I have found an easy code change (probably a bit of a hack) that allows me to get the information I need:
In the relevant file (in my case drivers/mtd/devices/m25p80.c) you can call one of the following:
dev_err("...");
dev_alert("...");
dev_warn("...");
dev_notice("...");
_dev_info("...");
Which are defined in include/Linux/device.h, so they are part of the Linux driver interface so you can use them from any driver.
I found that the dev_err() and devalert() both get printed out "on screen" during run time. However all of these device messages can be found in /var/log/messages. Since I added messages in the format: dev_notice("JEDEC id %06x\n", jedecid);, I could find the device ID with the following command:
cat /var/log/messages | grep -i jedec
Obviously using dev_err() ordev_alert() is not quite right! - but dev_notice() or even _dev_info() seem more appropriate.
Not yet marking this as the answer since it requires code changes - still hoping for a better solution if anyone knows of one...
Update
Although the above "solution" works, its a bit crappy - certainly will do the job and good enough for mucking around. But I decided that if I am making code changes I may as well do it properly. So I have now implemented changes to add an interface in sysfs such that you can get the flash id with the following command:
cat /sys/class/m25p80/m25p80_dev0/device_id
The main function calls required for this are (in this order):
alloc_chrdev_region(...)
class_create(...)
device_create(...)
sysfs_create_group(...)
This should give enough of a hint for anyone wanting to do the same, though I can expand on that answer if anyone wants it.
I had written a linux scsi low level driver for cdrom. Am able to receive commands one by one from application and am testing it using sg3-utils.
Now I want to receive more than one command while serving the first one.?
for this I tried changing the struct scsi_host members can_queue and cmd_per_lun to some big values like 40, even though not able to receive multiple commands.
Is there any way to test multiple command reception in existing drivers like scsi_debug ?
Please give a little more information ... when you say "receive commands" that implies you are a target. Maybe you mean "sending commands".
i still want to check my Bootloader + Linux Startupcode for an embedded device. Therefore i want to catch the time for every command printed to the serial port.
I know there are programs like putty (which i can dearly recommend), getty, cutecom, picocom, screen etc. But none of these add timestamps to the incomming messages on the host screen (I'm not really talking about the date, more like how many ms have gone since the first output). It actually sounds not like a big deal.
I found out there is one script doing what i wanted to have, called grabserial but it's not working properly, since it's to slow to process the whole output. I discussed this problem in a different forum (if you want to know: grabserial problem but it's not part of the topic). So i can't use that script.
Now again: can you tell me a terminal for Linux which adds timestamps to every line, which was received from a Serial Port?
Thank you
[Edit:] I've found a pretty rough workaround with cereal, which wants to have some settings, since it locks the port everytime you use it. In the end, it adds the actual date and time, not the startup time and difftime between each step, so as you can see I'm still looking for an adequate solution.
This might come 3 years too late, but minicom (https://en.wikipedia.org/wiki/Minicom) supports timestamps for every line printed on the terminal. In Ubuntu it's directly available in the default repos.
You might want to look in to using strace to monitor the serial port. See How can I monitor data on a serial port in Linux?
If you are willing to build the binary by yourself, you can try a branched picocom (https://github.com/codepox/picocom). This is based on picocom 1.7 which is a little old.
I have forked and enhanced this picocom and made it be able to show either delta-time or wall-clock timestamp. You can find it here (https://github.com/tdwong/picocom-with-timestamp). You still have to build the binary by yourself.
Here is how I use it. Note, N is the command to enable/toggle timestamp.
$ picocom -b 115200 /dev/ttyUSB0
...
<ctrl-a> N # enable delta-time timestamp
<ctrl-a> N # toggle wall-clock timestamp
<ctrl-a> N # disable timestamp
tio found at https://tio.github.io provides various timestamp options:
-t, --timestamp
Enable line timestamp.
--timestamp-format <format>
Set timestamp format to any of the following timestamp formats:
24hour 24-hour format ("hh:mm:ss.sss")
24hour-start 24-hour format relative to start time
24hour-delta 24-hour format relative to previous timestamp
iso8601 ISO8601 format ("YYYY-MM-DDThh:mm:ss.sss")
Default format is 24hour
In your case, showing how much time has passed since start, that would be something like this:
tio -t --timestamp-format 24hour-start /dev/ttyUSB0
Settings can also be enabled in tio configuration file ~/.tioconfig
I believe that ExtraPuTTY is the solution you are looking for.
However, I wasn't clear if you wanted something to run ON Linux or just to be able to monitor it (SSH to Linux). If you didn't want a Windows solution, then I apologize.
Let's take e.g. "top" application which displays system information and periodically updates it.
I want to run it using node.js and display that information (and updates!).
Code I've come up with:
#!/usr/bin/env node
var spawn = require('child_process').spawn;
var top = spawn('top', []);
top.stdout.on('readable', function () {
console.log("readable");
console.log('stdout: '+top.stdout.read());
});
It doesn't behave the way I expected. In fact it produces nothing:
readable
stdout: null
readable
stdout:
readable
stdout: null
And then exits (that is also unexpected).
top application is taken just as an example. Goal is to proxy those updates through the node and display them on the screen (so same way as running top directly from command line).
My initial goal was to write script to send file using scp. Done that and then noticed that I am missing progress information which scp itself displays. Looked around at scp node modules and they also do not proxy it. So backtracked to common application like top.
top is an interactive console program designed to be run against a live pseudo-terminal.
As to your stdout reads, top is seeing that its stdin is not a tty and exiting with an error, thus no output on stdout. You can see this happen in the shell if you do echo | top it will exit because stdin will not be a tty.
Even if it was actually running though, it's output data is going to contain control characters for manipulating a fixed-dimension console. (like "move the cursor to the beginning of line 2"). It is an interactive user interface and a poor choice as a programmatic data source. "Screen scraping" and interpreting this data and extracting meaningful information is going to be quite difficult and fragile. Have you considered a cleaner approach such as getting the data you need out of the /proc/meminfo file and other special files the kernel exposes for this purpose? Ultimately top is getting all this data from readily-available special files and system calls, so you should be able to tap into data sources that are convenient for programmatic access instead of trying to screen scrape top.
Now of course, top has analytics code to do averages and so forth that you may have to re-implement, so both screen-scraping and going through clean data sources have pros and cons, and aspects that are easy and difficult. But my $0.02 would be focus on good data sources instead of trying to screen scrape a console UI.
Other options/resources to consider:
The free command such as free -m
vmstat
and other commands described in this article
the expect program is designed to help automate console programs that expect a terminal
And just to be clear, yes it is certainly possible to run top as a child process, trick it into thinking there's a tty and all the associated environment settings, and get at the data it is writing. It's just extremely complicated and is analogous to trying to get the weather by taking a photo of the weather channel on a TV screen and running optical character recognition on it. Points for style, but there are easier ways. Look into the expect command if you need to research more about tricking console programs into running as subprocesses.
I'm debugging communications with a serial device, and I need to see all the data flowing both directions.
It seems like this should be easy on Linux, where the serial port is represented by a file. Is there some way that I can do a sort of "bi-directional tee", where I tell my program to connect to a pipe that copies the data to a file and also shuffles it to/from the actual serial port device?
I think I might even know how to write such a beast, but it seems non-trivial, especially to get all of the ioctls passed through for port configuration, etc.
Has anyone already built such a thing? It seems too useful (for people debugging serial device drivers) not to exist already.
strace is very useful for this. You have a visualisation of all ioctl calls, with the corresponding structure decoded. The following options seems particularly useful in your case:
-e read=set
Perform a full hexadecimal and ASCII dump of all the data read from
file descriptors listed in the
specified set. For example, to see all
input activity on file descriptors 3
and 5 use -e read=3,5. Note that this
is independent from the normal tracing
of the read(2) system call which is
controlled by the option -e
trace=read.
-e write=set
Perform a full hexadecimal and ASCII
dump of all the data written to file
descriptors listed in the specified
set. For example, to see all output
activity on file descriptors 3 and 5
use -e write=3,5. Note that this is
independent from the normal tracing of
the write(2) system call which is
controlled by the option -e
trace=write.
I have found pyserial to be quite usable, so if you're into Python it shouldn't be too hard to write such a thing.
A simple method would be to write an application which opened
the master side of a pty and the tty under test. You would then
pass your tty application the slave side of the pty as the 'tty device'.
You would have to monitor the pty attributes with tcgetattr() on the pty
master and call tcsetattr() on the real tty, if the attributes changed.
The rest would be a simple select() on both fd's copying data bi-directionally and copying it to a log.
I looked at a lot of serial sniffers. All of them are based on the idea of making a virtual serial port and sniff data from that port. However, any baud/parity/flow changes will break connection.
So, I wrote my own sniffer :). Most of the serial ports now are just USB-to-serial converters. My sniffer collects data from USB through debugfs, parse it and output to the console. Also any baudrate changes, flow control, line events, and serial errors are also recorded. The project is in the early stage of development and for now, only FTDI is supported.
http://code.google.com/p/uscmon/
Much like #MBR, I was looking into serial sniffers, but the ptys broke the parity check. However, his sniffer was not helping me, as I'm using a CP2102, and not a FT232. So I wrote my own sniffer, by following this, and now I have one that can record file I/O on arbitrary files: I called it tracie.