[OS] Debian Stretch for ODROID N2

[nosxxx]

I'm talking about N2 (i also have C2).
See: viewtopic.php?f=177&t=34737&p=257219&hi ... tc#p257219
I understand why the default kernel does not include the rtc as builtin, but it would be nice if there would be a second, which has built in rtc firmware.

[tobetter]

I'm talking about N2 (i also have C2).
See: viewtopic.php?f=177&t=34737&p=257219&hi ... tc#p257219
I understand why the default kernel does not include the rtc as builtin, but it would be nice if there would be a second, which has built in rtc firmware.

Why the default kernel does not include RTD driver as builtin?
Don't you have rtc_pcf8563 module loaded on the system up?

[nosxxx]

The rtc_pcf8563 is a "extra" module and not included directly in the kernel.

The RTC isn't synced on startup, because the kernel modules are loaded later than the system wants to sync the clock.

[ 4.894805] hctosys: unable to open rtc device (rtc0)
[ 6.679031] rtc-pcf8563 3-0051: rtc core: registered rtc-pcf8563 as rtc0

[meveric]

by adding rtc-pcf8563 and i2c-meson-master to the initramfs my init changed from:

Code: Select all

root@odroid-buster64:~# dmesg | grep rtc
[    4.921346] hctosys: unable to open rtc device (rtc0)
[    7.392881] rtc-pcf8563 3-0051: rtc core: registered rtc-pcf8563 as rtc0

to

Code: Select all

root@odroid-buster64:~# dmesg | grep rtc
[    5.125206] hctosys: unable to open rtc device (rtc0)
[    5.567589] rtc-pcf8563 3-0051: rtc core: registered rtc-pcf8563 as rtc0

It's still not the correct order, but it's been loaded much much earlier as it's now part of the initramfs.
Now I have to figure out how to prioritize this

[nosxxx]

I found that: https://stackoverflow.com/questions/116 ... load-order
Maybe that will help you.

[meveric]

that's for build-in modules, I'm using regular modules.
That's a huge difference.

[ab1jx]

Slow bootup times are a consequence of network issues (it waits too long for dhcp). Try booting with ethernet disconnected and it will be much faster.

Exactly. But at least if you can see what's happening you have an idea what's causing it. With some machines you get an output almost like dmesg, with this (and Armbian on a Rock64) I see a blank screen for a few minutes, can't tell what's going on. There's just a blinking underline cursor in the upper left corner of the screen. Assuming the video is initialized and working at that point, I'd much rather enable a more verbose output. I use the multi-user target, log in at a command prompt, type startx when I'm ready for GUI. Watching that stuff scrolling up my screen is useful, I don't like having it turned off. Can I turn it back on?

[meveric]

It's not "turned off" the N2 does simply not output it. I would never deactivate this on purpose.
The N2 is the only ODROID device that doesn't output any information at boot, and yes it sucks.

[ab1jx]

I remember (and was just trying to find at https://forum.pine64.org) a year or more ago there was a problem with some Ayufan Rock64 images where any USB actvity would give a flurry of (diagnostic) messages at a text console. The workaround was to set a verbosity level (log level?) somewhere to stop them, it might have been klog or syslog type stuff. But it seems like other settings gave useful output. And it was complex, there were levels but there were also categories I think and levels within each. That's all been fixed on the pine64 stuff for quite a while so I don't find references to it in their forum.

from a klogctl man page

Code: Select all

       Kernel constant   Level value   Meaning
       KERN_EMERG             0        System is unusable
       KERN_ALERT             1        Action must be taken immediately
       KERN_CRIT              2        Critical conditions
       KERN_ERR               3        Error conditions
       KERN_WARNING           4        Warning conditions
       KERN_NOTICE            5        Normal but significant condition
       KERN_INFO              6        Informational
       KERN_DEBUG             7        Debug-level messages
 

There's console_loglevel, default_message_loglevel, minimum_console_loglevel, default_console_loglevel (from the man page). There isn't a lot of userland control except there was a place to change the numbers in some config flle. It's a 4-digit number. That might cause more verbose output. The messages come from the kernel but a user can chose which ones he sees. Somewhere, I don't remember where. It ultimately comes from a switch in the kernel so if the N2 runs a different kernel that might do it. This is Linux generically so it would apply to both Odroid and Rock64.

[ab1jx]

There seem to be some wacky similarities here with Rock64. I spent most of a week once trying to get an rtl8192 wifi to work on my rock64. But they work fairly well on a Raspberry Pi, I have about 6 of them, used them for years. Just partly gave up on rtl8192 on Odroid.

Plugged in an old Ralink/MediaTek mt7601, nothing happens. lsmod shows nothing loaded for it. insmod mt7601u can't find the module. Locate shows it's in

Code: Select all

/lib/modules/4.9.177+/kernel/drivers/net/wireless/mediatek/mt7601u/mt7601u.ko

Which seems like an OK place but it doesn't find it.

Made a local copy where I was working and did

Code: Select all

 insmod ./mt7601u.ko

Shazam, I'm online again.

The MediaTek also worked better on the Rock64 than the rtl8192. I think the Raspbian driver for it is better driver than what you're using. Or the firmware isn't quite right. Something's a little off so it works sometimes but it's unreliable.

[meveric]

I have a couple of different DKMS WLAN drivers to replace the ones from HardKernel some of them work much better, and I can always make new versions. You should try checking them out.
Here's a list of them, not sure if this list is complete to be honest:

Code: Select all

r8168-dkms - dkms source for the r8168 network driver
8188eu-dkms - 8188eu driver in DKMS format.
8192cu-dkms - 8192cu driver in DKMS format.
8723bu-dkms - 8723bu driver in DKMS format.
mt7601-sta-dkms - Ralink MT7601 driver in DKMS format.
mt7610u-dkms - mt7610u driver in DKMS format.
rt5572-dkms - Support for the Ralink RT5572usb network card
rtl8192du-dkms - rtl8192du driver in DKMS format.
rtl8192eu-dkms - rtl8192eu driver in DKMS format.
rtl8812au-dkms - rtl8812au driver in DKMS format.
rtl88x2bu-dkms - rtl88x2bu driver in DKMS format.

[ab1jx]

My RPI Zero that's been running a Realtek adapter for months is using the 8192cu module when i ssh to it and do an lsmod, also cfg80211.

Hadn't heard of dkms so I looked it up, looks good.

I'm going to see if I can get 24 hours of being connected with this mt7601 for now, it's looking good so far. I'm not disconnected every 5 minutes, it's been a couple hours at least since I got it working. Not sure why it looked in the wrong places for the driver. idVendor 0x0bda Realtek Semiconductor Corp.

And by an lsusb -v the Realtek in the Zero is the same rtl8188cus running with the 8192cu driver (by lsmod)

Code: Select all

  idProduct          0x8176 RTL8188CUS 802.11n WLAN Adapter
  bcdDevice            2.00
  iManufacturer           1 Realtek
  iProduct                2 802.11n WLAN Adapter
  iSerial                 3 00e04c000001

The 8192cu driver seems to need the cfg80211 layer but work better.

[odroid]

Is the Debian also has the same WiFi power saving configuration as Ubuntu 18.x?
It seems to be worth to check the value of the WLAN powersave option.
wifi.powersave value must be 2 not 3 in /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf file.

[ab1jx]

The only thing I have in /etc/NetwokManager is a fle for ntp (that ntp stuck there). I tried Ubuntu once about 10 years ago, lasted about a week before I replaced it with Debian. I don't use NetworkManager (or wicd) (or rfkill), just a simple interfaces fle:

Code: Select all

auto wlan0
iface wlan0 inet dhcp
  wireless-essid Moto_lte

I can run my wifi open (no password) because I live in the country.

But having said that, I'm still using my Ralink/MediaTek MT7601 card. My checkwifi script has been pinging Google every 5 minutes for a day and a half, only twice did it resort to doing the ifdown/ifup reset (it logs them). I can connect to my Odrold by FTP or SSH from other machines when I want, it's just been almost perfect. I hate to mess with it but I should go back to testing Realtek stuff. This has been a good reliability baseline to compare the Realtek to if nothing else.

[meveric]

https://askubuntu.com/questions/85214/h ... -turned-on

The link above has different methods to disable powermanagement for WLAN adapters.
/etc/pm/config.d/blacklist and even directly in /etc/network/interfaces via a post-up call maybe that can help you preventing this issues.

[ab1jx]

https://askubuntu.com/questions/85214/h ... -turned-on

The link above has different methods to disable powermanagement for WLAN adapters.
/etc/pm/config.d/blacklist and even directly in /etc/network/interfaces via a post-up call maybe that can help you preventing this issues.

I don't have an /etc/pm and iwconfig says power management is off. Adding

Code: Select all

wireless-power off

to interfaces seems like a good idea if there's a need.

I like simplicity for the sake of reliability, I used OpenBSD for about 15 years and Linux is much more messy. There are layers on top of layers of cruft so you spend more time learning how somebody intended you should do something than just doing it in a minimal way, and there's more to break.

These are interesting considerations in case switching adapters from Ralink/MediaTek to Realtek turns power management on. I suppose the driver could do that. I was noticing that if there was some trickle of network traffic keeping things warm then it was more reliable, that could be a power management problem. But I'm coming up on 48 hours of near perfection from the Ralink.

Because the N2 runs on 12 volts i could run it from a battery with a regulated filtered charger and really rack up the uptime. And/or use solar panels. If you read the fine print on the wall wart it says 12 volts at 2 amps.

[ab1jx]

Back to trying to use the Realtek. I keep losing my dhcp lease, so iwconfig and ifconfig show:

Code: Select all

iwconfig:

eth0      no wireless extensions.

lo        no wireless extensions.

p2p0      IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm
          Retry short limit:7   RTS thr=2347 B   Fragment thr:off
          Encryption key:off
          Power Management:on

wlan0     IEEE 802.11  ESSID:"Moto_lte"
          Mode:Managed  Frequency:2.412 GHz  Access Point: E8:91:20:23:4F:38
          Bit Rate=72.2 Mb/s   Tx-Power=20 dBm
          Retry short limit:7   RTS thr=2347 B   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=36/70  Signal level=-74 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:12   Missed beacon:0

ifconfig:

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 40  bytes 2018 (1.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 2018 (1.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::213:efff:fe20:37f2  prefixlen 64  scopeid 0x20<link>
        ether 00:13:ef:20:37:f2  txqueuelen 1000  (Ethernet)
        RX packets 2868  bytes 2079828 (1.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2977  bytes 377604 (368.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Yet by /var/lib/dhcp/dhclient.leases the lease isn't expired or anything. This doesn't happen with the Ralink interfaces, it was almost perfect for 44 hours, minimal disconnecting (twice).

Actually it isn't the dhcp lease, by iwconfig it isn't associated with the AP anymore. ifdown then ifup fixes it for a few minutes.

Trying to look at drivers, on my RPI Zero (also using a Realtek but more reliably) lsmod shows

Code: Select all

8192cu and
cfg80211

While the Odroid shows:

Code: Select all

rtl8192cu  and
rtl_usb and
rtl8192c_common and
rtlwifi

My guess would be I'm running a different driver: 8192cu is not the same as rtl8192cu. Locate doesn't find a cfg80211.ko on this machine at all, which is needed by the 8192cu driver. I also don't see a 8192cu.ko.
------------
Sound: I don't have any and just noticed my lsmod doesn't show any snd_* modules loaded. alsactl init says it works but nothing happens, speaker-test produces no sound, nor smplayer or Audacity. Should I insmod something for sound? I hear a pop once in a while when fiddling like an amplifier is being turned on but that's it. I'm trying to use analog sound through the 3.5 mm jack going to a pair of computer speakers.

aplay -l shows:

Code: Select all

**** List of PLAYBACK Hardware Devices ****
card 0: AMLAUGESOUND [AML-AUGESOUND], device 0: SPDIF-B-dit-hifi dit-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: AMLAUGESOUND [AML-AUGESOUND], device 1: TDM-C-T9015-audio-hifi T9015-audio-hifi-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: AMLAUGESOUND [AML-AUGESOUND], device 2: SPDIF-dit-hifi dit-hifi-2 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

but when I poke around in /lib/modules/4.9.177+/kernel /sound I don't see anything that mentions amlauge at all.

[mad_ady]

8192cu is indeed different than rtl8192cu. One comes from the kernel, the other one may be newer. Run modinfo to get its version and module parameters. Maybe there's a module parameter to turn off pm.
One messy workaround is to ping your gateway continuously to prevent the nic from sleeping.

[ab1jx]

iwconfig shows power management is off. Anyway here's the modinfo from the zero's 8192cu module (the better one):

Code: Select all

filename:       /lib/modules/4.14.50+/kernel/drivers/net/wireless/realtek/rtl8192cu/8192cu.ko
version:        v4.0.2_9000.20130911
author:         Realtek Semiconductor Corp.
description:    Realtek Wireless Lan Driver
license:        GPL
srcversion:     04E124B6CFCD59884011188
alias:          usb:v0BDAp8186d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0789p016Dd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF6p0070d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04BBp0950d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v06F8pE035d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2357p0100d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp2E2Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp1004d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0E66p0020d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0E66p0019d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846pF001d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846p9021d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0B05p17ABd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF6p0061d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v20F4p624Dd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp2103d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp2102d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v4855p0091d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v07AAp0056d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v07B8p8178d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019pAB2Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v7392p7822d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0586p341Fd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p330Dd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p3309d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p330Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p3307d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019p1201d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFFCd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFFBd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFF8d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFFAd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFF9d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFF7d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v13D3p3358d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v13D3p3359d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp317Fd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp0A8Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:vCDABp8011d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8176d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04BBp094Cd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp1E1Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0B05p17BAd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:vCDABp8010d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p330Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019pAB2Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019p4902d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846p9043d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846p9042d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846p9041d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v4856p0091d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp5088d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF6p005Cd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v13D3p3357d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v4855p0090d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v20F4p648Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019pAB2Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp11F2d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp1102d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p3308d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v103Cp1629d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v06F8pE033d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0EB0p9071d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v07B8p8189d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v7392p7811d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF6p0052d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019pED17d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v1058p0631d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8191d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Cd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8178d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8177d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp17C0d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp018Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp818Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Fd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8754d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Dd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8170d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8176d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8191d*dc*dsc*dp*ic*isc*ip*in*
depends:        cfg80211
intree:         Y
name:           8192cu
vermagic:       4.14.50+ mod_unload modversions ARMv6 p2v8 
parm:           rtw_ips_mode:The default IPS mode (int)
parm:           ifname:The default name to allocate for first interface (charp)
parm:           if2name:The default name to allocate for second interface (charp)
parm:           rtw_initmac:charp
parm:           rtw_channel_plan:int
parm:           rtw_chip_version:int
parm:           rtw_rfintfs:int
parm:           rtw_lbkmode:int
parm:           rtw_network_mode:int
parm:           rtw_channel:int
parm:           rtw_mp_mode:int
parm:           rtw_wmm_enable:int
parm:           rtw_vrtl_carrier_sense:int
parm:           rtw_vcs_type:int
parm:           rtw_busy_thresh:int
parm:           rtw_ht_enable:int
parm:           rtw_cbw40_enable:int
parm:           rtw_ampdu_enable:int
parm:           rtw_rx_stbc:int
parm:           rtw_ampdu_amsdu:int
parm:           rtw_lowrate_two_xmit:int
parm:           rtw_rf_config:int
parm:           rtw_power_mgnt:int
parm:           rtw_low_power:int
parm:           rtw_wifi_spec:int
parm:           rtw_special_rf_path:int
parm:           rtw_antdiv_cfg:int
parm:           rtw_enusbss:int
parm:           rtw_hwpdn_mode:int
parm:           rtw_hwpwrp_detect:int
parm:           rtw_hw_wps_pbc:int
parm:           rtw_max_roaming_times:The max roaming times to try (uint)
parm:           rtw_force_iol:Force to enable IOL (bool)
parm:           rtw_mc2u_disable:int
parm:           rtw_mac_phy_mode:int
parm:           rtw_80211d:int
parm:           rtw_notch_filter:0:Disable, 1:Enable, 2:Enable only for P2P (uint)

A ping once a minute isn't so hard. I intended to ping the gateway but instead I did this in my crontab:
* * * * * ping -c 1 www.google.com > /dev/null
Seems to be working so far. Google will probably think it's weird. I just changed it to 192.168.43.1 (phone/gateway).

[meveric]

can you try installing 8192cu-dkms

Code: Select all

apt install 8192cu-dkms

It actually comes with a couple configs that look interesting.
Some module options:

8192cu-disable-power-management.conf

Code: Select all

# Disable power management in the 8192cu driver. This works around a bug in
# some hardware where the device never wakes back up.
# Credit goes to Saqib Razaq (https://github.com/s-razaq) for the fix.

# rtw_power_mgnt=0 disables power saving
# rtw_enusbss=0 disables USB autosuspend
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

even without the DKMS module, using the options might actually beneficial.
Although you also might have to blacklist the drivers from hardkernel first (build in modules in Kernel).

[ab1jx]

Wow, that was easy

Code: Select all

root@odroid:/usr/tmp/transmission_dl# apt install 8192cu-dkms
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  8192cu-dkms
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 701 kB of archives.
After this operation, 5,418 kB of additional disk space will be used.
Get:1 https://oph.mdrjr.net/meveric all/main arm64 8192cu-dkms all 1.10 [701 kB]
Fetched 701 kB in 2s (277 kB/s)      
Selecting previously unselected package 8192cu-dkms.
(Reading database ... 112083 files and directories currently installed.)
Preparing to unpack .../8192cu-dkms_1.10_all.deb ...
Unpacking 8192cu-dkms (1.10) ...
Setting up 8192cu-dkms (1.10) ...
Loading new 8192cu-1.10 DKMS files...
Building for 4.9.177+
Building for architecture arm64
Building initial module for 4.9.177+
Done.

8192cu:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.9.177+/updates/dkms/

depmod...

Backing up initrd.img-4.9.177+ to /boot/initrd.img-4.9.177+.old-dkms
Making new initrd.img-4.9.177+
(If next boot fails, revert to initrd.img-4.9.177+.old-dkms image)
update-initramfs................

DKMS: install completed.

But now what? Blacklisting I have to look up, I've only done a little blacklisting of DVB drivers for RTL2838 so the SDR stuff can work, and that was mostly done by rote. And not recently. Can I rmmod and insmod as a test?

And what about the cfg80211 that 8192cu needs, can I do that by dkms too?

The once-per-minute ping of the AP doesn't totally do it, I've had to run the ifdown/ifup script about 3 times since I set up the auto ping. I'm not sure the ping actually helps at all.

[meveric]

well installation was successful so if you reboot the new driver should be loaded.
I'm not sure if rmmod will work as this is a buildin driver.
Goto /usr/src/.... there should be a folder for the dkms driver.. search for the src folder of it.
You should find two config files:
blacklist-native-rtl8192.conf and 8192cu-disable-power-management.conf
Copy both to /etc/modprobe.d/
then try to reboot..

Check with lsmod and modinfo which driver is currently loaded afterwards.

[ab1jx]

Looks OK I think, lsmod shows:

Code: Select all

Module                  Size  Used by
ir_lirc_codec          16384  0
lirc_dev               24576  1 ir_lirc_codec
rtl2832_sdr            24576  0
videobuf2_vmalloc      16384  1 rtl2832_sdr
r820t                  32768  1
rtl2832                20480  1
8192cu                598016  0
dvb_usb_rtl28xxu       32768  1
dvb_usb_v2             28672  1 dvb_usb_rtl28xxu
rtc_pcf8563            20480  0
mali_kbase            471040  0
i2c_meson_master       20480  0
ip_tables              32768  0
x_tables               49152  1 ip_tables
ipv6                  479232  34

modinfo shows:

Code: Select all

filename:       /lib/modules/4.9.177+/updates/dkms/8192cu.ko
version:        v4.0.2_9000.20130911
author:         Realtek Semiconductor Corp.
description:    Realtek Wireless Lan Driver
license:        GPL
srcversion:     C7275C5B6150340CADA28E9
alias:          usb:v0BDAp8186d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0789p016Dd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF6p0070d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04BBp0950d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v06F8pE035d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2357p0100d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp2E2Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp1004d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0E66p0020d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0E66p0019d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846pF001d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846p9021d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0B05p17ABd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF6p0061d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v20F4p624Dd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp21F2d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp2103d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp2102d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v4855p0091d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v07AAp0056d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v07B8p8178d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019pAB2Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v7392p7822d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0586p341Fd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p330Dd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p3309d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p330Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p3307d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019p1201d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFFCd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFFBd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFF8d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFFAd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFF9d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04F2pAFF7d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v13D3p3358d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v13D3p3359d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp317Fd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp0A8Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:vCDABp8011d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v04BBp094Cd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp1E1Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0B05p17BAd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:vCDABp8010d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p330Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019pAB2Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019p4902d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846p9043d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846p9042d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0846p9041d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v4856p0091d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp5088d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF6p005Cd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v13D3p3357d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v4855p0090d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v20F4p648Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019pAB2Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp11F2d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v050Dp1102d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2001p3308d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v103Cp1629d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v06F8pE033d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0EB0p9071d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v07B8p8189d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v07B8p8188d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v7392p7811d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0DF6p0052d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v2019pED17d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v1058p0631d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8191d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Cd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8178d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8177d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp17C0d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp018Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp818Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Fd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8754d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Dd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Bd*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Ad*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp817Ed*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8170d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8176d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8191d*dc*dsc*dp*ic*isc*ip*in*
depends:        
vermagic:       4.9.177+ SMP preempt mod_unload modversions aarch64
parm:           rtw_ips_mode:The default IPS mode (int)
parm:           ifname:The default name to allocate for first interface (charp)
parm:           if2name:The default name to allocate for second interface (charp)
parm:           rtw_initmac:charp
parm:           rtw_channel_plan:int
parm:           rtw_chip_version:int
parm:           rtw_rfintfs:int
parm:           rtw_lbkmode:int
parm:           rtw_network_mode:int
parm:           rtw_channel:int
parm:           rtw_mp_mode:int
parm:           rtw_wmm_enable:int
parm:           rtw_vrtl_carrier_sense:int
parm:           rtw_vcs_type:int
parm:           rtw_busy_thresh:int
parm:           rtw_ht_enable:int
parm:           rtw_cbw40_enable:int
parm:           rtw_ampdu_enable:int
parm:           rtw_rx_stbc:int
parm:           rtw_ampdu_amsdu:int
parm:           rtw_lowrate_two_xmit:int
parm:           rtw_rf_config:int
parm:           rtw_power_mgnt:int
parm:           rtw_low_power:int
parm:           rtw_wifi_spec:int
parm:           rtw_special_rf_path:int
parm:           rtw_antdiv_cfg:int
parm:           rtw_enusbss:int
parm:           rtw_hwpdn_mode:int
parm:           rtw_hwpwrp_detect:int
parm:           rtw_hw_wps_pbc:int
parm:           rtw_max_roaming_times:The max roaming times to try (uint)
parm:           rtw_force_iol:Force to enable IOL (bool)
parm:           rtw_mc2u_disable:int
parm:           rtw_mac_phy_mode:int
parm:           rtw_80211d:int
parm:           rtw_notch_filter:0:Disable, 1:Enable, 2:Enable only for P2P (uint)

Now I guess I'll find out how stable it is.

It's at least 10 times better, my ping of Google by cron job every 5 minutes hasn't failed since I changed the driver, several hours. Before it was every few minutes. Got sound working by the wiki too. The DC power connector seems to be a 2.1 mm, I already had some around.

OK, 24 hours later it still looks excellent. My cron job that pings Google every 5 minutes logged no failures at all, the machine has stayed connected the whole time. This seems like the driver to use. And thanks to the DKMS it's pretty easy to retrofit one in.

[ab1jx]

It's not "turned off" the N2 does simply not output it. I would never deactivate this on purpose.
The N2 is the only ODROID device that doesn't output any information at boot, and yes it sucks.

I think this is because there's no BIOS here. On a traditional i386 machine firmware is in place for displaying text. The console (in non-GUI mode) does it but routines in the kernel are implementing text and scrolling it. It's really working in a framebuffer, you can put framebuffer graphics on top of the text and scroll it all together, copy it off to offscreen memory and put it back, I've done it.

Kernels for these machines need to implement text display and scrolling earlier. They're doing it anyway for text output, but nothing displays until the login prompt. Because screen output wasn't a priority. Initialize the video and set up text and scrolling early, then do everything else and print the kernel's ring buffer of messages to it. Something like earlyprintk=vga but there's no vga here, you have to create it. Raspberry Pis do it, I can see my wifi connecting or not long before the login prompt.

[meveric]

Raspberry Pis do it, I can see my wifi connecting or not long before the login prompt.

Every other ODROID does it, only the N2 does not support it at the moment.

[ab1jx]

I think on the Rock64 it was a major advantage of the Ayufan image over the Armbian, maybe I'm misremembering. I know I bought an adapter to implement a serial console then never used it. I started with Ayufan, tried Armbian for week or so, went back to Ayufan. I remember asking an Armbian guy about it because theirs was the first time I noticed it missing. If the option is set to wait for wifi to connect and that takes over a minute you can decide it's dead while it's still booting.

With this at least there's a little blinking underline cursor in the upper left. I think, I haven't rebooted in a couple days. I've moved in, getting on with life, everything seems to be working nicely.

[meveric]

The Rock64 is a Rockchip based board and not AmLogic.
In fact we had the ODROID N1 which is Rockchip based as well and as I said, it has the console output.
I think this issue is unique to the N2 at the moment and not unexpected, as the ODROID C2 (also AmLogic) also had a hard time at first to show console output which only started near the very end of the boot process when it first came out.
So I believe that's partly the fault of AmLogics framebuffer console drivers.

[ab1jx]

can you try installing 8192cu-dkms

Amazing, I just cobbed my way through installing that driver on my amd64 laptop. Windows was never like this. I did have to install my kernel headers, no big deal. I've always had the same problem on that, using one of the little Realteks. And only because my Atheros AR5418 is unreliable too.

[meveric]

glad it's working out for you

[ab1jx]

I'm using Linux odroid 4.9.177+ #1 SMP PREEMPT Sat May 18 09:49:10 CEST 2019 aarch64 GNU/Linux. I'm trying to install current llvm from sources from http://releases.llvm.org/download.html (because I want to build current Firefox) and I've hit what looks like either an internal gcc error or a problem with llvm

Code: Select all

Message from syslogd@odroid at Aug  6 05:17:58 ...
 kernel:[32795.156330@2] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP

Message from syslogd@odroid at Aug  6 05:17:58 ...
 kernel:[32796.186449@2] Process cc1plus (pid: 29432, stack limit = 0xffffffc094
c++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-6/README.Bugs> for instructions.
tools/obj2yaml/CMakeFiles/obj2yaml.dir/build.make:86: recipe for target 'tools/o
make[2]: *** [tools/obj2yaml/CMakeFiles/obj2yaml.dir/coff2yaml.cpp.o] Error 4
CMakeFiles/Makefile2:67773: recipe for target 'tools/obj2yaml/CMakeFiles/obj2yam
make[1]: *** [tools/obj2yaml/CMakeFiles/obj2yaml.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

So my first thought was to try a different gcc version. Except there doesn't seem to be one available here, I'm used to being able to pick from 2 or 3. I'm using what looks like a fairly standard sources.list:

Code: Select all

deb http://ftp.us.debian.org/debian stretch main contrib non-free
#deb-src http://ftp.us.debian.org/debian stretch main contrib non-free
deb http://ftp.us.debian.org/debian stretch-updates main contrib non-free
#deb-src http://ftp.us.debian.org/debian stretch-updates main contrib non-free
deb http://security.debian.org/debian-security stretch/updates main contrib non-
free
#deb-src http://security.debian.org/debian-security stretch/updates main contrib
 non-free
 

Maybe it's just a stack overflow, I can't tell really, but it's not software I wrote. Why is there only one gcc version (Debian 6.3.0-18+deb9u1)?

[meveric]

Debian Stretch only has gcc 6.3 available.
Debian Buster comes with 7.4 and 8.3.

You should check memory while compiling that's one of the most common issues of compiler errors (running out of memory).

[ab1jx]

Debian Stretch only has gcc 6.3 available.
Debian Buster comes with 7.4 and 8.3.

You should check memory while compiling that's one of the most common issues of compiler errors (running out of memory).

Hmm, check with what? I'm running 13 GB of swap, the last time I looked at it with top there was 5 GB of that free, then I went to bed. Building with cmake, gold, ninja, it got up to around 98% done at one point. Then I reconfigured it for a release build, only building for aarch64 so it started over.

The first 3 errors (2 from syslog to every terminal emulator window) worry me:

Code: Select all

Message from syslogd@odroid at Aug  6 05:17:58 ...
 kernel:[32795.156330@2] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP

Message from syslogd@odroid at Aug  6 05:17:58 ...
 kernel:[32796.186449@2] Process cc1plus (pid: 29432, stack limit = 0xffffffc094
4d0000)

c++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.

Why is it telling me the stack limit? Did it use up all it's stack? I'm not used to getting broadcast messages from syslogd, maybe that's always included.

Can I run cmake through gdb? I also have valgrind.


Only having one gcc seems like an oversight. Maybe I could install the deb's clang compiler and use that to build the newer clang and llvm.

[xabolcs]

About that "bad mode", there is a topic about it, give it a try!

[ab1jx]

About that "bad mode", there is a topic about it, give it a try!

Yes, there's a little script

Code: Select all

# The code below requires the package 'cpufrequtils' to be installed.
for ((cpu=0; cpu<`grep -c proc /proc/cpuinfo`; cpu++)); do
    sudo cpufreq-set -c $cpu -g performance
done

at https://www.llvm.org/docs/HowToBuildOnARM.html but I thought that was just for speeding up the build. 'll try it. I did "apt-get install cpufrequtils". I've never tried to overclock anything. cpufreq-info says:

Code: Select all

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: arm-big-little
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 1.90 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.90 GHz
  available cpufreq governors: ondemand, powersave, userspace, conservative, interactive, performance, schedutil
  current policy: frequency should be within 100.0 MHz and 1.90 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 500 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.13%, 250 MHz:0.22%, 500 MHz:0.11%, 667 MHz:0.05%, 1000 MHz:0.05%, 1.20 GHz:0.03%, 1.40 GHz:0.02%, 1.51 GHz:0.01%, 1.61 GHz:0.01%, 1.70 GHz:0.01%, 1.90 GHz:99.36%  (6400)
analyzing CPU 1:
  driver: arm-big-little
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 1.90 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.90 GHz
  available cpufreq governors: ondemand, powersave, userspace, conservative, interactive, performance, schedutil
  current policy: frequency should be within 100.0 MHz and 1.90 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.90 GHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.13%, 250 MHz:0.22%, 500 MHz:0.11%, 667 MHz:0.05%, 1000 MHz:0.05%, 1.20 GHz:0.03%, 1.40 GHz:0.02%, 1.51 GHz:0.01%, 1.61 GHz:0.01%, 1.70 GHz:0.01%, 1.90 GHz:99.36%  (6400)
analyzing CPU 2:
  driver: arm-big-little
  CPUs which run at the same hardware frequency: 2 3 4 5
  CPUs which need to have their frequency coordinated by software: 2 3 4 5
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 1.80 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz
  available cpufreq governors: ondemand, powersave, userspace, conservative, interactive, performance, schedutil
  current policy: frequency should be within 100.0 MHz and 1.80 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 100.0 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.56%, 250 MHz:0.04%, 500 MHz:0.02%, 667 MHz:0.01%, 1000 MHz:0.01%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:99.35%  (918)
analyzing CPU 3:
  driver: arm-big-little
  CPUs which run at the same hardware frequency: 2 3 4 5
  CPUs which need to have their frequency coordinated by software: 2 3 4 5
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 1.80 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz
  available cpufreq governors: ondemand, powersave, userspace, conservative, interactive, performance, schedutil
  current policy: frequency should be within 100.0 MHz and 1.80 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 100.0 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.56%, 250 MHz:0.04%, 500 MHz:0.02%, 667 MHz:0.01%, 1000 MHz:0.01%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:99.35%  (918)
analyzing CPU 4:
  driver: arm-big-little
  CPUs which run at the same hardware frequency: 2 3 4 5
  CPUs which need to have their frequency coordinated by software: 2 3 4 5
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 1.80 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz
  available cpufreq governors: ondemand, powersave, userspace, conservative, interactive, performance, schedutil
  current policy: frequency should be within 100.0 MHz and 1.80 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 100.0 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.56%, 250 MHz:0.04%, 500 MHz:0.02%, 667 MHz:0.01%, 1000 MHz:0.01%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:99.35%  (918)
analyzing CPU 5:
  driver: arm-big-little
  CPUs which run at the same hardware frequency: 2 3 4 5
  CPUs which need to have their frequency coordinated by software: 2 3 4 5
  maximum transition latency: 50.0 us.
  hardware limits: 100.0 MHz - 1.80 GHz
  available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz
  available cpufreq governors: ondemand, powersave, userspace, conservative, interactive, performance, schedutil
  current policy: frequency should be within 100.0 MHz and 1.80 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 100.0 MHz (asserted by call to hardware).
  cpufreq stats: 100.0 MHz:0.56%, 250 MHz:0.04%, 500 MHz:0.02%, 667 MHz:0.01%, 1000 MHz:0.01%, 1.20 GHz:0.00%, 1.40 GHz:0.00%, 1.51 GHz:0.00%, 1.61 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:99.35%  (918)

[meveric]

Hmm, check with what? I'm running 13 GB of swap, the last time I looked at it with top there was 5 GB of that free, then I went to bed.

You are aware that the ODROID only has 4GB of RAM... 4GB + 13 GB = 17GB "RAM" and you had 5 GB of SWAP free, so a total of 12 GB was used on a 4GB system.
And you really wonder if there's a memory issues?
You ARE aware that SWAP is not real memory, right?
And only cause you have 100GB SWAP doesn't mean you can use 100GB of RAM?
If your system uses 8GB SWAP that already means something is WRONG. SWAP is a means of LAST RESORT to make sure a system or application does not CRASH, it is not meant as "RAM EXTENSION" for regular work load.
If an applications asks for 1GB additional RAM and the RAM is already full, it can still crash even if there's still "SWAP" available.
Try building firefox with ONE thread instead of running it in 6, 10 or whatever threads.
If the systems SWAPs that means it's likely at some point is going to crash.

I did "apt-get install cpufrequtils". I've never tried to overclock anything.

While I agree setting CPU to performance mode is a good thing to do, you don't have to do this via cpufrequtils.
On the image pre-installed is something called "cpu-control" which is a script that allows you to configure the cpu governor and frequencies.

[ab1jx]

Of course. I once estimated that swap is about 1/1000 the speed of real RAM but that was in my i386 days working at a community college and trying to explain why RAM was a good investment. I usually installed the maximum possible. But with SOCs where you can't add more you're stuck without swap or being able to build on a big machine. I built Firefox on my Rock64 with 4 GB and swap, but wasted most of a week trying to do it on a Raspberry Pi.

Bash script calling whiptail, like setup-odroid or raspi-config, very useful technique. I can almost do GTK, but I've just hacked a few LXDE plugins to do what I want. https://sourceforge.net/projects/btctick Mostly I stick to command line stuff.

cpu-control.png (12.99 KiB) Viewed 6302 times

I was only trying to run 2 jobs at once: LLVM_PARALLEL_COMPILE_JOBS:STRING=2

Back to work, now that I've got an escape hatch back to Ondemand, notes on paper as a last resort.

[ab1jx]

That was it exactly. Finished the build and installed. I was watching top the whole time, it never swapped at all. I now have current llvm and

Code: Select all

root@odroid:/usr# clang --version
clang version 8.0.1 (tags/RELEASE_801/final)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /lib/llvm8/bin

I have to admit I got a chuckle out of a modern Linux box that doesn't even come with sudo. I always log in as root anyway. But some things like gqrx don't work like that so I tried sudo, didn't work. root owned the display, I'll get it eventually.

[meveric]

I have to admit I got a chuckle out of a modern Linux box that doesn't even come with sudo.

sudo is an application. Like any other application it can be installed.
It is not installed by default, as normally it's not required.
Debian philosophy is to separate user and administrators, you have a root user with privileges for administrative tasks, and you have a user with no privileges for regular work.
Ubuntu on the other hand disables the root account completely by default, but instead installs "sudo" per default and the "user" has sudo permissions to allow administrative tasks.
Both can be changed, either by installing sudo (on Debian) or by giving root a password to activate the root account (on Ubuntu).

[ab1jx]

In OpenBSD (and FreeBSD) you start as root and optionally create another user. In Raspbian the default user is pi, can't add more. Getting root access is almost as sneaky as Android, you do sudo chpass to set a root password, then you can use it. I always get frustrated by what I can't do as a non-root user and just log in as root. I did my time on other people's systems without being root about 25 years ago. I remember doing rm * once in my home directory and asking where the recycle bin was.

[delta]

Hi all,

I've been using this image for some months on my N2 with OpenMediaVault (bunch of debian packages) and some docker containers. Thanks for releasing and maintaining it.

It's working great and I'm happy with the board but I get random reboots every week or 2 weeks (the timing is not consistent) and I'm having a hard time fixing this issue.

I'm using the latest kernel (4.9.182+) and can't find anything interesting in Syslog:

sudo tail -n 20 /var/log/syslog.1

Code: Select all

Jul 25 23:47:52 odroid dockerd[3998]: time="2019-07-25T23:47:52.823105228+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:oq1zslsmxfrluxcwhl942v3vv leaving:false netPeers:1 entries:24 Queue qLen:0 netMsg/s:0"
Jul 25 23:52:53 odroid dockerd[3998]: time="2019-07-25T23:52:53.018879694+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:kwk42csx5yq66zliaron08do2 leaving:false netPeers:1 entries:13 Queue qLen:0 netMsg/s:0"
Jul 25 23:52:53 odroid dockerd[3998]: time="2019-07-25T23:52:53.020511360+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:psgw4g6zglragbqn9g85rtwuc leaving:false netPeers:1 entries:9 Queue qLen:0 netMsg/s:0"
Jul 25 23:52:53 odroid dockerd[3998]: time="2019-07-25T23:52:53.021957641+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:9coupvfcqth9iy2u5odzds172 leaving:false netPeers:1 entries:5 Queue qLen:0 netMsg/s:0"
Jul 25 23:52:53 odroid dockerd[3998]: time="2019-07-25T23:52:53.023222288+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:oq1zslsmxfrluxcwhl942v3vv leaving:false netPeers:1 entries:24 Queue qLen:0 netMsg/s:0"
Jul 25 23:57:53 odroid dockerd[3998]: time="2019-07-25T23:57:53.218944454+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:9coupvfcqth9iy2u5odzds172 leaving:false netPeers:1 entries:5 Queue qLen:0 netMsg/s:0"
Jul 25 23:57:53 odroid dockerd[3998]: time="2019-07-25T23:57:53.219136047+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:oq1zslsmxfrluxcwhl942v3vv leaving:false netPeers:1 entries:24 Queue qLen:0 netMsg/s:0"
Jul 25 23:57:53 odroid dockerd[3998]: time="2019-07-25T23:57:53.219186799+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:kwk42csx5yq66zliaron08do2 leaving:false netPeers:1 entries:13 Queue qLen:0 netMsg/s:0"
Jul 25 23:57:53 odroid dockerd[3998]: time="2019-07-25T23:57:53.219226760+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:psgw4g6zglragbqn9g85rtwuc leaving:false netPeers:1 entries:9 Queue qLen:0 netMsg/s:0"
Jul 26 00:00:01 odroid CRON[16156]: (root) CMD (/usr/sbin/omv-mkrrdgraph >/dev/null 2>&1)
Jul 26 00:00:42 odroid systemd[1]: Started Run anacron jobs.
Jul 26 00:00:42 odroid anacron[16394]: Anacron 2.3 started on 2019-07-26
Jul 26 00:00:42 odroid anacron[16394]: Will run job `cron.daily' in 5 min.
Jul 26 00:00:42 odroid anacron[16394]: Jobs will be executed sequentially
Jul 26 00:02:53 odroid dockerd[3998]: time="2019-07-26T00:02:53.418997960+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:oq1zslsmxfrluxcwhl942v3vv leaving:false netPeers:1 entries:24 Queue qLen:0 netMsg/s:0"
Jul 26 00:02:53 odroid dockerd[3998]: time="2019-07-26T00:02:53.419196720+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:kwk42csx5yq66zliaron08do2 leaving:false netPeers:1 entries:13 Queue qLen:0 netMsg/s:0"
Jul 26 00:02:53 odroid dockerd[3998]: time="2019-07-26T00:02:53.419240180+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:psgw4g6zglragbqn9g85rtwuc leaving:false netPeers:1 entries:9 Queue qLen:0 netMsg/s:0"
Jul 26 00:02:53 odroid dockerd[3998]: time="2019-07-26T00:02:53.419280391+12:00" level=info msg="NetworkDB stats odroid(c30d398ecbaa) - netID:9coupvfcqth9iy2u5odzds172 leaving:false netPeers:1 entries:5 Queue qLen:0 netMsg/s:0"
Jul 26 00:05:42 odroid anacron[16394]: Job `cron.daily' started
Jul 26 00:05:42 odroid anacron[17497]: Updated timestamp for job `cron.daily' to 2019-07-26

The system isn't doing anything before crashing:




So far, I've tried using 2 different PSUs and attaching a powered USB hub to avoid drawing any power from the N2 but I'm still getting the random reboots.

I'm hoping you guys can help?

[ab1jx]

Do you have persistent logging turned on? This is maybe not the best explanation of how to do i I've seen: https://www.quora.com/How-do-we-enable- ... gs?share=1

The journal doesn't survive reboots so it doesn't show what caused the reboot. The key seems to be to set "Storage=persistent" in /etc/systemd/journald.conf but make sure you've set up a place for the log files like in the longer version. See the journalctl man page too.

[ab1jx]

I got there eventually

nightly_splash1.png (150.08 KiB) Viewed 6141 times

I wish I could say how long it took to build but some crash took me out of X, which closed my rxvt window I was building in and stopped the build. I rebooted and finished at a console (no X running) next morning. My xorg log shows:

Code: Select all

[ 36570.170] (EE)
Fatal server error:
[ 36570.263] (EE) systemd-logind disappeared (stopped/restarted?)
[ 36570.263] (EE)
[ 36570.279] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[ 36570.279] (EE) Please also check the log file at "/var/log/Xorg.0.log" for ad
ditional information.
[ 36570.279] (EE)
[ 36570.814] (EE) Server terminated with error (1). Closing log file.

I thought I was getting a release, not a nightly build, but oh well. The ESR version in the debs was experiencing tab crashes on my Facebook page unless I ran with extensions disabled. I didn't install any extensions or find any to remove. The Nightly does Facebook OK. The ESR version was doing a container tab for Facebook, I don't think that worked quite right. I don't think Nightly is.

Yes, it does still have container tabs but Facebook didn't automatically get put into one. There's a separate Facebook Container Tab extension you can add, seems to work better with the new Nightly.

[delta]

Do you have persistent logging turned on? This is maybe not the best explanation of how to do i I've seen: https://www.quora.com/How-do-we-enable- ... gs?share=1

The journal doesn't survive reboots so it doesn't show what caused the reboot. The key seems to be to set "Storage=persistent" in /etc/systemd/journald.conf but make sure you've set up a place for the log files like in the longer version. See the journalctl man page too.

Thanks for the suggestion, I have set it up and I'll see if I can get any interesting information next time it crashes

[ab1jx]

Do you have persistent logging turned on? This is maybe not the best explanation of how to do i I've seen: https://www.quora.com/How-do-we-enable- ... gs?share=1

The journal doesn't survive reboots so it doesn't show what caused the reboot. The key seems to be to set "Storage=persistent" in /etc/systemd/journald.conf but make sure you've set up a place for the log files like in the longer version. See the journalctl man page too.

Thanks for the suggestion, I have set it up and I'll see if I can get any interesting information next time it crashes

It's sort of an odd system, I've only used it a couple times. You don't need to keep logs back very long time-wise as long as you can investigate soon after a crash. Figure out what the boot id of the previous boot was and look near the end of that section. With persistent logging on, "journalctl --list-boots" should let you pick the one you want.

[delta]

Ok so my system has just rebooted again for no apparent reason; last entries I am getting with journalctl are:

Code: Select all

août 11 15:00:01 odroid CRON[31010]: pam_unix(cron:session): session opened for user root by (uid=0)
août 11 15:00:01 odroid CRON[31009]: pam_unix(cron:session): session opened for user root by (uid=0)
août 11 15:00:01 odroid CRON[31017]: (root) CMD (/usr/sbin/omv-mkrrdgraph >/dev/null 2>&1)
août 11 15:00:01 odroid CRON[31018]: (root) CMD (/var/lib/openmediavault/cron.d/userdefined-6a07cf8c-47e5-4414-aa07-ec2831e34a81 >/dev/null 2>&1)
août 11 15:00:01 odroid CRON[31010]: pam_unix(cron:session): session closed for user root
août 11 15:00:05 odroid CRON[31009]: pam_unix(cron:session): session closed for user root

Which was just me creating a cron job to log the memory and swap usage every hour.

I have also noticed that swap was almost full 1 hour before the reboot (about 700MB out of 1G). But I am guessing that I would see at least 1 message about memory in my logs if it was the cause for the reboot, right?

Any other idea?

I really appreciate the help as I am running out of ideas and I am just hoping that it's not the hardware at this point.

[meveric]

IF you see a log entry about memory issues, than the Board would not crash, cause in that case the out of memory killer would have killed to process that was causing the memory issue in the first place and with that "saved" the system from crashing.
That doesn't mean that it's not happening at all.
The mere fact that you see that swap is used extensively already suggest that there is a memory issue, or else the SWAP would not be used.
SWAP is meant as a last resort measure to prevent system failure due to lack of available RAM. It is not meant as a means of "extending the RAM for regular work tasks".
In fact in many cases SWAP is too slow to prevent this at all, and if a application wants 1GB extra memory when only 100MB are free, it's likely requesting that huge chunk of memory can cause a failure already.

In order to reserve these additional 900MB it is not writing IN the SWAP, on the contrary. It is REMOVING what is currently in the RAM and for that particular task not being used.
Copies the "unused" data from RAM into SWAP to make 900MB RAM FREE, not to extend the RAM with the SWAP.
And this copy process can take a very long time, much longer than the request for the 1GB is able to wait for the memory to become free.
Which in best case means the OOM Killer (out-of-memory) will terminate the process before critical system failure, or in worst case that it means the system just crashes.

And don't get me starting what happens with the data in SWAP which is still "needed".

[delta]

Thanks for this clear explanation meveric, very interesting and I didn't know swapping could cause a system crash. My system still have plenty of RAM before crashing.

As for the reason my system is swapping, here's some additional background:
1. I'm using docker containers with docker swarm and I reckon one of the containers I'm using has a memory leak
2. To prevent that app from taking all the system RAM, I have limited the container to 500M of RAM with --memory setting
3. Unfortunately, I can't limit or forbid swap usage with --memory-swap as this option is not supported with docker swarm

Do you, by any chance, have an idea of how I could prevent swapping to cause a crash or maybe make OOM Killer more aggressive on this app?

I'm not sure it's the reason for my crashes yet but I reckon it's worth investigating.

[ab1jx]

Don't have any swap You'll get a nice hard crash instead. I was surprised that the image doesn't set up any swap so I added 8 GB or so. Not having swap is maybe fine if you only run one thing at a time and reboot a lot. I run 6-8 desktops in my pager and sometimes it's a month between reboots. If I'm compiling something I want Firefox swapped out of the way, but I might not want to close it and lose my tabs. Some manual control over what gets swapped out might be good.

What surprised me is that setting performance mode made a reliability improvement. I wasn't looking for speed. And the Firefox build ran like a banshee on all 6 cores. But i wasn't in X at all, fresh boot to a command line console, and it worked.

[meveric]

2. To prevent that app from taking all the system RAM, I have limited the container to 500M of RAM with --memory setting
3. Unfortunately, I can't limit or forbid swap usage with --memory-swap as this option is not supported with docker swarm

IF memory limit works, then swap wouldn't be used. Think about it. If you tell a container to use 500MB and after the 500 MB it uses 2GB SWAP, what is the point of memory limit?
I suggest you observe what is really using the swap. swap is only used when RAM is FULL, and not when there's still RAM available.
BUT memory can be given free when no longer used, even if there's still stuff in the swap.
So it's more likely that an application (or more than one) is using a lot of RAM "at times" which eats the RAM, fills the SWAP and then either crashes or gives some RAM free again.
Which from your point of view looks like "there's still RAM free, although it uses SWAP, therefore the memory limit works and instead it writes in SWAP"

Do you, by any chance, have an idea of how I could prevent swapping to cause a crash or maybe make OOM Killer more aggressive on this app?

I'm not sure it's the reason for my crashes yet but I reckon it's worth investigating.

swapping is not the cause of the crash.. using more RAM than available is what causes the crash. The SWAP is simply too slow to handle it, it's not the cause.
The cause is an application that wants more RAM than what is available.
You can configure OOM and other memory stats under: /proc/sys/vm/
For example in /proc/sys/vm/overcommit_memory you can disable over-committing of RAM of applications. Check the output of "htop" you'll see, that applications have two values "VIRT" and "RES".
RES is the currently used memory by the application VIRT is the memory the application "reserves" for later usage. In many scenarios VIRT greatly exceeds the available physical RAM + SWAP.
This is what is called "over-committing" the system allows the application to reserve more RAM + SWAP than what is currently available but in worst case an application will try to use this RAM at some point and this can cause a crash.
setting /proc/sys/vm/overcommit_memory to 2 will disable over-committing completely. /proc/sys/vm/overcommit_ratio can configure how many % can be used for over-commiting.
/proc/sys/vm/swappiness can control how aggressively you want to swap, etc. it's worth reading into these things a little.

I was surprised that the image doesn't set up any swap so I added 8 GB or so. Not having swap is maybe fine if you only run one thing at a time and reboot a lot.

The image is setup as a minimal system and not to force the user to follow a specific pattern. Setting up 8GB of swap would also increase the image size of 8GB, which in return would mean it would no longer fit on a 8GB SD/eMMC.
This might seem fine for you but others would not agree with that.
Aside from that. We've been using ODROIDs with 2GB of RAM for years and it was fine. Now you have 4GB and the first thing you need is "more RAM".
Anyway... Today rarely anyone uses "real SWAP" anymore. But instead uses ZRAM, which is probably 100~1000 times faster than physical swap on an SD/eMMC.
And installing zram-odroid would already give you in default configuration about 2GB SWAP (ZRAM) which can even be further configured.

What surprised me is that setting performance mode made a reliability improvement.

I guess that shows that the system is far from being rock solid at the moment.
My guess: swapping is a CPU intensive task, it needs to decide what parts of the memory is currently not needed. It needs to compress these pages in the memory and copy them to the SWAP and afterwards free the pages in RAM.
a on-demand governor uses the slowest possible CPU clock to reduce power consumption, therefore if a CPU intensive task shows up it needs to clock up the CPUs first.
The time that it needs to clock up the CPU before actually being able to perform the swapping task can already be too long for an application to wait for "free RAM".

Or on-demand is simply unstable.

[delta]

IF memory limit works, then swap wouldn't be used. Think about it. If you tell a container to use 500MB and after the 500 MB it uses 2GB SWAP, what is the point of memory limit?
I suggest you observe what is really using the swap. swap is only used when RAM is FULL, and not when there's still RAM available.
BUT memory can be given free when no longer used, even if there's still stuff in the swap.
So it's more likely that an application (or more than one) is using a lot of RAM "at times" which eats the RAM, fills the SWAP and then either crashes or gives some RAM free again.
Which from your point of view looks like "there's still RAM free, although it uses SWAP, therefore the memory limit works and instead it writes in SWAP"

Regarding this specific paragraph, it does use the swap according to docker documentation

If --memory-swap is unset, and --memory is set, the container can use twice as much swap as the --memory setting

https://docs.docker.com/config/containe ... ap-details
And like I said in my post earlier, I am not able to use --memory-swap as it is not available with docker swarm

Also, this is what my RAM usage looks like just before a crash: (white part with no data is the crash)



That being said, I changed some settings lately (including increasing the swap size) and instead of a crash I lost all access to both my USB drives just now:

Code: Select all

[146327.633701] IPVS: Creating netns size=2176 id=117
[148128.261801] IPVS: Creating netns size=2176 id=118
[148844.404391] sd 1:0:0:0: [sda] tag#13 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD OUT 
[148844.407190] sd 1:0:0:0: [sda] tag#13 CDB: Write(10) 2a 00 15 dc 1e b8 00 04 00 00
[148849.512103] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
[148849.514817] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting host.
[148849.538123] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000 microseconds.
[148849.540052] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not halting.
[148849.547501] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[148849.554457] usb 2-1.4: cmd cmplt err -108
[148849.558342] usb 2-1.4: cmd cmplt err -108
[148849.562584] usb 2-1.4: cmd cmplt err -108
[148849.566831] usb 2-1.4: cmd cmplt err -108

And I get heaps of I/O errors after that.
I've tried googling this error and a possible cause in older kernels was USB power saving which I have already disabled but I'm still getting this error. Could this be power related? Or maybe a problem with the kernel?