pmartin

For now, I have decided to play with the autofs timeout option (making it really long). Since my server is always on, and there is only one NFS share, I have no issue if it remains mounted for a long time.. (I use autofs because it nicely handles the power outage cases, i.e. the system automatically recovers from a power outage and resumes operations with no manual intervention.) Hopefully a long timeout will workaround the leakage by avoiding umount operations (best case), or at least reducing them to a handful per day (worst case). Then I can wait for the kernel upgrade. Lazy me.. Thanks for the quick answer.

I use 5.32 dev on NanoPi NEO: $ uname -a Linux watchdev 4.11.5-sun8i #11 SMP Fri Jun 23 20:03:23 CEST 2017 armv7l GNU/Linux I use NFSv4 and autofs. The number of "[NFSv4 callback]" processes increase each time a volume is mounted, and does not decrease when un-mounting: # ps axwww |grep -i nfsv4 | grep -v grep 1478 ? S 0:00 [NFSv4 callback] 1501 ? S 0:00 [NFSv4 callback] 1515 ? S 0:00 [NFSv4 callback] # umount /storage/motion # ps axwww |grep -i nfsv4 | grep -v grep 1478 ? S 0:00 [NFSv4 callback] 1501 ? S 0:00 [NFSv4 callback] 1515 ? S 0:00 [NFSv4 callback] # ls /storage/motion backup config firmware public scripts videos # ps axwww |grep -i nfsv4 | grep -v grep 1478 ? S 0:00 [NFSv4 callback] 1501 ? S 0:00 [NFSv4 callback] 1515 ? S 0:00 [NFSv4 callback] 1550 ? S 0:00 [NFSv4 callback] # umount /storage/motion # ps axwww |grep -i nfsv4 | grep -v grep 1478 ? S 0:00 [NFSv4 callback] 1501 ? S 0:00 [NFSv4 callback] 1515 ? S 0:00 [NFSv4 callback] 1550 ? S 0:00 [NFSv4 callback] # ls /storage/motion backup config firmware public scripts videos # ps axwww |grep -i nfsv4 | grep -v grep 1478 ? S 0:00 [NFSv4 callback] 1501 ? S 0:00 [NFSv4 callback] 1515 ? S 0:00 [NFSv4 callback] 1550 ? S 0:00 [NFSv4 callback] 1566 ? S 0:00 [NFSv4 callback] This causes me problems because I use my NanoPi NEO boards as home-made IP cameras (motion software) and motion events are stored on a PS server running Debian. This causes autofs to un-mount and re-mount the file server's volume many times a day. After searching a bit, I found several references to this issue, and it seems that the problem was introduced in 4.9 and that a fix is available in 4.11.6: https://security-tracker.debian.org/tracker/CVE-2017-9059 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863550 Is there any plan to upgrade the Armbian kernel to 4.11.6? Thanks. Pascal.

I am trying to install perf on armbian. It happens that perf is dependent on the kernel release (see /usr/bin/perf, a shell script). I use kernel 4.10.0-sun8i, but the linux-tools installed are apparently for kernel 3.16: # uname -r 4.10.0-sun8i # apt-get install linux-tools Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libdw1 libperl5.20 libpython2.7 linux-tools-3.16 Suggested packages: linux-doc-3.16 The following NEW packages will be installed: libdw1 libperl5.20 libpython2.7 linux-tools linux-tools-3.16 0 upgraded, 5 newly installed, 0 to remove and 1 not upgraded. [...] # /usr/bin/perf /usr/bin/perf: line 24: exec: perf_4.10: not found E: linux-tools-4.10 is not installed. Is a linux-tools package available for kernel 4.10? Thanks. Pascal.

I also tried the same MicroSD card on another NanoPi NEO I have (which was not plugged in during the outage), and I see a different MAC addresses on each boot (I tried 3 times). That makes me think that this might not be a hardware issue caused by the outage.

I realize there have been a few topics on this, but it seems to me that this was considered fixed. When using 5.23 with a 4.8 kernel, the MAC address was stable. After upgrading to 5.25, the MAC address was still the same as before. However after an outage, the two boards running 5.25 came up with a new MAC address (two boards still running 5.23 came up with the same MAC address). Then the MAC address seems to change every boot. The problem is that the FiOS router (an ActionTec) I have remembers both the machine name and the MAC address (it nicely creates a DNS entry). If the same name appears with a different MAC address, it ignores the name from DHCP and create a new entry with a made-up name. The router does not let you delete an entry, only rename it. (It is obviously a case of a router trying to be too smart for its own good: why does not it trust the DHCP name to begin with?) So now I have unpredictable IP addresses and names. Searching through google, I found an advice to add "hwaddress ether xx:xx:xx:xx:xx" to /etc/networks/interfaces. However after setting the MAC address this way (to the original MAC address), the network does not start properly and no new machine is even listed by the router. If I remove the statement, the network starts again. Any advice, or pointer to the right topic, will be appreciated. Thanks.

Igor, In the (very unlikely) case that the DEV kernel happens to not boot, how do I reinstate the 3.4.113 kernel? (BTW, I tried to see if the uvcvideo module from 4.8 would compile, but V4L2 data structures have changed since then, so it is quite a bit beyond my level as a short term solution.) Thank you for the help.

To answer my own questions.. I build kernel 3.4.113 on an Ubuntu guest, following Igor's documentation. But that was actually not really necessary.. I found a backported usbtv driver at: https://github.com/mwelchuk/usbtv it is installed on its own (not part of a V4L2 backport) using dkms. It does not require rebuilding the kernel and there is no symbol or V4L2 version conflict. It works as "well" on NanoPi Neo as on PC: grabbing only a few frames per second with motion (or zoneminder) seems to cause some weird images with half the content old. I wonder if that could be because it tries to start capture in the middle of a frame? Now I do have another problem with uvcvideo (another "EasyCap" device that was reported as using an USBTV007, but is a different chipset). The device is recognized, but generates error when opening /dev/video0 -- that same device works on PC Debian Linux 4.7.8. (Sorry for changing topic, but if anyone has tips, I welcome any.) Thanks.

How did you recompile the kernel? I am used to Debian, but here uname -a states kernel version "3.4.112", package linux-image-sun8i claims to be version "5.23" and installing linux-source leads to linux-source-3.16. I am somewhat lost with these seemingly inconsistent versions and some help will be greatly appreciated. Thanks.

From my experience with the RPi: creating the gpio group and adding the proper udev rules is all that is needed. I am fine with adding my account name to the gpio group (I understand that server use cases might not want to grant access to GPIO to all users). My applications do not require so fast access that I need any /dev/gpiomem. Normal access to GPIO is capable of thousands read/write per second at least, and all I need for sprinkler control is tens of read/write per _day_ . If the application needs the kind of speed that /dev/gpiomem provides, how does it get consistent and stable timing on Linux? Real-time priorities? Even then.. I am also fond of the RPi, but Raspbian is not always right. I do remember GPIO on Raspbian being a mess for some time. It handled GPIO properly only recently (adding the udev rules within the last 2 years or so). I had to survive some udev rules' oddities (open the gpio pin, see access being allowed, then rescinded, then allowed again--a race condition probably). Regarding support: maybe add a table documenting the Linux GPIO to board connector's pins mapping in each board's specific page? See the Scargill blog on the NanoPi Neo (http://tech.scargill.net/the-friendlyarm-nanopi-neo/) as an example.