Virtueller Rechner mit Grafik

jsffm · 1. August 2017

bzw. gestartet?

kls · 1. August 2017

Danke, 3PO! Manchmal muß man einfach mit der Nase draufgestoßen werden ;-).
Es war zwar jede Menge libvirt-* Zeug installiert, aber "libvirt" selber nicht.
Hab's installiert und neu gebootet, und jetzt kann's weiter gehen... :-).

Klaus

hopsi · 1. August 2017

Zitat von 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

kls · 1. August 2017

zgrep XEN /proc/config.gz

hopsi · 1. August 2017

dann taugt der Kernel sowohl für dom0 als auch für domU.

Christian

kls · 1. August 2017

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.103

Beim 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.174

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?

Klaus

iNOB · 1. August 2017

Yes. Guggst du hier.

Gruß
iNOB

kls · 1. August 2017

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

menuentry '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
}

Alles anzeigen

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

udobroemme · 1. August 2017

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. :).

kmoss · 1. August 2017

Zitat von kls

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

Spoiler anzeigen

Werde es auch mit der Linuxvariante vom XenCenter versuchen.

hopsi · 1. August 2017

Zitat von kls

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

xen ~ # 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 ~ #

Alles anzeigen

governor ist bei mir auf ondemand:

Code

xen ~ # 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

Alles anzeigen

Christian

kls · 2. August 2017

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

speefak · 2. August 2017

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

iNOB · 2. August 2017

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

HTPC-Schrauber · 3. August 2017

Zitat von kls

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

kls · 3. August 2017

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 RPM

Gibt es für die CPU-Temperatur auch einen "Durchgriff" auf die Hardware? Hab leider nichts dazu gefunden.

Klaus

hopsi · 3. August 2017

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.

Spoiler anzeigen

Code

xen ~ # 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

Alles anzeigen

Christian

HTPC-Schrauber · 3. August 2017

acpitz-virtual-0 klingt in der Tat nach irgendwas Virtuellem.

Hast Du sensors-detect ausgeführt?

kls · 3. August 2017

Ja, sensors-detect hab ich gemacht. Hat aber nichts gefunden:

sensors-detect --auto

Code

# 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.

Alles anzeigen

Klaus

hopsi · 4. August 2017

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

Virtueller Rechner mit Grafik

Jetzt mitmachen!

Teilen