Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Everything posted by tkaiser

  1. When you divide by 100 do not use "$1/100" but "sprintf("%.1f", $1/100)" instead as regex. As a reference my whole config that deals with A20/AXP209, several sensor sources and now also CPU stats: http://pastebin.com/ARcjtjzL I do not read out the sensors directly but let my temperature daemon preprocess the raw data (sanitizes numbers if sensors report anomal values as it happens sometimes and does some averaging to get smoother graphs): For CPU stats I use a function that will be called every 20 seconds and processes the counters present in /proc/stat and writes the 6 values I'm interested in (see last graph above) into /tmp/cpustat from where they were picked up by a RPI-Monitor regex: ProcessStats() { set $(awk -F" " '/^cpu / {print $2"\t"$3"\t"$4"\t"$5"\t"$6"\t"$7"\t"$8}' </proc/stat) UserStat=$1 NiceStat=$2 SystemStat=$3 IdleStat=$4 IOWaitStat=$5 IrqStat=$6 SoftIrqStat=$7 UserDiff=$(( ${UserStat} - ${LastUserStat} )) NiceDiff=$(( ${NiceStat} - ${LastNiceStat} )) SystemDiff=$(( ${SystemStat} - ${LastSystemStat} )) IdleDiff=$(( ${IdleStat} - ${LastIdleStat} )) IOWaitDiff=$(( ${IOWaitStat} - ${LastIOWaitStat} )) IrqDiff=$(( ${IrqStat} - ${LastIrqStat} )) SoftIrqDiff=$(( ${SoftIrqStat} - ${LastSoftIrqStat} )) Total=$(( ${UserDiff} + ${NiceDiff} + ${SystemDiff} + ${IdleDiff} + ${IOWaitDiff} + ${IrqDiff} + ${SoftIrqDiff} )) CPULoad=$(( ( ${Total} - ${IdleDiff} ) * 100 / ${Total} )) UserLoad=$(( ${UserDiff} *100 / ${Total} )) SystemLoad=$(( ${SystemDiff} *100 / ${Total} )) NiceLoad=$(( ${NiceDiff} *100 / ${Total} )) IOWaitLoad=$(( ${IOWaitDiff} *100 / ${Total} )) IrqCombinedLoad=$(( ( ${IrqDiff} + ${SoftIrqDiff} ) *100 / ${Total} )) echo "${CPULoad} ${SystemLoad} ${UserLoad} ${NiceLoad} ${IOWaitLoad} ${IrqCombinedLoad}" >/tmp/cpustat LastUserStat=${UserStat} LastNiceStat=${NiceStat} LastSystemStat=${SystemStat} LastIdleStat=${IdleStat} LastIOWaitStat=${IOWaitStat} LastIrqStat=${IrqStat} LastSoftIrqStat=${SoftIrqStat} } # ProcessStats
  2. Just a small follow-up: To get an idea what's going on inside enclosures I added one DS1820 externally to get ambient temperature and one DHT11 inside the server's enclosure close to the PSU (took me some time to patch the programm to read out the DHT11 without a pull-up resistor and to realize that it's not enough to add w1-gpio and w1_therm to /etc/modules when w1_sunxi is missing to be able to talk to the DS1820). Since the device is some sort of a surveillance server (feeds 5 RPi B+ with camera module via PoE and both records their video streams and 'transcodes' to be accessible in realtime via VLC) I also added the ability to record the internal temperature of all 5 PiSpy cams: RPi-Monitor is really great to realize obvious relationships otherwise invisible :-)
  3. I also think hddtemp is either missing or needs a fix (when the disk model is too young). You should give the following a try hddtemp /dev/sda --debug In case you've an USB disk check the comments regarding smartctl/hdparm (and be aware that when you're running wheezy that you might need to patch a smartmontools script since the version shipping with Wheezy is outdated as hell) https://github.com/ThomasKaiser/RPi-Monitor/blob/devel/scripts/sunxi-temp-daemon.sh#L118-L142 BTW: I reworked the sunxi_tp_temp code to be able to deal with both A10 and A20 (they've different temperature curves and I tried to adopt the new code from kernel 4.x for this). And with Yuri's help we're now able to distinguish between A10 and A20 (and possibly A13 as well. The A13 is said to have the same thermal sensor as A20 but is otherwise A10's direct sibling): #!/bin/bash CheckSunxiHardware() { SunxiGeneration="$(awk -F" " </proc/cpuinfo '/^Hardware/ {print $3$4}')" case ${SunxiGeneration} in *sun7i*) # A20 CpuPart="$(awk -F" " </proc/cpuinfo '/^CPU part/ {print $4}')" case ${CpuPart} in *0xc07*) echo "A20: /path/to/sunxi_axp209_temp 144700 100" ;; esac ;; *sun5i*|*A1X*) CpuRevision="$(awk -F" " </proc/cpuinfo '/^Revision/ {print $3}')" case ${CpuRevision} in *a13*|*A13*) # A13 echo "A13: /path/to/sunxi_axp209_temp 144700 100" ;; *) # A10 echo "A10: /path/to/sunxi_axp209_temp 257000 133" ;; esac ;; esac } # CheckSunxiHardware CheckSunxiHardware Will ship this as an update soon.
  4. OK, the web process still isn't running. AFAIK the the next step would be a "service rpimonitor stop" and then let RPi-Monitor run interactively in debug mode: /usr/bin/rpimonitord -v Should print out everything that's wrong on stdout/stderr.
  5. It seems on your system no unprivileged user exists and therefore the rpimonitor's web process doesn't start. I would try to create a user tim (with which you should connect from then on -- working as root isn't the best idea): ​/usr/sbin/useradd -d /home/tim -m -s /bin/bash tim gpasswd -a tim sudo passwd tim service rpimonitor start You should be able to login from then on as 'tim' and become root via 'sudo su -'
  6. Do you know zcat /proc/config.gz zgrep -i nfs /proc/config.gz And since everything's on Github you can have a look there also for the kernel config: https://github.com/igorpecovnik/lib/tree/next/config/
  7. FYI: Testing finished / feature freeze. I submitted a second pull request to Xavier to include the current state with the next RPi-Monitor release. In case you've further comments feel free to discuss them here :-) If you want to try it out in the meantime you should follow these steps: # become root eg. by "sudo su -" cd /tmp && wget http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz md5sum sunxi-monitor.tar.gz | grep -i 6822bcd7fe5cb2403eed9747e7cfff52 || exit 1 service rpimonitor stop cd / && tar -xzf /tmp/sunxi-monitor.tar.gz pkill -f '/bin/bash /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh' 2>/dev/null nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh & service rpimonitor start If you chose the first installation method (compare with http://rpi-experiences.blogspot.fr/p/rpi-monitor-installation.html please) then when RPi-Monitor 2.11 will be released all you've to do is a simple 'apt-get update/upgrade' and you're done. You should keep in mind that when you change templates then create them with a new and unique name otherwise conflicts while doing 'apt-get upgrade' will occur.
  8. FYI: Running the very same test (" cd /mnt/sda/ && stress -t 900 -c 2 -m 2 -i 2 -d 2"), first time with the R1 being powered through the LiPo connector and second run through the crappy Micro-USB power-in (consumption peaks and voltage drops down to 4.7V -- the PSU provides 5.0V and with just 20 cm cable and Micro-USB we loose between 0.1-0.3V idle/load) Powered through battery connector: Powered the crappy way through Micro-USB connector:
  9. Ah, ok. I forgot to mention that it's essential to stop and restart the temperature daemon since the old daemon writes 'degrees * 1000' into the temp files and the new one only 'degrees * 10'. So currently you have a mismatch between the daemon reporting old values and the config interpreting according to new rules. pkill -f '/bin/bash /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh' && (cd /tmp && nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh & ) should do the job (or a reboot if you want to play Windows )
  10. Can you please elaborate on the error you get? A screenshot or terminal output (if it's directly related to the temp daemon) would help. Regarding the switch IC: I don't know whether it has a thermal sensor inside that can be queried. I would doubt it. For network packets you have to query kernel interfaces. But I don't know whether the BCM provides per port statistics.
  11. Glad you resolved it. But you should be prepared that other stuff might break now (I believe this is defined for a reason). $TERM is an ugly beast ;-) An alternative approach is to use aliases (since it seems to only affect one single tool you use). alias mc="TERM=xterm /usr/bin/mc" in one of the startup files read by bash and you're done (and don't introduce yet unknown side effects). Also useful if you've other terminal related problems or you just dislike colors in some programs: alias mcm="TERM=xterm-mono /usr/bin/mc" Now "mcm" would invoke a b/w mc instance. Aliases are powerful. Since I'm a lazy guy I even use them to open stuff from the command line in Cocoa apps (on OS X -- of course ) macbookpro-tk:~ tk$ type photoshop photoshop is aliased to `open -a /Applications/Adobe\ Photoshop\ CC\ 2015/Adobe\ Photoshop\ CC\ 2015.app'
  12. Thx for reporting that, found the problem. It was defined as "GAUGE " with trailing whitespace instead of "GAUGE". I fixed that (as well as other stuff, eg. smoothing temperature graphs for SoC/PMU, less frequent disk checks, configurable check interval and so on): http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz (MD5: 6822bcd7fe5cb2403eed9747e7cfff52) Same procedure as before. Stop rpimonitor, untar from / and restart. Now everything should work out of the box. Feedback welcome!
  13. I don't know where the defaults are stored. So it depends on the shell you use. If you're using zsh you would add "export TERM=xterm" to ~/.zshrc and if you're using bash instead you would have to write it to both ~/.bashrc and ~/.bash_profile (see chapter INVOCATION in bash's manual page -- for whatever reason one file is read when you start a login shell and the other if it's a not a login shell)
  14. What does the output of "echo $TERM" looks like? In case it's "linux" you might give the following a try: TERM=xterm mc
  15. Hmm... I thought installing Linaro's standalone cross-compiler toolchain is recommended? I use http://releases.linaro.org/14.11/components/toolchain/binaries/arm-linux-gnueabihf/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.tar.xz and unpacked it in /usr/local and define export PATH="/usr/local/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf/bin/:$PATH" @Yuri: Since you're using an A10 I would love to get feedback regarding reading out thermal values from its TP's thermal sensor inside. Please have a look at this thread. Would be great if you could unpack the sunxi-monitor.tar.gz archive and provide the output of /usr/share/rpimonitor/scripts/sunxi_tp_temp 1447 to get a clue whether this approachs works on A10/A13 as well. Thx (and sorry for thread hijacking)
  16. Since you get "This Site is not available" and RPi-Monitor has its own web server you might check which process is listening on port 8888 and in case there is the other web app then adjust /etc/rpimonitor/daemon.conf (add a line with eg. "daemon.port=8088" and try to access this port afterwards) and restart rpimonitor afterwards. To check which process listens of which port you could use lsof -i BTW: Your ps output only shows the rpimonitord process responsible for collecting data (and running as root). The web server runs under an unprivileged account (and it seems in your case it does not run maybe due to port conflicts)
  17. If anyone is testing here's a bugfix version of sunxi-temp-daemon.sh: http://pastebin.com/pxxKaTQ4 Changes: Check existence of /dev/sda prior to testing, make check intervals configurable, check disk temperature less frequently
  18. I you don't find any informations in the logs (var/log/syslog) then you should have a closer look whether it's really off (eg. caused by an emergency shutdown due to overheating or undervoltage) or you aren't able to interact with the Board. In general it's a good idea to use monitoring to get a clue what's going on. In case you're using Kernel 3.4 then RPi-Monitor would be the weapon of choice (see pinned thread in this forum)
  19. Hi, I started to adjust RPi-Monitor's settings for the Banana Pi a while ago and reworked the whole stuff in the meantime (since it was focused on Banana Pi and some parts were too quick&dirty -- especially temp file handling of the temperature daemon). I also adjusted the consumption measurements for Lamobo R1 since it's the best idea to power the board through the LiPo battery connector -- for this case you need the axp209_cpu_pmu_temp_r1.conf template! Here you find an installation overview for RPi-Monitor (takes you 3 minutes if you are able to copy&paste): http://rpi-experiences.blogspot.fr/p/rpi-monitor-installation.html Here you find what's different on sunxi: https://github.com/ThomasKaiser/RPi-Monitor/blob/master/README_sunxi.md Here you find the adjustments: http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz (MD5: 6822bcd7fe5cb2403eed9747e7cfff52. It will take you additional 3 minutes to 'install' -- see below) The archive contains the following: /etc/rpimonitor/data.conf /etc/rpimonitor/template/sunxi_axp209.conf /etc/rpimonitor/template/axp209_cpu_pmu_temp.conf /etc/rpimonitor/template/axp209_cpu_pmu_temp_r1.conf /usr/share/rpimonitor/scripts/sunxi_tp_temp /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh Contents: data.conf is relinked to template/sunxi_axp209.conf which includes all the basic RPi-Monitor stuff but uses template/axp209_cpu_pmu_temp.conf for all the A10/A20/AXP209 specific stuff since this differs totally from Raspberry Pi. The sunxi_tp_temp binary is able to read out A20's temperature and sunxi-temp-daemon.sh is a script I rewrote from scratch since it's not possible to collect thermal data from disks/SoC under heavy load (RPi-Monitor isn't that patient waiting for external ressources to respond. So I created a daemon that collects thermal data into 3 temporary files and redirect RPi-Monitor to read from there). WARNING: Most of the sunxi stuff works only with kernel 3.4.x since in mainline the I2C/sysfs interface to the AXP209 PMU disappeared. Installation: Install RPi-Monitor as outlined in the link above, then stop it, untar the archive from /, ensure that /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh will be running and start rpimonitor again. # become root eg. by "sudo su -" service rpimonitor stop cd / && tar -xzf /path/to/sunxi-monitor.tar.gz nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh & service rpimonitor start To let the collection of thermal data survive a reboot it's a good idea to add "/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh &" prior to "exit 0" to /etc/rc.local
  20. That sounds great. BTW: Testing with 4.2-rc3 I always ended up relinking /boot/zImage manually (no idea why). BTW: The sunxi-mmc patch seems to work so I would propose an immediate inclusion: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested?start=30#3038
  21. You might also run into this error if for whatever reasons the rootfs is set read-only: I made this experience myself when fiddling around with other FS for the rootfs: http://forum.armbian.com/index.php/topic/120-f2fs-for-rootfs/?p=573 In case you're always using the same SD card I would first test whether it's physically ok. Use either H2testw or F3 on Linux or OS X.
  22. And there you find benchmarks as well...
  23. Maybe it's a good idea to wait for feedback regarding stability issues with AP6181 -- compare with http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested?start=24#2903please
  24. Everything now works as expected: root@cubietruck:~# uname -a Linux cubietruck 4.1.2-cubietruck #16 SMP Fri Jul 24 18:43:14 CEST 2015 armv7l GNU/Linux root@cubietruck:~# zgrep CONFIG_REGULATOR_AXP20X /proc/config.gz CONFIG_REGULATOR_AXP20X=y root@cubietruck:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 312000 528000 720000 864000 912000 960000 I added a request for enhancement on Igor's github and provide the kernel dpkgs temporarely here: http://kaiser-edv.de/tmp/4.1.2-cubietruck-next.tar
  25. Seems to be related to CONFIG_REGULATOR_AXP20X -- compare with the thread mentioned above. In the cubietruck's device tree CPU voltage scaling is also enabled but Igor's kernel config reads 'CONFIG_REGULATOR_AXP20X not set' at the moment. So Igor pointed already in the right direction and I missed these obvious differences between both .dts completely :-\ You should try to build the kernel yourself using CONFIG_REGULATOR_AXP20X=y (or watch the aforementioned thread whether Leonardo provides informations what went wrong in his case -- the Debian kernel builds this stuff as a module and that seems to not load correctly -- so you might also be able to compile the module).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines