Ankündigung

Einklappen
Keine Ankündigung bisher.

Mit ETS und KNXnet/IP Routing über eibd auf den KNX

Einklappen
X
Einklappen
 
  • Seite von 4
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
Vorherige 1 2 3 4 template Weiter
    #16
    Zitat von mkoegler Beitrag anzeigen

    Zur Eingrenzung:

    - "gdb eibd"
    - "run <eibd parameter>"
    [tun, was man sonst im Betrieb tut]
    - <Strg-C>
    - "signal SIGINT"
    Entwerder beendet sich der EIBD jetzt ohne Fehler oder es kommt die Melung über einen Segmentation fault. Dann bitte "bt" ausführen.

    Hier die Debugger Logs. Hier deutet nichts auf ein SIGSEGV hin, oder?

    Code:
    [root@david homeserver]# gdb eibd
GNU gdb (GDB) Fedora (6.8.50.20090302-38.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) run  -t1023 -D -i -S -T -R usb:
Starting program: /opt/eibd/bin/eibd -t1023 -D -i -S -T -R usb:
Failed to read a valid object file image from memory.
Layer 7(00000000,4B48C9C1) EIBD should not run as root
W00000001: EIBD should not run as root
Layer 1(080BDAE0,4B48C9C1) Detect
Layer 1(080BDAE0,4B48C9C1) Using 4:2:1:0:0 (2:129)
Layer 1(080BDAE0,4B48C9C1) Open
Layer 1(080BDAE0,4B48C9C1) Claimed
Layer 1(080BDAE0,4B48C9C1) Opened
Layer 1(080BDAE0,4B48C9C1) Send(064): 01 13 09 00 08 00 01 0F 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(080BDAE0,4B48C9C1) StartRecv
Layer 0(080BDAE0,4B48C9C1) Send(064): 01 13 09 00 08 00 01 0F 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(080BDAE0,4B48C9C1) StartSend
Layer 0(080BDAE0,4B48C9C1) SendComplete 64
Layer 0(080BDAE0,4B48C9C1) RecvComplete 64
Layer 0(080BDAE0,4B48C9C1) RecvUSB(064): 01 13 0B 00 08 00 03 0F 02 00 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(080BDAE0,4B48C9C1) StartRecv
Layer 1(080BDAE0,4B48C9C1) Recv(064): 01 13 0B 00 08 00 03 0F 02 00 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 1(080BDAE0,4B48C9C1) Send(064): 01 13 0A 00 08 00 02 0F 03 00 00 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(080BDAE0,4B48C9C1) Send(064): 01 13 0A 00 08 00 02 0F 03 00 00 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(080BDAE0,4B48C9C1) StartSend
Layer 1(080BDBA8,4B48C9C1) EMI1
Layer 2(080BE578,4B48C9C1) Open
Layer 2(080BE578,4B48C9C1) Opened
Layer 3(080BE908,4B48C9C1) Open
Layer 2(080BE578,4B48C9C1) OpenL2
Layer 0(080BDBA8,4B48C9C1) Send-EMI(005): 46 01 00 60 12
Layer 1(080BDAE0,4B48C9C1) Send(064): 01 13 0D 00 08 00 05 01 01 00 00 46 01 00 60 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(080BDAE0,4B48C9C1) SendComplete 64
Layer 0(080BDAE0,4B48C9C1) Send(064): 01 13 0D 00 08 00 05 01 01 00 00 46 01 00 60 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(080BDAE0,4B48C9C1) StartSend
Layer 0(080BDAE0,4B48C9C1) SendComplete 64
Layer 8(080C5D00,4B48C9C1) OpenInetSocket 6720
Layer 8(080C5D00,4B48C9C1) InetSocket opened
Layer 8(080BE998,4B48C9C1) Open
Layer 0(080BF440,4B48C9C1) Open
Layer 0(080BF440,4B48C9C1) Openend
Layer 3(080BE908,4B48C9C1) registerBroadcast 080BE998
Layer 3(080BE908,4B48C9C1) registerBroadcast 080BE998 = 1
Layer 3(080BE908,4B48C9C1) registerGroup 080BE998
Layer 3(080BE908,4B48C9C1) registerGroup 080BE998 = 1
Layer 3(080BE908,4B48C9C1) registerIndividual 080BE998 0
Layer 3(080BE908,4B48C9C1) registerIndividual 080BE998 = 1
Layer 8(080BE998,4B48C9C1) Opened
Layer 4(080BE500,4B48C9C1) GroupCacheInit

Program received signal SIGINT, Interrupt.
0xffffe410 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.10.1-4.i686 libgcc-4.4.1-2.fc11.i586 libstdc++-4.4.1-2.fc11.i586
(gdb) bt
#0  0xffffe410 in ?? ()
#1  0x080ad0a8 in ?? ()
#2  0x080acf78 in ?? ()
#3  0x080acff8 in ?? ()
#4  0x48a9dfbd in ___newselect_nocancel () from /lib/libc.so.6
#5  0xb7fc8fd2 in __pth_sched_eventmanager (now=0x80ad300, dopoll=0)
    at pth_sched.c:639
#6  0xb7fc9de8 in __pth_scheduler (dummy=0x0) at pth_sched.c:369
#7  0xb7fcb719 in pth_spawn_trampoline () at pth_lib.c:216
#8  0x48a0458b in makecontext () from /lib/libc.so.6
#9  0x489f32f1 in sigemptyset () from /lib/libc.so.6
#10 0x00000000 in ?? ()
(gdb)

    Kommentar

      #17
      Zitat von mkoegler Beitrag anzeigen
      Workaround: Gibt der ETS die Addresse 0.0.0, dann sollte es funktionieren.
      Okay, damit erhalte ich nun dieselbe Stabilität wie beim Tunneling, D.h. manchmal kann ich den Siemens Taster erfolgreich programmieren und manchmal nicht. Gleiche Fehlermeldung wie beim o.g. Programmierfehler im Tunneling Modus. Danke erstmal für den Tipp.

      Ich habe derzeit nur eine zweite Schnittstelle (RS232/BCU1), welche am ETS PC hängt. Aber ich vermute, dass die ETS es nicht unterstützt über Tunneling oder Routing zu programmieren während sie über ihren Busmonitor via COM2: aufzeichnet. Müsste dann wohl erst eine Kernelmodul für den eibd kompilieren und die Schnittstelle an meinen Server hängen und dann dort über eine zweite eibd Instanz die Kommunikation mitschneiden. Oder gibt es einen eleganteren Weg?

      Kommentar

        #18
        Habe jetzt die COM-Schnittstelle auch an meinen Server gehängt und wie folgt die beiden eibd's gestartet:

        eibd für KNXnet/IP Routing/Tunneling per USB:

        Code:
        /opt/eibd/bin/eibd  -t1023 -D -i -S -R -T usb: > eibd-usb.log
        eibd für's Monitoring:

        Code:
        /opt/eibd/bin/eibd  -t1023 -u  bcu1:/dev/eib0 > eibd-serial.log
        letzterer scheint trotz dem -t1023 jedoch nur die Gruppenkommunikation aufzuzeichen und nicht die Programmierung. Woran liegt das? Müsste ich es auf unterschiedlichen Rechnern machen?

        Im Anhang die Logs der beiden eibd's, aber vermutlich nicht brauchbar, da der seriell angeschlossene eibd (mit kernel modul) kaum etwas mitloggt.
        Angehängte Dateien

        Kommentar

          #19
          Zitat von jonofe Beitrag anzeigen
          Hier die Debugger Logs. Hier deutet nichts auf ein SIGSEGV hin, oder?

          Code:
          [root@david homeserver]# gdb eibd
GNU gdb (GDB) Fedora (6.8.50.20090302-38.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) run  -t1023 -D -i -S -T -R usb:
Starting program: /opt/eibd/bin/eibd -t1023 -D -i -S -T -R usb:
Failed to read a valid object file image from memory.
Layer 7(00000000,4B48C9C1) EIBD should not run as root
W00000001: EIBD should not run as root
Layer 1(080BDAE0,4B48C9C1) Detect
[...]
Layer 3(080BE908,4B48C9C1) registerIndividual 080BE998 0
Layer 3(080BE908,4B48C9C1) registerIndividual 080BE998 = 1
Layer 8(080BE998,4B48C9C1) Opened
Layer 4(080BE500,4B48C9C1) GroupCacheInit

Program received signal SIGINT, Interrupt.
0xffffe410 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.10.1-4.i686 libgcc-4.4.1-2.fc11.i586 libstdc++-4.4.1-2.fc11.i586
(gdb) bt
#0  0xffffe410 in ?? ()
#1  0x080ad0a8 in ?? ()
#2  0x080acf78 in ?? ()
#3  0x080acff8 in ?? ()
#4  0x48a9dfbd in ___newselect_nocancel () from /lib/libc.so.6
#5  0xb7fc8fd2 in __pth_sched_eventmanager (now=0x80ad300, dopoll=0)
    at pth_sched.c:639
#6  0xb7fc9de8 in __pth_scheduler (dummy=0x0) at pth_sched.c:369
#7  0xb7fcb719 in pth_spawn_trampoline () at pth_lib.c:216
#8  0x48a0458b in makecontext () from /lib/libc.so.6
#9  0x489f32f1 in sigemptyset () from /lib/libc.so.6
#10 0x00000000 in ?? ()
(gdb)
          Der interessante Teil fehlt noch.
          Jetzt muss man noch "signal SIGINT" ausführen, um Strg+C an den EIBD zu schicken. Dann erst sollte der Absturz auftreten, wo dann "bt" die Position liefert.

          Kommentar

            #20
            Zitat von jonofe Beitrag anzeigen
            eibd für's Monitoring:

            Code:
            /opt/eibd/bin/eibd  -t1023 -u  bcu1:/dev/eib0 > eibd-serial.log
            letzterer scheint trotz dem -t1023 jedoch nur die Gruppenkommunikation aufzuzeichen und nicht die Programmierung. Woran liegt das? Müsste ich es auf unterschiedlichen Rechnern machen?
            Man muss den "busmonitor1 local:/tmp/eib" starten, um an die nötigen Infos zu kommen (= Äquivaltent zum ETS Busmonitor).

            Die nötigen Infos finde ich sowohl im -t1023 Output vom EIBD oder auch in der Ausgabe von busmonitor1. Im konkreten Fall wäre fast der -t1023 Output besser, da sich dieser besser in Relation zum anderen Trace setzen läßt.

            Und noch etwas: Bitte den Trace von einen fehlgeschlagen Programmierversuch machen. Es ja darum, das Problem beim Programmieren einzugrenzen.

            Kommentar

              #21
              Zitat von mkoegler Beitrag anzeigen
              Man muss den "busmonitor1 local:/tmp/eib" starten, um an die nötigen Infos zu kommen (= Äquivaltent zum ETS Busmonitor).
              Okay werde ich später versuchen!

              Zitat von mkoegler Beitrag anzeigen
              Die nötigen Infos finde ich sowohl im -t1023 Output vom EIBD oder auch in der Ausgabe von busmonitor1. Im konkreten Fall wäre fast der -t1023 Output besser, da sich dieser besser in Relation zum anderen Trace setzen läßt.
              Aber der eibd an der seriellen Schnittstelle liefert doch gerade mit -t1023 keine Detailinfos wie du im letzten angehängten Log sehen konntest. Woran liegt das denn?

              Zitat von mkoegler Beitrag anzeigen
              Und noch etwas: Bitte den Trace von einen fehlgeschlagen Programmierversuch machen. Es ja darum, das Problem beim Programmieren einzugrenzen.
              Klar. Auch die Logs im letzten Posting waren von einem nicht erfolgreichen Versuch. Werde dann später auch so lange programmieren, bis der Versuch nicht erfolgreich ist. Die Trefferquote ist ca. 50% bei "einfachen" KNX-Geräten. Beim TS2+ ist sie 100%, aber wir wollen ja erstmal klein anfangen.

              Danke für deinen Support und gute Nacht!

              Kommentar

                #22
                Zitat von jonofe Beitrag anzeigen
                1) Aber der eibd an der seriellen Schnittstelle liefert doch gerade mit -t1023 keine Detailinfos wie du im letzten angehängten Log sehen konntest. Woran liegt das denn?


                2) Klar. Auch die Logs im letzten Posting waren von einem nicht erfolgreichen Versuch. Werde dann später auch so lange programmieren, bis der Versuch nicht erfolgreich ist. Die Trefferquote ist ca. 50% bei "einfachen" KNX-Geräten. Beim TS2+ ist sie 100%, aber wir wollen ja erstmal klein anfangen.
                Add 1) -t1023 zeichnet auf, was der EIBD tut. Wenn busmonitor1 läuft, ändert sich sein Verhalten.

                Add 2) In den letzten ZIP File kann ich im Log von keinen der beiden EIBD eine Spur von einen Programmierversuch erkennen.

                Kommentar

                  #23
                  Zitat von mkoegler Beitrag anzeigen
                  In dem Fall ist der EIBD Schuld. Das NAT für Routing ist unvollständig/fehlerhaft implementiert (Korrektur wird ziemlich kompliziert werden).

                  Workaround: Gibt der ETS die Addresse 0.0.0, dann sollte es funktionieren.
                  eibd im pu branch hat einen wenig gesten Patch für das Problem - jetzt sollte es wieder mit jeder Adresse gehen.

                  Update: erster Fix für die doppelten Telegramme im pu branch (nur für USB, PEI16, EIBnet/IP und FT1.2 Backend)

                  Kommentar

                    #24
                    Zitat von mkoegler Beitrag anzeigen
                    eibd im pu branch hat einen wenig gesten Patch für das Problem - jetzt sollte es wieder mit jeder Adresse gehen.

                    Update: erster Fix für die doppelten Telegramme im pu branch (nur für USB, PEI16, EIBnet/IP und FT1.2 Backend)
                    Hi,

                    ich wollte gerade den neuen patch aus den pu-branch testen.

                    Code:
                    aclocal -I m4
autoheader
automake -a --foreign
autoconf
./configure --enable-onlyeibd --enable-eibnetip --enable-eibnetiptunnel --enable-usb --enable-eibnetipserver
                    Bis zum configure funktioniert es problemlos.

                    Beim make erhalte ich dann folgenden Fehler:

                    Code:
                    [root@david bcusdk]# make
echo "#define PKGDATADIR \"/usr/local/share/bcusdk\"" >path.h
echo "#define PKGLIBDIR \"/usr/local/lib/bcusdk\"" >>path.h
make  all-recursive
make[1]: Entering directory `/root/eibd/eibd_new/19012010/bcusdk'
Making all in .
make[2]: Entering directory `/root/eibd/eibd_new/19012010/bcusdk'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/root/eibd/eibd_new/19012010/bcusdk'
Making all in common
make[2]: Entering directory `/root/eibd/eibd_new/19012010/bcusdk/common'
g++ -DHAVE_CONFIG_H -I. -I..     -g -O2 -fno-rtti -fno-exceptions -MT image.o -MD -MP -MF .deps/image.Tpo -c -o image.o image.cpp
In file included from my_strings.h:23,
                 from types.h:25,
                 from image.h:23,
                 from image.cpp:24:
/usr/include/string.h:564: error: âinpâ was not declared in this scope
/usr/include/string.h:564: error: expected â,â or â;â before âthrowâ
make[2]: *** [image.o] Error 1
make[2]: Leaving directory `/root/eibd/eibd_new/19012010/bcusdk/common'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/eibd/eibd_new/19012010/bcusdk'
make: *** [all] Error 2
                    Was läuft hier schief?

                    Kommentar

                      #25
                      Zitat von jonofe Beitrag anzeigen
                      Beim make erhalte ich dann folgenden Fehler:

                      Code:
                      [root@david bcusdk]# make
echo "#define PKGDATADIR \"/usr/local/share/bcusdk\"" >path.h
echo "#define PKGLIBDIR \"/usr/local/lib/bcusdk\"" >>path.h
make  all-recursive
make[1]: Entering directory `/root/eibd/eibd_new/19012010/bcusdk'
Making all in .
make[2]: Entering directory `/root/eibd/eibd_new/19012010/bcusdk'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/root/eibd/eibd_new/19012010/bcusdk'
Making all in common
make[2]: Entering directory `/root/eibd/eibd_new/19012010/bcusdk/common'
g++ -DHAVE_CONFIG_H -I. -I..     -g -O2 -fno-rtti -fno-exceptions -MT image.o -MD -MP -MF .deps/image.Tpo -c -o image.o image.cpp
In file included from my_strings.h:23,
                 from types.h:25,
                 from image.h:23,
                 from image.cpp:24:
/usr/include/string.h:564: error: âinpâ was not declared in this scope
/usr/include/string.h:564: error: expected â,â or â;â before âthrowâ
make[2]: *** [image.o] Error 1
make[2]: Leaving directory `/root/eibd/eibd_new/19012010/bcusdk/common'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/eibd/eibd_new/19012010/bcusdk'
make: *** [all] Error 2
                      Was läuft hier schief?
                      Sieht nach einen Problem mit der Build-Umgebung am System auf. An der Stelle, wo string.h inkludiert wird, ist kaum EIBD Code übersetzt worden. Vielleicht gibt es einen Konflikt zwischen EIBD und glibc.

                      Ferndiagnose ohne mehr Infos ist schwierig.
                      Das System was für eine Distribution (Fedora?)?
                      Welche Version von
                      * glibc
                      * gcc
                      * g++/c++
                      * libstdc++
                      * kernel-headers / linux-header
                      sind installiert (rpm -qa)?

                      Kommentar

                        #26
                        Hi,

                        Scheint tatsächlich ein Problem mit meinem Kernel zu sein.

                        Habe vor einigen Tagen von 2GB auf 4GB Speicher aufgerüstet und dann SMP im Kernel aktiviert um beide Cores des Prozessors zu nutzen und dann VMWare Server installiert.

                        Die Speicherverwaltung des Kernels scheint nicht stabil zu laufen. Hatte eben entsprechende Fehler vom klogd in meinen Log-Files.
                        Nach einem Reboot bzw. Hard-Reset funktioniert es nun wieder.

                        Ich konnte den eibd aus dem pu-Branch kompilieren und habe per Routing versucht einen einfachen Taster zu programmieren. Erfolgsrate ca. 50%.

                        Im Anhang jetzt ein Log eines erfolgreichen und eines nicht erfolgreichen Programmierversuchs. Vielleicht hilft das ja bei der Fehlersuche.

                        Die Fehlermeldung der ETS ist übrigens "Das Gerät antwortet nicht."

                        Das Programmieren via routing mit einer anderen physikalischen Adresse als 0.0.0 in der ETS scheint zu funktionieren. Auch hier ist die Erfolgsquote 50% beim Programmieren eines einfachen Tasters.
                        Angehängte Dateien

                        Kommentar

                          #27
                          Zitat von jonofe Beitrag anzeigen
                          Scheint tatsächlich ein Problem mit meinem Kernel zu sein.

                          Habe vor einigen Tagen von 2GB auf 4GB Speicher aufgerüstet und dann SMP im Kernel aktiviert um beide Cores des Prozessors zu nutzen und dann VMWare Server installiert.

                          Die Speicherverwaltung des Kernels scheint nicht stabil zu laufen. Hatte eben entsprechende Fehler vom klogd in meinen Log-Files.
                          Nach einem Reboot bzw. Hard-Reset funktioniert es nun wieder.
                          Kernel-Problem halte ich für unwahrscheinlich. Kernel/Speicher Problem würde eher Segmentation Faults hervorrufen. Die Fehlermeldung vom Compiler sieht nach einen Bug in der Toolchain (Compiler, Header) aus.

                          Zitat von jonofe Beitrag anzeigen
                          Ich konnte den eibd aus dem pu-Branch kompilieren und habe per Routing versucht einen einfachen Taster zu programmieren. Erfolgsrate ca. 50%.

                          Im Anhang jetzt ein Log eines erfolgreichen und eines nicht erfolgreichen Programmierversuchs. Vielleicht hilft das ja bei der Fehlersuche.

                          Die Fehlermeldung der ETS ist übrigens "Das Gerät antwortet nicht."

                          Das Programmieren via routing mit einer anderen physikalischen Adresse als 0.0.0 in der ETS scheint zu funktionieren. Auch hier ist die Erfolgsquote 50% beim Programmieren eines einfachen Tasters.
                          Jetzt sind wir wieder beim Ursprungsproblem mit den unknown TPDU, das für die Abbrüche verantwortlich ist. Die verbleibende Frage ist nur, ist dein Interface oder das programmierte Gerät schuld.

                          Mit deinen zweiten Interface (PEI16) könnte man es auf 2 Arten eingrenzen:
                          1) Exportiere das zweite Interface (PEI16) per EIBD und mach die selben Tests damit. Wenn keine "Das Geräte antwortet nicht" auftreten, ist dein momentanes Interface (USB) schuld.
                          2) Starte auf dem zweiten Interface einen EIBD und verbinde damit busmonitor1 (soll während des gesamten Tests durchlaufen). Parallel zweiten EIBD (USB) starten und Programmiertests machen. -t1023 von beiden EIBDs mir bitte zukommen lassen.

                          Variante 2 ist aussagekräftiger.

                          PS: Danke für deine Tests

                          Kommentar

                            #28
                            Ich hatte tatsächlich heute morgen Segmentation Faults und nicht mehr den weiter oben geposteten Fehler. Das hatte mich ja so verwundert, dass es plötzlich ein völlig anderer Fehler war. Dazu dann mempage allocation Fehler in den Logs und nach einem Reboot war alles wieder gut. Sehr mysteriös. ;-)

                            Sorry, war wohl schon zu lange her (> 1 Woche) ;-) ... ich werde noch mal die zweite Variante mit dem zweiten eibd auf einer anderen Maschine durchführen. Werde evtl. erst am Samstag dazu kommen, aber ich ich werds auf jeden Fall machen. Hab im Moment noch ein paar andere Baustellen.

                            Danke für deinen Support.

                            Kommentar

                              #29
                              Zitat von jonofe Beitrag anzeigen
                              Ich hatte tatsächlich heute morgen Segmentation Faults und nicht mehr den weiter oben geposteten Fehler. Das hatte mich ja so verwundert, dass es plötzlich ein völlig anderer Fehler war. Dazu dann mempage allocation Fehler in den Logs und nach einem Reboot war alles wieder gut. Sehr mysteriös. ;-)
                              Wenn wirklich massive Speicherprobleme vorliegen, könnte auch der Pagecache betroffen gewesen sein.

                              Wenn ich ein System mit solchen Symtomen hätte, würde ich den Maschine erst einmal mit memtest86 (ist zB auf jeder OpenSuSE Install-CD im Bootmenü) min 1-2 durchchecken lassen. Wenn ein Fehler gemeldt wird, dann Tausch dein RAM.

                              Kommentar

                                #30
                                Hier jetzt die logs eines fehlerhaften Programmierversuchs über KNXnet/IP Routing von 2 Rechnern. Einmal vom Server und einmal vom Monitoring Client.

                                Es handelt sich jeweils um den aktuellen eibd au dem pu-Branch, gestartet wie folgt:

                                Server:

                                Code:
                                /usr/local/bin/eibd -t1023 -D -i -S -T -R usb:4:2:1:0 > server.log
                                Monitoring Client:

                                Code:
                                /usr/local/bin/eibd -t1023 -i ip: > monitor.log
                                Vielleicht kann man jetzt sehen, ob das Programmierproblem an der ETS, der Schnittstelle oder am eibd liegt.
                                Angehängte Dateien

                                Kommentar

                                Vorherige 1 2 3 4 template Weiter
                                Lädt...
                                X

                                Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.

                                Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.

                                Ich stimme zu