Posts by nst

nanohcv wrote:

Ja das cxd2099 Modul wurde nicht gefunden und ddbridge hängt nur von dvb-core ab.

Dann ist schlicht kein Treiber da, der Dein CI bedient (das ist ziemlicher Murks, wenn die Distro das nicht mitcompiled, das liegt aber ausschliesslich im Einflussbereich der Distromaintainer...). Gibts in Fedora evtl. sowas wie ein "kernel-staging-modules" Package?

EDIT (schon wieder): Ja, gibts: "kmod-staging" in RPMFusion. Siehe auch https://ask.fedoraproject.org/…le-rts5139-kernel-module/ (anderer Treiber, gleiches Problem).

dddvb sollte das Problem aber nicht mitbringen.

nanohcv wrote:

Unter 4.13 und dem aktuellen dddvb git (87246de124e4a7939dee4b4b71248a52c9c6893) geht es aber auch nicht mehr.

In dem Fall bitte das Problem direkt beim DD-Support einkippen. EDIT: Was mir zu

noch einfällt: Das ist ein Sony CXD2099AR basiertes CI-Flex. Du solltest mal checken, ob Dein Kernel das cxd2099 Modul mitbringt ("modinfo cxd2099") und/oder ddbridge davon abhängt ("modinfo ddbridge", depends: sollte "dvb-core,cxd2099" oder umgekehrt ausgeben). Wenn das NICHT da ist, bringt Deine Distro evtl. keine Staging-Module mit. Mit dem upstream-Code sollte das dennoch laufen, deshalb der Support-Hinweis.

Mahlzeit,

gestern war offenbar mal wieder "Merge-Day" im media_tree, dabei wurden die ddbridge-0.9.32 Patches mitgemerged. Die Changes werden in Linux-4.16(rc1) landen. Einen wirklichen Grund, darauf zu warten, gibts aber eigentlich nicht, dddvb-0.9.31->0.9.32 war im Tunerkartenbereich nur 'ne Aufräumaktion.

Passend hab' ich gestern abend alles zurechtgerückt (dddvb-linux-kernel komplett rebased und alte Branches gekillt, media_build upgedated). Gegen Kernel <=3.13 (u.a. Trusty Stock Kernel) gibts derzeit noch ein Problem mit 'nem Backport Patch (kommt noch) und der pvrusb2-Treiber ("Hauppauge WinTV-PVR USB2 support") ist zumindest temporär hinten rüber gefallen, sonst sollte aber erstmal alles passen.

Viel Spass,

nst

SurfaceCleanerZ meinte evtl. die aktuelle Inkompatibilität der DD-Hardware auf ASRock Apollo Lake Boards, in der Form, dass die Karten nach kurzer Zeit Probleme auf dem PCIe Bus kriegen und sich von selbigem verabschieden. Wichtig: Es sind offenbar wirklich nur ASRock Boards involviert, ASUS Apollo Lake Boards laufen allem anschein nach problemlos. Nichtsdestotrotz: YMMV!

beinhart wrote:

na da wart ich doch gerne ...

Habe gestern alles upgedated und rebased. Wenn du "mediatree/master-ddbridge" installieren willst, brauchst Du aus dem media_build den "buildall-ioctl" Branch (bitte beim Clone/Checkout beachten - der Einfachheit halber würde ich alles neu clonen). Hinweis: Gegen 3.11-3.16 einschliesslich könnte es derzeit Probleme geben, ich teste selbst aktuell nur gegen 4.13 bzw. 4.14rc.

3 = Bitmaske, Bit 0 (1) = Pagecache, Bit 1 (2) = Dentries and Inodes. Auf https://unix.stackexchange.com…d-cache-on-a-linux-system gibts 'ne ausführliche Erklärung

... oder bis heute abend warten, bis ich auf den aktuellen media_build upstream rebased hab, da sind die passenden Fixes schon drin.

crow wrote:

Ohne Virtualisierung und Passthrough wird die karte richtig erkant (gleiche Hardware und gleiche OS und Kernel) und /dev/dvb/adapter0 wird auch erstellt.

Gut, dann gibts mit Karte und Treibern keine Probleme. Dein Fehler wird irgendwo beim Routing vom Host zur VM auftreten. Bitte separaten Thread aufmachen,

das hat mit den DD Treibern nichts zu tun.

crow wrote:

dvb-fe-tool findet keine signal werte obwohl LNB (Astra 19.2) mit Tuner1 verbunden ist.

Wenn der Demod nicht instruiert wird, einen Sender zu empfangen (durch VDR, oder irgendeine andere Userspace-Software), liegen auch keine Signalstatistiken an.

crow wrote:

Code

1. [root@vdrserver ~]# uname -a
2. [root@vdrserver ~]# modinfo ddbridge
3. filename: /lib/modules/4.13.9-1-ARCH/kernel/drivers/media/pci/ddbridge/ddbridge.ko.gz
4. version: 0.5

Aktualisierte Bridge mit MSI Support usw. gibts erst ab 4.14. Deine Karte sollte aber auch mit 4.13 laufen (und sogar davor; für die Akten: Meine DVB-C+DVB-T Hardware läuft im Server derzeit mit 'nem Stock 4.13er Kernel ohne Out-of-Tree-Module). Ich würde erstmal ohne Virtualisierung und Passthrough testen, wenn die Karte dann läuft, liegt Dein Problem im Virtualisierer (das ist dann aber kein Treiberproblem mehr).

Grillbert wrote:

Hier wird behauptet dass der neue Treiber (387.12) mit 4.14 RC3 ohne Patches läuft - ich habe es aber leider nicht hinbekommen.

Ich scheine auf meinem Intel System auch in diese DRM Problematik zu laufen und habe das nicht aufgelöst bekommen

Code

1. FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'sme_me_mask'

(evtl meinen sie mit "AMD" alle amd64 Systeme?)

Die Lösung liegt vermutlich in dem Satz "The workaround – for the time being – is to de-select this feature in the Kernel config…." - da fehlt mir aber das Wissen wie ich das machen.

Display More

Genau daran scheiterts im Augenblick. Ich hab an anderer Stelle versucht, das aufzulösen (u.a. nach einem Hint, wie das jemand auf OpenSUSE gelöst bekommen hat), vergebens. Wahrscheinlich erfordert das am Ende, angepasste Kernel Images zu basteln (und das ist einer der Gründe, wieso ich selbst keine Binärdistro benutze). Das könnte mit Ubuntu 18.04 putzig werden, wenn NVIDIA und Kernel-Maintainer sich nicht einig werden oder NVIDIA keine Anpassungen am Blob vornimmt, siehe auch https://www.spinics.net/lists/linux-arch/msg41946.html

Du könntest noch 4.13 oder 4.12 probieren und dann den bekannten media_build Weg testen, um die DD-Treiber (mit oder ohne IRQ Test) ins System zu kriegen.

Sorry für das Theater...

Irgendwie erschliesst sich mir derzeit nicht, was jetzt wirklich irgendwas verbessert... Fakt ist auf jeden Fall, dass die NVIDIA BinBlobs derzeit mit neuen Kernel-Versionen absolut keinen Spass machen (im Sinne von: Funktioniert nicht).

Olsche wrote:

Aktueller Stand ist, dass der Rechner mittlerweile seit Montag mittag ohne jedes Problem mit MSI=1 läuft.

Klingt schonmal super. Ich denke im Moment aber, dass das eher im Kernel Upgrade begründet ist, basierend auf Feedback von anderer Stelle...

jasminj wrote:

Aber ned für den Test!

Die Testerei ist derzeit NUR für IRS UNGLEICH ffffffff (vgl. Olsche - 00000003) bei I2C Timeouts interessant. Bus Fehler haben mit dem IRQ Handling nichts zu tun.

Nabend zusammen,

kurze Zwischeninfo: Wenn ddbridge anfängt, I2C Timeouts ins Kernellog zu loggen, und hinter "IRS" steht "ffffffff", bedeutet das zu 99% nicht, dass zu irgendeiner Zeit Interrupts (egal, ob MSI oder Legacy/PIN based - msi=0) verloren gegangen sind, sondern dass die Kommunikation zwischen PCIe-Bus und Karte weggeschmiert ist (ffffffff = Fehler beim Lesen von IOMem). Die zuletzt hier verlinkten Branches/Patches beheben das NICHT. In diesem Fall bitte zuallererst ein aktuelles Kernelimage installieren, vor allem, wenn ziemlich aktuelle Hardware (Apollo Lake Celerons usw.) mit alten Kerneln (3.13, 4.4 usw.) zum Einsatz kommt.

Für Ubuntu (auch yaVDR) und Debian gibts passendes im Ubuntu Kernel PPA:

http://kernel.ubuntu.com/~kernel-ppa/mainline/

Bitte nach Möglichkeit 4.14 installieren (ja, ist Stand Heute noch rc(6)), das erspart auf jeden Fall weitere Basteleien mit den DD Treibern mit Handkompilieren, DKMS Packages usw.

nst

Grillbert wrote:

Ich hoffe ich schaffe es in den nächsten Tagen mal ein bisschen Leerlauf zum Schrauben und Testen zu finden.

Wenn Du anfängst zu testen, mach mal bitte erstmal nur einen Schritt: Entweder erst die irqtest-Treiber installieren, oder erst ein Kernel Image vom Ubuntu PPA installieren. Erst den zweiten Schritt "dazu", wenn nach dem Ersten weiterhin Probleme auftreten.

Hast Du jetzt nur das nackte Kernel Image installiert, oder auch schon den linux_media Kram mit dem IRQ Refactoring installiert? (vgl. ddbridge-0.9.31intermediate-integrated vs. ddbridge-0.9.32-integrated-irqtest[hab das Versionstag-Update nicht gepusht])

Abend zusammen,

und - Ping Grillbert   Olsche (ich zieh die I2C Timeout Diskussion mal vom dkms Thread weg, das gehört da nicht hin)

Ich würde Euch Zwei bitten, etwas Testcode auf Euren I2C-Timeout-geplagten Systemen auszuprobieren. Ich hab das IRQ Handling etwas refaktoriert, ob es allerdings wirklich was bringt, weiss ich nicht (und mittlerweile zweifel' ich immer mehr dran), aber die kleine Chance und so... Also:

Bitte haltet ein Backup von /lib/modules/kernelversion bereit, was Ihr bei Bedarf zurückkopieren könnt, oder sorgt sonstirgendwie dafür, dass Ihr die Kernelmodule vom laufenden Kernel wiederherstellen könnt. Am Besten Auf jeden Fall vorher jegliche DVB-Treiber DKMS-Pakete deinstallieren. Und bitte auch sowohl msi=0 als auch msi=1 testen.

Ich bin gespannt...

Olsche

Patches/Tests werden noch was dauern. Kannst Du in der Zwischenzeit mal 'n ganz aktuelles Kernelimage von

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14-rc5/ bei Dir testen, mit msi=1 und 0 (Achtung, 0 ist default), und mit beiden Tunern? Möglicherweise fehlen im 4.4er noch irgendwelche Quirks für Deinen Chipsatz. Achso, und vorher das DKMS deaktivieren oder deinstallieren, das ist alles im Image drin.

EDIT: Irgendwie geht das hier grad ziemlich heftig am eigentlichen Topic vorbei... Falls ein Mod vorbei kommt, sollte das mal gesplittet werden... Sorry.

EDIT2: Die Timeoutproblematik geht hier weiter. Back to Topic (media-build-dkms).

Olsche wrote:

Code

1. CPU0 CPU1 CPU2 CPU3
2. 23: 2178 75299869 0 0 IO-APIC 23-fasteoi ddbridge

Danke, interessant. Ich teste hier gerade was (altes P35 C2D Board, zwei DD-Karten - CTv6 und CI Duo Bridge), mit msi=0 ist mir die CTv6 hier auch abgeschmiert. Die zwei Karten sind zwar zum Resource/IRQ-Sharing mit anderen Board-Komponenten gezwungen, aber auf dem "CTv6-Interrupt" ist totenstille, während auf dem "CIDuo-Interrupt" ein Device fröhlich Aktivität generiert (letztere ist dabei noch nie kaputtgegangen).

Olsche wrote:

Kurzer Zwischenstand, nachdem ich immer noch kein Windows installiert habe. Seitdem ich nur einen Tuner der S2 benutze, hatte ich keinen Timeout mehr. Wenn du obige Ausgabe auch mit zwei Tunern benötigst, aktiviere ich ihn kurzzeitig wieder.

Nein, Sekundärtuner oder zusätzliche Flexmodule belegen keine weiteren PCI(e) Resourcen.
Was anderes: Kriegst Du es ggf. hin, Kernel/Treiber zu Patchen und neu zu compilieren?

Könnte einer (oder auch mehrere) der auch und vor allem mit msi=0 von I2C Timeouts betroffenen mal die Ausgabe von "cat /proc/interrupts" posten?