photron Geschrieben June 20, 2012 at 10:20 Share Geschrieben June 20, 2012 at 10:20 Ich lese die mit netcat aus. Ungefaehr so: echo -n -e "\x$STACKID\x01\x04\00" | nc -w1 $HOST 4223 Deshalb kommt wahrscheinlich immer eine neue IP Connection zu stande. Diese Abfrage erfolgt im Normalfall 1 mal pro Stunde. (Im obingen Logfile waren es Testaufrufe) Ich muss hier auf Ubuntu nc mit -q1 statt -w1 verwenden, da sonst nc die Verbindung zu früh schließt. Ansonsten funktioniert das hier auch so wie erwartet. Nach dem Umstecken sieht der USB Port seit 2 Wochen so aus: USB1.1_Port -- USB2.0_Hub +-- Masterbrick_mit_0,3m_Kabel +--Webcam_mit_1m_Kabel Die Webcam laeuft problemlos weiter. USB-mäßig sollte das kein Problem sein. Wie lang ist denn das Kabel zwischen Master und Temperature Bricklet? Hast du vielleicht da ein besonders langes Kabel dran? Oder hast du was in der nähe, dass EMV-mässig stören kann, große Motoren oder Neonröhren beim Einschalten etc? Oder fallen die Aufhänger des Master zufällig mit Gewittern zusammen? Der Rambedarf hat sich vor den Abstuerzen nicht veraendert, so dann man annehmen kann, dass es kritische Stelle ueberschritten wurden. Aber mal weitergedacht: Da sich die Abstuerze/Disconnects immer schneller ereignen scheint evtl eine andere Resource zur Neige zu gehen. Welche koennte das sein? Gefühlt sollte das kein RAM Problem sein. Neue TCP/IP Connections öffnen ändert hier im Test nichts am RAM Verbrauch von brickd. Das gilt auch fürs Packets schicken zwischen Client, brickd und Brick. Es gibt wie gesagt ein Speicherleak Problem im Zusammenhang mit USB ab- und anstecken. Da bin ich gerade dabei das zu Untersuchen. Aber das kann hier nicht dein Problem sein. Ich will beim besten Willen weder dem brickd noch dem Masterbrick die Schuld an den Problemen geben, aber egal wo das Problem ist, wenn es Auftritt kann man sie nicht mehr absprechen. Deine Beschreibung, dass du manchmal brickd neustarten musst und manchmal den Master resetten musst damit es wieder geht, deutet für mich darauf hin, dass hier 2 Probleme vorliegen. Eins im Master und eins in brickd. Edit: Nachtrag. Der Masterbrick muss aber noch ansprechbar sein! Masterbrick wird noch gelistet. Zur Zeit ist der brickd "stoped". lsusb Bus 001 Device 017: ID 16d0:063d GrauTec (2. USB Port) Bus 001 Device 016: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader (2. USB Port) Bus 001 Device 014: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 (2. USB Port) Bus 001 Device 005: ID 058f:6254 Alcor Micro Corp. USB Hub (2. USB Port) Bus 001 Device 003: ID 14cd:125a Super Top (1. USB Port) Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub (System) Ich gehe davon aus, dass wenn ich den Masterbrick vom USB abziehe, dass lsusb ihn auch nicht mehr anzeigt. Dementsprechend muss noch eine Kommunikation moeglich sein. Ich hab das hier gerade nochmal mit borg besprochen und er meint dass kann durchaus sein, dass die Kommunikation des Masters hängt, aber dennoch USB soweit funktioniert dass er in lsusb noch da ist. Dein letztes Log sieht auch exakt wie erwartet aus. Da mir gerade die Ideen ausgehen, hier mal ein Vorschlag der eher in Blau hinaus geht. Falls du die Möglichkeit hast könntest du dein Temperature Bricklet mit diesem Plugin flashen: http://download.tinkerforge.com/_stuff/temperature-bricklet-100khz.bin Diese liest den Temperatur Sensor auf dem Bricklet mit 100kHz statt 400kHz aus. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben June 20, 2012 at 11:13 Autor Share Geschrieben June 20, 2012 at 11:13 Hallo photon. Ich muss hier auf Ubuntu nc mit -q1 statt -w1 verwenden, Entschuldigung, das hatte ich mal in einem anderen Beitrag geschrieben und ich wusste nicht, dass du es testen wolltest. @all Debian: -q1 schliesst Verbindung nach dem Absenden (z.b. fuer set_io4_port1) -w1 wartet noch auf Rueckantwort (z.B. fuer get_temperatur) Ubuntu: -q1 wartet auch auf Rueckantwort (z.B. fuer get_temperatur) -w1 wartet nicht ab! Ob es ueberhaupt eine Funktion hat weiss ich nicht. Wie lang ist denn das Kabel zwischen Master und Temperature Bricklet? Usb 0,3m, dann 1m zum Temp.Bricklet und 1m zum IO4 Bricklet. Oder hast du was in der nähe, dass EMV-mässig stören kann, große Motoren oder Neonröhren beim Einschalten etc? Oder fallen die Aufhänger des Master zufällig mit Gewittern zusammen? Motoren und Gewitter sind es nicht. Bei dem heutigen Absurz gegen 11:20h (siehe Logfile unten) koennte es sein, dass der ArbeitsPC eingeschaltet worden ist. Dort ist eine 10-fach Steckdosenleiste mit 200W PC, 2 Monitoren, 2 Watt Lautsprecher und einer SchreibtischNEONlampe. Phyisch ist dieser Computer ueber einen Ethernetswitch mit dem MiniPC verbunden an dem das MasterBrick haengt. Natuerlich auch uebers Stromnetz verbunden. Das koennte ein Hinweis sein, ABER das kann nicht das Problem sein als sich das Brick mitten in der Nacht verabschiedetet hat. Wird das eine Gleichung mit 3 Unbekannten oder ein Ueberraschungsei mit 3 gleichzeitigen Fehlern? Das mit dem flashen muss ich verschieben, werde ich aber mal machen. Aber kommen wir zur aktuellen Situation: Um 11:27 war es wieder soweit. Anbei das Logfile mit Kommentaren, wobei mir besonders diese Zeile auffaellt: 11:21:48 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect Was hat die zu bedeuten? Wie muss ich das Logfile ab 11:21h interpretieren? # Abruf 10:00h. OK. 10:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99977cc> 10:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 10:00:01 <INFO> <usb_device.py:311> Write to device: 1 10:00:01 <INFO> <usb_device.py:184> Write callback length: 4 10:00:01 <INFO> <usb_device.py:275> Read callback: 1 10:00:01 <INFO> <brick_protocol.py:74> Callback: 1 10:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99977cc> # Abruf 11:00h OK. 11:00:02 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99977ec> 11:00:02 <INFO> <usb_device.py:158> Add callback for message: 1 11:00:02 <INFO> <usb_device.py:311> Write to device: 1 11:00:02 <INFO> <usb_device.py:184> Write callback length: 4 11:00:02 <INFO> <usb_device.py:275> Read callback: 1 11:00:02 <INFO> <brick_protocol.py:74> Callback: 1 11:00:04 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99977ec> # Keine Aktion - Keine Abfrage - Logfile ungekuerzt. 11:21:48 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect # Warum sind hier 6 Sekunden Pause? 11:27:13 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <usb_device.py:126> Deleting USB device 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it # Abruf 12:00h nicht moeglich 12:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99946ec> 12:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99946ec> Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben June 20, 2012 at 11:38 Share Geschrieben June 20, 2012 at 11:38 Ich weiß nicht ob das mit einem der beiden Probleme zusammenhängt, aber ich habe (unter Windows) teilweise das Problem, dass der brickd sich beim ab- und anstecken der Bricks verschluckt und dann bis zum Neustart des brickd das gleiche Brick nicht mehr vom brickd erkannt wird. Das heißt unsichtbarkeit im brick-viewer und in den Bindings. War für mich bisher kein Problem, aber hilft euch vielleicht weiter... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben June 20, 2012 at 12:23 Share Geschrieben June 20, 2012 at 12:23 Okay, 1m Bricklet Kabel sind schon die längeren, da du aber nichts ungewöhnliches in der nähe hast würde ich ein EMV Problem hier mal ausschießen wollen. Das Log ist sehr interessant. "Read callback not successful (status 1): Probably disconnect" ist normal wenn du den Brick resettest oder absteckst. Die Meldung hängt mit der Funktionsweise von USB zusammen. brickd schickt für jedes USB Device 5 Read Befehle ab. Diese blockieren dann so lange bis es etwas von USB zu lesen gibt und liefern dann das Gelesene ab. Wenn jetzt der Brick resettet oder abgesteckt wird dann brechen die wartenden Read Befehle mit einen Fehler ab und genau das führt zu dieser Meldung. Das eigentliche Problem mit dieser Meldung um 11:21:48 ist aber, dass sie ohne äußeren Einwirkung in Form von Reset drücken oder Abstecken zu kommen scheint. Das ist verdächtig. Die folgenden "USB context broken, trying to fix it" Meldungen besagen, dass beim Abfragen aller USB Devices des Systems ein Fehler aufgetreten ist und brickd versucht diesen zu beheben, aber scheitert. Warum 6min zwischen "Read callback not successful" und "Removed USB device" vergehen ist mir nicht klar. Im normalen Reset ober Absteck Fall kommen die beiden Medlungen direkt nacheinander. Das du nach einem "Read callback not successful" keine Antwort mehr vom Brick bekommst ist erwartet. So ist das gerade in brickd programmiert. Du kannst das mal testweise ändern, indem du in src/brickd/usb_device.py in Zeile 304 das 'self.alive = False' auskommentierst. Dann wird nach einem solchen Fehler versucht weiterzulesen. else: # TODO: Better error handling logging.warn("Read callback not successful (status " + str(status) + "): Probably disconnect") self.alive = False # diese Zeile auskommentieren per # Da aber danach das "USB context broken, trying to fix it" im Log kommt vermute sich da USB Probleme. Dazu einige Fragen: - Welche libusb Version hast du installiert? Wir verwenden hier 1.0.8. - Welche Linux Kernel Version verwendest du da? - Hast/Hattest du das Problem auch wenn der Master direkt am Rechner angeschlossen ist ohne USB Hub da zwischen? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben June 20, 2012 at 14:33 Autor Share Geschrieben June 20, 2012 at 14:33 Hallo photron. Vielen Dank fuer die Unterstuetzung. Der PC wurde mittlerweile faelschlicher Weise ueber den Powerknopf runtergefahren und danach fuhr er sauber wieder hoch. Ich hoffe dass ich nicht wieder 2 Wochen warten muss bis das Problem auftritt. :-) Zu Deinen Fragen: Das System ist ein Debian Suqeeze "aus der Tuete". Es ist auf dem aktuellen Stand. Welche libusb Version hast du installiert? Wir verwenden hier 1.0.8. - Welche Linux Kernel Version verwendest du da? - Hast/Hattest du das Problem auch wenn der Master direkt am Rechner angeschlossen ist ohne USB Hub da zwischen? # uname -a Linux PC 2.6.32-5-486 #1 Sun May 6 03:29:22 UTC 2012 i586 GNU/Linux # cat /etc/debian_version 6.0.5 # dpkg -l| grep libusb ii libusb-0.1-4 2:0.1.12-16 userspace USB programming library ii libusb-1.0-0 2:1.0.8-2 userspace USB programming library PC# deborphan -d libusb-0.1-4 libusb-0.1-4 usbutils gnupg udev PC# deborphan -d libusb-1.0-0 libusb-1.0-0 libdc1394-22 brickd Der Masterbrick war immer mit Hub dazwischen dran. Frueher war nur die Cam dran, da brauchte man noch keine Hub. Entweder nehme ich mal einen anderen USB Hub oder haenge Cam+USBBootDevice an Port1 und Masterbrick ohne Hub an Port 2 So, nachdem nun im Moment wieder alles laeuft werde ich mir die Sache weiter ansehen. Auch die Begleitumstaende werde ich genauer beobachten und hoffentlich werden wir schlauer. Die Aenderung in "src/brickd/usb_device.py" habe ich noch nicht gemacht. Ich ueberlege ein weiteres Sytem so aufzusetzen und an einer anderen Location zu plazieren. Da muss es aber problemlos durchlaufen. :Schauder: Weiter Abstuerze werde ich "vermelden" und ueber jeden guten Tipp bin ich dankbar. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben June 20, 2012 at 15:08 Share Geschrieben June 20, 2012 at 15:08 Deine Software speziell libusb ist auf aktuellem Stand. Ich hatte jetzt fast gehofft du hättest eine alte libusb Version und wir könnten der die Probleme in die Schuhe schieben Bezüglich USB Hub. Wir hatten hier mal ein Problem mit einem USB Hub, das sich unter dmesg mit 'USB port xy disabled by hub (EMI?), re-enabling' darstellte. Diese Problem führte auch dazu, dass ein Brick nicht mehr ansprechbar war. Allerdings war er dann auch nicht mehr unter lsusb aufgeführt. Daher wäre es interessant ob unter dmesg irgendwas zu USB steht außer die zu erwartenden Connect und Disconnect Einträge für an- und abgesteckte USB Geräte. Ansonsten ist natürlich weiterhin interessant was im brickd Log steht wenn das Problem auftritt. Sieht das immer so aus wie dein letztes kommentiertes Log? Wir kommen dem Problem schon noch auf die Spur Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben June 20, 2012 at 16:15 Autor Share Geschrieben June 20, 2012 at 16:15 Hallo photron. Daher wäre es interessant ob unter dmesg irgendwas zu USB steht außer die zu erwartenden Connect und Disconnect Einträge für an- und abgesteckte USB Geräte. "dmesg" zeigt mir nur die Eintraege an die seit dem letzen Boot reingeschrieben wurden, also kann ich zu dem Haenger nichts sagen. Unter /var/log/dmesg.* finde ich nur alte Files, die durch das automatische Backup gesichert worden sind. Wo sollte das dmesg von VOR dem aktuellen re-boot sein? Ansonsten ist natürlich weiterhin interessant was im brickd Log steht wenn das Problem auftritt. Sieht das immer so aus wie dein letztes kommentiertes Log? Das hatte ich bei den letzten Abstuerzen noch nicht an. Also muss man auf den naechsten Absturz warten. BTW: Koenntet ihr bitte das Datum mit ins Logfile schreiben! Anstelle von: "20:53:22 <INFO> <usb_device.py:113> Adding read transfer" Dies bitte daraus machen: "20120620_20:53:22 <INFO> <usb_device.py:113> Adding read transfer" Ich schliesse keine Wette ab woran es liegt. Ich habe schon viele Geister gesucht und ich bin auch gespannt in welchen Verlies wir rauskommen. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben June 20, 2012 at 16:38 Share Geschrieben June 20, 2012 at 16:38 Ah, sorry. Ich meinte dmesg und das Log nicht für die letzten Abstürzen, sondern für mögliche zukünftige Logeinträge mit Datum zu versehen ist in git schon passiert und die nächste brickd Version wird es beinhalten. Bis dahin kannst du in config.py das Datumsformat manuell ändern: LOGGING_DATEFMT = "%H:%M:%S" durch LOGGING_DATEFMT = "%Y-%m-%d %H:%M:%S" ersetzen. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben June 20, 2012 at 16:49 Autor Share Geschrieben June 20, 2012 at 16:49 Hallo photron, danke fuer den Tip. :-) Kommt aber erst beim naechsten start des brickd zum tragen. Bis dahin warten wir und harren der Dinge die da kommen. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben June 25, 2012 at 12:26 Autor Share Geschrieben June 25, 2012 at 12:26 Hallo photron, nun war es wieder soweit. Seit 5 Tagen war Ruhe, bzw. alles lief reibungslos. Die letzten Abfragen der Temperaturwerte von heute. Einmal pro Stunde: 20120625_04:00:03;1340589603;23.56 20120625_05:00:04;1340593204;23.56 20120625_06:00:03;1340596803; 20120625_07:00:03;1340600403; 20120625_08:00:03;1340604003; 20120625_09:00:03;1340607603; 20120625_10:00:03;1340611203; /var/log/brickd. Siehe 5:05h!! # 4:00h Abfrage OK. 04:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99dd0cc> 04:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 04:00:01 <INFO> <usb_device.py:311> Write to device: 1 04:00:01 <INFO> <usb_device.py:184> Write callback length: 4 04:00:01 <INFO> <usb_device.py:275> Read callback: 1 04:00:01 <INFO> <brick_protocol.py:74> Callback: 1 04:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99dd0cc> # 5:00h Abfrage OK. 05:00:02 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99dd0cc> 05:00:02 <INFO> <usb_device.py:158> Add callback for message: 1 05:00:02 <INFO> <usb_device.py:311> Write to device: 1 05:00:02 <INFO> <usb_device.py:184> Write callback length: 4 05:00:02 <INFO> <brick_protocol.py:74> Callback: 1 05:00:02 <INFO> <usb_device.py:275> Read callback: 1 05:00:04 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99dd0cc> # WIE JEDEN MORGEN um 5:05h wurde durch ein "Avocent PM10*" eine 230V 0,5W LED Lampe angeschaltet. #Das Ding macht (im Moment) nichts anders. Das An/Aus passiert 2 mal am Tag. #Es gab in den letzen Tagen keine Probleme. 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect # Keine Abfrage moeglich 06:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99dd0cc> 06:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 06:00:01 <INFO> <usb_device.py:311> Write to device: 1 06:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99dd0cc> # Keine Abfrage moeglich 07:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99dd12c> 07:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 07:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99dd12c> *) Avocent PM10 PC:~#lsusb Bus 001 Device 006: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 005: ID 16d0:063d GrauTec Bus 001 Device 004: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 001 Device 003: ID 14cd:125a Super Top Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub dmesg hat keine USB Eintraege. Letzer dmesg Eintrag 2 Stunden nach dem booten vor 5 Tagen. Mein Ueberlegungen bisher: Es gibt zwei unterschiedliche Weghaenger: Zum einen ist nur das USB Device nicht ansprechbar, zum anderen nur haengt sich der USB Bus weg. Ein Stop und Start des brick hat diesmal geholfen. Ein Resetknopfdruck am Masterbrick war nicht notwendig. Manchmal muss aber auch der Resetknopf gedrueckt werden. Nochmaldruebernachdenk: Letzens ist das Problem zeitlich mit dem Einschalten des "grossen" PC mit Schreibtischlampe zusammengefallen (2m entfernt), diesmal mit dem Einschalten einer winzigen LED Lampe ueber eine professionelle Remotebox direkt in der Naehe. (Ja, da ist ein Ralais drin). Sind die (Bricklet-)Kabel doch Antennen? Ist das evtl. doch ein EMV Thema? Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben June 25, 2012 at 13:12 Share Geschrieben June 25, 2012 at 13:12 Vom Log her sieht das Problem exakt so aus wie beim letzten Mal. Der Read Callback ist fehlgeschlagen und dann ging nix mehr. Das ein Neustart von brickd reicht um das Problem zu beheben deutet darauf hin, dass brickd da möglicherweise zu pessimistisch ist. Mich interessiert sehr ob meine vorgeschlagene Änderung in usb_device.py ('self.alive = False' in Zeile 304 auskommentieren) nicht schon reicht um einen Teil es Problems zu beheben. Nämlich den Teil bei dem in brickd Neustart alleine hilft. Nochmaldruebernachdenk: Letzens ist das Problem zeitlich mit dem Einschalten des "grossen" PC mit Schreibtischlampe zusammengefallen (2m entfernt), diesmal mit dem Einschalten einer winzigen LED Lampe ueber eine professionelle Remotebox direkt in der Naehe. (Ja, da ist ein Ralais drin). Sind die (Bricklet-)Kabel doch Antennen? Ist das evtl. doch ein EMV Thema? Das ist möglich, es gibt hier im Forum in paar Leute die definitiv mit EMV Probleme haben. Wir denken da im Moment über Lösungen nach wie man das längerfristig hardware- und softwaremäßig robuster machen kann im Hinblick auf EMV. Das ist allerdings nichts was eben auf die Schnelle geht. Du könntest mal Xennas Lösung testen. Da hat es geholfen die Bricks und Bricklets in eine Keksdose aus Metal zu stecken und so zu schirmen: http://www.tinkerunity.org/forum/index.php/topic,601.msg4008.html#msg4008 Das mag für deine Temperaturmessung nicht die idealste Lösung sein Ansonsten kann ich nur nochmal raten die 100kHz Firmware für das Temperature Bricklet bei Gelegenheit zu testen. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben June 26, 2012 at 14:24 Autor Share Geschrieben June 26, 2012 at 14:24 Hallo photron, Das mag für deine Temperaturmessung nicht die idealste Lösung sein Herzlichen Dank fuer Dein Verstaendniss! So nun habe ich die eine Zeile auskommentiert. Ich bin beim brickd v 1.0.7 geblieben. (Keine 2 Aenderungen auf einmal) Die Datei ist: /usr/share/brickd/usb_device.py Die Zeile ist aber die 281 (nicht 304). Zur Sicherheit: logging.info("Read callback: " + str(type)) else: # TODO: Better error handling logging.warn("Read callback not successful (status " + str(status) + "): Probably disconnect") ##Zeile281 self.alive = False try: transfer.submit() except libusb1.USBError: logging.warn("Transfer exception: Probably disconnect") self.alive = False Nun warten und Tee trinken. Die 100kHz Firmware kann ich im Moment nicht einspielen, wobei diese erste Option erstmal seine Wirkung zeigen kann. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben June 26, 2012 at 14:38 Share Geschrieben June 26, 2012 at 14:38 Okay, das ist das richtige self.alive = False. Meine Erwartung ist, dass du mit dieser Zeile auskommentiert jetzt immer noch diesen spontanen "Read callback not successful (status 1): Probably disconnect" Fehler im Log sehen wirst, danach die Temperaturabfrage dennoch weiter funktioniert. Bin gespannt ob sich das bestätigt. PS: Ich trink hier gerade Pfefferminztee mit Zitrone Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben July 8, 2012 at 11:13 Autor Share Geschrieben July 8, 2012 at 11:13 Hallo photron, so nun bin ich wieder da und kann den Beitrag verfassen. Das Problem ist letzte Woche wieder aufgetaucht. Dabei hat sich sogar ein Teil des USB Busses weggehaengt. Aus der Ferne konnte ich nur den Rechner rebooten, was aber keinen Erfolgt hatte. Der Masterbrick ist trotz zweiter Reboots nicht erreichbar. Ich gehe davon aus, dass ein Druck auf den Resetknopft am Masterbrick das Problem sofort loest. Also der Reihe nach. Das "self.alive = False." ist so eingetragen. So sieht der lsusb normalerweise aus (Kopie aus voherigem Posting): PC:~#lsusb Bus 001 Device 006: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Port 2 Bus 001 Device 005: ID 16d0:063d GrauTec Port 2 Bus 001 Device 004: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Port 2 Bus 001 Device 003: ID 14cd:125a Super Top Port 1 Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub Port 2 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Port root Nun /var/log/brickg.log von besagter Problemzeit. In voller Laenge, aber es ist trotzdem ueberschaubar. Normalerweise wird jede Stunde einmal das Temperaturbricklet abgefragt. 2 mal am Tag wird eine 230V LED Lampe via RS232 Schittstelle an und ausgeschaltet. # 5:00h Bricklet Abfrage noch ok. 2012-07-03 05:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x9b2d0ac> 2012-07-03 05:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 2012-07-03 05:00:01 <INFO> <usb_device.py:311> Write to device: 1 2012-07-03 05:00:01 <INFO> <usb_device.py:184> Write callback length: 4 2012-07-03 05:00:01 <INFO> <brick_protocol.py:74> Callback: 1 2012-07-03 05:00:01 <INFO> <usb_device.py:275> Read callback: 1 2012-07-03 05:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x9b2d0ac> # Hier geht das Problem los. Wieder 5:05h. Als die 230V LED Leuchte, via RS232, eingeschaltet wurde. 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:286> Transfer exception: Probably disconnect 2012-07-03 05:05:03 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:03 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:03 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <INFO> <usb_device.py:126> Deleting USB device 2012-07-03 05:05:04 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:06 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:06 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device # Hier laeuft die erste Abfrage nach dem Problem um 6:00h in Leere. 2012-07-03 06:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x9b268ec> 2012-07-03 06:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x9b268ec> 2012-07-03 07:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x9b26f6c> 2012-07-03 07:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x9b26f6c> 2012-07-03 08:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x9b269cc> 2012-07-03 08:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x9b269cc> # PC rebooted. USB devices nicht erreichtbar. Siehe lsusb. 2012-07-03 08:32:08 <INFO> <brickd_linux.py:76> brickd started # Anfrage laeuft ins leere, da USB Devices nicht verfuegbar. Siehe lsusb. 2012-07-03 09:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa562dac> 2012-07-03 09:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa562dac> # PC erneut rebooted 2012-07-03 09:28:08 <INFO> <brickd_linux.py:76> brickd started # Jede Stunde laeuft die Anfrage ins Leere. ... u.s.w. 2012-07-03 10:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa08cdac> 2012-07-03 10:00:04 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa08cdac> 2012-07-03 11:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 11:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 12:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 12:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 13:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 13:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa09206c> lsusb sieht nach dem 1. und 2. Reboot so aus: PC:/# lsusb Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Was nun tun? Ich wuerde gerne nur mal den Resetknopf am Masterbrick druecken und dann schauen on sich die Devices wieder melden oder hast du eine andere Idee? Ich gehe davon aus, das bei einem Reboot des PC die 5 Volt Versorgungsspannung fuer die USB Ports nicht unterbrochen wird (Sicher bin ich mir aber nicht). Das koennte erklaeren warum ein haengender Masterbrick (oder anderes USB Device) auch nach dem Reboot den Bus blockiert. Soll man das Problem mit der installierten Firmware (brickd 1.0.7) weiter versuchen einzugrenzen oder die aktuelle Firmware + brickd aufspielen? Viele Gruesse Der Loetkolben. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben July 9, 2012 at 15:14 Autor Share Geschrieben July 9, 2012 at 15:14 Hallo, hier der Nachtrag direkt von der Hardware: Druck auf den Resetknopf am Brick. Das Ergebnis: lsusb Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Kein erfolg also. 2. Druck auf Resetknopf: Gleiches Ergebnis: Kein Erfolg. Masterbrick vom Strom getrennt (Usb Kabel abgezogen und angesteckt): Kein Erfolg. USB Hub (an dem das Masterbrick, die Cam und ein Reader haengen) aus dem USB Port vom PC gezogen und wieder angesteckt. Ergebnis: Alles ok. lsusb Bus 001 Device 010: ID 16d0:063d GrauTec Bus 001 Device 009: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 008: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 001 Device 007: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Was lernen wir das daraus? Ich weiss es nicht. Ist es der Hub oder der USB Port selbst? Oder wird der Bus nur durch einen externen Event abgeschossen? Dies zur ersten Info. Das Problem wird weiterbeobachtet und ich muss mir erstmal gedanken ueber dieses Ergebnis machen. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 10, 2012 at 08:36 Share Geschrieben July 10, 2012 at 08:36 Zusammengefasst: Das Schalten der Lampe um 5:05 Uhr für dazu das im Log abrupt ein "Read callback not successful (status 1): Probably disconnect" auftaucht. Danach funktioniert die Temperaturabfrage nicht mehr. Dass die Abfrage nach dem "Read callback not successful" nicht mehr funktioniert ist mir klar warum. Da ist dann die Kommunikation zwischen brickd und Master abgerissen. Das "self.alive = False" hat erstmal nicht geschadet hat aber auch nichts gebracht, weil da dann auch noch ein "Transfer exception: Probably disconnect" im Log kommt. Das "usb context broken, trying to fix it" hängt mit einem Bug in python-libusb zusammen. Es bedeute im Endeffekt, dass die unterliegende C libusb ein Problem mit dem Auflisten von USB Geräten hat. Das muss robuster werden, ich arbeite daran. In deinem Fall spielt das aber denke ich keine Rolle. Das in diesem Fall erst dass ab- und anstecken des USB Hubs es wieder zum funktionieren gebracht hat deutet darauf hin, dass sich diesmal der USB Hub aufgehängt hat. Da das jetzt schon mehrfach mit dem Schalten der Lampe zusammengefallen ist könnte das ein EMV Problem sein. Die Frage ist nun wer hier dem Empfindliche ist. Es könnte der Master sein. Nach deinem Bericht über den Hub könnte es aber auch der Hub sein und könnte es schon immer gewesen sein. Je nachdem wie stark sich der Hub verschluckt reißt mal nur die Verbindung zum Master ab, mal hängt sich der ganz Hub auf. Da kann man jetzt mehreres testen: - Master ohne Hub anschließen - Master in die Blechdose - Hub in die Blechdose Welche räumliche bzw. verkabelungsmäßige Nähe haben denn der Rechner an dem der Hub hängt, der Hub selbst, der Master, das Avocent PM10 und die Lampe? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben July 12, 2012 at 18:02 Autor Share Geschrieben July 12, 2012 at 18:02 Hallo photron, danke fuer die Analyse und Hilfestellung. Da das jetzt schon mehrfach mit dem Schalten der Lampe zusammengefallen ist könnte das ein EMV Problem sein. Die Frage ist nun wer hier dem Empfindliche ist. Sehe ich auch so. Ist es die 230V LED Lampe oder die Neonschreibtischlampe oder eine sonstige Spannungsspitzenquelle? ... Am 10.7.2012 gab es den naechsten Ausfall. Kurzzusammenfassung: Brickd stop/start brachte nichts. Ein Druck auf den Resetknopf am Master hat geholfen. Diesmal musste keine Hardware abgestoepselt werden! Einzige Auffaelligkeit: Zwischen 22:00h und 23:00h wurde der "grosse" PC mit "Neon"schreibtischlampe angeschaltet. Er ist ca. 2 Meter entfernt und nur via Ethernet/Switch und Stromleitung mit dem Masterbrick-PC verbunden. Im dmesg waren diesbezueglich keine Eintraege. Die Logs im Detail: # 22:00h Abfrage OK. 2012-07-10 22:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa0990ac> 2012-07-10 22:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 2012-07-10 22:00:01 <INFO> <usb_device.py:311> Write to device: 1 2012-07-10 22:00:01 <INFO> <usb_device.py:184> Write callback length: 4 2012-07-10 22:00:01 <INFO> <usb_device.py:275> Read callback: 1 2012-07-10 22:00:01 <INFO> <brick_protocol.py:74> Callback: 1 2012-07-10 22:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa0990ac> # Zwischen 22:00h und 23:00h wurde der "grosse" PC mit "Neon"schreibtischlampe angeschaltet. Er ist ca. 2 Meter entfernt und nur via Ethernet/Switch und Stromleitung mit dem Masterbrick-PC verbunden. # Abfragen waren nicht mehr moeglich. 2012-07-10 23:00:02 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa0990ac> 2012-07-10 23:00:02 <INFO> <usb_device.py:158> Add callback for message: 1 2012-07-10 23:00:02 <INFO> <usb_device.py:311> Write to device: 1 2012-07-10 23:00:02 <INFO> <usb_device.py:184> Write callback length: 4 2012-07-10 23:00:04 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa0990ac> # dto. Keine Abfrage moeglich. 2012-07-11 00:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa09916c> 2012-07-11 00:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 2012-07-11 00:00:01 <INFO> <usb_device.py:311> Write to device: 1 2012-07-11 00:00:01 <INFO> <usb_device.py:184> Write callback length: 4 2012-07-11 00:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa09916c> lsusb vor dem Druck auf den Masterbrick Resetknopf: PC:/var/log# lsusb Bus 001 Device 010: ID 16d0:063d GrauTec Bus 001 Device 009: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 008: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 001 Device 007: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub lsusb nach dem Druck auf dem Resetknopf am Masterbrick. Es hat sich nur die GrauTec ID geaendert. Zugriff war sofort wieder moeglich. PC:/var/log# lsusb Bus 001 Device 011: ID 16d0:063d GrauTec Bus 001 Device 009: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 008: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 001 Device 007: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Hat nun der Hub oder Masterbrick ein Problem? Als naechstes ueberlegen wir den Hub mit Cam (an diesem Port) wegzulassen. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben July 13, 2012 at 15:36 Autor Share Geschrieben July 13, 2012 at 15:36 Zwei weitere Ausfaelle gleicher Art. Durch einschalten des entfernt stehenden PC scheint der Ausfall erneut ausgeloest worden sein. Problemloesung wie oben: Brickd stop/start brachte keine Erfolg. Ein Druck auf den Resetknopf des Masterbrick und der Zugriff funktionierte wieder. Die Logfiles schenke ich mir, da keine neue Information dort enthalten sind. Wir folgen der 1. Idee von photron: Masterbrick ohne Hub. Wir werden jetzt an den 2. USB port NUR den Masterbrick stecken. Die Cam wird sich mit dem der SDCard einen Port teilen. Die Lage der Kabel versuchen wir so zu lassen wie sie sind. USB Anschluss bisher: USBPORT1 --- CARDREADER + SDCARD USBPORT2 --- HUB + CARDREADER_inside_HUB + CAM + MASTERBRICK + 1m --- TempBricklet + 1m --- IO4 Bricklet USB Anschluss neu, wobei Masterbrick "solo" am USB Port haengt. USBPORT1 --- HUB + CARDREADER_inside_HUB + SDCARD + CAM USBPORT2 --- MASTERBRICK + 1m --- TempBricklet + 1m --- IO4 Bricklet Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
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.