(kernel-)Bug DS18B20 ??

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Moinsen,
    ich versuch jetzt seit einigen Tagen das emonCMS meines Bruders in den Produktivbetrieb zu bekommen.
    Dazu gibt's ein C-Programm, das u.a. 10 DS18B20 Sensoren ausliest und die Daten per Web-API in das lokale EmonCMS einpflegt.
    Nach einiger Zeit (Rekord war bisher 10 Stunden) ist die Anwendung allerdings tot - sie hängt in einem read() von einem der Sensoren.
    Jetzt bin ich zumindest schon mal so weit, dass das Kernel-Modul Fehler in die messages schreibt.
    Daher meine Frage: kommt jemandem folgende Meldung bekannt vor oder kennt jemand dieses Verhalten?

    Spoiler anzeigen


    [ 3439.432222] Unable to handle kernel NULL pointer dereference at virtual address 00000004
    [ 3439.432262] pgd = cdda0000
    [ 3439.432276] [00000004] *pgd=19ee8831, *pte=00000000, *ppte=00000000
    [ 3439.432311] Internal error: Oops: 817 [#1] PREEMPT ARM
    [ 3439.432327] Modules linked in: ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables bcm2708_wdog i2c_dev i2c_bcm2708 snd_bcm2835 snd_pcm snd_seq snd_seq_device snd_timer snd w1_therm w1_gpio wire cn uio_pdrv_genirq uio
    [ 3439.432479] CPU: 0 PID: 3177 Comm: emonClient_mt Not tainted 3.18.11+ #781
    [ 3439.432498] task: db3fc380 ti: db336000 task.ti: db336000
    [ 3439.432541] PC is at w1_slave_show+0x2d8/0x398 [w1_therm]
    [ 3439.432571] LR is at vsnprintf+0x27c/0x3e0
    [ 3439.432589] pc : [<bf02736c>] lr : [<c02fc18c>] psr: 20000013
    [ 3439.432589] sp : db337e08 ip : bf0275c0 fp : db337e54
    [ 3439.432607] r10: 000000aa r9 : db337e27 r8 : db337e27
    [ 3439.432621] r7 : d685de50 r6 : d9edc000 r5 : 00000fe5 r4 : 00000000
    [ 3439.432637] r3 : 00000000 r2 : 1002ff7f r1 : 464b01ae r0 : 0000000d
    [ 3439.432653] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
    [ 3439.432667] Control: 00c5387d Table: 0dda0008 DAC: 00000015
    [ 3439.432681] Process emonClient_mt (pid: 3177, stack limit = 0xdb3361b0)
    [ 3439.432696] Stack: (0xdb337e08 to 0xdb338000)
    [ 3439.432718] 7e00: bf0275d8 00000000 00000001 db2fd294 cdd70478 aed70478
    [ 3439.432742] 7e20: 7f464b01 aa1002ff 000b6f54 cdc18ae0 bf027704 d9d79f80 00001000 d9edc000
    [ 3439.432768] 7e40: c05a0ae4 00000001 db337e6c db337e58 c0364494 bf0270a0 cdc18ae0 d685de58
    [ 3439.432791] 7e60: db337e94 db337e70 c01ab358 c0364474 cdc18ae0 00000001 db337eb8 00000000
    [ 3439.432814] 7e80: 00001000 ce302d20 db337ea4 db337e98 c01a9c88 c01ab2c8 db337ef4 db337ea8
    [ 3439.432837] 7ea0: c015cd10 c01a9c60 db336008 cdc18b10 b6f53000 db337f78 00000000 00000000
    [ 3439.432860] 7ec0: db336028 00000000 db311480 d9d79f80 b6f53000 db336000 db337f78 00001000
    [ 3439.432885] 7ee0: b6f53000 00001000 db337f3c db337ef8 c01aa670 c015cb64 5661dc24 c0138688
    [ 3439.432908] 7f00: 5661dc24 db3114b4 00000000 db337f78 00000000 ce302d20 b6f53000 db336000
    [ 3439.432932] 7f20: db337f78 00001000 b6f53000 00000000 db337f74 db337f40 c01386b4 c01aa558
    [ 3439.432955] 7f40: db337f5c db337f50 c0155d3c 00000000 00000000 ce302d23 ce302d20 00001000
    [ 3439.432977] 7f60: b6f53000 00000000 db337fa4 db337f78 c0138dc8 c0138628 00000000 00000000
    [ 3439.433002] 7f80: 017dadf0 0000007e 00000000 00000003 c000eaa8 db336000 00000000 db337fa8
    [ 3439.433025] 7fa0: c000e800 c0138d88 017dadf0 0000007e 00000006 b6f53000 00001000 00000000
    [ 3439.433047] 7fc0: 017dadf0 0000007e 00000000 00000003 b5d1aa90 b5d1bf90 0000000a b5d1aa90
    [ 3439.433070] 7fe0: 00000000 b5d1a970 b6e6feb8 b6e542b4 80000010 00000006 00000000 00000000
    [ 3439.433146] [<bf02736c>] (w1_slave_show [w1_therm]) from [<c0364494>] (dev_attr_show+0x2c/0x58)
    [ 3439.433188] [<c0364494>] (dev_attr_show) from [<c01ab358>] (sysfs_kf_seq_show+0x9c/0x104)
    [ 3439.433219] [<c01ab358>] (sysfs_kf_seq_show) from [<c01a9c88>] (kernfs_seq_show+0x34/0x38)
    [ 3439.433254] [<c01a9c88>] (kernfs_seq_show) from [<c015cd10>] (seq_read+0x1b8/0x488)
    [ 3439.433282] [<c015cd10>] (seq_read) from [<c01aa670>] (kernfs_fop_read+0x124/0x16c)
    [ 3439.433318] [<c01aa670>] (kernfs_fop_read) from [<c01386b4>] (vfs_read+0x98/0x188)
    [ 3439.433346] [<c01386b4>] (vfs_read) from [<c0138dc8>] (SyS_read+0x4c/0xa0)
    [ 3439.433386] [<c0138dc8>] (SyS_read) from [<c000e800>] (ret_fast_syscall+0x0/0x48)
    [ 3439.433413] Code: eb4b5402 e5173004 e51b2031 e51b1035 (e5832004)
    [ 3439.439395] ---[ end trace ec2b42b5a58f8df1 ]---

    Ich muss da jetzt erst mal weiterschauen ...
    Vielleicht hat ja der eine oder andere noch eine Idee zu diesem schrägen Verhalten?
    Kleiner Hinweis am Rande: ein cat auf eine Sensordatei kann in diesem instabilen Zustand so hängen, dass er nicht mal mehr mit kill -9 eliminiert werden kann (reinrassiger Zombie im kernelmodus) sondern ein reboot nötig ist ( der dann auch teilweise hängt und nur noch Steckerziehen hilft).

    Ich halt' Euch jedenfalls auf dem Laufenden ...

    cu,
    -ds-

  • Hallo Dreamshader,

    spaßeshalber habe ich mal die erste Zeile Deines Fehler-Logs in eine Suchmaschine eingegeben. Da kommen unzählig viele gleichwertige Fundstellen, die auf einen Kernel-Bug hindeuten.

    Ich würde das entweder dem Kernel-Team mitteilen - oder abwarten, da Du sicherlich nicht der erste bist, der diesen Fehler hat. Solche Bugs werden üblicherweise in den nächsten Tagen beseitigt werden.

    Ein anderer schreibt als Antwort auf das Problem:

    Zitat

    It means you are trying to access a NULL pointer in your code. Put NULL checks in your code to find out where.


    [Quelle]
    Dann hast Du irgendwo im Code Optimierungspotential... Viel Spaß beim Pointer-biegen!


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (4. Dezember 2015 um 21:38)

  • Hi Andreas,


    ... Da kommen unzählig viele gleichwertige Fundstellen, die auf einen Kernel-Bug hindeuten.
    ...


    tja ... so seh ich das auch ... Blöderweise taucht die Meldung im Zusammengang mit NICs, USB und hastenichtgesehn auch auf. Scheint also eine zentrale Stelle irgendwo im Kernel zu sein.

    Na mal sehen ... ich mach jetzt einfach mal einen upgrade ( das ist ein vorgefertigtes Image von OpenEnergyMonitor ... das ist natürlich auch irgendwie blöd :s ) ... und versuch das hier bei mir mal zu reproduzieren.

    So was nervt :fies:

    //EDIT:
    Naja ... wenn es mir zu bunt wird, dann häng ich die Sensoren einfach an einen Pro Mini und übertrag' die Daten per SPI/I2C/UART ... ;) ... ich lass' mich doch von so einem kleinen Querulanten nicht verarschen :lol:

    cu,
    -ds-

  • ich habe es doch aufgegeben die DS18B20 per PI auszulesen, im Atmel habe ich am Quellcode gewerkelt bis es lief, nun schon 5 Jahre.
    PI und mehrere DS18B20 als parasitär auch mit 820 Ohm pullup hat bei mir nie funktioniert, die Krücke mit der extra VCC mochte ich nicht.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (4. Dezember 2015 um 22:53)

  • Hallo Jar, hallo Dreamshader,

    das könnte es auch sein. Einer der vielen Links hielt auich einen Hinweis auf unpassenden POullup-Widerstände.

    Möglicherweise liegt es auch an der parasitären Versoprgung (die ich nie ausprobiert habe). Schaltet man den DS18B20 über die 3 Pins (Versorgungsspannung V+, GND, Widerstand ca 4k7 zwischen DQ und V+) dann habe ich damit noch nie Probleme gehabt.

    Beste Grüße
    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (4. Dezember 2015 um 22:35)

  • Hallöle,
    es scheint sich herauszukristallisieren, dass es sich tatsächlich um einen Kernel-Bug handelt bzw. gehandelt hat.
    Nach einem upgrade und anschliessendem Neustart des RPi läuft alles wie am Schnürchen :) ...

    Da ist wohl in dem System, auf das das EMONCMS-Image aufsetzt, noch ein Bug drin ( das war wheezy vom 5.5.2015, wenn ich mich nicht irre ) ...

    Nur sonderbar, dass ich immer in solche Fallen tappe :fies:

    Na gut, ...
    noch mal beobachten und dann kann ich das hier wohl abhaken.

    -ds-


  • ...Nur sonderbar, dass ich immer in solche Fallen tappe :fies:

    wieso du, du hast da kein Alleinstellungsmerkmal!

    TomTom ich finde einen Fehler in der winCE App, mein Freund hat den selben Fehler in seinem TomTom Navi, ich frage auf der Messe am Stand:"Sie sind der erste der diesen Fehler meldet", ich weiss die lügen immer, aber App und Gerät gleicher Fehler und keiner merkt es?

    Ich finde einen Lib Fehler in Eagle der sich seit 20 Jahren durch alle Versionen schlängelt und die Hotline ist verwundert das ich es melde, kannte angeblich keiner. Ich erwarte nach 20 Jahren das die ausgelieferten LIBs fehlerbereinigt sind, zuviel?

    PI und DS18B20 rate mal warum ich aufgab vor 2 Jahren.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hi jar ...

    naja ... ich meine: wheezy vom 5.5.2015 ... DS18B20-Kernel-Treiber fehlerhaft
    Beides in Kombination sicher 1000e male im Einsatz, sicher auch hier im Forum und keiner kannte das Problem?
    Mag ich zwar auch nicht so recht glauben, scheint aber so zu sein ...

    Nun, was soll's ... scheint ja jetzt in Ordnung zu sein.

    Um dem Ganzen was positives abzuringen: alle, die das -> Image von OpenenergyMonitor <- nutzen und lokal DS18B20 Sensoren anschliessen wollen/angeschlossen haben: update und upgrade machen. Sonst verzweifelt ihr unter Umständen mit den Sensorabfragen.
    Und alle, die das Image vom 5.5.2015 nutzen und Probleme mit DS18B20 Sensoren haben: auch mal mit update / upgrade probieren.

    Na dann mach' ich hier mal dass Licht aus,
    -ds-

  • Schuld an einem Null Pointer Ausnahmefehler ist eigentlich kein richtiger Bug sondern ein Programmierfehler. Oft verweist ein Pointer auf ein Objekt, welches nicht da ist. Das passiert immer dann, wenn in der Software nicht dafür gesorgt wurde vor dem Aufrufen zu prüfen ob es existiert. Das muss nicht an dem Programm liegen, welches man selbst geschrieben hat, es können auch Fehler in Bibliotheken vorhanden sein, die man nutzt. Einen Kernel Bug halte ich doch für recht unwahrscheinlich. Evtl wurde durch das Upgrade eine Bibliothek erneuert. Was mich nur wundert, ist dass das Verhalten erst nach einer bestimmten Zeit aufgetreten ist. Auch dass ist ein Anzeichen für einen Fehler ausserhalb des Kernels.


  • ... Einen Kernel Bug halte ich doch für recht unwahrscheinlich.
    ... Auch dass ist ein Anzeichen für einen Fehler ausserhalb des Kernels.


    Warum? Hast Du da eine Begründung dafür, wenn Du schon solche Aussagen postest, oder ist das doch nur reines "Bauchgefühl"?
    Der erste Bug, der mir das Leben mit Raspbian schwer gemacht hat, war ein WLAN-Abbruch, der, wie sich dann herausstellte, wochenlang als Kernel-Bug bekannt aber noch nicht gefixed herausstellt. Und der tauchte auch mal nach 15 Minuten und mal nach etlichen Stunden auf (bei annähernd gleichen Randbedingungen).
    Hier lesen Leute mit, da würde ich an Deiner Stelle solche Aussagen eher als Meinung qualifizieren und nicht als Tatsache posten ... ;)

    cu,
    -ds-
    Automatisch zusammengefügt:


    Gab es nicht kurzzeitig einen Fehler im 1wire-Paket?

    Kann gut sein ... ich glaub' sogar, ich habe beim upgrade was von 1wire durchflitzen sehen ...
    Ich guck halt nun mal nicht jedesmal, wenn ich irgendein Progrämmchen schreibe, erst nach, ob da ein Bug bekannt ist. Und wenn irgendwas hakt, dann vermute ich erst mal den Fehler bei mir, und wühle mich nicht durch die issues von Raspbian und Kernel.
    Wie gesagt ... ist ja egal.
    Nur erstaunlich, dass es hier niemand gemerkt hat. Weil der Bug, der sollte auch z.B. in Python zu spüren sein ...

    bye,
    -ds-

  • Der Fehler lag im w1-therm-Modul und war eigentlich bekannt. Man hätte den Fehler abfangen können, indem man vor Abfrage prüft, ob der Sensor den man abfragt überhaupt da ist. Ein Sensor, der warum auch immer kurz mal nicht oder falsch im Verzeichnis war, hat dann ein "NULL-Objekt" bei Abfrage zurückgegeben und die NULL pointer exeption verursacht. Da die Module zum Kernel gehören bzw. von ihm geladen werden, kann man das als Kernel Bug bezeichnen, da hat also Dreamshader recht. "Bauchgefühl" war es also nicht. Eher eine Frage der Philosophie, da ich der Meinung bin, das ladbare Module nicht zum Kernel gehören sondern eher mit Treibern vergleichbar sind. Aber ich will da keinen Meinungsstreit vom Zaune brechen, zudem das Problem behoben wurde.

  • Der Clou: der Sensor war da und auch lesbar ...
    Ich baue die Liste mit den Sensoren immer schon dynamisch aus den verfügbaren Informationen des Systems auf. Schliesslich kann jederzeit mal einer ausfallen, defekt oder stromlos sein, ...

    Spoiler anzeigen

    Die Information, dass evtl. mal das eine oder andere File "verschwunden" war, hatte ich auch. Wie gesagt, das File war da und auch lesbar ... sonst wäre der freeze im read() ja gar nicht passiert ;)
    Also nix mit "hätte verhindert/umgangen werden können" ... (wieder so eine Aussage, die als Tatsache gepostet wird und sich als Mutmaßung herausstellt ... hast Du das wirklich nötig?) - ich bin weder "auf der Brennsuppn dahrgeschwumma" noch schreib ich seit gestern Software ... :fies:

    btw: hättest Du den Eingangspost (aufmerksam) gelesen, wäre Dir der Hinweis aufgefallen, dass ein cat auf die Datei sich ebenso "festfrisst" ... nun ist aber ein cat auf eine nicht existierende schlecht möglich ;)
    Im Übrigen führt ein fread() auf einen NULL-Pointer bzw. ein read() auf einen ungültigen fd sicher nicht zu einem Fehler im 1Wire-Kernel-Modul ... Ist also kompletter Mumpitz, was Du da geschrieben hast.


    cu,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!