• Content count

  • Joined

  • Last visited

About piknew

  • Rank
    Advanced Member

Recent Profile Visitors

377 profile views
  1. My plan is (on Friday - when I get physical access to device): 1. Unplug network cable and plug in into built-in eth0 port if successful then get logs/dmesg etc. 2. Move the device neat to PC (or laptop near to this board), connect by UART and try to login (of course I know that it is without initial login prompt). Fortunately I am using portable UPS, so there should be no issue. Any more suggestions? As topic is basically related to other (unfortunately other users the do not confirmed if connect by ssh is working (without debug option it seems that connection is not done at all).
  2. Dear All, today my Opi PC stoppped responding. But I think it is not totally "dead". From other machine I did: root@PKSERVER:~# ssh -vvv pkbackup OpenSSH_6.7p1 Debian-5+deb8u4, OpenSSL 1.0.1t 3 May 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug3: checking match for 'exec "/etc/ssh/pkdata.sh %n"' host pkbackup debug1: Executing command: '/etc/ssh/pkdata.sh pkbackup' debug1: permanently_drop_suid: 0 debug3: command returned status 1 debug1: /etc/ssh/ssh_config line 18: no match 'exec "/etc/ssh/pkdata.sh pkbackup"' debug3: match not found debug1: /etc/ssh/ssh_config line 21: Applying options for * debug2: ssh_connect: needpriv 0 ......................... a lot of lines ................................. debug1: Offering RSA public key: /root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp cc:d4:2d:54:9e:33:87:8e:ef:e0:b1:e3:dc:25:46:67 debug3: sign_and_send_pubkey: RSA cc:d4:2d:54:9e:33:87:8e:ef:e0:b1:e3:dc:25:46:67 debug1: Authentication succeeded (publickey). Authenticated to pkbackup ([]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. At this moment this is the last message from ssh. Quite interesting that CTRL+C is not working (session is already on remote machine side). Please note that previously I provided stacktrace which was registered in log: It was related to network driver (dwmac-sun8i): [44339.175188] dwmac-sun8i 1c30000.ethernet: packet dropped [55271.062033] kworker/0:0H: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null) [55271.062702] kworker/0:0H cpuset=/ mems_allowed=0 [55271.063225] CPU: 0 PID: 21267 Comm: kworker/0:0H Not tainted 4.14.18-sunxi #24 [55271.063347] Hardware name: Allwinner sun8i Family [55271.063793] Workqueue: xprtiod xs_tcp_data_receive_workfn [55271.064500] [<c010db15>] (unwind_backtrace) from [<c010a0d9>] (show_stack+0x11/0x14) [55271.064924] [<c010a0d9>] (show_stack) from [<c0868f69>] (dump_stack+0x69/0x78) Maybe this is the way (not kernel itself)? EDIT (from RPI SBC): https://github.com/raspberrypi/linux/issues/2482 Similar issue (I am also using nfs as primary "storage"). In my case also there was "packet dropped". Please note https://github.com/6by9/linux/commit/d9941e07f7b8d34a9404374c0e583ba6e5f25da9 Note to moderator: if this is wrong way - please delete/move it to "trash". EDIT2: I noticed difference to TSO between default and mainline in bonding driver, but no difference in eth interface. default: root@PKSERVER:~# ethtool -k bond0 | grep segmentation tcp-segmentation-offload: off tx-tcp-segmentation: off [requested on] tx-tcp-ecn-segmentation: off [requested on] tx-tcp6-segmentation: off [requested on] generic-segmentation-offload: on tx-fcoe-segmentation: off [fixed] root@PKSERVER:~# ethtool -k eth0 | grep segmentation tcp-segmentation-offload: off tx-tcp-segmentation: off [fixed] tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: off [fixed] generic-segmentation-offload: on tx-fcoe-segmentation: off [fixed] root@PKSERVER:~# mainline: root@PKOTHER:~# ethtool -k bond0 | grep segmentation Cannot get device udp-fragmentation-offload settings: Operation not supported tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: on tx-tcp-mangleid-segmentation: on tx-tcp6-segmentation: on generic-segmentation-offload: on tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: on tx-gre-csum-segmentation: on tx-ipxip4-segmentation: on tx-ipxip6-segmentation: on tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on tx-sctp-segmentation: off [fixed] tx-esp-segmentation: off [fixed] root@PKOTHER:~# ethtool -k eth0 | grep segmentation Cannot get device udp-fragmentation-offload settings: Operation not supported tcp-segmentation-offload: off tx-tcp-segmentation: off [fixed] tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off [fixed] tx-tcp6-segmentation: off [fixed] generic-segmentation-offload: on tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-gre-csum-segmentation: off [fixed] tx-ipxip4-segmentation: off [fixed] tx-ipxip6-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-udp_tnl-csum-segmentation: off [fixed] tx-sctp-segmentation: off [fixed] tx-esp-segmentation: off [fixed] root@PKOTHER:~# For device "pkbackup" ("frozen") I am using 1GBit USB eth1, but until I get physical access to this device - I am not able to confirm what are the settings for this interface).
  3. Sure. I will treat it as warning - do not use "stop" for this service. If there is relable way to recognise if "stop" is done on behalf of shutdown then it would be good idea to add it here as condition... I guess it is EOT for this "issue". How about the test that I've done here: https://forum.armbian.com/topic/7548-apt-list-vs-mainline-very-slow/?do=findComment&amp;comment=56805 I can repeat it, however as "apt" itself is a binary - I do not know what is really done by this tool here (no child processes, eg gzip etc.)...
  4. For the issue "systemctl stop armbian-hardware-monitor" - the reason is quite obvious, this line of script /usr/lib/armbian/armbian-hardware-monitor: /sbin/modprobe -r $(cut -f1 -d' ' </proc/modules) In my case (hint: removing network/binding modules is basically "showstopper"): root@PKHELPER:~# cut -f1 -d' ' </proc/modules rpcsec_gss_krb5 bonding snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio dw_hdmi_cec evdev 8189es sun8i_dw_hdmi dw_hdmi cec sun8i_codec_analog snd_soc_simple_card sun4i_codec sun4i_i2s snd_soc_simple_card_utils ir_lirc_codec lirc_dev snd_soc_core rtc_ds1307 sunxi_cir snd_pcm_dmaengine cfg80211 snd_pcm snd_timer snd rfkill soundcore sun4i_gpadc_iio sun4i_tcon sun8i_mixer sun4i_drm uio_pdrv_genirq uio fuse uas pwrseq_simple sy8106a_regulator realtek
  5. Please see attached log.txt. This is the sequence of operations to reproduce (on my Orange Pi+2 in this case). Important is that removal or restore of /etc/apt/apt.conf.d/02-armbian-compress-indexes file shall be followed by apt update command. Result of armbianmonitor -u is here. Edit 1: my Opi+2 just "died" (this part of post shall be probably moved to new topic I guess). Igor, can you please try following? I was able to "make unresponsible" my both Opi+ and now OpiZero: Starting point - armbian-hardware-monitor was disabled wg. no related symlink in /etc/systemd/.... // Please do not ask why I disabled it . Enabling it was caused by message in armbianmonitor -u - so, next is what I did. root@PKOTHER:~# systemctl enable armbian-hardware-monitor Created symlink from /etc/systemd/system/basic.target.wants/armbian-hardware-monitor.service to /lib/systemd/system/armbian-hardware-monitor.service. root@PKOTHER:~# systemctl start armbian-hardware-monitor root@PKOTHER:~# systemctl stop armbian-hardware-monitor Interesting thing is that "PuTTY" is keeping connection (by means of TCP?) // as it is seen first I was trying to connect to "pkhelper" (OPi+2 which stop responding after commands as given above and is a subject of my my tests for armbiuanmonitor -u): Last command was not completed. And device... in not accessible anymore. I was able to reproduce it wit both OP'is. admin@PKSERVER:~$ ssh root@pkother ssh: connect to host pkother port 22: No route to host Edit 2: now both of my "servers" are restarted, so I can resume testing...
  6. Actually I have found root cause of this slowness. It is a file: /etc/apt/apt.conf.d/02-armbian-compress-indexes After removing it - everything is very fast again. So, the issue is rather not related to kernel. It is related to Armbian support files (in my case the version is 5.47).
  7. After upgrade two of my boards to mainline (4.14.51-sunxi) I have noticed that simple command apt list basically stopped working. It stuck at "Listing ..." (at this moment 1 core of CPU is utilized in 100%). Now I run it in background to see if eventually it will be completed... So far (15 minutes)... nothing. apt list --installed is also very slow, but after some time it gives results. However, it is much slower than on "default" (3.4.113-sun8i) Can anybody check it and reconfirm?
  8. Orange Pi Zero (which I am using for "testing"). I have built: Then I started normal (for me at least) activity) - cron.d is running my own backup software every one hour. This one in general is "rsync" (it is scanning disks/nfs) - determines the differences, storing state in sqlite3 db... So, I guess most of "my use cases". I will let you results. So, far it is OK. I can say that this test "frozen" next kernel (downloaded from stable repository) upgrade after around 1 day... Some results: backup-TEST.run.1.log
  9. Hi, case is related to Opi Zero H2+: I have done cpuburn test and some time after start it thrown following message: Is there any throttling here?
  10. For me it did. On all of my boards (Opi+2e, Opi+2, OpiPC, OpiZero) I was trying: stable "next" nightly "next" Unfortunately it failed (sometimes I was able to get some exceptions in logs, example of one of them is here: So I went back to "default" (stable). And on all boards - no issues.
  11. Just FYI - I have reverted to 3.4.113-sun8i on all my SBCs: Orange Pi+ 2E Orange Pi+ 2 Orange Pi PC Orange Pi Zero (H2+/512) The reason is here: Thread in A20, but for me seems to happen on H2+/H3).
  12. piknew

    30-sysinfo get_ip_addresses()

    Thanks. I have tested it with custom entry: SHOW_IP_PATTERN="^[ewr].*|^br.*|^lt.*|^umts.*|^bond.*" Test is successful on: Orange Pi+ 2E Orange Pi+ 2 Orange Pi PC Orange Pi Zero (H2+/512) My config for network is to make binding for network interfaces, so bond0 interface is the valid one.
  13. piknew

    30-sysinfo get_ip_addresses()

    During some experiments with nightly builds I noticed that script 30-sysinfo was updated. However, with additional regexp |^br.* - which will include bridges. Maybe I misunderstood, but I thought br interfaces shall be rather excluded, bond included, shall not they? So far I keep modified copy of script (from "proposal" above) and I am using it after it is overwritten by "upgrade".
  14. Hi, my OPIs after upgrading to mainline also started to be unresponsive. Today OPI+2e - before it died (ping was working but rest of services - not) following was dumped to kernel.log:
  15. Conclusion and many thanks especially to martinayotte: I must have explicit line in armbianEnv.txt: root@PKTOOL:~# cat /boot/armbianEnv.txt verbosity=0 rootdev=/dev/mmcblk1p1 user_overlays=ds1307 extraargs=pty.legacy_count=2 root@PKTOOL:~# EDIT: Both /etc/fstab and /boot/armbianEnv.txt was migrated to UUID, so my images are compatible again with both SD and EMMC. Additionally there is suggestion - as I have upgraded from legacy I didn't have armbianEnv.txt file at all. armbian-config hasn't created any... So, content was only my "guessing". Maybe it will be worth to add ceration of such a file automatically? I guess it may be an issue with correct detection of boot device when still under "old kernel". This would be "would" prediction. So, maybe warning at the end... EDIT: with UUID approach it would not be so difficult. Many thanks to everybody. I have solved my problem