You could also create a pcap file and review via wireshark.
I had that in my mind, but couldn't remember how it was working
- old man, old limited "RAM" here -
You could also create a pcap file and review via wireshark.
I had that in my mind, but couldn't remember how it was working
- old man, old limited "RAM" here -
- I've NO idea of "Pi OS Lite" [1] -
but maybe you could get some useful output if you open two terminals on the nfs server:
- one running dmesg -w or journalctl -f to see what is happening
and
- one running sudo exportfs -ra ( or -rav)
see: man exportfs
you could also mount the exports on the nfs server itself to see if all is working.
if this is all working (local mounts) you should investigate your network (firewall, etc., maybe starting with simply pinging each others, ...)
IIRC (long ago playing with nfs) a simple wrong placed blank in /etc/exports caused long lasting "fun"...
[1]
did you investigated on their forum (if available) too ?
no idea if it's installable on OpenmediaVault (wasn't it based on Debian ?), but to look into network traffic:
But I'll still try to find the NFS issue
... and please report here
LibreELEC contains a very stripped down version of Linux ("just enough OS..."), but try lsblk or fdisk -l ...
lsblk, fdisk are also stripped
but a sgdisk and parted is available
some questions:
1. did your lan setup ever run or is it a regression ( I esp. mean: simultaneous recording and replaying) ?
2. you said running SMB is fine, why don't run SMB [3.1 ?!] only ?
3. why are you shoveling big data through an LAN ?
I esp. mean when all 4 satellites on the intel box are recording
why not store the data where they first appear (at the intel box) ?
4. what does the network traffic and the CPU load on an PI look like when doing 4x recording *and* 4x replaying concurrently (!) ?
did you checked it with htop, etc. ?
- I've no idea from PI or FHEM or VDR) -
5. but isn't the intel box a lot more potent then the PI and wouldn't it make more sense to run a NFS server on the intel box too and in the dependence of what OS is currently running on the intel to maybe use a newer version of NFS (4.x) / kernel ? [1]
[1]
newer mostly means "better", but the opposite might also be true (sometimes it is, but sometimes only !)
I guess you're nailed with an aged kernel on the PI ?
I've read newer kernels benefiting from more throughput ...
I've currently also no idea if NFS 4.x provides any benefit over 3.x, but usually a newer version fixes the bugs/shortcommings in an elder version ... (sometimes )
or I'm to stupid to find the way to change it
/etc/nfsmount.conf
see:
https://linux.die.net/man/5/nfsmount.conf
clear (?): adjusting {r,w}size => no need to provide them as mount option (client) - I would like to say - dito: Proto, etc.
===
btw.: google is also a search engine
I believe it's an rsize / wsize issue of the Raspi NFS Server
Nevertheless what I enter on client site using mount for rsize and wsize the value don't change
did you read in the link to nfs from comment #15 the chapter "Transport Methodes" ?
to it seems UDP, TCP, wsize, rsize, MTU are depending on each other...
maybe a stupid hint: changing the the config file on the server needs a restart of the server
some more links:
another tool to measure bandwidth, MSS/MTU, etc. could be iPerf3:
iPerf - The TCP, UDP and SCTP network bandwidth measurement tool
usage:
iPerf - iPerf3 and iPerf2 user documentation
P.S.
maybe it's worth to check on what speed the network interfaces are currently running ?
Background:
got a new mainboard with 2.5 Gbit Intel LAN (driver: igc) running in an 1 Gbit LAN with dhcp and sometimes I got 100 Mbit only on the igc.
- it could be the kernel (5.15.y) , it could be the new firmware on the router too, ..., no idea ... -
question: is your experiences a regression ?
- just my 2 ct -
would playing with wsize and rsize have an affect ?
see:
moons ago I played with it to see how to get the best throughput.
it turned out that the defaults were not that ideal.
at that time the defaults were: rsize=1048576,wsize=1048576
I got the best with: rsize=32768,wsize=32768
but -as said - it's years ago: old NFS server (3.x ?), old disk, ...
write: read: in MB/s
=================
6,91 49,68 NFS-default wsize, rsize)
35,31 81,45 rsize=8192,wsize=8192
34,90 101.75 rsize=16384,wsize=16384
49.86 110.62 rsize=32768,wsize=32768 (nearly full GB-LAN speed [ 125 MB/s (theoretically)]
thanks following my advice.
alas I can't help further, means no expert here reading/understanding log files.
One question: was debugging set on (unsure: and with a subseq. reboot) before creating the above log file ?
my last advice (currently we both are still alone here):
if you don't get enough attention to this thread I would create a thread in this forum under Topic "Bug Reports" with an useful subject title, like the one for this thread with prefix "Regression:" , and just create a *link* in that thread to this thread here (NOT copy&paste content)
heitbaum thanks for clarification
this will save your electricity bill too
moons ago I had a Pentium 4, always running on top CPU speed sucking ~160 W when "idle" (modern Desktop idle: ~35 W)
thanks
with the todays nightly i915 firmware is loaded again !
nice !
regarding your advice in comment #7
is initrd=gpu.cpio the only bootparameter I need when I created a gpu.cpio ?
means: could I omit " i915.enable_guc=2" ?
currently running the todays nightly, without a created gpu.cpio, and without i915.enable_guc=2 the firmware for guc and huc is *not* loaded.
======
another part:
with dmesg|grep -iEw 'bad|bug|conflict|corrupted|error|fail|failed|fault|fatal|invalid|Lock|NULL|segfault|stack|trace|warn'
I get
...
[ 1.575942] fsck: Cannot initialize conversion from codepage 850 to ANSI_X3.4-1968: Invalid argument
[ 1.576150] fsck: Cannot initialize conversion from ANSI_X3.4-1968 to codepage 850: Invalid argument
...
just a hint, cause I currently do not plan to write a new bugreport or so.
should I ?
you were talking about test builds ...
*I* don't think so too :
moving back to stable could only be a first step to investigate where the problem could be, e.g. excluding it's hardware
if you want to get a fix you need the test with a *clean* nightly without any magic settings. just with the addons where the box could play TV/movies.
Only then it is in an environment where a developer (maybe with the same hardware) could replay/investigate where he maybe has something done wrong...[1]
So please *first* start with a clean nightly and a further step then could be: testing with (maybe) magic settings/addon's under nightly too, all step by step.
[1]
if he did ?!
this question is unanswered !
it's especially unanswered while I'm able to run nightly without trouble and I guess the same goes for the developer.
the questions is:
what is up with *your* box running nightly and why ?
moving to stable doesn't help much getting the answers
The suspend is most likely a Linux kernel thing AFAIK, but unless something magically happens in the upcoming v5.15 kernel
on a Rocket Lake box with wifi/BT compiled as module box does not suspend with 5.15.y, but does with 5.14.y
letting the wifi/BT modules off the 5.15.y kernel box suspends.
seems to be a regression.
a kernel bug report is in work ...
hallo
I usually load the Firmware (FW) for i915 via bootparameter "i915.enable_guc=2", but with nightly it doesn't work anymore.
with "dmesg|grep -iE 'drm|guc|huc|vgem'"
I get the following:
LE Release
=========
[ 0.738268] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[ 0.806598] [drm] GuC communication enabled
[ 0.819929] i915 0000:00:02.0: [drm] GuC firmware i915/kbl_guc_33.0.0.bin version 33.0 submission:disabled
[ 0.819931] i915 0000:00:02.0: [drm] HuC firmware i915/kbl_huc_4.0.0.bin version 4.0 authenticated:yes
[ 0.914124] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0
nightly
======
[ 0.744771] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[ 0.748948] i915 0000:00:02.0: [drm] [ENCODER:106:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it
[ 0.749016] i915 0000:00:02.0: Direct firmware load for i915/kbl_guc_62.0.0.bin failed with error -2
[ 0.749019] i915 0000:00:02.0: [drm] GuC firmware i915/kbl_guc_62.0.0.bin: fetch failed with error -2
[ 0.749021] i915 0000:00:02.0: [drm] GuC firmware(s) can be downloaded from https://git.kernel.org/pub/scm/linux/…e.git/tree/i915
[ 0.749671] i915 0000:00:02.0: [drm] GuC is uninitialized
[ 0.801989] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
AFAIK, if i915 is compiled into the kernel versus as a module i915 FW doesn't get loaded [1]
Does LE compiles i915 into kernel since kernel 5.15 ?
[1]
running kernel 5.15.2 on a Rocket Lake box under Fedora with i915 compiled as a module shows no trouble.
running kernel 5.15.2 on a Rocket Lake box under Fedora with i915 compiled into the kernel shows the above errors.
idea's ?