Sound|audio|snd and evbug modules miraculusly loaded

Hi all

Beginning with this post, I discovered that on the machine I intend to use to drive a bridgemill and a lathe via parport based BOB, there were some modules loaded, that I did not understand why.

As I lack of time for now, I will leave the details to be added in this thread. I will edit this first post as I go, to keep interested readers lets say in birds view of what's to be expected.

Greez
chris

Edit Sep. 29th, 2020:

1. Background
The pc I intend to use for my bridgemill and lathe is a Dell OptiPlex 980 SFF. It controlled the mill and bridge well with LinucCNC 2.7.x. As 2.8.0 was released recently, an update was due. In order to get everything about right or as good as possible right from the start, I started looking into reasonably optimising latency , having in mind that we have purchased a Deckel FP2NC where we want to replace the Dialog 4 (still runningm but not as comfortavle) with a LinuxCNC based controller. I wrote the script to gather pc and test latency related data. My first attempt was to find a good pc. Prooved, the dell 980 is not bad. So I started in looking into optimising stuff for this machine.

2. Steps undertaken to optimes

a) Selecting the hw platform
I had to equal Dell OptiPlex 980 SFF, one of them doing just fine with wheezy based LCNC 2.7.x. However I could not find another at the time being to serve as a backup and is first gen core based. So I started to look around for something newer. Based on some posts in this forum and what was available in numbers plus probably a couple more years. I purchased a hp 8300 elite desktop and agreed with the seller that he reserve 3 more units for me. The test results looked OK . but the dealer did not keep the served units (Grrrr!) and elsewhere not a single unit was available anymore. Fujitsu Esprimo Q920s where widely available then. It gave very promising test results , but they do not have parallel ports. They also vanished from the market as a I looked again. I tested other pc's with deceiving results and then two more Dell 980 were available for no money. So be it then for now: Dell OptiPlex 980.

b) Bios
I tweeked the Bios settings, which I will post in another thread, yet to be opened later on. For the time being and to set focus on the stuff to be discussed in this thread, I disabled audio in the bios. Booting "stock" kernels, there were no "snd" modules loaded and while running lcnc-hw, there was no audio output (see here for the 4 core desktop version of the 980).

c) Os
I checked out the os to use. As tommylight pointed out here , debian has a bit better latency than mint. My rudimental tests confirmed this, also Himarc3D came to the same conclusion here . So I decided to stick with debian buster.

d) Kernel
Note: If I talk of stock kernels here, they are off course rt kernels as required for 2.8.0.
Then I started to look in to the best suited kernel. I tested some 5.x kernels with rather disappointing results if compared to 4.x kernels. Thus I decided to stick with 4.x kernels for the time being. BeagleBrainz came to the same conclusion here .
BeagleBrainz pointed me to his kernels and encouraged me to try these. BeagleBrainz's kernels are optimised by him for latency and aimed at Mint. As said before, I intend to stay with debian, but tommylight hinted they should run with debian too.
So I started to play with BeagleBrainz's kernels. My feeling is, they are promising. Thus I am interested and willing to help sort out some problems these kernels may have. I got some surprises which were not observed using stock kernels:

1. real time delays on basethread, see here . after preventing the sound modules from being loaded ( see here ), the rt errors were gone, so I consider this solved. However partially only:
2. a miraculously appearing audio device, :
   At first, I was not able to track what was loading the module. "dmesg | | grep -Ei "snd|audio|sound"" just returned nothing. Proofed, dmesg was cluttered with "evbug" messages (see below). Once the loading of evbug was omitted, I could see the process loading the sound module in dmesg:

   dmesg | grep -Ei "snd|audio|sound"
   [    0.334838] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)

   Tommylight observed that a hdmi onboard device cannot be disabled. Preventing the loading of the subsequently triggered kernel modules can be looked at as a solution, but it remains unclear what triggers the appearance ofthe device itself. I'd like to understand and solve this for good. Puzzling is also, that device is named "Lenovo" while everything in this machine is definitely *NOT* Lenovo!
3. evbug module loaded (see here) . It can be blacklisted and BeagleBrainz promised bake new kernels without evbug module enabled, see below (thank you). So I consider this solved, too.

e) Desktop environment
For my daily duties, I use OpenSuSe with Kde/Plasma. Had that with wheezy based LCNC 2.7.x too. Reading up in the forum here, Xfce seemed to be proposed by many. Testing Mint, Mate came into play too. tommylight pointed out here , that Xfce provides better latency than mate under Mint. I assume he is right. I tested Xfce and Kde here and as I am used to Kde (though I know, not reall light weight) plus a bit better latency results, I will stick with Kde for now at least.

f) Remaining steps
Select the "best" kernel
Play with boot parameters
Clean up services (stop everything not needed)

Update as of Sep. 30th 2020

d) Kernel
As tommylight and BeagleBrainz indicated, rtai kernels are still around. I'll look into that.

Rebuilding kernel without evbug, will post links.

To everyone else, this is just a test kernel, not for production use. Do not use. If you do you are on your own, there is a possibility it may randomly and successfully divide by zero and cause Bad Stuff (tm) to happen.

Kernel, headers & libcdev are here

cnc.beaglebrainz.net/seuchato/

BB

What would you like me to do?
I do write some engineering applications using C++, but I am definitely no kernel hacker. Still: I am willing to help, as your kernels give the lowest servo thread values initially. They do rise later though and I would guess, you have them optimised for servo not (yet?) for base thread.

greez
chris

I recompiled the kernel without the evbug module.
It should help with latency on your 980 as it shouldn't be spamming the syslog with event debugging. Why it loads on your machine I really can't sure.

As for the following, I'd posit that the PCI-ID matches that of some Lenovo Hardware.
Which is likely related to this:
patchwork.kernel.org/patch/10533087/

Can't really figure out what this means, but the very message is included here:

code.woboq.org/linux/linux/drivers/acpi/osi.c.html

Thx for recompiling the kernels. Downloading now, will try it at lunchbreack.

Jfyi: Stock 4.19.0-11-rt-amd64 is now running lcnc-hw:

we are some 10 minutes short of completing the run. As you can see, that "OSI" thingy sees the "Lenovo-NV-HDMI-Audio" but during the run of lcnc-hw no sound modules are loaded. In addition: there are no snd modules "fake installed", else there would be a file named "snd.conf" in /etc/modprobe.d. Weird isn't it?

greez
chris

Short short short version, it's a BIOS workaround for the hdmi audio.

Good explanation here as to why this might be needed:
unix.stackexchange.com/questions/246672/...arameter-in-the-grub

Can confirm: evbug is not started, even if *NOT* fake installed:
However sound modules are installed, see above.

Will run lcnc-hw now and see what we get there.

Greez
chris

PS: There must be something different other than your optimisation that triggers the loading of the sound modules in your kernel as opposet to sockj kernels tested. But what? How can this be traced?

Been looking up your link and surfed here , see post of N0madK, Message 4 of 5. I subsequently added "acpi_osi=!Linux-Lenovo-NV-HDMI-Audio", which prevents the previously reported "ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)". But snd modules still get loaded:

So, still no joy.

greez
chris