bzw. gestartet?
Virtueller Rechner mit Grafik
-
- [Virtualisierung]
- kls
-
-
-
Irgendwie scheine ich mit XEN kein Glück zu haben.
Ich habe jetzt opeenSUSE 42.3 und das XEN-Paket installiert. Im Boot-Menü kann ich wählen zwischen dem normalen und dem XEN-Kernel. Allerdings melden beide bei 'uname -a' das Gleiche:Linux linux-7117 4.4.76-1-default #1 SMP Fri Jul 14 08:48:13 UTC 2017 (9a2885c) x86_64 x86_64 x86_64 GNU/Linux
Was gibt 'zgrep XEN /proc/config.gz' denn aus?
Christian
-
Code
Alles anzeigenCONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PVHVM=y # CONFIG_XEN_512GB is not set CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y CONFIG_XEN_PVH=y CONFIG_PCI_XEN=y CONFIG_XEN_PCIDEV_FRONTEND=m CONFIG_XEN_BLKDEV_FRONTEND=m CONFIG_XEN_BLKDEV_BACKEND=m CONFIG_XEN_SCSI_FRONTEND=m CONFIG_NETXEN_NIC=m CONFIG_XEN_NETDEV_FRONTEND=m CONFIG_XEN_NETDEV_BACKEND=m CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m CONFIG_HVC_XEN=y CONFIG_HVC_XEN_FRONTEND=y CONFIG_TCG_XEN=m CONFIG_XEN_WDT=m CONFIG_XEN_FBDEV_FRONTEND=m CONFIG_USB_XEN_HCD=m # CONFIG_MMC_SDHCI_XENON is not set CONFIG_XEN_BALLOON=y # CONFIG_XEN_SELFBALLOONING is not set CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y CONFIG_XEN_BALLOON_MEMORY_HOTPLUG_LIMIT=512 CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=m CONFIG_XEN_BACKEND=y CONFIG_XENFS=m CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=y CONFIG_XEN_GNTDEV=m CONFIG_XEN_GRANT_DEV_ALLOC=m CONFIG_SWIOTLB_XEN=y CONFIG_XEN_TMEM=m CONFIG_XEN_PCIDEV_BACKEND=m CONFIG_XEN_SCSI_BACKEND=m CONFIG_XEN_PRIVCMD=m CONFIG_XEN_ACPI_PROCESSOR=m CONFIG_XEN_MCE_LOG=y CONFIG_XEN_HAVE_PVMMU=y CONFIG_XEN_EFI=y CONFIG_XEN_AUTO_XLATE=y CONFIG_XEN_ACPI=y CONFIG_XEN_SYMS=y CONFIG_XEN_HAVE_VPMU=y
-
dann taugt der Kernel sowohl für dom0 als auch für domU.
Christian
-
Der Weg zu XEN scheint ein Steiniger zu sein...
Wenn ich den normalen Kernel boote, dann wird die CPU-Frequenz dynamisch geregelt:
grep MHz /proc/cpuinfo:
cpu MHz : 1019.974
cpu MHz : 1000.092
cpu MHz : 1237.151
cpu MHz : 2155.583
cpu MHz : 2653.104
cpu MHz : 2006.667
cpu MHz : 1003.861
cpu MHz : 1000.103Beim XEN-Kernel sieht das so aus:
cpu MHz : 2904.174
cpu MHz : 2904.174
cpu MHz : 2904.174
cpu MHz : 2904.174
cpu MHz : 2904.174
cpu MHz : 2904.174
cpu MHz : 2904.174
cpu MHz : 2904.174Das heißt, dort laufen alle Kerne immer mit maximaler Frequenz, was sich natürlich auch in entsprechender Wärmeentwicklung äussert.
Ist das bei XEN grundsätzlich so, oder kann man das irgendwo einstellen?Klaus
-
-
Danke. Ich wollte jetzt mal, wie auf dieser Seite angegeben, "cpufreq=dom0-kernel" beim Booten angeben, aber das ist ja auch alles nicht mehr so klar und übersichtlich, wie es mal war :-(. Die Datei /boot/grub2/grub.cfg wird aus verschiedensten Quellen generiert, und ich weiß echt nicht, wo ich da "cpufreq=dom0-kernel" einfügen sollte. Also hab ich es einfach mal direkt in /boot/grub2/grub.cfg reingeschrieben (auch wenn man das eigentlich nicht soll ;-):
Code
Alles anzeigenmenuentry 'openSUSE Leap 42.3, with Xen hypervisor' --class opensuse --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-1468d90d-6f46-4791-9c43-a171814b69e9' { insmod part_gpt insmod ext2 set root='hd0,gpt1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1' 1468d90d-6f46-4791-9c43-a171814b69e9 else search --no-floppy --fs-uuid --set=root 1468d90d-6f46-4791-9c43-a171814b69e9 fi echo 'Loading Xen 4.9.0_08-2 ...' if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then xen_rm_opts= else xen_rm_opts="no-real-mode edd=off" fi #multiboot /boot/xen-4.9.0_08-2.gz placeholder vga=gfx-1024x768x16 ${xen_rm_opts} multiboot /boot/xen-4.9.0_08-2.gz placeholder vga=gfx-1024x768x16 ${xen_rm_opts} cpufreq=dom0-kernel echo 'Loading Linux 4.4.76-1-default ...' module /boot/vmlinuz-4.4.76-1-default placeholder root=UUID=1468d90d-6f46-4791-9c43-a171814b69e9 resume=/dev/disk/by-uuid/66f8765b-ee54-4a00-95d7-6b78a83b1e62 splash=silent quiet showopts echo 'Loading initial ramdisk ...' module --nounzip /boot/initrd-4.4.76-1-default }
Ob das aber wirklich die richtige Stelle ist, ist fraglich, denn nach einem Reboot liefen immer noch alle CPUs mit maximaler Frequenz. Wobei ich das in der dom0 auflisten lasse, falls das wichtig sein sollte. Erstmal muß die dom0 vernünftig laufen, bevor es überhaupt Sinn macht, weiterzumachen...Klaus
-
So weit mir bekannt, trägt man bei openSUSE den Parameter in der /etc/default/grub bei GRUB_CMDLINE_LINUX_DEFAULT="... ein und führt dann grub2-mkconfig aus. Das überlebt dann auch das nächste Suse-Update. :).
-
Der Weg zu XEN scheint ein Steiniger zu sein...
Das Durchreichen der einzigen GraKa ging bei mir mit dem XenCenter besser als erwartet. Anbei ein inxi vom KUbuntu-ISO
inxi -v2
Code
Alles anzeigenSystem: Host: kubuntu Kernel: 4.10.0-19-generic x86_64 (64 bit) Desktop: KDE Plasma 5.9.4 Distro: Ubuntu 17.04 Machine: Device: xen System: MSI product: MS-7971 v: 1.0 Mobo: N/A model: N/A BIOS: American Megatrends v: 1.B0 date: 05/11/2017 CPU(s): 2 Single core Intel Core i5-6500s (-HT-SMP-) speed: 3202 MHz (max) Graphics: Card-1: Intel HD Graphics 530 Card-2: Device 1234:1111 Display Server: X.Org 1.19.3 drivers: modesetting (unloaded: fbdev,vesa) Resolution: 1920x1080@60.00hz GLX Renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2) GLX Version: 3.0 Mesa 17.0.3 Network: Card: Failed to Detect Network Card! Drives: HDD Total Size: NA (-) ID-1: model: N/A Info: Processes: 163 Uptime: 2 min Memory: 720.6/3946.6MB Client: Shell (bash) inxi: 2.3.8
Werde es auch mit der Linuxvariante vom XenCenter versuchen.
-
Das heißt, dort laufen alle Kerne immer mit maximaler Frequenz, was sich natürlich auch in entsprechender Wärmeentwicklung äussert.
Ist das bei XEN grundsätzlich so, oder kann man das irgendwo einstellen?Wenn ich mich nicht irre, siehst Du in dom0 genauso wie in domU nur virtuelle CPUs, vcpus. dom0 ist da letztendlich nur eine privillegierte domU, unter all dem ist der hypervisor. dom0 also neben den domU, nicht unter diesen.
Bei mir macht der hypervisor das power-management, den Unterschied der Frequenzen sieht man in der dom0:
Code
Alles anzeigenxen ~ # grep MHz /proc/cpuinfo && xenpm get-cpufreq-states|grep current cpu MHz : 3398.912 cpu MHz : 3398.912 cpu MHz : 3398.912 cpu MHz : 3398.912 cpu MHz : 3398.912 cpu MHz : 3398.912 cpu MHz : 3398.912 cpu MHz : 3398.912 current frequency : 800 MHz current frequency : 800 MHz current frequency : 3401 MHz current frequency : 2500 MHz current frequency : 3401 MHz current frequency : 800 MHz current frequency : 800 MHz current frequency : 800 MHz xen ~ #
governor ist bei mir auf ondemand:
Code
Alles anzeigenxen ~ # xenpm get-cpufreq-para 0 cpu id : 0 affected_cpus : 0 cpuinfo frequency : max [3401000] min [800000] cur [800000] scaling_driver : acpi-cpufreq scaling_avail_gov : userspace performance powersave ondemand current_governor : ondemand ondemand specific : sampling_rate : max [10000000] min [10000] cur [20000] up_threshold : 80 scaling_avail_freq : 3401000 3400000 3200000 3000000 2800000 2700000 2500000 2300000 2100000 1900000 1700000 1500000 1400000 1200000 1000000 *800000 scaling frequency : max [3401000] min [800000] cur [800000] turbo mode : enabled
Christian
-
hopsi: stimmt, das sehe ich mit den (inzwischen wieder hergestellten) Standardeinstellungen hier auch. Dann muß die Wärmeentwicklung wohl von was Anderem gekommen sein (es war gestern sehr heiß hier ;-).
Allerdings verstehe ich nicht, warum in /proc/cpuinfo nicht gleich die richtigen Werte ausgegeben werden. Sowas führt doch nur zu Verwirrung. Gleiches sollte sich immer gleich verhalten...
Klaus
-
ich frage mich gerade warum so kompliziert ...
Die Zeit, die in die Xen und co Virtualisierung gesteckt wurde, und eine Lösung scheint immer noch nicht in Sicht ... da ist es doch viel effektiver sich ein NAS ( HP Microserver ) in den Keller zu stellen, Datenbanken und OS etc. auf die SSD zu speichern und als Storage HDDs rein - fertig. 215 mb/s sind mit LAN Aggregation kein Thema und viel mehr schaffen die Billig SSDs auch nicht. Ich hatte vor der o.g. Lösung auch an Paravirtualisung gedacht aber aus genau den im Thread genannten Gründen mich dann für eine dedizierte Server Client/Desktop Lösung entschieden. Mein HP Microserver ist mit einer 2x DVB-S2 Karte an der Schüssel angebunden, die vdr Installation mit vnsi streaming für die clients verwaltet und streamt alles im netzwerk, NAS Daten werden via autofs/sshfs eingebunden. OMV gabs beim Aufsetzen des o.g. Systems nur auf Debian 7 Basis, Debian 8 war schon draußen und so hab ich auch OMV weggelassen.
Die ganzen Software Lösungen wie Virtualisierung OMV und co sind alle schön und gut aber je komplizierter ein System, je fehleranfälliger ist es auch. Virtualisierung nutze ich auf meinem Desktopsystem zwar auch, aber die Speicherpfade bzw. Virtualboximages liegen direkt auf dem NAS. So habe ich de facto einmal ~200mb/s für die VMS und nochmal 400 mb/s fürs native System auf der verbauten SSD. Virtualbox und das Virtualbox Webinterface sind auf dem NAS als Backup installiert, sodass ich bei einem Desktopausfall die VMs auch über das NAS starten oder Routing VMs im Headlessmodus permanent laufen lassen kann.
Video Konvertierung z.b. läuft dann je nach Zeitvorgabe auf dem Dekstop in der VM oder auf dem NAS in der VM. Wie jetzt im Urlaub ist der Desktop Rechner aus und das NAS konvertiert Videos, Strombilanztechnisch sicher auch etwas günstiger als den Desktop laufen zu lassen.PS : ne uptime von 560 Tagen ... gabs da keine kernelupdates ? 1,5 Jahre ohne Kernelupdate kann ein Sicherheitsrisiko sein
PSS : wenns natürlich um das herumspielen mit ParaVMs geht und der Erfolg das Ziel ist o.g. Lösung nicht das Gelbe vom Ei
-
Wenn man es einmal verstanden hat, ist das mit XEN gar nicht so schwer. Ubuntu Server 16.04 LTS als Basis für die Dom0 genommen, entsprechende Config für die Domus erstellt und schon kann man sich auslassen. Liegt halt immer am eigenen Ermessen, ob man seine Zeit für so etwas opfern möchte. By the way... mein erster XEN-Server hatte knapp 2 Jahre Uptime
-
Allerdings verstehe ich nicht, warum in /proc/cpuinfo nicht gleich die richtigen Werte ausgegeben werden. Sowas führt doch nur zu Verwirrung. Gleiches sollte sich immer gleich verhalten...
Du sitzt einem Missverständnis auf.
Bei Xen hast Du es mit einem Klasse 1 Hypervisor zu tun. D.h. die Dom0, in die das System bootet, ist selbst nur eine VM. Diese ist zwar zur Verwaltung des Hypervisors privilegiert, aber dennoch nur eine VM.
Auf /proc/cpuinfo siehst Du also letztlich auch nur eine virtuelle CPU, nicht den direkten Durchgriff auf die physische.
Der Kernel der Dom0 läuft selbst nur unter Kontrolle des Hypervisors.
Willst Du wissen, was das Powermangement der physischen Maschine macht, dann musst Du den Hypervisor fragen und nicht den Kernel der virtuellen Maschine (in dem Fall Dom0).
Das geht dann mit xenpm.
Wenn Du Powermanagement für die Dom0 einrichtest, dann machst Du Powermanagement für eine virtuelle Maschine (was eher sinnfrei ist).Gleiches passiert, wenn Du z.B. mit Top schauen willst, was auf der Maschine so los ist. Du siehst nur Prozesse Deiner VM. In dem Falle also Prozesse der Dom0.
Willst Du wissen, was insgesamt auf der Maschine los ist, dann musst Du xentop verwenden. Das greift auf die Daten des Hypervisors zurück und liefert damit echte Werte.Dieser Umstand ist bei Xen erstmal etwas verwirrend. Daran muss man sich gewöhnen.
Diese vermeintliche Unsinnigkeit kommt daher, das die Verwaltungsinstanz für den Xen Hypervisor eben eine Linux-Instanz ist (eben die Dom0), aber eben selbst nur eine VM.Um es noch mehr zu verdeutlichen:
Man kann und sollte der Dom0 auch nicht alle CPUs zugestehen. Sie braucht die normalerweise gar nicht. Meistens reicht für die Dom0 eine vCPU. Dann siehst Du dort und /proc/cpuinfo auch nur eine CPU.
Noch deutlicher beim Arbeitspeicher:
Die Dom0 sollte im Arbeitspeicher beschränkt werden (je nach Aufgaben reicht 1 GB). Damit sieht man in der Dom0 auch wieder nur den zugewiesenen Speicher.
Lässt man der Dom0 den vollen Arbeitspeicher, dann hat das folgenden Effekt:
Immer, wenn ein Gast gestartet wird, muss der Arbeitsspeicher der Dom0 erst reduziert werden. Damit welcher für den Gast frei ist.
Der Gast läuft ja nicht als Prozess auf der Dom0, sondern als eigentständige VM neben der Dom0. Also muss der Dom0 Speicher erst weggenommen werden, um ihn dem neuen Gast zuzuweisen.Mehr dazu hier: https://wiki.xenproject.org/wiki/Tuning_Xen_for_Performance
-
Danke, das war mir so in der Tiefe nicht klar. Ich dachte die "dom0" sei "die physikalische Maschine".
Das dürfte dann wohl auch der Grund sein, warum "sensors" immer die gleichen Werte liefert, obwohl sich die Belastung der CPU ändert:
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +119.0°C)
temp2: +29.8°C (crit = +119.0°C)asus-isa-0000
Adapter: ISA adapter
cpu_fan: 0 RPMGibt es für die CPU-Temperatur auch einen "Durchgriff" auf die Hardware? Hab leider nichts dazu gefunden.
Klaus
-
Klaus, die sensoren sollte korrekte Werte liefern, wenn die passenden Sensoren abgefragt werden. acpitz-virtual-0 klingt da erst mal verdächtig falsch.
Die Werte bei Abfrage in der dom0 ändern sich bei mir auch, wenn ich etwas Last in einer domU erzeuge.
Code
Alles anzeigenxen ~ # sensors coretemp-isa-0000 Adapter: ISA adapter Package id 0: +48.0°C (high = +80.0°C, crit = +100.0°C) Core 0: +45.0°C (high = +80.0°C, crit = +100.0°C) Core 1: +43.0°C (high = +80.0°C, crit = +100.0°C) Core 2: +48.0°C (high = +80.0°C, crit = +100.0°C) Core 3: +43.0°C (high = +80.0°C, crit = +100.0°C) nct6776-isa-0290 Adapter: ISA adapter Vcore: +0.90 V (min = +0.00 V, max = +1.74 V) in1: +1.85 V (min = +0.00 V, max = +0.00 V) ALARM AVCC: +3.44 V (min = +0.00 V, max = +0.00 V) ALARM +3.3V: +3.42 V (min = +0.00 V, max = +0.00 V) ALARM in4: +0.94 V (min = +0.00 V, max = +0.00 V) ALARM in5: +1.69 V (min = +0.00 V, max = +0.00 V) ALARM in6: +0.90 V (min = +0.00 V, max = +0.00 V) ALARM 3VSB: +3.44 V (min = +0.00 V, max = +0.00 V) ALARM Vbat: +3.30 V (min = +0.00 V, max = +0.00 V) ALARM fan1: 1045 RPM (min = 0 RPM) fan2: 1158 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 1719 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +44.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor CPUTIN: +22.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN: +30.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor PECI Agent 0: +48.0°C (high = +80.0°C, hyst = +75.0°C) (crit = +100.0°C) PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C PCH_MCH_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled xen ~ # sensors coretemp-isa-0000 Adapter: ISA adapter Package id 0: +56.0°C (high = +80.0°C, crit = +100.0°C) Core 0: +52.0°C (high = +80.0°C, crit = +100.0°C) Core 1: +52.0°C (high = +80.0°C, crit = +100.0°C) Core 2: +52.0°C (high = +80.0°C, crit = +100.0°C) Core 3: +49.0°C (high = +80.0°C, crit = +100.0°C) nct6776-isa-0290 Adapter: ISA adapter Vcore: +0.90 V (min = +0.00 V, max = +1.74 V) in1: +1.85 V (min = +0.00 V, max = +0.00 V) ALARM AVCC: +3.42 V (min = +0.00 V, max = +0.00 V) ALARM +3.3V: +3.42 V (min = +0.00 V, max = +0.00 V) ALARM in4: +0.94 V (min = +0.00 V, max = +0.00 V) ALARM in5: +1.69 V (min = +0.00 V, max = +0.00 V) ALARM in6: +0.90 V (min = +0.00 V, max = +0.00 V) ALARM 3VSB: +3.44 V (min = +0.00 V, max = +0.00 V) ALARM Vbat: +3.30 V (min = +0.00 V, max = +0.00 V) ALARM fan1: 1052 RPM (min = 0 RPM) fan2: 1153 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 1719 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +45.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor CPUTIN: +22.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN: +30.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor PECI Agent 0: +55.0°C (high = +80.0°C, hyst = +75.0°C) (crit = +100.0°C) PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C PCH_MCH_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled
Christian
-
acpitz-virtual-0 klingt in der Tat nach irgendwas Virtuellem.
Hast Du sensors-detect ausgeführt?
-
Ja, sensors-detect hab ich gemacht. Hat aber nichts gefunden:
Code
Alles anzeigen# sensors-detect revision 6284 (2015-05-31 14:00:33 +0200) # Board: ASUSTeK COMPUTER INC. Q170T # Kernel: 4.4.76-1-default x86_64 # Processor: Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz (6/158/9) Running in automatic mode, default answers to all questions are assumed. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors... No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 16h thermal sensors... No AMD Family 15h power sensors... No AMD Family 16h power sensors... No Intel digital thermal sensor... No Intel AMB FB-DIMM thermal sensor... No Intel 5500/5520/X58 thermal sensor... No VIA C7 thermal sensor... No VIA Nano thermal sensor... No Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes Found unknown chip with ID 0xd121 (logical device B has address 0x290, could be sensors) Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Some systems (mainly servers) implement IPMI, a set of common interfaces through which system health data may be retrieved, amongst other things. We first try to get the information from SMBIOS. If we don't find it there, we have to read from arbitrary I/O ports to probe for such interfaces. This is normally safe. Do you want to scan for IPMI interfaces? (YES/no): Probing for `IPMI BMC KCS' at 0xca0... No Probing for `IPMI BMC SMIC' at 0xca8... No Some hardware monitoring chips are accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Lastly, we can probe the I2C/SMBus adapters for connected hardware monitoring devices. This is the most risky part, and while it works reasonably well on most systems, it has been reported to cause trouble on some systems. Do you want to probe the I2C/SMBus adapters now? (YES/no): Found unknown SMBus adapter 8086:a123 at 0000:00:1f.4. Sorry, no supported PCI bus adapters found. Next adapter: i915 gmbus dpc (i2c-0) Do you want to scan it? (yes/NO/selectively): Next adapter: i915 gmbus dpb (i2c-1) Do you want to scan it? (yes/NO/selectively): Next adapter: i915 gmbus dpd (i2c-2) Do you want to scan it? (yes/NO/selectively): Next adapter: DPDDC-D (i2c-3) Do you want to scan it? (yes/NO/selectively): Next adapter: SMBus I801 adapter at f040 (i2c-4) Do you want to scan it? (YES/no/selectively): Client found at address 0x50 Probing for `Analog Devices ADM1033'... No Probing for `Analog Devices ADM1034'... No Probing for `SPD EEPROM'... No Probing for `EDID EEPROM'... No Client found at address 0x52 Probing for `Analog Devices ADM1033'... No Probing for `Analog Devices ADM1034'... No Probing for `SPD EEPROM'... No Sorry, no sensors were detected. Either your system has no sensors, or they are not supported, or they are connected to an I2C or SMBus adapter that is not supported. If you find out what chips are on your board, check http://www.lm-sensors.org/wiki/Devices for driver status.
Klaus -
Vermutung: Kernel: 4.4 ist etwas alt für Kaby Lake. 4.4 ist aus Januar 2016, Kaby Lake wurde erst 2017 vorgestellt.
Da fehlen dann wohl die Treiber für Sensoren auf Board und Prozessor. Würde auf 4.10 oder gleich 4.11 wechseln.
Christian
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!