DVB-S Hauppauge Nexus-S rev. 2.1 problem

jojoax · January 28, 2008 at 12:36 PM

Moin,
ich hab hier ein (K)ubuntu basierendes VDR System mit Remote-Boot von einem Server, vdr Verzeichnis von einem Server mit Raid etc. aufgebaut.

Seitdem ich das eTobi.net Paketarchiv (eigentlich für Debian etch) nutze, bekomme ich bei Aufzeichnungen, aber auch mal bei normalem "Guck" Betrieb, diesen Fehler:

Code

... 
Jan 28 12:19:39 vdr kernel: [ 1364.368080] dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Jan 28 12:19:39 vdr kernel: [ 1364.368118] dvb-ttpci: av7110_fw_cmd error -110
...
Jan 28 12:19:48 vdr kernel: [ 1373.184434] saa7146_i2c_writeout: timed out waiting for end of xfer
...

Das am Video (FBAS) Ausgang anliegende Signal friert ein und der vdr oder/und dvb-s treiber dvb-ttpci ist tot.

Die Hardware der Maschine ist:

Code

root@vdr:~# lspci
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
01:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev c0)
01:0b.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)


root@vdr:~# cat /proc/interrupts
           CPU0       CPU1
  0:        498          0   IO-APIC-edge      timer
  1:          2          0   IO-APIC-edge      i8042
  8:          7          0   IO-APIC-edge      rtc
  9:          0          0   IO-APIC-fasteoi   acpi
 14:         25          0   IO-APIC-edge      libata
 15:          0          0   IO-APIC-edge      libata
 16:          0          0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
 17:     418497          0   IO-APIC-fasteoi   uhci_hcd:usb2, eth0
 18:          3          0   IO-APIC-fasteoi   uhci_hcd:usb3, ohci1394
 19:        167          0   IO-APIC-fasteoi   uhci_hcd:usb4, HDA Intel
 20:    3773945          0   IO-APIC-fasteoi   saa7146 (0)
NMI:          0          0
LOC:     669984     903815
ERR:          0
MIS:          0
root@vdr:~#

Display More

So allmählich nervt das unglaublich und ich fange an zu verzweifeln.
Das dvb-ttpci lässt sich nicht mehr entladen, die einzige Abhilfe ist ein Neustart.

Irgend eine Idee, wo ich noch gucken kann ?

Jojo

Dr. Seltsam · January 28, 2008 at 6:01 PM

ich habe auf einem neuen Board (Via K8M800-Chipsatz) jetzt das gleiche Problem mt einer FuSi DVB-C.

Hast Du wirklich nur vdr-Pakete erneuert, keinen Kernel?

Lässt sich das Problem mit einem Downgrade der vdr-Version beheben?

Was für eine CPU? SMP-Kernel?

jojoax · January 31, 2008 at 9:36 AM

Moin,
Ich hab mir hier den standard distri kernel(rt) von Gutsy installiert:

Code

root@vdr:~# uname -a
Linux vdr 2.6.22-14-rt #1 SMP PREEMPT RT Mon Oct 15 01:05:51 GMT 2007 i686 GNU/Linux

Der Das problem könnte im Kernel liegen, so hab ich testhalber mal ohne ACPIC
und APIC laufen. Ergebnis wurde besser, aber noch nicht gerade zufriedenstellend.

Ich boote übrigens ohne Harddisk via dhcp und tftpd von einem server aus.
So ist das Teil mega leise und es kann auch nix kaputt gehen.

Code

root@server:/# cat /tftpboot/pxelinux.cfg/C0A80B3B
MENU TITLE VDR Netzboot
DEFAULT vdr
PROMPT 0
TIMEOUT 1
LABEL vdr
MENU LABEL VDR Ubuntu Gutsy 2.6.22-rt
KERNEL ubu2622rt.bzi
APPEND initrd=ubu2622rt.dsk rw locale=de_DE root=/dev/nfs  nfsroot=192.168.11.1:/tftpboot/rootfs/ubuntu-gutsy/vdr,v3 noapic noacpi
IPAPPEND 1
root@server:/#

Display More

Weil ich eben leise und remote boote, is das Ding auch recht störunanfällig, eben bis auf das aufhängen der Nexus Karte...

Ich probiere mal den i386 Kernel von Gutsy aus... hmm.
Aus das bauen eines eigenen Kernel wollte ich verzichten, weil Remote Boot ... am liebsten wäre mir halt der original Kern der Distri.

Jojo

Dr. Seltsam · January 31, 2008 at 9:46 AM

Hast Du einen Doppelkern-Processor? Ist der Kernel mit SMP-Unterstützung kompiliert? Dann versuch mal die Kernel-Bootoption nosmp

Wenn das hilft, versuch ohne smp mal folgendes:

cat /proc/interrupts bei geladenem dvb-ttpci

notier den IRQ für saa7146 (z.B. 21)

dann sorge dafür, dass vor dem Laden von dvb-ttpci folgendes ausgeführt wird:

Code

echo 1 > /proc/irq/21/smp_affinity

Dann werden die interrupts fest der ersten CPU zugeordnet. Ist ein Tip von UFO und hat bei mir geholfen!

jojoax · January 31, 2008 at 9:47 AM

Nachtrag.

Ich hab über ein bereits laufendes System die eTobi Archive drüber installiert.
Hmm, eigentlich fingen damit die Hänger bemerkbar an.

Die VDR Version vom Gutsy war mir etwas "rudimentär".

Als Cpu hab ich

Code

Intel(R) Pentium(R) Dual  CPU  E2160  @ 1.80GHz

Dual Core mit SMP, ubuntu RT Kernel.

Ich probier die i386 Fassung als nächstes aus. Glücklicherweise einfach via Remote Boot ....

Jojo

Dr. Seltsam · January 31, 2008 at 9:47 AM

Quote
Original von jojoax
standard distri kernel(rt) von Gutsy installiert:
Code
root@vdr:~# uname -a
Linux vdr 2.6.22-14-rt #1 SMP PREEMPT RT Mon Oct 15 01:05:51 GMT 2007 i686 GNU/Linux

ist ein SMP-Kernel!

jojoax · January 31, 2008 at 9:48 AM

Yepp, klar ist das SMP Kernel, ist ja auch eine Dual Core CPU ...
Sind Dir da probs bekannt ?

Würd ungern einen Sonder-kernel kochen...
Jojo

Dr. Seltsam · January 31, 2008 at 10:05 AM

Quote

Original von jojoax
Yepp, klar ist das SMP Kernel, ist ja auch eine Dual Core CPU ...
Sind Dir da probs bekannt ?

siehe oben
da haben sich postings überschnitten

jojoax · January 31, 2008 at 10:09 AM

NOSMP Test läuft ... um 12:30 weiss ich, ob Dein Vorschlag hier Verbesserungen bringt - mal eine Aufnahme abwarten -.

mfG
Jojo

jojoax · January 31, 2008 at 12:20 PM

Mit der "NOSMP" Kernel Option hat das Ding gerade stabil aufgezeichnet.

Ich probiere mal

Code

modprobe dvb_ttpci
DVBIRQ=`cat /proc/interrupts |grep saa7146| cut -d: -f1|sed -e 's/ //'`
test -f /proc/irq/$DVBIRQ/smp_affinity && echo 1 > /proc/irq/$DVBIRQ/smp_affinity

in /etc/rc.local im vollen SMP Betrieb...

Schaun wir mal...
Jojo

jojoax · January 31, 2008 at 1:46 PM

Danke - Der Tipp funktioniert !
Jojo
PS:
Mein Shuttle Barebone incl. Gehäuse

PS2: wenn jmd. Tipp braucht, das VDR ebenfalls Netzwerk-gebootet zu machen, nur fragen

jojoax · January 31, 2008 at 1:49 PM

Nachtrag, funktioniert nicht stabil - hält nur länger durch.

Die "NOSMP" Option beim Kernelboot scheint zu helfen. Dann ist das system auch nicht mehr Multiprozessing, sprich noad tut sich schwerer ... ;<

jojo

Dr. Seltsam · January 31, 2008 at 5:33 PM

ich bin mir nicht sicher, ob es ausreicht, den smp_affinity-Befehl erst nach dem Laden des Treibers abzusetzen.

was mich auch wundert: wenn ich mit nosmp boote, habe ich bei der Abfrage cat /proc/interrupts nur auf einer CPU interrupts. Der IRQ ist dann 11.
Mit gebootetem SMP-Kernel hat die DVB-Karte den IRQ 21 und bei aktiviertem smp_affinity-Befehl werden interrupts auf beiden CPUs ausgewiesen.

jojoax · January 31, 2008 at 5:40 PM

das mit *vor* Treiberladen ist ja zu bewerkstelligen.

Ich probier es nachher aus.

Jojo

DVB-S Hauppauge Nexus-S rev. 2.1 problem

Participate now!

Users Viewing This Thread