Sundtek Support Forum

As mentioned first enable the feature again, I saw there were many changes not only sysvipc, sysvipc is very likely unrelated to what you really need or want. This won’t affect only us but also other software packages in a negative way. Android comes with its own software environment and they implemented another IPC mechanism.

By the way dream box also tried to disable sysvipc but they went back quickly years ago since they saw multiple drawbacks. Don’t force the removal of a standard unless it’s really officially deprecated and you really have to.

Please test re enabling it and loading the particular module which you are looking for

There are many other changes, I highly doubt enabling sysvipc will affect your plan. Doublecheck this with your team, if it really breaks something we can help with enabling the socket route within the driver for your system.

Don’t limit your system for no real reason.

Hi,

I do not recommend disabling `CONFIG_SYSVIPC`. Many Linux applications depend on System V IPC, and by disabling it you are stripping away a significant part of the standard Linux IPC functionality. Even embedded Linux set-top boxes commonly have `SYSVIPC` enabled. I would not remove it without a very good reason.

`CONFIG_SYSVIPC` provides System V shared memory, semaphores, and message queues. These interfaces have been part of Unix/Linux for decades and are still actively used. Shared memory in particular allows processes to exchange data efficiently without repeatedly copying large amounts of data between separate process buffers, which can save CPU time.

We also have an Android build of our driver that can operate without SYSVIPC, but Android uses different mechanisms for inter-process communication and shared memory. Alternatively, we can even use Unix domain sockets instead of SYSVIPC where necessary.

However, the fact that Android can work without System V IPC is not a good reason to remove it from a normal Linux build.

I see virtually no practical benefit in disabling `CONFIG_SYSVIPC`, while doing so unnecessarily reduces compatibility with existing Linux software.

If I would see the advantage of the removal I would have no problem with doing so - but limiting the system in that area doesn't look like a benefit to me.

Meine Kollegin hat Dir eine Email zugeschickt, der Tuner wird getauscht. Kein LED bedeutet wohl dass beim FPGA was nicht passt (kalte Lötstelle eventuell).

was geben folgende Befehle aus:

/opt/bin/mediaclient --testastra -d /dev/dvb/adapter0/frontend0

$ /opt/bin/mediaclient --testastra -d /dev/dvb/adapter0/frontend0
Testing Astra 19.2 Frequencies
DVBS
LO Band / 18V:
Checking for lock:
. [LOCKED]
LO Band / 13V:
Checking for lock:
.. [LOCKED]
HI Band / 18V:
Checking for lock:
. [LOCKED]
HI Band / 13V:
Checking for lock:
.. [LOCKED]
DVB-S2 ZDF HD / 18V
Checking for lock:
. [LOCKED]

Mit abgezogenem Netzteil:

$ /opt/bin/mediaclient --testastra -d /dev/dvb/adapter0/frontend0
Testing Astra 19.2 Frequencies
DVBS
LO Band / 18V:
Checking for lock:
. [LOCKED]
LO Band / 13V:
Checking for lock:
. [LOCKED]
HI Band / 18V:
Checking for lock:
..........
HI Band / 13V:
Checking for lock:
..........
DVB-S2 ZDF HD / 18V
Checking for lock:
..........


/opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0

$ /opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0
media scan tp: 0
Timed out after 1 seconds
Total found: 0 PMTs (incl. unknown 0x0000)
Scan finished after 0 packets (0 bytes)

Es hat die ganze Zeit während der Tests keine LED geleuchtet.