info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
USB-Tastatur debuggen?
1 view
Skip to first unread message
Marc Haber
Jun 17, 2021, 1:22:05 PM6/17/21
to
Hallo,
ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
mehr verstehen, sobald das Betriebssystem gebootet ist.
Der eine bootet "klassisch" direkt über die Firmware (kernel und
initrd in config.txt genannt), startet dann aber sofort ein X und in
dem X einen Browser. Bei dieser Art des Systemstarts habe ich keine
Möglichkeit, vor dem Start des Betriebssystems über die Tastatur mit
dem System zu inteagieren.
Der andere bootet eine SBBR-konforme EFI-Firmware, die dann einen grub
und der dann den Kernel (siehe
https://www.raspberrypi.org/forums/viewtopic.php?t=282839). Hier kann
ich sowohl die EFI-Firmware als auch den grub vollständig über die
Tastatur bedienen, es ist nur vorbei sobald das System läuft.
Das Betriebssystem ist jeweils Debian Unstable. Auf beiden Systemen
kann ich mich nach dem Start per ssh einloggen und ich kann auf den
Maschinen arbeiten, also auch nach Fehlern suchen. Beide Maschinen
sehen die Tastaturen in lsusb.
Ich _vermute_, dass es unterschiedliche Gründe hat, dass die
Tastaturen nicht gehen, nur mit demselben Ergebnis. Bei dem klassisch
bootenden System würde ich jetzt ungerne am Systemstart herumprökeln,
und das EFI-System ist Technologie von der blutenden Kante, da kann
sowas schonmal passieren.
Gibt es eine Möglichkeit, vor dem Tastaturtreiber zu sehen, ob da
überhaupt Events auf dem USB hereinkommen, wenn ich auf der Tastatur
Tasten drücke? Wie würde ich hier bei der Fehlersuche vorgehen?
Hier die Syslog-Einträge vom Erkennen der Tastatur beim klassisch
bootenden System:
|mh@rpi4-20210413:~$ lsusb
|Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
|Bus 001 Device 004: ID 0eef:0005 D-WAV Scientific Co., Ltd WS170120
|Bus 001 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
|Bus 001 Device 005: ID 04d9:a088 Holtek Semiconductor, Inc.
|Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
|Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
|Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
|mh@rpi4-20210413:~$
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.598923] hid: raw HID events driver (C) Jiri Kosina
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.616185] usbcore: registered new interface driver usbhid
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.625256] usbhid: USB HID core driver
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.673173] usb 1-1.2.1: new low-speed USB device number 5 using xhci_hcd
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.817120] usb 1-1.2.1: New USB device found, idVendor=04d9, idProduct=a088, bcdDevice= 1.13
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.829157] usb 1-1.2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Und hier vom EFI-System (und einer anderen Tastatur):
|zgadmin@rpi4dev:~$ lsusb
|Bus 002 Device 002: ID 8564:1000 Transcend Information, Inc. JetFlash
|Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
|Bus 001 Device 003: ID 04d9:1702 Holtek Semiconductor, Inc. Keyboard LKS02
|Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
|Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
|zgadmin@rpi4dev:~$
|Jun 17 18:17:10 rpi4dev kernel: [ 3.277825] usb 1-1.3: new low-speed USB device number 3 using xhci-hcd
|Jun 17 18:17:10 rpi4dev kernel: [ 3.424131] usb 1-1.3: New USB device found, idVendor=04d9, idProduct=1702, bcdDevice= 4.06
|Jun 17 18:17:10 rpi4dev kernel: [ 3.424143] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
|Jun 17 18:17:10 rpi4dev kernel: [ 3.424148] usb 1-1.3: Product: USB Keyboard
|Jun 17 18:17:10 rpi4dev kernel: [ 3.424152] usb 1-1.3: Manufacturer:
|Jun 17 18:17:10 rpi4dev kernel: [ 3.431984] hid: raw HID events driver (C) Jiri Kosina
|Jun 17 18:17:10 rpi4dev kernel: [ 3.475543] usbcore: registered new interface driver usbhid
|Jun 17 18:17:10 rpi4dev kernel: [ 3.475554] usbhid: USB HID core driver
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
mehr verstehen, sobald das Betriebssystem gebootet ist.
Der eine bootet "klassisch" direkt über die Firmware (kernel und
initrd in config.txt genannt), startet dann aber sofort ein X und in
dem X einen Browser. Bei dieser Art des Systemstarts habe ich keine
Möglichkeit, vor dem Start des Betriebssystems über die Tastatur mit
dem System zu inteagieren.
Der andere bootet eine SBBR-konforme EFI-Firmware, die dann einen grub
und der dann den Kernel (siehe
https://www.raspberrypi.org/forums/viewtopic.php?t=282839). Hier kann
ich sowohl die EFI-Firmware als auch den grub vollständig über die
Tastatur bedienen, es ist nur vorbei sobald das System läuft.
Das Betriebssystem ist jeweils Debian Unstable. Auf beiden Systemen
kann ich mich nach dem Start per ssh einloggen und ich kann auf den
Maschinen arbeiten, also auch nach Fehlern suchen. Beide Maschinen
sehen die Tastaturen in lsusb.
Ich _vermute_, dass es unterschiedliche Gründe hat, dass die
Tastaturen nicht gehen, nur mit demselben Ergebnis. Bei dem klassisch
bootenden System würde ich jetzt ungerne am Systemstart herumprökeln,
und das EFI-System ist Technologie von der blutenden Kante, da kann
sowas schonmal passieren.
Gibt es eine Möglichkeit, vor dem Tastaturtreiber zu sehen, ob da
überhaupt Events auf dem USB hereinkommen, wenn ich auf der Tastatur
Tasten drücke? Wie würde ich hier bei der Fehlersuche vorgehen?
Hier die Syslog-Einträge vom Erkennen der Tastatur beim klassisch
bootenden System:
|mh@rpi4-20210413:~$ lsusb
|Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
|Bus 001 Device 004: ID 0eef:0005 D-WAV Scientific Co., Ltd WS170120
|Bus 001 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
|Bus 001 Device 005: ID 04d9:a088 Holtek Semiconductor, Inc.
|Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
|Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
|Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
|mh@rpi4-20210413:~$
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.598923] hid: raw HID events driver (C) Jiri Kosina
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.616185] usbcore: registered new interface driver usbhid
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.625256] usbhid: USB HID core driver
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.673173] usb 1-1.2.1: new low-speed USB device number 5 using xhci_hcd
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.817120] usb 1-1.2.1: New USB device found, idVendor=04d9, idProduct=a088, bcdDevice= 1.13
|Jun 17 18:15:20 rpi4-20210413 kernel: [ 6.829157] usb 1-1.2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Und hier vom EFI-System (und einer anderen Tastatur):
|zgadmin@rpi4dev:~$ lsusb
|Bus 002 Device 002: ID 8564:1000 Transcend Information, Inc. JetFlash
|Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
|Bus 001 Device 003: ID 04d9:1702 Holtek Semiconductor, Inc. Keyboard LKS02
|Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
|Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
|zgadmin@rpi4dev:~$
|Jun 17 18:17:10 rpi4dev kernel: [ 3.277825] usb 1-1.3: new low-speed USB device number 3 using xhci-hcd
|Jun 17 18:17:10 rpi4dev kernel: [ 3.424131] usb 1-1.3: New USB device found, idVendor=04d9, idProduct=1702, bcdDevice= 4.06
|Jun 17 18:17:10 rpi4dev kernel: [ 3.424143] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
|Jun 17 18:17:10 rpi4dev kernel: [ 3.424148] usb 1-1.3: Product: USB Keyboard
|Jun 17 18:17:10 rpi4dev kernel: [ 3.424152] usb 1-1.3: Manufacturer:
|Jun 17 18:17:10 rpi4dev kernel: [ 3.431984] hid: raw HID events driver (C) Jiri Kosina
|Jun 17 18:17:10 rpi4dev kernel: [ 3.475543] usbcore: registered new interface driver usbhid
|Jun 17 18:17:10 rpi4dev kernel: [ 3.475554] usbhid: USB HID core driver
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Andreas Kohlbach
Jun 17, 2021, 1:45:43 PM6/17/21
to
On Thu, 17 Jun 2021 19:22:04 +0200, Marc Haber wrote:
>
> ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
> aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
> mehr verstehen, sobald das Betriebssystem gebootet ist.
Kann aus den Logs kein Problem erkennen.
>
> ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
> aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
> mehr verstehen, sobald das Betriebssystem gebootet ist.
Wenn hier aber USB abschmiert, kann ich oft brutal mittels
udevadm trigger
alles neu initialisieren. Musst Du in Deinem Fall per SSH-Zugriff (dort
natürlich root werden) machen, wenn die Tastatur lokal nicht funktioniert.
Wenn das geht, beseitigt es Dein Problem zwar nicht, umschifft es aber
bis zu einer Problemfindung.
--
Andreas
PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Marc Haber
Jun 17, 2021, 3:12:56 PM6/17/21
to
Andreas Kohlbach <a...@spamfence.net> wrote:
>On Thu, 17 Jun 2021 19:22:04 +0200, Marc Haber wrote:
>> ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
>> aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
>> mehr verstehen, sobald das Betriebssystem gebootet ist.
>
>Kann aus den Logs kein Problem erkennen.
>
>Wenn hier aber USB abschmiert, kann ich oft brutal mittels
>
>udevadm trigger
>
>alles neu initialisieren.
Das funktioniert nur wenn sich wirklich was auf dem Bus getan hat. Das
>On Thu, 17 Jun 2021 19:22:04 +0200, Marc Haber wrote:
>> ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
>> aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
>> mehr verstehen, sobald das Betriebssystem gebootet ist.
>
>Kann aus den Logs kein Problem erkennen.
>
>Wenn hier aber USB abschmiert, kann ich oft brutal mittels
>
>udevadm trigger
>
>alles neu initialisieren.
ist hier nicht der Fall, im syslog tut sich gar nichts bei diesem
Aufruf.
Aber eine schöne Idee.
>Wenn das geht, beseitigt es Dein Problem zwar nicht, umschifft es aber
>bis zu einer Problemfindung.
Markus Heinz
Jun 17, 2021, 3:34:02 PM6/17/21
to
Hallo.
Am Thu, 17 Jun 2021 19:22:04 +0200
schrieb Marc Haber <mh+usene...@zugschl.us>:
> Hallo,
>
> ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
> aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
> mehr verstehen, sobald das Betriebssystem gebootet ist.
[...]
aufzeichnen und dann z.B. mit Wireshark ansehen.
Hier zwei URLs dazu (auf Englisch):
<https://usb.ktemkin.com/usbmon>
<https://www.kernel.org/doc/html/latest/usb/usbmon.html>
Ich habe jedoch keine eigene Erfahrung in der Nutzung dieses Tools.
> Grüße
> Marc
Viele Grüße
Markus
Am Thu, 17 Jun 2021 19:22:04 +0200
schrieb Marc Haber <mh+usene...@zugschl.us>:
> Hallo,
>
> ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
> aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
> mehr verstehen, sobald das Betriebssystem gebootet ist.
> Das Betriebssystem ist jeweils Debian Unstable. Auf beiden Systemen
> kann ich mich nach dem Start per ssh einloggen und ich kann auf den
> Maschinen arbeiten, also auch nach Fehlern suchen. Beide Maschinen
> sehen die Tastaturen in lsusb.
>
> Ich _vermute_, dass es unterschiedliche Gründe hat, dass die
> Tastaturen nicht gehen, nur mit demselben Ergebnis. Bei dem klassisch
> bootenden System würde ich jetzt ungerne am Systemstart herumprökeln,
> und das EFI-System ist Technologie von der blutenden Kante, da kann
> sowas schonmal passieren.
>
> Gibt es eine Möglichkeit, vor dem Tastaturtreiber zu sehen, ob da
> überhaupt Events auf dem USB hereinkommen, wenn ich auf der Tastatur
> Tasten drücke? Wie würde ich hier bei der Fehlersuche vorgehen?
Eine Möglichkeit ist "usbmon". Damit kann man die USB-Kommunikation
> kann ich mich nach dem Start per ssh einloggen und ich kann auf den
> Maschinen arbeiten, also auch nach Fehlern suchen. Beide Maschinen
> sehen die Tastaturen in lsusb.
>
> Ich _vermute_, dass es unterschiedliche Gründe hat, dass die
> Tastaturen nicht gehen, nur mit demselben Ergebnis. Bei dem klassisch
> bootenden System würde ich jetzt ungerne am Systemstart herumprökeln,
> und das EFI-System ist Technologie von der blutenden Kante, da kann
> sowas schonmal passieren.
>
> Gibt es eine Möglichkeit, vor dem Tastaturtreiber zu sehen, ob da
> überhaupt Events auf dem USB hereinkommen, wenn ich auf der Tastatur
> Tasten drücke? Wie würde ich hier bei der Fehlersuche vorgehen?
aufzeichnen und dann z.B. mit Wireshark ansehen.
Hier zwei URLs dazu (auf Englisch):
<https://usb.ktemkin.com/usbmon>
<https://www.kernel.org/doc/html/latest/usb/usbmon.html>
Ich habe jedoch keine eigene Erfahrung in der Nutzung dieses Tools.
> Grüße
> Marc
Viele Grüße
Markus
Marc Haber
Jun 18, 2021, 3:06:32 AM6/18/21
to
Markus Heinz <markus...@uni-dortmund.de> wrote:
>Eine Möglichkeit ist "usbmon". Damit kann man die USB-Kommunikation
>aufzeichnen und dann z.B. mit Wireshark ansehen.
Oh, hübsch.
>Eine Möglichkeit ist "usbmon". Damit kann man die USB-Kommunikation
>aufzeichnen und dann z.B. mit Wireshark ansehen.
Leider habe ich auf dem ACPI-pi kein X, und auf dem DT-Pi keine
tastatur zur Bedienung des X. Wireshark über X-Forwarding ist so gut
wie unbenutzbar.
><https://www.kernel.org/doc/html/latest/usb/usbmon.html>
Auf beiden Systemen ist die Tastaur auf Bus 1. In einem cat
/sys/kernel/debug/usb/usbmon/1u sehe ich beim Ein- und Ausstecken der
Tastaturen Aktivität, nicht jedoch beim Betätigen von Tasten.
Jetzt bin ich völlig verwirrt, das kann doch nicht gleichzeitig bei
zwei Tastaturen an unterschiedlichen Systemen kaputtgegangen sein?!?
Markus Heinz
Jun 18, 2021, 3:52:48 AM6/18/21
to
Hallo.
Am Fri, 18 Jun 2021 09:06:31 +0200
schrieb Marc Haber <mh+usene...@zugschl.us>:
> Markus Heinz <markus...@uni-dortmund.de> wrote:
> >Eine Möglichkeit ist "usbmon". Damit kann man die USB-Kommunikation
> >aufzeichnen und dann z.B. mit Wireshark ansehen.
>
> Oh, hübsch.
>
> >Hier zwei URLs dazu (auf Englisch):
> >
> ><https://usb.ktemkin.com/usbmon>
>
> Leider habe ich auf dem ACPI-pi kein X, und auf dem DT-Pi keine
> tastatur zur Bedienung des X. Wireshark über X-Forwarding ist so gut
> wie unbenutzbar.
Eventuell lässt sich die USB Kommunikation in einer Datei speichern und
dann auf einem anderen Rechner mit Wireshark analysieren.
> ><https://www.kernel.org/doc/html/latest/usb/usbmon.html>
>
> Auf beiden Systemen ist die Tastaur auf Bus 1. In einem cat
> /sys/kernel/debug/usb/usbmon/1u sehe ich beim Ein- und Ausstecken der
> Tastaturen Aktivität, nicht jedoch beim Betätigen von Tasten.
>
> Jetzt bin ich völlig verwirrt, das kann doch nicht gleichzeitig bei
> zwei Tastaturen an unterschiedlichen Systemen kaputtgegangen sein?!?
Funktionieren die beiden Tastaturen denn an anderen Systemen?
Am Fri, 18 Jun 2021 09:06:31 +0200
schrieb Marc Haber <mh+usene...@zugschl.us>:
> Markus Heinz <markus...@uni-dortmund.de> wrote:
> >Eine Möglichkeit ist "usbmon". Damit kann man die USB-Kommunikation
> >aufzeichnen und dann z.B. mit Wireshark ansehen.
>
> Oh, hübsch.
>
> >Hier zwei URLs dazu (auf Englisch):
> >
> ><https://usb.ktemkin.com/usbmon>
>
> Leider habe ich auf dem ACPI-pi kein X, und auf dem DT-Pi keine
> tastatur zur Bedienung des X. Wireshark über X-Forwarding ist so gut
> wie unbenutzbar.
dann auf einem anderen Rechner mit Wireshark analysieren.
> ><https://www.kernel.org/doc/html/latest/usb/usbmon.html>
>
> Auf beiden Systemen ist die Tastaur auf Bus 1. In einem cat
> /sys/kernel/debug/usb/usbmon/1u sehe ich beim Ein- und Ausstecken der
> Tastaturen Aktivität, nicht jedoch beim Betätigen von Tasten.
>
> Jetzt bin ich völlig verwirrt, das kann doch nicht gleichzeitig bei
> zwei Tastaturen an unterschiedlichen Systemen kaputtgegangen sein?!?
Marc Haber
Jun 18, 2021, 4:51:53 AM6/18/21
to
Markus Heinz <markus...@uni-dortmund.de> wrote:
>Am Fri, 18 Jun 2021 09:06:31 +0200
>schrieb Marc Haber <mh+usene...@zugschl.us>:
>Am Fri, 18 Jun 2021 09:06:31 +0200
>schrieb Marc Haber <mh+usene...@zugschl.us>:
>> Jetzt bin ich völlig verwirrt, das kann doch nicht gleichzeitig bei
>> zwei Tastaturen an unterschiedlichen Systemen kaputtgegangen sein?!?
>
>Funktionieren die beiden Tastaturen denn an anderen Systemen?
Wie ich im ersten Artikel dieses Threads schon schrieb, kann man mit
>> zwei Tastaturen an unterschiedlichen Systemen kaputtgegangen sein?!?
>
>Funktionieren die beiden Tastaturen denn an anderen Systemen?
jeder Tastatur auf dem EFI-System sowohl die EFI-Firmware als auch den
Bootmanager bedienen, erst mit dem Start des Linux-Kernels
funktioniert es nicht mehr. Das "klassisch" bootende System hat weder
bedienbare Firmware noch Bootmanager, daher muss ich hier den Test
schuldig bleiben.
Marc Haber
Jun 25, 2021, 4:00:50 PM6/25/21
to
Marc Haber <mh+usene...@zugschl.us> wrote:
>ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
>aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
>mehr verstehen, sobald das Betriebssystem gebootet ist.
Beide Maschinen haben einen schimmligen Testkernel aus eigener Küche,
>ich habe hier zwei Raspberry Pi 4 mit zwei völlig unterschiedlich
>aufgesetzten Betriebssystemen, die beide meine USB-Tastaturen nicht
>mehr verstehen, sobald das Betriebssystem gebootet ist.
bei dem CONFIG_HID_GENERIC nicht gesetzt war. Ein "M" rein, und schon
geht's wieder.
0 new messages