Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upKernel 4.9 kworker/0 100% cpu on boot #3058
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
rtiangha
Aug 29, 2017
If you wait 10 minutes, does it stop? On first boot after installation, dracut is invoked and runs in the background until it's done. Just let it sit for a bit; it should finish eventually.
rtiangha
commented
Aug 29, 2017
|
If you wait 10 minutes, does it stop? On first boot after installation, dracut is invoked and runs in the background until it's done. Just let it sit for a bit; it should finish eventually. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
ktmdan
Aug 29, 2017
Not a problem with installation this has been working fine its just a problem with 4.9 kernel. Seems to be locking up because nouveau doing edid detection. This looks like an upstream bug.
Children Self Command Shared Object Symbol
# ........ ........ ........... ................. ..............................
#
100.00% 0.00% kworker/0:2 [kernel.kallsyms] [k] process_one_work
|
---process_one_work
|
--99.96%--nvif_notify_work
nouveau_connector_hotplug
drm_helper_hpd_irq_event
**nouveau_connector_detect**
|
|--96.63%--drm_get_edid
| |
**| |--94.37%--drm_do_get_edid**
| | drm_do_probe_ddc_edid
| | i2c_transfer
| | __i2c_transfer
| | |
| | |--89.93%--bit_xfer
| | | |
| | | |--42.12%--sclhi
| | | | |
| | | | |--27.61%--__udelay
| | | | | delay_tsc
| | | | |
| | | | |--8.83%--nvkm_i2c_bus_getscl
| | | | | |
| | | | | --8.82%--ioread32
| | | | |
| | | | --5.66%--nvkm_i2c_bus_setscl
| | | | |
| | | | --5.64%--ioread32
| | | |
| | | |--26.84%--__udelay
| | | | |
| | | | --26.84%--delay_tsc
| | | |
| | | |--10.26%--acknak
| | | | |
| | | | |--5.37%--sclhi
| | | | | |
| | | | | |--3.42%--__udelay
| | | | | | delay_tsc
| | | | | |
| | | | | |--1.19%--nvkm_i2c_bus_getscl
| | | | | | ioread32
| | | | | |
| | | | | --0.77%--nvkm_i2c_bus_setscl
| | | | | ioread32
| | | | |
| | | | |--3.89%--__udelay
| | | | | delay_tsc
| | | | |
| | | | --0.70%--nvkm_i2c_bus_setsda
| | | | ioread32
| | | |
| | | |--4.02%--nvkm_i2c_bus_setscl
| | | | |
| | | | --4.02%--ioread32
| | | |
| | | |--3.85%--nvkm_i2c_bus_getsda
| | | | |
| | | | --3.85%--ioread32
| | | |
| | | |--1.36%--try_address
| | | | i2c_outb
| | | | |
| | | | --0.67%--sclhi
| | | | |
| | | | --0.56%--__udelay
| | | | delay_tsc
| | | |
| | | --0.69%--i2c_outb
| | |
| | --4.41%--nvkm_i2c_aux_i2c_xfer
| | |
| | |--2.83%--ioread32
| | |
| | --1.57%--g94_i2c_aux_xfer
| | |
| | --1.52%--__const_udelay
| | delay_tsc
| |
| --2.26%--drm_do_probe_ddc_edid
| i2c_transfer
| __i2c_transfer
| |
| --2.00%--bit_xfer
| |
| --0.91%--try_address
| |
| --0.90%--i2c_outb
|
--3.13%--i2c_transfer
__i2c_transfer
bit_xfer
|
--1.98%--try_address
|
--1.80%--i2c_outb
|
|--0.86%--sclhi
| |
| --0.62%--__udelay
| delay_tsc
|
--0.68%--__udelay
delay_tsc
ktmdan
commented
Aug 29, 2017
•
edited by marmarek
Edited 1 time
-
marmarek
edited Aug 29, 2017 (most recent)
edited by marmarek
Edited 1 time
-
Aug 29, 2017 (most recent)
|
Not a problem with installation this has been working fine its just a problem with 4.9 kernel. Seems to be locking up because nouveau doing edid detection. This looks like an upstream bug. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
4.9.45 just hit testing repository. Check if it happens there too. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
ktmdan
commented
Aug 29, 2017
|
Yes it has fixed the issue along with other interrupt issues. Thanks! |
ktmdan
closed this
Aug 29, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ktmdan commentedAug 29, 2017
•
edited
Edited 1 time
-
ktmdan
edited Aug 29, 2017 (most recent)
Qubes OS version (e.g.,
R3.2):R3.2
Affected TemplateVMs (e.g.,
fedora-23, if applicable):dom0
Expected behavior:
System stabilizes and becomes usable after boot.
Actual behavior:
System stays in 100% cpu on dom0 processor thread
GUI is very unresponsive.
Steps to reproduce the behavior:
Boot into 4.9.35-19 kernel
General notes:
Kernel 4.4.67-13 works fine. Small lag with cursor when starting AppVMs.
Only thing odd about this system is that I'm using nouveau video driver with 3x 30" monitors on a GTX 670.
Processor: Intel i7-5820K Haswell
Memory: 36gb
Motherboard: Asus X99-A
Boot:
[4.9.35-19.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu
kernel=vmlinuz-4.9.35-19.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-xxx rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.preliminary_hw_support=1 rd.luks.allow-discards=1 intel_iommu=on trace_event=iommu iommu=pt,debug,verbose apic_verbosity=debug
ramdisk=initramfs-4.9.35-19.pvops.qubes.x86_64.img
There were some complaints about high interrupts causing the problem which doesn't appear to be the case.
Related issues: