FlyingDoc Geschrieben August 22, 2019 at 20:15 Geschrieben August 22, 2019 at 20:15 Hallo TF Team. Ich wollte es schon ewig melden, habe es aber lange verpasst, da ich arbeitsmäßig und familiär ziemlich gebunden bin im Moment. Bei meinem Laptop habe ich folgendes Phänomen. Beim Start von Win 10 kann der Daemon keine Verbindung aufbauen. Ich habe heute mal in die Log geschaut warum und habe folgendes gefunden. 2019-08-22 21:51:08.044366 <E> <event_winapi.c:228> Could not write to USB ready pipe: WSAECONNABORTED (71010053) 2019-08-22 21:52:09.341898 <I> <log_winapi.c:173> Log Viewer connected to info pipe 2019-08-22 21:52:23.436638 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) Die Verbindung funktioniert erst, wenn ich den Daemon Dienst neu starte. 2019-08-22 21:53:48.196921 <I> <main_winapi.c:209> Received stop command 2019-08-22 21:53:48.196922 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-08-22 21:53:48.197252 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-08-22 21:53:48.197274 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-08-22 21:53:48.197308 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-08-22 21:53:48.200701 <I> <main_winapi.c:489> Brick Daemon 2.4.0 stopped 2019-08-22 21:53:49.534941 <I> <main_winapi.c:376> Brick Daemon 2.4.0 started (as service) 2019-08-22 21:53:49.555603 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2019-08-22 21:53:49.556743 <I> <libusb:windows_init> UsbDk backend is not available 2019-08-22 21:53:49.596024 <I> <usb.c:194> Added USB device (bus: 1, device: 4) at index 0: IMU Brick 2.0 [6wVmVp] 2019-08-22 21:53:49.941343 <I> <log_winapi.c:173> Log Viewer connected to info pipe Ich vermute mal, das mein Rechner einfach zu schnell startet und etwas noch nicht geladen ist was der Daemon beim USB benötigt. Vom Start bis zum Login Screen sind es rund 10 Sekunden. Vielleicht kann man das Problem ja beheben in dem man vor dem Verbindungsversuch testet ob die benötigte Treiberkomponente schon im Windows geladen ist. P.s. Könntet iht die Länge des Logfile begrenzen. Mir hat der Daemon meine Platte mit dem Logfile völlig vollgeschrieben. Also alles wenn eine bestimmte Größe erreicht ist die ältesten Beiträge abschneiden. Das waren dann mehrere GByte. ( Kein Scherz) Und da hatte ich nur eine 256 GByte Systemplatte. Jetzt 1 TByte. Er Protokolliert ja alles. Und wenn jede Sekunde ein Fehlereintrag kommt geht das ratz fatz. Ich habe mich gewundert warum meine Systemplatte irgend wann bis auf das letzte Byte gefüllt war. Da schliesst man ja nicht sofort drauf. Zitieren
photron Geschrieben August 23, 2019 at 08:37 Geschrieben August 23, 2019 at 08:37 Die Fehler haben so erstmal nichts mit USB zu tun. Die USB Ready Pipe, um die es hier geht, ist ein interner Mechanismus in brickd um dem Event Loop mitzuteilen, dass es libusb Events gibt. Die Pipe besteht aus zwei miteinander verbundenen Sockets. Die Fehler die du da siehst, sind Connection Aborted und Connection Reset Fehler zwischen den beiden Sockets. Diese beiden Sockets sind aber nur intern in brickd verbunden und zu nichts externem. Mir ist unklar wie du diese Art von Fehlern bei diesen beiden Sockets haben kannst. Wenn ich raten müsste würde ich sagen, das brickd startet und dann Windows das Netzwerk Subsystem neustartet und das dann die interne Verbindung der beiden Sockets killt. Alternative hast du komische Virenscanner oder Firewalls installiert die dazwischenfunken. Tritt das Problem jedes mal auf? Bezüglich Log Rotation: Ich nehme das mal auf die TODO Liste auf. Zitieren
FlyingDoc Geschrieben August 23, 2019 at 19:11 Autor Geschrieben August 23, 2019 at 19:11 Bei jedem Systemstart tritt der Fehler auf. Zitieren
photron Geschrieben August 26, 2019 at 10:47 Geschrieben August 26, 2019 at 10:47 Es wirkt so als ob Brick Daemon zu früh gestartet wird. Dienste können untereinander Abhängigkeiten haben, aber ich kann nicht so richtig rausbekommen, was hier die richtige Abhängigkeit ist. Teste mal bitte die folgenden drei Abhängigkeiten durch. Starte eine Eingabeaufforderung als Administrator und gib dort einen der Befehle ein und starte dann den Rechner neu. sc config "Brick Daemon" depend=tcpip sc config "Brick Daemon" depend=netman sc config "Brick Daemon" depend=lanmanserver Zitieren
FlyingDoc Geschrieben August 26, 2019 at 21:57 Autor Geschrieben August 26, 2019 at 21:57 Der erste Versuch und ein Volltreffer. Mit sc config "Brick Daemon" depend=tcpip funktioniert es. Zitieren
FlyingDoc Geschrieben December 13, 2019 at 09:23 Autor Geschrieben December 13, 2019 at 09:23 Hallo TF Team. Leider bringt der Deamon auch in der neuen Version noch das Problem das er beim ersten Start nicht funktioniert , aber dafür mir die Festplatte mit dem Logfile zuspammt. Vorgestern Abend installiert. Und innerhalb von 4h über 8 GB an Logfile produziert. Wolltet ihr nicht die maximale Anzahl der Einträge limitieren? Zitieren
photron Geschrieben December 13, 2019 at 11:21 Geschrieben December 13, 2019 at 11:21 Sorry, das steht beides noch auf der TODO Liste ist mir aber durch die Lappen gegangen. Sprich, das alte Problem ist noch da, du kannst es aber durch sc config "Brick Daemon" depend=tcpip begeben und die Logdatei Explosion entsteht durch das Loggen wegen dieses Problems? Zitieren
photron Geschrieben December 13, 2019 at 13:48 Geschrieben December 13, 2019 at 13:48 Teste mal bitte diese Version, die hat jetzt von sich aus "tcpip" als Abhängigkeit gesetzt. Das sollte dein direktes Problem beheben: https://download.tinkerforge.com/_stuff/brickd_windows_2_4_1_tcpip.exe Logrotation kommt dann in Kürze auch noch. Zitieren
FlyingDoc Geschrieben December 18, 2019 at 22:15 Autor Geschrieben December 18, 2019 at 22:15 Ich habe die Version getestet. Geht nicht. Innerhalb von ein paar Minuten war das Log von 0 auf 244 MB angestiegen. Ich habe mal die ständig kommenden Einträge minimiert. Es ist immer der selbe. Deswegen die Sternchen. 2019-12-16 22:38:06.442993 <I> <main_winapi.c:376> Brick Daemon 2.4.1 started (as service) 2019-12-16 22:38:06.444293 <W> <main_winapi.c:384> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details 2019-12-16 22:38:06.460943 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2019-12-16 22:38:06.462639 <I> <libusb:windows_init> UsbDk backend is not available 2019-12-16 22:38:06.518538 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-16 22:38:11.020795 <I> <network.c:304> Added new client (N: 127.0.0.1:62490, T: plain-socket, H: 956/956, B: 0, P: 0, A: disabled) 2019-12-17 00:19:17.431758 <I> <client.c:252> Client (N: 127.0.0.1:62490, T: plain-socket, H: 956/956, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-17 22:46:23.991284 <E> <event_winapi.c:228> Could not write to USB ready pipe: WSAECONNABORTED (71010053) 2019-12-17 22:47:26.695720 <I> <network.c:304> Added new client (N: 127.0.0.1:64583, T: plain-socket, H: 972/972, B: 0, P: 0, A: disabled) 2019-12-17 22:47:26.710409 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710460 <E> <usb_transfer.c:300> Could not submit write transfer 017785A8 (handle: 0177C7B0, submission: 13) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.710524 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710546 <E> <usb_transfer.c:300> Could not submit write transfer 017789C4 (handle: 0177C880, submission: 14) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.710618 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710643 <E> <usb_transfer.c:300> Could not submit write transfer 01778DE0 (handle: 0177C950, submission: 15) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.710687 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710706 <E> <usb_transfer.c:300> Could not submit write transfer 017791FC (handle: 0177CA20, submission: 16) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.710745 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710763 <E> <usb_transfer.c:300> Could not submit write transfer 01779618 (handle: 0177CAF0, submission: 17) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.710801 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710821 <E> <usb_transfer.c:300> Could not submit write transfer 01779A34 (handle: 0177CBC0, submission: 18) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.710856 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710874 <E> <usb_transfer.c:300> Could not submit write transfer 01779E50 (handle: 0177CC90, submission: 19) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.710908 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710926 <E> <usb_transfer.c:300> Could not submit write transfer 0177A26C (handle: 0177CD88, submission: 20) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.710965 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.710983 <E> <usb_transfer.c:300> Could not submit write transfer 0177A688 (handle: 0177D268, submission: 21) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:26.711043 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2019-12-17 22:47:26.711076 <E> <usb_transfer.c:300> Could not submit write transfer 0177AAA4 (handle: 0177CF28, submission: 22) to IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_IO (-1) 2019-12-17 22:47:38.064350 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:47:38.064393 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:47:38.064411 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:47:38.064426 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:47:38.064440 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:47:38.064454 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:47:38.064468 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:47:38.064482 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) * * * * 2019-12-17 22:48:11.770978 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771162 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771193 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771212 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771226 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771240 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771254 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771268 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771282 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771296 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771301 <I> <main_winapi.c:209> Received stop command 2019-12-17 22:48:11.771310 <E> <event_winapi.c:261> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-17 22:48:11.771796 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01773818 (handle: 01770CD0, submission: 12) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.771828 <W> <usb_transfer.c:243> Leaking pending read transfer 01773818 (handle: 01770CD0, submission: 12) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.771853 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01773C34 (handle: 01770DA0, submission: 2) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.771870 <W> <usb_transfer.c:243> Leaking pending read transfer 01773C34 (handle: 01770DA0, submission: 2) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.771888 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01774050 (handle: 01770E70, submission: 3) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.771913 <W> <usb_transfer.c:243> Leaking pending read transfer 01774050 (handle: 01770E70, submission: 3) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.771930 <W> <usb_transfer.c:208> Could not cancel pending read transfer 0177446C (handle: 01770F80, submission: 4) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.771954 <W> <usb_transfer.c:243> Leaking pending read transfer 0177446C (handle: 01770F80, submission: 4) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.771970 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01774888 (handle: 017704A0, submission: 5) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.771980 <W> <usb_transfer.c:243> Leaking pending read transfer 01774888 (handle: 017704A0, submission: 5) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.771993 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01774CA4 (handle: 01770570, submission: 6) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.772004 <W> <usb_transfer.c:243> Leaking pending read transfer 01774CA4 (handle: 01770570, submission: 6) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.772016 <W> <usb_transfer.c:208> Could not cancel pending read transfer 017750C0 (handle: 01777A20, submission: 7) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.772026 <W> <usb_transfer.c:243> Leaking pending read transfer 017750C0 (handle: 01777A20, submission: 7) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.772040 <W> <usb_transfer.c:208> Could not cancel pending read transfer 017754DC (handle: 01777B30, submission: 8) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.772052 <W> <usb_transfer.c:243> Leaking pending read transfer 017754DC (handle: 01777B30, submission: 8) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.772064 <W> <usb_transfer.c:208> Could not cancel pending read transfer 017758F8 (handle: 01777C40, submission: 9) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.772087 <W> <usb_transfer.c:243> Leaking pending read transfer 017758F8 (handle: 01777C40, submission: 9) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.772115 <W> <usb_transfer.c:208> Could not cancel pending read transfer 01775D14 (handle: 01778518, submission: 10) for IMU Brick 2.0 [6wVmVp]: LIBUSB_ERROR_NOT_FOUND (-5) 2019-12-17 22:48:11.772134 <W> <usb_transfer.c:243> Leaking pending read transfer 01775D14 (handle: 01778518, submission: 10) for IMU Brick 2.0 [6wVmVp] 2019-12-17 22:48:11.772454 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772476 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772488 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772498 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772509 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772519 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772530 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772539 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772550 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772574 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772584 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772594 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772604 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772614 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772625 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772635 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772646 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772656 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772666 <E> <libusb:do_close> Device handle closed while transfer was still being processed, but the device is still connected as far as we know 2019-12-17 22:48:11.772676 <W> <libusb:do_close> A cancellation for an in-flight transfer hasn't completed but closing the device handle 2019-12-17 22:48:11.772771 <W> <libusb:libusb_exit> some libusb_devices were leaked 2019-12-17 22:48:11.774399 <I> <main_winapi.c:489> Brick Daemon 2.4.1 stopped Zitieren
photron Geschrieben December 19, 2019 at 02:48 Geschrieben December 19, 2019 at 02:48 Das verwundert mich jetzt. Die brickd_windows_2_4_1_tcpip.exe Version führt bei der Installation sc config "Brick Daemon" depend=tcpip aus. Als du das vorher mit brickd 2.4.0 händisch gemacht hast, sagtest du, das hätte das Problem behoben. Schau mal bitte in der Dienste-Ansicht nach, ob das geklappt hat, also ob Brick Daemon eine Abhängigkeit auf den TCP/IP-Protokolltreiber hat. Nur damit ich das richtig verstehe, tritt das Problem mit brickd_windows_2_4_1_tcpip.exe noch genauso auf wie vorher? Sprich, ist brickd nach dem Windows Start in diesem kaputten Zustand und wenn du den Dienst von Hand neustartet dann geht es? Dein Log sieht komisch aus. Hast du das komisch zusammen geschnitten? Der lange Zeitsprung ist komisch: 2019-12-16 22:38:06.518538 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-16 22:38:11.020795 <I> <network.c:304> Added new client (N: 127.0.0.1:62490, T: plain-socket, H: 956/956, B: 0, P: 0, A: disabled) 2019-12-17 00:19:17.431758 <I> <client.c:252> Client (N: 127.0.0.1:62490, T: plain-socket, H: 956/956, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-17 22:46:23.991284 <E> <event_winapi.c:228> Could not write to USB ready pipe: WSAECONNABORTED (71010053) 2019-12-17 22:47:26.695720 <I> <network.c:304> Added new client (N: 127.0.0.1:64583, T: plain-socket, H: 972/972, B: 0, P: 0, A: disabled) Die ReadPipe/WritePipe Fehler sind auch komische, aber das mag alles ein Folgefehler von WSAECONNABORTED sein. Hast du etwas in der brickd.ini umgestellt? Mich wundert, dass brickd da eine Warnung ausgibt. Ich hab den WSAECONNRESET Fehler, der das Log vollmüllt jetzt mal fatal gemacht. Brick Daemon beendet sich jetzt, wenn dieser Fehler auftritt anstatt das Log voll zu schreiben. Das ist so auf Dauer keine schöne Lösung, aber erstmal besser als es vorher war. Die angehängt brickd Version ist nicht signiert. Ich habe hier gerade nicht meinen normalen Entwicklungsrechner zur Hand. Windows wird also etwas mehr meckern. Kannst du mit dieser Version ein Debug Log des WSAECONNABORTED Problems erzeugen? Dazu in brickd.ini das log.level von info auf debug stellen. Ich habe versucht mich über die möglichen Ursachen von WSAECONNABORTED zu belesen, verstehe aber dennoch nicht, wie das hier in diesem speziellen Fall zu Stande kommen kann. brickd_windows_2_4_1+fd1.exe Zitieren
FlyingDoc Geschrieben December 23, 2019 at 20:28 Autor Geschrieben December 23, 2019 at 20:28 Neue Version getestet. Ergebnis. Hab den Angeschlossenen IMU nicht gesehen. War einzeln angesteckt und sonst nichts. Nach dem ich den Deamon neu gestartet habe war der IMU in der Liste zu sehen und hat funktioniert. Das Log ist aber nicht exorbitand geswachsen. 2019-12-20 22:40:17.187668 <I> <main_winapi.c:388> Brick Daemon 2.4.1+fd1 started (as service) 2019-12-20 22:40:17.189340 <W> <main_winapi.c:396> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details 2019-12-20 22:40:19.465268 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2019-12-20 22:40:19.467268 <I> <libusb:windows_init> UsbDk backend is not available 2019-12-20 22:49:26.088046 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-20 22:49:27.245592 <I> <network.c:304> Added new client (N: 127.0.0.1:50029, T: plain-socket, H: 940/940, B: 0, P: 0, A: disabled) 2019-12-20 22:49:35.551313 <I> <client.c:252> Client (N: 127.0.0.1:50029, T: plain-socket, H: 940/940, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-20 22:49:39.023099 <I> <usb.c:414> Removing USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-21 00:51:20.674954 <E> <event_winapi.c:268> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-21 00:51:20.675353 <E> <event.c:539> Event loop aborted 2019-12-21 00:51:20.676987 <I> <main_winapi.c:501> Brick Daemon 2.4.1+fd1 stopped 2019-12-21 23:07:30.674533 <I> <main_winapi.c:388> Brick Daemon 2.4.1+fd1 started (as service) 2019-12-21 23:07:30.675699 <W> <main_winapi.c:396> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details 2019-12-21 23:07:30.686123 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2019-12-21 23:07:30.687530 <I> <libusb:windows_init> UsbDk backend is not available 2019-12-21 23:07:30.727582 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-21 23:07:34.647431 <I> <network.c:304> Added new client (N: 127.0.0.1:51074, T: plain-socket, H: 936/936, B: 0, P: 0, A: disabled) 2019-12-21 23:07:38.880840 <I> <client.c:252> Client (N: 127.0.0.1:51074, T: plain-socket, H: 936/936, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-21 23:08:49.093330 <I> <network.c:304> Added new client (N: 127.0.0.1:51215, T: plain-socket, H: 952/952, B: 0, P: 0, A: disabled) 2019-12-21 23:08:57.386102 <I> <client.c:252> Client (N: 127.0.0.1:51215, T: plain-socket, H: 952/952, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-22 00:06:13.795580 <I> <usb.c:414> Removing USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-22 02:07:39.397166 <E> <event_winapi.c:268> Could not read from USB ready pipe: WSAECONNRESET (71010054) 2019-12-22 02:07:39.397829 <E> <event.c:539> Event loop aborted 2019-12-22 02:07:39.399960 <I> <main_winapi.c:501> Brick Daemon 2.4.1+fd1 stopped 2019-12-22 23:06:32.050797 <I> <main_winapi.c:388> Brick Daemon 2.4.1+fd1 started (as service) 2019-12-22 23:06:32.052312 <W> <main_winapi.c:396> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details 2019-12-22 23:06:32.065926 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2019-12-22 23:06:32.067303 <I> <libusb:windows_init> UsbDk backend is not available 2019-12-22 23:06:32.106933 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-22 23:06:35.404747 <I> <network.c:304> Added new client (N: 127.0.0.1:53396, T: plain-socket, H: 948/948, B: 0, P: 0, A: disabled) 2019-12-22 23:07:22.462057 <I> <usb.c:414> Removing USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-22 23:08:19.440094 <I> <client.c:252> Client (N: 127.0.0.1:53396, T: plain-socket, H: 948/948, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-23 21:06:26.097493 <E> <usb_winapi.c:119> Could not write to notification pipe: WSAECONNABORTED (71010053) 2019-12-23 21:06:26.100215 <E> <usb_winapi.c:119> Could not write to notification pipe: WSAECONNABORTED (71010053) 2019-12-23 21:06:58.502323 <I> <network.c:304> Added new client (N: 127.0.0.1:54934, T: plain-socket, H: 896/896, B: 0, P: 0, A: disabled) 2019-12-23 21:07:14.821635 <I> <client.c:252> Client (N: 127.0.0.1:54934, T: plain-socket, H: 896/896, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-23 21:07:16.057508 <I> <network.c:304> Added new client (N: 127.0.0.1:54938, T: plain-socket, H: 952/952, B: 0, P: 0, A: disabled) 2019-12-23 21:07:20.838120 <I> <main_winapi.c:211> Received stop command 2019-12-23 21:07:26.060894 <I> <main_winapi.c:501> Brick Daemon 2.4.1+fd1 stopped 2019-12-23 21:24:48.974478 <I> <main_winapi.c:388> Brick Daemon 2.4.1+fd1 started (as service) 2019-12-23 21:24:48.975639 <W> <main_winapi.c:396> Warning(s) in config file 'C:\ProgramData\Tinkerforge\Brickd\brickd.ini', run with --check-config option for details 2019-12-23 21:24:48.991629 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2019-12-23 21:24:48.993204 <I> <libusb:windows_init> UsbDk backend is not available 2019-12-23 21:24:49.036225 <I> <usb.c:194> Added USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6wVmVp] 2019-12-23 21:24:49.185194 <I> <network.c:304> Added new client (N: 127.0.0.1:57447, T: plain-socket, H: 972/972, B: 0, P: 0, A: disabled) 2019-12-23 21:24:51.315636 <I> <client.c:252> Client (N: 127.0.0.1:57447, T: plain-socket, H: 972/972, B: 0, P: 0, A: disabled) disconnected by peer 2019-12-23 21:24:53.125924 <I> <network.c:304> Added new client (N: 127.0.0.1:57457, T: plain-socket, H: 984/984, B: 0, P: 0, A: disabled) Zitieren
photron Geschrieben January 7, 2020 at 00:16 Geschrieben January 7, 2020 at 00:16 Das Log kann in der Version (fd1) nicht mehr so explodieren, denn sobald der Fehler auftritt beendet sich brickd , anstatt die Platte vollzuschreiben. Was mich auch wundert ist, dass vor dem Fehler im Log immer lange Pause sin,. teils 22 Stunden: 2019-12-17 00:19:17 Letzte Meldung vor dem Fehler 2019-12-17 22:46:23 Fehlermeldung 2019-12-20 22:49:39 Letzte Meldung vor dem Fehler 2019-12-21 00:51:20 Fehlermeldung 2019-12-22 23:08:19 Letzte Meldung vor dem Fehler 2019-12-23 21:06:26 Fehlermeldung Kannst du noch nachvollziehen, was du zum Zeitpunkt des Fehlers am PC gemacht hast? Hast du ihn zu dem Zeitpunkt in Standby oder irgendeinen Schlafzustand geschickt, oder ihn daraus aufgeweckt? Teste mal bitte diese brickd Version (fd2) und zeig mal bitte deine brickd.ini (C:\ProgramData\Tinkerforge\Brickd\brickd.ini) Datei vor. Diese brickd Version beendet sich jetzt bei Auftreten des Fehlers nicht mehr direkt, sondern versucht den Fehler zu reparieren. Sprich das Problem wird weiterhin auftreten können, aber brickd erkennt das jetzt und versucht damit umzugehen. Das Problem sollte also im Log noch sichtbar sein, aber den Betrieb nicht mehr stören. Auch ist das Log jetzt auf 5 Dateien a 5 MB (also 25 MB gesamt) beschränkt. brickd_windows_2_4_1+fd2.exe Zitieren
eqo9wk Geschrieben April 20, 2020 at 18:34 Geschrieben April 20, 2020 at 18:34 Hallo, ich habe ein ähnliches Problem. Allerdings hat das System bereits funktioniert, seit Samstag funktioniert es leider nicht mehr. Die IMU wird im Brickviewer nicht erkannt. Die o. g. Lösungsansätze habe ich erfolglos durchprobiert. Die IMU wird korrekt im Gerätemanager fehlerlos angezeigt, an einem Win 10-Home-Rechner klappt es auch. Am Win 10-Professional-Tablet (auf dem sie schon lief) leider nicht mehr. Hier Auszüge der Log-Datei: 2020-04-20 19:38:22.024275 <I> <main_winapi.c:376> Brick Daemon 2.4.1 started (as service) 2020-04-20 19:38:22.035434 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2020-04-20 19:38:22.037397 <I> <libusb:windows_init> UsbDk backend is not available 2020-04-20 19:38:51.673132 <I> <usb.c:194> Added USB device (bus: 1, device: 5) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 19:40:48.175310 <E> <libusb:windows_transfer_callback> detected I/O error 433: [433] Ein nicht vorhandenes Gerät wurde angegeben. 2020-04-20 19:40:48.175566 <W> <usb_transfer.c:126> Read transfer 01B12160 (handle: 01B10790, submission: 3) returned with an error from IMU Brick 2.0 [6eQ7KJ]: LIBUSB_TRANSFER_ERROR (1) 2020-04-20 19:40:48.182009 <E> <libusb:windows_transfer_callback> detected I/O error 433: [433] Ein nicht vorhandenes Gerät wurde angegeben. 2020-04-20 19:40:48.182080 <W> <usb_transfer.c:126> Read transfer 01B1257C (handle: 01B108A0, submission: 4) returned with an error from IMU Brick 2.0 [6eQ7KJ]: LIBUSB_TRANSFER_ERROR (1) 2020-04-20 19:40:48.182483 <E> <libusb:windows_transfer_callback> detected I/O error 433: [433] Ein nicht vorhandenes Gerät wurde angegeben. 2020-04-20 19:40:48.182547 <W> <usb_transfer.c:126> Read transfer 01B12998 (handle: 01B109B0, submission: 5) returned with an error from IMU Brick 2.0 [6eQ7KJ]: LIBUSB_TRANSFER_ERROR (1) ... 2020-04-20 19:43:20.875218 <I> <usb.c:414> Removing USB device (bus: 1, device: 6) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 19:43:28.300357 <I> <usb.c:194> Added USB device (bus: 1, device: 7) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 19:59:08.312717 <I> <main_winapi.c:209> Received stop command 2020-04-20 19:59:08.324549 <I> <main_winapi.c:489> Brick Daemon 2.4.1 stopped 2020-04-20 19:59:09.758619 <I> <main_winapi.c:376> Brick Daemon 2.4.1 started (as service) 2020-04-20 19:59:09.765551 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2020-04-20 19:59:09.767211 <I> <libusb:windows_init> UsbDk backend is not available 2020-04-20 19:59:09.805120 <I> <usb.c:194> Added USB device (bus: 1, device: 7) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 20:00:34.782149 <I> <main_winapi.c:209> Received stop command 2020-04-20 20:00:34.793452 <I> <main_winapi.c:489> Brick Daemon 2.4.1 stopped 2020-04-20 20:01:02.908534 <I> <main_winapi.c:376> Brick Daemon 2.4.1 started (as service) 2020-04-20 20:01:02.922099 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2020-04-20 20:01:02.923548 <I> <libusb:windows_init> UsbDk backend is not available 2020-04-20 20:01:02.960692 <I> <usb.c:194> Added USB device (bus: 1, device: 7) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 20:05:20.529198 <E> <libusb:windows_transfer_callback> detected I/O error 433: [433] Ein nicht vorhandenes Gerät wurde angegeben. 2020-04-20 20:05:20.529362 <W> <usb_transfer.c:126> Read transfer 01751324 (handle: 00BEEC00, submission: 2) returned with an error from IMU Brick 2.0 [6eQ7KJ]: LIBUSB_TRANSFER_ERROR (1) 2020-04-20 20:05:20.529675 <E> <libusb:windows_transfer_callback> detected I/O error 433: [433] Ein nicht vorhandenes Gerät wurde angegeben. ... 2020-04-20 20:05:20.566342 <E> <libusb:windows_transfer_callback> detected I/O error 433: [433] Ein nicht vorhandenes Gerät wurde angegeben. 2020-04-20 20:05:20.566391 <W> <usb_transfer.c:126> Read transfer 01751740 (handle: 00BEED10, submission: 156) returned with an error from IMU Brick 2.0 [6eQ7KJ]: LIBUSB_TRANSFER_ERROR (1) 2020-04-20 20:05:20.566501 <E> <libusb:winusbx_submit_bulk_transfer> ReadPipe/WritePipe failed: [22] Das Gerät erkennt den Befehl nicht. 2020-04-20 20:05:20.566557 <E> <usb_transfer.c:300> Could not submit read transfer 01751740 (handle: 00BEED10, submission: 165) to IMU Brick 2.0 [6eQ7KJ]: LIBUSB_ERROR_IO (-1) 2020-04-20 20:05:20.620455 <I> <usb.c:414> Removing USB device (bus: 1, device: 7) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 20:05:27.565592 <I> <usb.c:194> Added USB device (bus: 1, device: 8) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 20:11:33.833839 <I> <main_winapi.c:207> Received shutdown command 2020-04-20 20:11:33.843054 <I> <main_winapi.c:489> Brick Daemon 2.4.1 stopped 2020-04-20 20:12:08.073745 <I> <main_winapi.c:376> Brick Daemon 2.4.1 started (as service) 2020-04-20 20:12:08.109371 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2020-04-20 20:12:08.319262 <I> <libusb:windows_init> UsbDk backend is not available 2020-04-20 20:12:08.932430 <I> <usb.c:194> Added USB device (bus: 1, device: 3) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 20:15:11.874746 <I> <main_winapi.c:207> Received shutdown command 2020-04-20 20:15:11.880295 <I> <main_winapi.c:489> Brick Daemon 2.4.1 stopped 2020-04-20 20:15:48.616674 <I> <main_winapi.c:376> Brick Daemon 2.4.1 started (as service) 2020-04-20 20:15:48.672392 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2020-04-20 20:15:48.760944 <I> <libusb:windows_init> UsbDk backend is not available 2020-04-20 20:15:48.973038 <I> <usb.c:194> Added USB device (bus: 1, device: 1) at index 0: IMU Brick 2.0 [6eQ7KJ] 2020-04-20 20:17:51.182255 <I> <main_winapi.c:207> Received shutdown command 2020-04-20 20:17:51.188556 <I> <main_winapi.c:489> Brick Daemon 2.4.1 stopped 2020-04-20 20:18:25.712949 <I> <main_winapi.c:376> Brick Daemon 2.4.1 started (as service) 2020-04-20 20:18:25.731330 <I> <libusb:winusbx_init> libusbK DLL is not available, will use native WinUSB 2020-04-20 20:18:25.758149 <I> <libusb:windows_init> UsbDk backend is not available 2020-04-20 20:18:25.944091 <I> <usb.c:194> Added USB device (bus: 1, device: 1) at index 0: IMU Brick 2.0 [6eQ7KJ] Zitieren
photron Geschrieben April 21, 2020 at 09:00 Geschrieben April 21, 2020 at 09:00 Nein, das ist ein anderes Problem. Das Problem vom FlyingDoc ist ein internes Socket Problem, das brickd aus dem Tritt bringt. Du hast eher einen Wackelkontakt in der USB Verkabelung der zu Fehlern in der USB Kommunikation führt. Es geht hier um eine IMU, die an einem PC funktioniert, aber an einem anderen nicht mehr? Von den Fehlermeldungen her sieht das wie gestörte USB Kommunikation aus. Da die IMU an einem PC funktioniert, gehe ich davon aus, dass das Problem nicht direkt an der IMU liegt. Ich tippe auf ein beschädigtes USB Kabel oder auf einen Wackelkontakt an der USB Buchse am PC. Verwendest du in beiden Fällen das selbe USB Kabel, oder testet du mit zwei verschiedenen USB Kabeln? Wenn du mit zwei verschiedenen USB Kabeln testet, dann teste bitte das Kabel vom funktionierenden PC am nicht-funktionierenden PC, um zu sehen ob es am Kabel liegt. Teste am nicht-funktionierenden PC andere USB Buchsen, um zu sehen ob es die eine USB Buchse ist. Teste am nicht-funktionierenden PC andere USB Geräte an der Buchse an der die IMU nicht funktioniert, um zu sehen ob es die eine USB Buchse ist. Zitieren
eqo9wk Geschrieben April 21, 2020 at 14:04 Geschrieben April 21, 2020 at 14:04 Hallo phototron, danke für die umgehende Antwort. Ja, ich nutze das gleiche USB-Kabel. Am PC super stabil. Ein getauschtes Kabel brachte keine Änderung. Das Tablet hat nur einen USB-A-Anschluss. Allerdings hängt an diesem einen Anschluss ein aktiver USB-Hub an dem mehrere "Geräte" hängen. Diese funktionieren alle. Die IMU funktioniert an diesem Tablet weder über den USB-Hub noch direkt angeschlossen. ... Jetzt habe ich über die Software "USBDeview" die gespeicherten USB-Anmeldedaten der IMU zurückgesetzt. Jetzt geht sie wieder. Danke! Zitieren
photron Geschrieben April 21, 2020 at 14:34 Geschrieben April 21, 2020 at 14:34 Windows speichert sich in der Registry Informationen zu jedem jemals angeschlossenen USB Gerät. Das diese Informationen so verfälscht/beschädigt werden können, dass das zu diesem Verhalten führt war mir nicht bekannt. Gut zu wissen. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.