• Content Count

  • Joined

  • Last visited

  1. I know the RPi is pretty limited on the GPIO pins. Now my question is how it looks on Le Potato, i.E. is it possible to power a fan directly from the GPIO pins? Powering it from the 3.3 V line seems to work just fine but I fear damaging hardware by trying to connect it to a GPIO instead.
  2. Could help a lot if you could give a link to what exactly you installed. I found this bug report: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1584488 - So the message seems harmless and should go away when you update. Sounds like there's no display server whatsoever but kodi doing everything directly. Try pressing Ctrl + Alt + F2 when kodi is running to get to a terminal. Log in as root there and see what's running with systemctl status
  3. Sorry about that. In the meantime everything seems to work, it was just bad reception. I re-arranged the antenna and got: root@libre-computer-board:/home/libre# ntpq -c as -c cv -c rv ind assid status conf reach auth condition last_event cnt =========================================================== 1 6448 8811 yes none none reject mobilize 1 2 6449 961b yes yes none sys.peer clock_alarm 1 associd=0 status=0060 6 events, clk_unspec, device="RAW DCF77 CODE (Conrad DCF77 receiver module)", timecode="--#---##-#####---D--S---8-2-p------p1-4--212-----1124-1---p", po
  4. Today we got working UART A, so I decided to wire up a cheap DCF77 receiver to it. On a first test I got spammed with libre-computer-board ntpd[1518]: parse: convert_rawdcf: start bit / parity check FAILED for "###############RADMLS1248124P124812P1248121241248112481248P??" This was solved with the following kernel patch: diff -Nru libretech-linux.old/drivers/tty/serial/meson_uart.c libretech-linux/drivers/tty/serial/meson_uart.c --- libretech-linux.old/drivers/tty/serial/meson_uart.c 2017-10-24 19:49:30.776000382 +0200 +++ libretech-linux/drivers/tty/serial/meson_uart.c 2017-10-24 1
  5. That's weird and might be why you see these errors. Could you check the outut of cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and if it says anything other than performance do sudo echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor (please note that this setting won't survive a reboot) and then redo your testing? BTW: Is wget https://git.kernel.org/torvalds/t/linux-4.14-rc5.tar.gz a good way to reproduce the issue for you? What's ifconfig and cat /etc/resolv.conf telling before and after you do ifdown/ifup?
  6. Did you comile your own kernel? Just asking as I had similar issues when compiling a custom kernel with any other CPU frequency governor than Performance. This is how it should be: $ gunzip -c /proc/config.gz | grep CPU_FREQ_GOV CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
  7. Same here (make -j4 with gcc/g++) but it doesn't always bring the system down. It showed 45000 at the time the log messages happened. A pretty good way to reproduce seems to be doing "make -j4" on http://distfiles.macports.org/openfst/openfst-1.3.4.tar.gz - you'll either see internal "compiler error: Bus error" or "g++: internal compiler error: Segmentation fault (program cc1plus)" while dmesg shows the messages from @CaptManiac. I observed this on the 2GB Kit Special (first batch of production-ready batch of 2GB boards, push pin heatsink, custom active cooling case with fan,