• Posts

  • Joined

 Content Type 


Member Map




Everything posted by tkaiser

  1. 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:
  2. 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 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/' 2>/dev/null nohup /usr/share/rpimonitor/scripts/ & service rpimonitor start If you chose the first installation method (compare with 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.
  3. 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:
  4. 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/' && (cd /tmp && nohup /usr/share/rpimonitor/scripts/ & ) should do the job (or a reboot if you want to play Windows )
  5. 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.
  6. 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\'
  7. 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): (MD5: 6822bcd7fe5cb2403eed9747e7cfff52) Same procedure as before. Stop rpimonitor, untar from / and restart. Now everything should work out of the box. Feedback welcome!
  8. 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)
  9. What does the output of "echo $TERM" looks like? In case it's "linux" you might give the following a try: TERM=xterm mc
  10. Hmm... I thought installing Linaro's standalone cross-compiler toolchain is recommended? I use 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)
  11. 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)
  12. If anyone is testing here's a bugfix version of Changes: Check existence of /dev/sda prior to testing, make check intervals configurable, check disk temperature less frequently
  13. 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)
  14. 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): Here you find what's different on sunxi: Here you find the adjustments: (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/ 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 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/ 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/ & service rpimonitor start To let the collection of thermal data survive a reboot it's a good idea to add "/usr/share/rpimonitor/scripts/ &" prior to "exit 0" to /etc/rc.local
  15. 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:
  16. 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: 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.
  17. And there you find benchmarks as well...
  18. Maybe it's a good idea to wait for feedback regarding stability issues with AP6181 -- compare with
  19. 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:
  20. 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).
  21. FYI:!topic/linux-sunxi/ld7lem8QTv0
  22. Nope, didn't even tried it due to focus on other problems (strange network performance stuff I'm currently after).
  23. I read it like 'powering the board using the Micro-USB-pwr-in connector and using a LiPo battery as UPS'. And the question is whether the board will supply power to a SATA disk when running on battery (UPS mode). This is somewhat different to the mode we power the board (providing more than 4.2V on the LiPo connector therefore forcing the AXP209 into 'non battery' mode). And according to 'multi' then the disk won't work:
  24. Put this in /etc/rc.local prior to the last line "exit 0"
  25. Depends on what you want. I would have a look at If it's just about routing and maybe Wi-Fi as well, check which cheap TP-Link router is fully supported by OpenWRT.