Feature #1348
open
Feature #1344: Hardware/Inventarisierung: Masterplan
lspci als JSON
100%
Description
Mach mal...
Updated by Jannik Schönartz about 4 years ago
lspci hat selber auch keine Möglichkeit JSON auszugeben, aber es gibt den Parameter "-mm" (Produce machine-readable output).
Das Beispiel kommt vom Pool-PC "zeft9003".
$ lspci -vmm
Slot: 00:00.0
Class: Host bridge
Vendor: Intel Corporation
Device: 8th Gen Core Processor Host Bridge/DRAM Registers
SVendor: Fujitsu Technology Solutions
SDevice: Device 124a
Rev: 07
Slot: 00:02.0
Class: VGA compatible controller
Vendor: Intel Corporation
Device: Device 3e92
SVendor: Fujitsu Technology Solutions
SDevice: Device 124a
Slot: 00:12.0
Class: Signal processing controller
Vendor: Intel Corporation
Device: Cannon Lake PCH Thermal Controller
SVendor: Fujitsu Technology Solutions
SDevice: Device 1246
Rev: 10
Slot: 00:14.0
Class: USB controller
Vendor: Intel Corporation
Device: Cannon Lake PCH USB 3.1 xHCI Host Controller
SVendor: Fujitsu Technology Solutions
SDevice: Device 1246
Rev: 10
ProgIf: 30
Slot: 00:14.2
Class: RAM memory
Vendor: Intel Corporation
Device: Cannon Lake PCH Shared SRAM
SVendor: Fujitsu Technology Solutions
SDevice: Device 1246
Rev: 10
Slot: 00:16.0
Class: Communication controller
Vendor: Intel Corporation
Device: Cannon Lake PCH HECI Controller
SVendor: Fujitsu Technology Solutions
SDevice: Device 1246
Rev: 10
Slot: 00:17.0
Class: SATA controller
Vendor: Intel Corporation
Device: Cannon Lake PCH SATA AHCI Controller
SVendor: Fujitsu Technology Solutions
SDevice: Device 1246
Rev: 10
ProgIf: 01
Slot: 00:1d.0
Class: PCI bridge
Vendor: Intel Corporation
Device: Cannon Lake PCH PCI Express Root Port 9
Rev: f0
Slot: 00:1f.0
Class: ISA bridge
Vendor: Intel Corporation
Device: Device a306
SVendor: Fujitsu Technology Solutions
SDevice: Device 1246
Rev: 10
Slot: 00:1f.3
Class: Audio device
Vendor: Intel Corporation
Device: Cannon Lake PCH cAVS
SVendor: Fujitsu Technology Solutions
SDevice: Device 1247
Rev: 10
Slot: 00:1f.4
Class: SMBus
Vendor: Intel Corporation
Device: Cannon Lake PCH SMBus Controller
SVendor: Fujitsu Technology Solutions
SDevice: Device 1246
Rev: 10
Slot: 00:1f.5
Class: Serial bus controller [0c80]
Vendor: Intel Corporation
Device: Cannon Lake PCH SPI Controller
SVendor: Fujitsu Technology Solutions
SDevice: Device 1246
Rev: 10
Slot: 00:1f.6
Class: Ethernet controller
Vendor: Intel Corporation
Device: Ethernet Connection (7) I219-LM
SVendor: Fujitsu Technology Solutions
SDevice: Ethernet Connection (7) I219-LM
Rev: 10
Slot: 01:00.0
Class: Non-Volatile memory controller
Vendor: Samsung Electronics Co Ltd
Device: NVMe SSD Controller SM981/PM981
SVendor: Samsung Electronics Co Ltd
SDevice: Device a801
ProgIf: 02
NUMANode: 0
Updated by Simon Rettberg about 4 years ago
-m sieht gut aus. Vermutlich wird das hier am einfachsten sein:
# lspci -mn 00:00.0 "0600" "1002" "5950" -r10 "103c" "280a" 00:01.0 "0604" "1002" "5a3f" "" "" 00:07.0 "0604" "1002" "5a39" "" "" 00:12.0 "0106" "1002" "4380" -p01 "103c" "2812" 00:13.0 "0c03" "1002" "4387" -p10 "103c" "280a" 00:13.1 "0c03" "1002" "4388" -p10 "103c" "280a" 00:13.2 "0c03" "1002" "4389" -p10 "103c" "280a" 00:13.5 "0c03" "1002" "4386" -p20 "103c" "280a" 00:14.0 "0c05" "1002" "4385" -r13 "103c" "280a" 00:14.1 "0101" "1002" "438c" -p8f "103c" "280a" 00:14.3 "0601" "1002" "438d" "103c" "280a" 00:14.4 "0604" "1002" "4384" -p01 "" "" 00:18.0 "0600" "1022" "1100" "" "" 00:18.1 "0600" "1022" "1101" "" "" 00:18.2 "0600" "1022" "1102" "" "" 00:18.3 "0600" "1022" "1103" "" "" 01:05.0 "0300" "1002" "5974" "103c" "280a" 01:05.1 "0380" "1002" "5874" "103c" "280b" 3f:00.0 "0200" "14e4" "167b" -r02 "103c" "280a"
Updated by Jannik Schönartz over 3 years ago
- Status changed from New to Closed
- Assignee changed from BAS-Crew to Jannik Schönartz
- % Done changed from 0 to 100
Wurde mit commit implementiert.
Ich habe dafür lspci -mn benutzt und dann ein json draus gebastelt. Das sieht dann folgendermaßen aus:
Updated by Jannik Schönartz over 3 years ago
- Assignee changed from Jannik Schönartz to Simon Rettberg
- % Done changed from 100 to 90
Ist es wirklich einfcher, den parameter "-n" zu benutzen und nicht direkt die strings zu nehmen?
Ich müsste sonst fürs iDoIT das selber parsen oder gibt es da eine gescheite Schnittstelle, so dass man immer eine aktuelle Liste im json-Format bekommt?
Updated by Steffen Ritter over 3 years ago
- Status changed from Closed to Feedback
Updated by Simon Rettberg over 3 years ago
- Assignee changed from Simon Rettberg to Jannik Schönartz
Ohne -n wird standardmäßig die DB der Distro genutzt, es gibt auch noch einen Switch, um alles frisch nachzuschlagen. Manchmal gibts da halt noch Korrekturen im Nachhinein. Wenn du die IDs nicht mitspeicherst kannst du dann z.B. schlecht nach Rechnern mit identischen Karten suchen. Daher Ruft das der Sat zur Anzeige periodisch neu ab; dort könnte man nachgucken wie das geht (irgendwo im statistics Modul), sonst gibts da bestimmt auch ein fertiges Paket im NPM was einem dann mal geschmeidig noch 400 andere Dependencies reinholt :-)
Updated by Jannik Schönartz over 3 years ago
- Assignee changed from Jannik Schönartz to Simon Rettberg
Klingt plausibel.
Es gibt zwar eine NPM-Lib aber die hat selber 0 dependencies (und einen komischen Methodenaufruf).
Da schreib ich doch dann lieber ne eigene, in der ich noch ein paar dependencies schaffen kann. ;)
Ich zieh mir dann einfach immer wieder mal die aktuellste Liste von https://github.com/pciutils/pciids
Updated by Jannik Schönartz about 3 years ago
Also ich habe mit 763c5bd4 mal eine lib geschrieben, welche die aktuelle PCI-ID Liste aus dem pciids-GIT herunterlädt, parsed und passende Funktionen zur Verfügung stellt.
Ich letzte Woche mal an meinem MSI-Laptop gearbeitet und habe festgestellt, dass lspci bzw. die Hersteller unfug treiben.
Laut der manpage von lspci:
slot, class, vendor name, device name, subsystem vendor name and subsystem name
Das Problem sind die Subvendor ID und Subsystem ID.
Hier mal das Beispiel von meinem MSI Laptop.
Man sieht deutlich, dass die letzten zwei IDs fast immer "1462" und "1102" sind.
"1462" steht hier für "Micro-Star International Co., Ltd. [MSI]", also hat der Hersteller vom Laptop sich bei den meisten Geräten einfach als Subvendor eingetragen.
Aber ich sehe nicht, woher die subsystem id "1102" kommt.
Lässt man in lspci die strings anzeigen, dann schreibt lspci den Subvendor ganz normal rein und bei der subsystem id kommt einfach noch mal der normale Device-Name.
Das sorgt allerdings dafür, dass es für die selben Kombinationen aus Subvendor ID und Subsystem ID unterschiedliche strings bei raus kommen.
Hier mal der Output mit -mnn, da steht hinter dem string auch noch direkt die jeweilige ID.
- "Micro-Star International Co., Ltd. [MSI] [1462]" "Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [1102]"
- "Micro-Star International Co., Ltd. [MSI] [1462]" "4th Gen Core Processor Integrated Graphics Controller [1102]"
- [168c] Vendor: Qualcomm Atheros
- [003e] Device: QCA6174 802.11ac Wireless Network Adapter
- [1a56] Subvendor: Bigfoot Networks, Inc.
- [1525] Subsystem: Killer N1525 Wireless-AC
Vermutlich ist das sinnvollste, wenn keine passende Kombination für Subvendor + Subsystem gefunden wird, es einfach zu ignorieren.
Updated by Simon Rettberg over 2 years ago
Semi-related, wir bräuchten noch die Zugehörigkeit von PCI-Geräten zu iommu-Gruppen. Woher nehmen und nicht stehlen?
lspci ist selbst in Ubuntu 21.04 noch zu alt für json output, plus keine Ahnung ob das da drin wäre. Eine dreckige Lösung wäre, den dmesg output zu parsen, und wiederum in den lspci-output reinzuballern, oder als extra Sektion, ka was schöner ist.
root@bwpc6-2-mini:~# dmesg | grep -i "iommu group" [ 1.486305] pci 0000:00:00.0: Adding to iommu group 0 [ 1.486313] pci 0000:00:02.0: Adding to iommu group 1 [ 1.486320] pci 0000:00:04.0: Adding to iommu group 2 [ 1.486330] pci 0000:00:12.0: Adding to iommu group 3 [ 1.486341] pci 0000:00:14.0: Adding to iommu group 4 [ 1.486348] pci 0000:00:14.2: Adding to iommu group 4 [ 1.486358] pci 0000:00:16.0: Adding to iommu group 5 [ 1.486364] pci 0000:00:16.3: Adding to iommu group 5 [ 1.486372] pci 0000:00:17.0: Adding to iommu group 6 [ 1.486394] pci 0000:00:1b.0: Adding to iommu group 7 [ 1.486410] pci 0000:00:1f.0: Adding to iommu group 8 [ 1.486417] pci 0000:00:1f.3: Adding to iommu group 8 [ 1.486424] pci 0000:00:1f.4: Adding to iommu group 8 [ 1.486431] pci 0000:00:1f.5: Adding to iommu group 8 [ 1.486438] pci 0000:00:1f.6: Adding to iommu group 8 [ 1.486459] pci 0000:01:00.0: Adding to iommu group 9
Updated by Jannik Schönartz over 2 years ago
lspci wird ja aktuell eh im python skript manuell geparsed, kann aber die iommu group eh nicht ausgeben.
Ich würde es trotzdem an der stelle im lspci hinzufügen. Ich denke das ist cleaner, als nochmal extra eine Struktur nach pci-interfaces anzulegen.
Mein Vorschlag wäre sich via find die ganzen Pfäde ausgeben zu lassen und daraus die info zu holen:
$ find /sys/kernel/iommu_groups/*/devices/* /sys/kernel/iommu_groups/0/devices/0000:00:00.0 /sys/kernel/iommu_groups/1/devices/0000:00:12.0 /sys/kernel/iommu_groups/2/devices/0000:00:14.0 /sys/kernel/iommu_groups/2/devices/0000:00:14.2 /sys/kernel/iommu_groups/3/devices/0000:00:16.0 /sys/kernel/iommu_groups/4/devices/0000:00:17.0 /sys/kernel/iommu_groups/5/devices/0000:00:1d.0 /sys/kernel/iommu_groups/6/devices/0000:00:1f.0 /sys/kernel/iommu_groups/6/devices/0000:00:1f.3 /sys/kernel/iommu_groups/6/devices/0000:00:1f.4 /sys/kernel/iommu_groups/6/devices/0000:00:1f.5 /sys/kernel/iommu_groups/6/devices/0000:00:1f.6 /sys/kernel/iommu_groups/7/devices/0000:01:00.0
Hab das so mal ins Skript reingepackt und commited
Im lspci Objekt gibt es dann (falls vorhanden) einfach ein weiteres feld namens "iommu_group".
Der Gruppenname ist aktuell als String gespeichert, könnte man allerdings auch als int speichern.
So sieht dann das fertige lspci objekt aus.
Updated by Simon Rettberg over 2 years ago
Kaputt und es kommt gar kein JSON bei mir:
Traceback (most recent call last):
File "collect_hw_info_json.py", line 318, in <module>
main()
File "collect_hw_info_json.py", line 287, in main
_collecthw['lspci'] = get_lspci()
File "collect_hw_info_json.py", line 114, in get_lspci
iommu_raw = run_subprocess('find /sys/kernel/iommu_groups/*/devices/*').split('\n')
AttributeError: 'bool' object has no attribute 'split'
Updated by Jannik Schönartz over 2 years ago
Da ist mir wohl eine kleiner check durch die lappen gegangen. Fixed
Updated by Simon Rettberg over 2 years ago
K cool das geht jetzt, mir fiel aber grad noch auf, dass ein DVD-Laufwerk auch als HDD erkannt wird.... Mal noch gucken woran das liegt. Müsste dann früher aber auch schon kaputt gewesen sein.
Updated by Simon Rettberg over 2 years ago
Traceback (most recent call last):
File "/opt/openslx/system-check/collect_hw_info_json.py", line 320, in <module>
main()
File "/opt/openslx/system-check/collect_hw_info_json.py", line 286, in main
_collecthw['drives'] = get_disk_info()
File "/opt/openslx/system-check/collect_hw_info_json.py", line 93, in get_disk_info
disks = listdir(diskdir)
FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-path/'
Updated by Simon Rettberg over 2 years ago
Wäre gut, wenn bei den Netzwerkdaten noch der Link Speed bei steht.
Updated by Jannik Schönartz over 2 years ago
Wegen dem error hab ich mal noch ein paar checks eingebaut (FIX)
Sollte also behoben sein.
Laufwerk und Link Speed schau ich mir dann am Dienstag an.
Updated by Jannik Schönartz over 2 years ago
Network speed habe ich zu den "net"-Infos hinzugefügt (commit)
Für die CD/DVD-Situation fand ich wodim nicht so gut.
Scheint eine veraltete Abzweigung von cdrtools zu sein.
Alternativ kann man doch einfach die Daten aus /proc/sys/dev/cdrom/info holen oder spricht da etwas dagegen?
So sieht da der output von der Datei aus:
CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: sr1 sr0 drive speed: 48 48 drive # of slots: 1 1 Can close tray: 1 1 Can open tray: 1 1 Can lock tray: 1 1 Can change speed: 1 1 Can select disk: 0 0 Can read multisession: 1 1 Can read MCN: 1 1 Reports media changed: 1 1 Can play audio: 1 1 Can write CD-R: 1 1 Can write CD-RW: 1 1 Can read DVD: 1 1 Can write DVD-R: 1 1 Can write DVD-RAM: 1 1 Can read MRW: 1 1 Can write MRW: 1 1 Can write RAM: 1 1
Geparsed hab ich das ganze auch schon mal (commit, wobei das neue Skript bisher nur auf meinem Rechner lokal (mit 2 eingesteckten Laufwerken) getestet wurde.
Parsed /proc/sys/dev/cdrom/info
Passt das so?