ya_usbir + "BUG: unable to handle kernel paging request"

  • Hallo,


    ich habe yavdr 0.5 am laufen. Basis ist ein AMD E350 System mit zusätzlicher Nvidia-Karte + Kernel ZFS. Seitdem ich einen yausbir v3.0 angeschlossen und als Empfänger und Transmitter konfiguriert habe ist das System instabil. Wenn man irgend eine Fernbedienung eine Weile benutzt bleibt das System komplett stehen. Es ist dabei egal ob die Codes der Fernbedienung dem System bekannt sind oder nicht.


    Wenn ich den lircd ohne den yausbir-Treiber laufen lasse ist es wieder stabil. memtest findet keine Fehler. Kennt jemand für das Problem eine Lösung? Gibt es einen verbesserten Treiber für den lircd?


    Viele Grüße


    Frank


    Hier mal die Logs von zwei Abstürzen:



    Code
    kernel: [ 1839.068521] BUG: unable to handle kernel paging request at 00000000ff7f0d01
    kernel: [ 1839.068543] IP: [<ffffffff811642fb>] __kmalloc+0x7b/0x190
    kernel: [ 1839.068565] PGD 0 
    kernel: [ 1839.068574] Oops: 0000 [#1] SMP 
    kernel: [ 1839.068585] CPU 1 
    kernel: [ 1839.068589] Modules linked in: bnep rfcomm nfsd nfs lockd fscache auth_rpcgss drm_kms_helper drm nfs_acl sunrpc i2c_algo_bit ext2 rc_dib0700_rc5 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec dvb_usb_dib0700 dib7000p dib0090 snd_hwdep dib7000m snd_pcm dib0070 dvb_usb snd_seq_midi snd_rawmidi dib8000 ir_lirc_codec snd_seq_midi_event lirc_dev dvb_core snd_seq ir_mce_kbd_decoder ir_sony_decoder snd_timer nvidia(P) ir_jvc_decoder snd_seq_device ir_rc6_decoder dib3000mc sp5100_tco ir_rc5_decoder snd ir_nec_decoder rc_core dibx000_common btusb soundcore psmouse bluetooth snd_page_alloc joydev i2c_piix4 serio_raw k10temp mac_hid acpi_ipmi ipmi_msghandler acpi_pad sbs sbshc pci_slot video acpi_power_meter f71882fg lp parport zfs(P) zcommon(P) znvpair(P) zavl(P) zunicode(P) spl(O) zlib_deflate dm_crypt hid_logitech ff_memless raid10 raid0 multipath linear vesafb hid_cherry usbhid hid raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx rai
    kernel: d1 r8169 pata_atiixp
    kernel: [ 1839.068796] 
    kernel: [ 1839.068806] Pid: 1, comm: init Tainted: P           O 3.2.0-35-generic #55-Ubuntu MSI MS-7698/E350IA-E45 (MS-7698)
    kernel: [ 1839.068821] RIP: 0010:[<ffffffff811642fb>]  [<ffffffff811642fb>] __kmalloc+0x7b/0x190
  • ich habe yavdr 0.5 am laufen. Basis ist ein AMD E350 System mit zusätzlicher Nvidia-Karte + Kernel ZFS. Seitdem ich einen yausbir v3.0 angeschlossen und als Empfänger und Transmitter konfiguriert habe ist das System instabil. Wenn man irgend eine Fernbedienung eine Weile benutzt bleibt das System komplett stehen. Es ist dabei egal ob die Codes der Fernbedienung dem System bekannt sind oder nicht.


    Das ist aber kein yaVDR-Thema. Das ist ganz offensichtlich ein Treiber- oder Kernel-Problem. Weder Treiber noch Kernel kommen von uns.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Solche komplett Stehenbleiber hatte ich damals auch.


    Bin da Lösungsorientiert rangegangen und habe mich von dem yausb Teil getrennt.


    Munter bleiben, Rossi

  • Solche komplett Stehenbleiber hatte ich damals auch. Bin da Lösungsorientiert rangegangen und habe mich von dem yausb Teil getrennt.


    Was gibt es denn Empfängertechnisch für eine Alternativlösung?



    Das ist aber kein yaVDR-Thema.


    Wenn dem so ist möchte ich einen Moderator bitten das Thema an die richtige Stelle zu verschieben.


    Wer kann mir sonst helfen den Bug zu finden?


    Das ist ganz offensichtlich ein Treiber- oder Kernel-Problem. Weder Treiber noch Kernel kommen von uns.


    Ich habe mir mal den lirc in der Version 0.9.0-0yavdr0~precise vorgenommen. Im Vergleich mit der Ubuntu-Version ist da ja unter anderem der ya_usbir-Treiber hinzugekommen. Den habe ich auf die aktuelle Version aktualisiert. Leider bleibt damit das System auch stehen.


    Hat jemand eine Idee wie man das debuggen kann? Per Syslog könnten entscheidene Informationen verloren gehen.


    Viele Grüße


    Frank

  • Ich habe mal den debug-Code aktiviert und das Gerät an zwei verschiedenen USB-Controller ausprobiert. Ich bekomme oft die Meldungen:


    yaUsbIr: Interrupt read (64: Resource temporarily unavailable) (could not get bound driver: No data available).
    yaUsbIr: error reading, device went offline


    Im Code wird vorher die Funktion "usb_interrupt_read" aufgerufen.

  • _frank,


    Das ist ein Fehler in der LibUSB! Dort ist der Fehler zu suchen, ich kenne yaVDR selber nicht und kann den Fehler auf allen Systemen die ich hier habe nicht nachvollziehen. Auf meine Clients habe ich hier LibUSB 1.0.9-3.1.2.


    Aber wie ich an der Fehlermelung hier sehe

    yaUsbIr: Interrupt read (64: Resource temporarily unavailable) (could not get bound driver: No data available).

    hast du schon im Code

    Code
    int rawhidrecv(raw_hid *hid, void *buf, int len, int timeout)
    {
    	int r;
    	if (hid==NULL) return -1;
    	r = usb_interrupt_read(hid->usb, hid->ep_in, (char*)buf, len, timeout);
    	if (r >= 0) return r;
    	if (r == -110) return 0;// timeout
    	//logprintf(LOG_NOTICE,"yaUsbIr: Interrupt read (%d: %m) (%s).\n", r, usb_strerror());
    	return -1;
    }


    die logprintf-Zeile eindokumentiert. Wird denn lirc-0.9.0_ya_usbirv2.diff..tar.gz verwendet?


    Grüße Uwe

    Multiroom-System:
    Server: ASRock J4105, openSUSE Tumbleweed, 14TB HD, Cine S2 (4Tuner), vdr2.4.0, streamdev-server

    FullHD-Client1: Zotac ZBOX HD-ND22, openSUSE 13.1, vdr2.2.0, streamdev-client, xineliboutput, IR-Empfänger/Sender/Einschalter yaUsbIR V3.5
    FullHD-Client2: Zotac ZBOX HD-ND22, openSUSE 42.1, vdr2.2.0, streamdev-client, softhddevice, IR-Empfänger/Sender/Einschalter yaUsbIR V3.5
    Test-Client: ASRock B85M, openSUSE Tumbleweed, vdr2.4.0, streamdev-client, softhddevice, IR-Empfänger/Sender/Einschalter yaUsbIR V3.5

  • Uwe:


    Danke für die schnelle Antwort das hilft mir sehr gut weiter. Auf dem System sind die Versionen 1.0.9~rc3-2ubuntu1 und 0.1.12-20 installiert. Lirc ist gegen die 0.1-Version gelinkt. Ich werde mal schauen die lirc-Build-Scripte so umzubauen dass es die 1.0-Version benutzt. Ich hatte vorher noch mit dem FDTI-Empfänger rumgespielt. Der hatte arge Probleme mit dem Timing. Das könnte dann die gleiche Ursache sein.

  • Danke nochmal Uwe für die Mithilfe. In der Debian/Ubuntu-Welt wird noch eine veraltete Version von libusb 0.x als Parallelinstallation zur Version 1 genutzt. Es gibt inzwischen eine Kompatibilitätsschicht für die Version 0.x die direkt mit libusb 1 zusammenarbeitet.


    Nach den folgenden Schritten wurde das System bei mir stabiler. Getestet habe ich das auf zwei Systemen.


    Code
    # sudo apt-get install libusb-1.0-0-dev
    # wget "http://downloads.sourceforge.net/project/libusb/libusb-compat-0.1/libusb-compat-0.1.4/libusb-compat-0.1.4.tar.bz2"
    # tar -xjf libusb-compat-0.1.4.tar.bz2
    # cd libusb-compat-0.1.4
    # ./configure
    # make
    # sudo make install
    # sudo ln -s /etc/ld.so.conf.d/libc.conf /etc/ld.so.conf.d/1-local.conf
    # sudo ldconfig
    # sudo service lircd restart
  • Ich konnte noch diese Fehlermeldung per stderr vom lirc vor einem Absturz entlocken. Ich werde mal versuchen eine andere Distribution zu nehmen oder lirc und libusb komplett neu zu bauen.


    Code
    libusb:error [libusb_cancel_transfer] cancel transfer failed error -5
    libusb:warning [handle_timeout] async cancel failed -5 errno=22
  • Ich habe nun noch einmal mit einer kompletten Neuinstallation und auf anderer Hardware die Probleme nachgestellt. Mit openSUSE und einem selbst gebauten lirc gibt es keine Abstürze. Danach habe ich yavdr installiert und nach einiger Zeit und IR-Aktivität bleibt das System stehen. Mit der Lösung von Beitrag 8 läuft das System.

  • Hallo,


    danke an _frank für die Beschreibung und Analyse! Ich bin nach obiger Anleitung vorgegangen bei der Installation von libusb-compat, allerdings habe ich libusb-compat-0.1.5 genutzt, die mittlerweile erschienen ist (ohne zu wissen, welche Unterschiede bestehen zwischen den Versionen). Trotzdem treten die Freezes bei mir weiterhin auf (Mainboard ist AsRock B75-Pro3M, für Details siehe auch meinen Thread: Freezes bei AsRock B75-Pro3M / Cine S2 V6.2 / yaUsbIr v3).


    Hat jemand von Euch hier evtl. neue Erkenntnisse?


    Vielleicht habe ich ja auch einfache Fehler gemacht und libusb-compat bleibt ungenutzt auf dem System? Muss das Ubuntu-Paket libusb-0.1 deinstalliert werden, so wie hier beschrieben?
    http://libusb.6.n5.nabble.com/…usb-compat-td3312325.html
    https://bugs.launchpad.net/ubu…sb/+bug/991004/comments/2
    Ich bin ansonsten nach seahawks super-Anleitung vorgegangen: yaUsbIr V3 und yaVDR


    Viele Grüße
    hepi

  • Hallo hepi,


    sorry ich hatte vergessen das "gelöst" aus dem Betreff zu entfernen. Die Abstürze konnte ich damit reduzieren aber nicht beseitigen. Seit dem bediene ich den VDR über eine Android-App und die Web-Oberfläche. Ich werde demnächst (irgend wann) den VDR neu aufsetzen. Für den Fernbedienungsempfang wird "FLIRC" http://www.flirc.tv/ zum Einsatz kommen. Ob ich yavdr als Basis nehme habe ich auch noch nicht entschieden.


    Abschließend: yausbir ist genial funktioniert aber nicht mit yavdr und ubuntu 12.04


    Viele Grüße


    Frank

  • Ich suche eher eine Distribution die nicht so viel an Komponenten austauscht damit man bei solchen Fehlern sich auch an die Distribution wenden kann anstatt über Zuständigkeiten zu diskutieren (s. gda vom 1. Januar).


    Im beiderseitigen Interesse begrüße ich deine Entscheidung und wünsche ich dir dabei viel Erfolg, toi, toi, toi.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Hallo Gerald,


    sorry. Da habe ich mich im Ton vergriffen.


    Im yavdr sollte zumindest die Unterstützung für diesen Empfänger deaktiviert werden bis libusb1 zum Einsatz kommt. Das Erspart vielen anderen Fehlersuche.


    Viele Grüße und ein schönes Wochenende,


    Frank

  • Im yavdr sollte zumindest die Unterstützung für diesen Empfänger deaktiviert werden bis libusb1 zum Einsatz kommt. Das Erspart vielen anderen Fehlersuche.


    Ich wüsste nicht, wie man selektiv die Unterstützung für die Version 3 des yaUsbIr deaktivieren könnte. Die ersten beiden Generationen laufen ja soweit ich weiß (ich habe selbst auch noch einen yaUsbIr V1, der sich komplett unauffällig an mehreren yaVDR/Ubuntu 12.04 Rechnern verhält) ohne Probleme (und dafür ist die gepatchte lirc-Version, die wir aktuell in main anbieten auch ursprünglich gedacht gewesen).


    Den yaUsbIr V3 hatte ich bislang nur an Testrechnern, die keine allzu große Uptime erreichen.


    Kannst du evtl. nochmal genau beschreiben mit welchen Kombinationen von lirc und libusb du die Probleme unter Ubuntu 12.04/yaVDR 0.5 hattest?
    urknall aus dem Team klang am Mittwoch mit der Kombination aus libusb 1.0.15-1 mit dem lirc-Paket aus unstable-main (https://launchpad.net/~yavdr/+…10/+listing-archive-extra) nach dem ersten Tag Dauertest recht zuversichtlich - wenn das klappt wird das sicherlich über kurz oder lang in unseren PPAs landen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moin,


    da ich hier zwei v3 problemlos am laufen habe, fände ich einfach deaktivieren jetzt nicht wirklich toll ;)


    Gruß S.

  • Wie gesagt ich sehe keinen Sinn darin da was rauszunehmen, das ist ein schönes Stück Hardware und wenn es Treiberprobleme im Zusammenspiel mit bestimmten USB-Controllern gibt, muss man die halt beheben, bis es möglichst bei jedem rund läuft.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Im yavdr sollte zumindest die Unterstützung für diesen Empfänger deaktiviert werden bis libusb1 zum Einsatz kommt. Das Erspart vielen anderen Fehlersuche.


    Genau anders herum ist es richtig. Je mehr über diesen Fehler stolpern, desto größer ist die Chance jemanden zu finden, der den Fehler findet und behebt. Da ich persönlich diese Hardware nicht einsetze, muss die Fehlerbehebung von anderen kommen.
    Deaktivieren wir diese Hardware, dann ist der Aufwand für diejenigen die den Fehler suchen wollen zu hoch.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Hallo,


    wenn auch die Version 3 grundsätzlich stabil funktioniert scheint es eine Sache zwischen Chipsatz und dem yausbir v3 zu sein. Oder gibt es unterschiedliche Softwareversionen des yausbir? Meine Version ist eine der ersten. Deswegen hatte vielleicht auch der Tausch der libusb wenig/nichts gebracht. Ich habe vor meinen VDR Rechner auszutauschen. Kandidat wäre ein B85-Board. Hoffentlich ist das Kompatibel.


    Viele Grüße


    Frank

  • Übrigens bei mir verursachte die besagte v3 auch Freezes. Mit der Compat Version von libusb gefühlt selten aber dennoch unerträglich. Aktuell habe ich yausbir bis auf weiteres abgeschaltet und nutze wieder cir.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!