[workaround] Keine Funktion GPIO/WiringPI mit Kernel 4.9.28 v7 !!!

Frank_Huber · 30 Juni 2017, 13:36:28

EDIT:

Kernel 4.9.28 v7 hat ein Problem mit WiringPI.
lässt sich auch über Google finden.

Workaround:
Kernel downgrade auf 4.4 mit

Code Auswählen

sudo rpi-update 2ca627126e49c152beb1bf7abd7122ce076dcc65

Mahlzeit,

Habe heute meine 4 Instanzen mit Updates versorgt.
Raspbian: apt-get update, apt-get dist-upgrade, sudo apt-get clean
FHEM: update
dannach unter Raspbian: sudo reboot.

So, miot dem Reboot haben auf allen 4 Raspberries die GPIOs anfangen zu spinnen.
sind alle unkontrolliert auf active.
Ergebnis waren wild fahrende Rollos und wild schaltende Lampen.

Gibt es mit aktuellen Systemen bekannte Probleme mit GPIOs?
Was kann ich wie analysieren?
Da alle 4 begonnen haben mit dem Update zu spinnen denke ich stark dass es am Update liegt.

Hat jemand eine Ahnung oder Idee woran es hängt und wie ich es lösen kann?

Hab die GPIOs mit externen Pull Up versorgt. keine Schalter betätigt da niemand zuahuse und trotzdem waren die GPIO pinlevel down.

Hilfe!

Grüße
Frank

Frank_Huber · 30 Juni 2017, 13:43:27

Nachtrag. Hab jetzt über VPN 3 der 4 raspberries runtergefahren.

Über Kamera sehe ich jetzt immernoch einen Aussen-Strahler am flackern. obwohl der RPI runtergefahren ist...

Bin grad echt ratlos. muss mir das nachher zuhause genauer ansehen.

Logfile Extrakt:

Code Auswählen

2017.06.30 13:08:20 1: Can't open file: GPIO_IN_04_Kino, active_low
2017.06.30 13:08:25 1: Can't open file: GPIO_IN_05_Werkstatt, active_low
2017.06.30 13:08:30 1: Can't open file: GPIO_IN_06_HSA, active_low
2017.06.30 13:08:35 1: Can't open file: GPIO_IN_07_Flur_KG, active_low
2017.06.30 13:08:40 1: Can't open file: GPIO_IN_08_Lager, active_low
2017.06.30 13:08:45 1: Can't open file: GPIO_IN_09_Heizung, active_low
2017.06.30 13:08:52 1: Can't open file: GPIO_IN_10_GMA_Rauch, active_low
2017.06.30 13:08:57 1: Can't open file: GPIO_IN_11_GMA_CO, active_low
2017.06.30 13:09:02 1: Can't open file: GPIO_IN_12, active_low
2017.06.30 13:09:07 1: Can't open file: GPIO_IN_13, active_low
2017.06.30 13:09:12 1: Can't open file: GPIO_IN_14, active_low
2017.06.30 13:09:17 1: Can't open file: GPIO_IN_15, active_low

Frank_Huber · 30 Juni 2017, 13:56:19

Zitat von: Frank_Huber am 30 Juni 2017, 13:43:27
Nachtrag. Hab jetzt über VPN 3 der 4 raspberries runtergefahren.

Über Kamera sehe ich jetzt immernoch einen Aussen-Strahler am flackern. obwohl der RPI runtergefahren ist...

Bin grad echt ratlos. muss mir das nachher zuhause genauer ansehen.

Logfile Extrakt:
Code Auswählen Erweitern
2017.06.30 13:08:20 1: Can't open file: GPIO_IN_04_Kino, active_low 2017.06.30 13:08:25 1: Can't open file: GPIO_IN_05_Werkstatt, active_low 2017.06.30 13:08:30 1: Can't open file: GPIO_IN_06_HSA, active_low 2017.06.30 13:08:35 1: Can't open file: GPIO_IN_07_Flur_KG, active_low 2017.06.30 13:08:40 1: Can't open file: GPIO_IN_08_Lager, active_low 2017.06.30 13:08:45 1: Can't open file: GPIO_IN_09_Heizung, active_low 2017.06.30 13:08:52 1: Can't open file: GPIO_IN_10_GMA_Rauch, active_low 2017.06.30 13:08:57 1: Can't open file: GPIO_IN_11_GMA_CO, active_low 2017.06.30 13:09:02 1: Can't open file: GPIO_IN_12, active_low 2017.06.30 13:09:07 1: Can't open file: GPIO_IN_13, active_low 2017.06.30 13:09:12 1: Can't open file: GPIO_IN_14, active_low 2017.06.30 13:09:17 1: Can't open file: GPIO_IN_15, active_low

So wie es aussieht sind nur GPIO Eingänge betroffen

Wernieman · 30 Juni 2017, 13:58:52

Hast Du "damals" an den Berechtigungen für GPIO "rumgefummelt"? Dieses könnte durchs Ubuntu-update "gelöscht" worden sein

- Ich hoffe, Du hast Dir angeguckt, was upgedatet werden sollte?
- Beim nächsten mal, mit EINEM Testen ... wenn O.K. dann erst komplett ausrollen (am besten beim Unwichtigsten)

Intruder1956 · 30 Juni 2017, 14:00:00

kann es sein das durch das dist-update evtl. Gpio deaktiviert wurde.
evtl. mal raspi config schauen

Code Auswählen

P8 Remote GPIO Enable/Disable remote access to GPIO pins

nur ein gedanke

Gruß Werner

Frank_Huber · 30 Juni 2017, 14:15:00

Rechte habe ich geprüft, die passen.

die raspi-config sieht verändert aus.
da heist es jetzt GPIO Freigabe über netzwerk!?

Murphys law. Hab bisher immer erst einen hochgezogen und dann den Rest. Das hat noch nie Probleme bereitet, jetzt alle auf einmal und klar. jetzt gibts Probleme...

Rechte sehen gut aus:

Code Auswählen


root@huber-pi-kg:/sys/class/gpio# ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Jun 30 14:16 export
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio10 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio10
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio11 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio11
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio12 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio12
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio13 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio13
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio14 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio14
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio15 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio15
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio16 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio16
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio17 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio18 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio19 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio19
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio20 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio20
lrwxrwxrwx 1 root gpio    0 Jun 30 14:15 gpio21 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio21
lrwxrwxrwx 1 root gpio    0 Jun 30 14:15 gpio22 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio22
lrwxrwxrwx 1 root gpio    0 Jun 30 14:15 gpio23 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio23
lrwxrwxrwx 1 root gpio    0 Jun 30 14:15 gpio24 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio24
lrwxrwxrwx 1 root gpio    0 Jun 30 14:15 gpio25 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio25
lrwxrwxrwx 1 root gpio    0 Jun 30 14:15 gpio26 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio26
lrwxrwxrwx 1 root gpio    0 Jun 30 14:15 gpio27 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio27
lrwxrwxrwx 1 root gpio    0 Jun 30 14:13 gpio4 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio4
lrwxrwxrwx 1 root gpio    0 Jun 30 14:13 gpio5 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio5
lrwxrwxrwx 1 root gpio    0 Jun 30 14:13 gpio6 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio6
lrwxrwxrwx 1 root gpio    0 Jun 30 14:13 gpio7 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio7
lrwxrwxrwx 1 root gpio    0 Jun 30 14:13 gpio8 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio8
lrwxrwxrwx 1 root gpio    0 Jun 30 14:14 gpio9 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio9

WiringPI ist version 2.4.4
Kernel ist version 4.9.28 v7

Frank_Huber · 30 Juni 2017, 14:34:48

mach grad kernel downgrade auf 4.4
hoffe das bringt was...

Intruder1956 · 30 Juni 2017, 14:36:53

es könnte auch am WiringPi liegen.
Ich meine mich erinnern zu können das ich vor ca. 2-3 Wochen eine S.USV eingebunden habe und dabei Probleme hatte.
WiringPi läuft nicht mit dem neuen Kernel > hatte ich bei Google gefunden
Darum habe ich meine S.USV ohne WiringPi installiert und funktioniert

Gruß Werner

und viel Erfolg

Frank_Huber · 30 Juni 2017, 14:41:19

mit kernel 4.4 läuft alles.

werd dann erstmal alle Kernel downgraden und dann testen.
WiringPI sollte ja gar nicht mehr notwendig sein.
Das wird aber erst alles auf dem Test-Raspi vollzogen.
nochmal brauch ich das nicht wie heute...

Patrik.S · 10 Juli 2017, 21:51:46

Die GPIO's werden bei Dir direkt oder über die PiFace Erweiterung angesprochen?

Zitatwild fahrende Rollos und wild schaltende Lampen.

kommt mir indirekt bekannt vor.

Meine seit langem stabile Lösung, wobei ich aber eben auch eine PiFace Erweiterung nutze, ist das Setzen des "tri" Modus der PiFace Input Pins.
In der init.d/fhem mache ich dazu direkt vor dem FHEM Start:

Code Auswählen


# für alle PiFace Inputs, den internen Pullup Widerstand aktivieren um einen stabilen Eingang zu bekommen
# ToDo: verschieben des gpio -x... Kommandos an eine andere Boot Stelle. Muss aber für und vor dem Fhem Start gemacht werden
        for i in `seq 200 207`; do sudo gpio -x mcp23s17:200:0:0 mode $i tri; done

        # normaler Start
        perl fhem.pl fhem.cfg

Warum mache ich das?

Ein gpio -P readall hatte bei mir mit dem PiFace ein Flakern/Tooglen der Inputs gezeigt, obwohl nichts angeschlossen oder geschaltet war.
Davon waren die Pins 200 - 206 betroffen, aber nie der Pin 207.

In der Shell hatte ich diese Dauerschleife ausgeführt

Code Auswählen

while (true); do clear; gpio -p readall; sleep 1; done

Und die Ausgabe zeigte immer mal eine "1" auf den genannten Input-Pins

Code Auswählen


+------+---------+--------+
| Pin | Digital | Analog |
+------+---------+--------+
| 200 | 1 | 0 |
| 201 | 1 | 0 |
| 202 | 1 | 0 |
| 203 | 1 | 0 |
| 204 | 1 | 0 |
| 205 | 1 | 0 |
| 206 | 0 | 0 |
| 207 | 0 | 0 |
| 208 | 0 | 0 |
| 209 | 0 | 0 |
| 210 | 0 | 0 |
| 211 | 0 | 0 |
| 212 | 0 | 0 |
| 213 | 0 | 0 |
| 214 | 0 | 0 |
| 215 | 0 | 0 |
+------+---------+--------+

+------+---------+--------+
| Pin | Digital | Analog |
+------+---------+--------+
| 200 | 0 | 0 |
| 201 | 0 | 0 |
| 202 | 1 | 0 |
| 203 | 1 | 0 |
| 204 | 1 | 0 |
| 205 | 1 | 0 |
| 206 | 0 | 0 |
| 207 | 0 | 0 |
| 208 | 0 | 0 |
| 209 | 0 | 0 |
| 210 | 0 | 0 |
| 211 | 0 | 0 |
| 212 | 0 | 0 |
| 213 | 0 | 0 |
| 214 | 0 | 0 |
| 215 | 0 | 0 |
+------+---------+--------+

+------+---------+--------+
| Pin | Digital | Analog |
+------+---------+--------+
| 200 | 0 | 0 |
| 201 | 0 | 0 |
| 202 | 0 | 0 |
| 203 | 0 | 0 |
| 204 | 0 | 0 |
| 205 | 0 | 0 |
| 206 | 0 | 0 |
| 207 | 0 | 0 |
| 208 | 0 | 0 |
| 209 | 0 | 0 |
| 210 | 0 | 0 |
| 211 | 0 | 0 |
| 212 | 0 | 0 |
| 213 | 0 | 0 |
| 214 | 0 | 0 |
| 215 | 0 | 0 |
+------+---------+--------+

Ja, aber warum setze ich diesen Modus und es hilft?
Weil der Entwickler mir das auf meine Anfrage hin als Tipp geraten hatte.

ZitatTry setting the internal pull-ups as this isn't done in the setup code.

Wozu brauche ich das?
Ich habe an meinen Inputs ganz simple Wassermelder realisiert, indem der Input gegen GND auf low zieht, sobald die zwei Kontakte durch Wasser verbunden werden.
Siehe https://forum.fhem.de/index.php/topic,50427.msg421780.html

Ich habe nun seit dem Mai 2017 einen 4.9'er Kernel drauf und mind. seit dem 20.06. den 4.9.28-v7 und weiterhin keine Probleme mit meinen GPIO Inputs.

Der WiringPI Entwickler hat im Dezember wegen des 4.9 Kernel ein Update gemacht auf die Version 2.44
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=167934&start=200#p1144459

Das einzige was ich tatsächlich auf einem der weiteren PIs noch zusätzlich updaten musste, wegen einer anderen Anwendung, war die erwähnte Pi4J Libary für eine Webanwendung mit dem aktuellen Snapshot 1.2 zu erneuern, siehe https://github.com/Pi4J/pi4j/issues/349

Zumindest mit der Dauerschleife für gpio -p readall könntest Du überprüfen, was deine Inputs für ein High/Low Level denken zu haben.