Hola usuario de nuestro sitio, tenemos la respuesta a lo que estabas buscando, desplázate y la encontrarás más abajo.
Solución:
Encontré este hilo en lkml que responde un poco a tu pregunta. (Parece que incluso el propio Linus estaba desconcertado sobre cómo averiguar el origen de esos hilos).
Básicamente, hay dos formas de hacer esto:
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)
Para esto, necesitará que ftrace esté compilado en su kernel y habilitarlo con:
mount -t debugfs nodev /sys/kernel/debug
En la documentación de ftrace.txt se encuentra disponible más información sobre las funciones de rastreo de funciones de Linux.
Esto mostrará lo que están haciendo todos los subprocesos y es útil para rastrear múltiples trabajos pequeños.
cat /proc/THE_OFFENDING_KWORKER/stack
Esto generará la pila de un solo hilo haciendo mucho trabajo. Puede permitirle averiguar qué causó que este hilo específico acaparara la CPU (por ejemplo). THE_OFFENDING_KWORKER es el pid del kworker en la lista de procesos.
La solución es: no sé cómo encontrar la causa. Nadie me lo dijo hasta ahora.
Pero hablar con los desarrolladores de BTRFS reveló un error en los controladores btrfs al escribir muchos archivos pequeños en un período de tiempo muy corto. Este es un problema en kernels desde 3.0 hasta 3.1. Tal vez se solucione en 3.2.
Mientras tanto, obtuve un parche para el kernel actual que resolvió el problema.
Tuve un problema similar; mirando la pila de hilos del kworker:
while true ; do clear ; grep -n ^ /proc/24910/stack | sort -rn | cut -d: -f 2- ; sleep 1 ; done
[] 0xffffffffffffffff
[] kthread+0x0/0xe0
[] ret_from_fork+0x42/0x70
[] kthread+0x0/0xe0
[] kthread+0xc1/0xe0
[] worker_thread+0x0/0x550
[] worker_thread+0x53/0x550
[] process_one_work+0x14b/0x420
[] rpm_idle+0x1ad/0x220
[] __rpm_callback+0x2d/0xb0
[] usb_runtime_idle+0x26/0x30 [usbcore]
[] usb_runtime_idle+0x0/0x30 [usbcore]
[] __pm_runtime_suspend+0x5c/0x90
[] __pm_runtime_idle+0x69/0x90
[] rpm_suspend+0x105/0x620
[] rpm_callback+0x1f/0x70
[] __rpm_callback+0x2d/0xb0
[] usb_runtime_suspend+0x0/0x80 [usbcore]
[] usb_runtime_suspend+0x2e/0x80 [usbcore]
[] usb_suspend_both+0xef/0x1f0 [usbcore]
[] usb_resume_interface.isra.6+0xa6/0x100 [usbcore]
[] hub_resume+0x23/0x60 [usbcore]
[] hub_activate+0xc6/0x5c0 [usbcore]
[] usb_kill_urb+0x3f/0xa0 [usbcore]
[] hub_port_status+0xd9/0x120 [usbcore]
[] __queue_work+0x12f/0x340
[] insert_work+0x46/0xb0
[] usb_control_msg+0xc4/0x110 [usbcore]
[] usb_start_wait_urb+0x9a/0x150 [usbcore]
[] update_curr+0xd7/0x120
Supuse que son los módulos usb. Anteriormente, en otra máquina había grabado alegremente todos los dispositivos USB y [uex]Los módulos hci se dan cuenta de que había apagado el teclado (¡ni siquiera ctrl-shift-sysrq-U!), así que terminé haciendo esto:
MODS="uvcvideo ohci_hcd ehci_hcd xhci_hcd ohci_pci ehci_pci xhci_pci usbcore"
( echo $MODS $MODS | xargs -n 1 rmmod -v ; sleep 3 ; echo $MODS | xargs -n 1 modprobe -v ; )
[email protected]:~# ( echo $MODS $MODS | xargs -n 1 rmmod -v ; sleep 3 ; echo $MODS | xargs -n 1 modprobe -v ; )
rmmod: ERROR: Module ohci_hcd is in use by: ohci_pci
rmmod: ERROR: Module ehci_hcd is in use by: ehci_pci
rmmod: ERROR: Module xhci_hcd is in use by: xhci_pci
rmmod: ERROR: Module uvcvideo is not currently loaded
rmmod: ERROR: Module ohci_pci is not currently loaded
rmmod: ERROR: Module ehci_pci is not currently loaded
rmmod: ERROR: Module xhci_pci is not currently loaded
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/media/usb/uvc/uvcvideo.ko
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/ehci-hcd.ko
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/ohci-hcd.ko
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/xhci-hcd.ko
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/ehci-pci.ko
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/ohci-pci.ko
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/xhci-pci.ko
Hizo el truco:
grep -n ^ /proc/24910/stack | sort -rn | cut -d: -f 2-
[] 0xffffffffffffffff
[] kthread+0x0/0xe0
[] ret_from_fork+0x42/0x70
[] kthread+0x0/0xe0
[] kthread+0xc1/0xe0
[] worker_thread+0x0/0x550
[] worker_thread+0xcc/0x550
Entonces, mi principal sospechoso es este dispositivo: RTL8723B * Módulo WIFI + Bluetooth. Me pregunto ahora si el código de administración de energía se da cuenta de que es el mismo dispositivo si intenta, por ejemplo, apagar un adaptador BT sin usar.
contexto:
[email protected]:~# lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0c45:651b Microdia
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 0bda:b001 Realtek Semiconductor Corp.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[email protected]:~# lsmod | grep usb
btusb 45056 0
btbcm 16384 1 btusb
btintel 16384 1 btusb
bluetooth 438272 5 bnep,btbcm,btusb,btintel
usbcore 200704 8 btusb,uvcvideo,ohci_hcd,ohci_pci,ehci_hcd,ehci_pci,xhci_hcd,xhci_pci
usb_common 16384 1 usbcore
[email protected]:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux stable-updates (sid)
Release: stable-updates
Codename: sid
[email protected]:~# uname -a
Linux hp 4.1.0-2-amd64 #1 SMP Debian 4.1.6-1 (2015-08-23) x86_64 GNU/Linux
[email protected]:~# dmesg | tail -n 20
[97865.088740] usb 2-4: SerialNumber: HP Webcam
[97865.091557] uvcvideo: Found UVC 1.00 device HP Webcam (0c45:651b)
[97865.105948] input: HP Webcam as /devices/pci0000:00/0000:00:13.2/usb2/2-4/2-4:1.0/input/input17
[97865.189817] usb 3-3: new full-speed USB device number 2 using ohci-pci
[97865.350981] usb 3-3: No LPM exit latency info found, disabling LPM.
[97865.368958] usb 3-3: New USB device found, idVendor=0bda, idProduct=b001
[97865.368969] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[97865.368976] usb 3-3: Product: Bluetooth Radio
[97865.368981] usb 3-3: Manufacturer: Realtek
[97865.368985] usb 3-3: SerialNumber: 00e04c000001
[97865.375859] Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
[97865.375867] Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_fw.bin
[97865.375896] usb 3-3: firmware: failed to load rtl_bt/rtl8723b_fw.bin (-2)
[97865.375902] usb 3-3: Direct firmware load for rtl_bt/rtl8723b_fw.bin failed with error -2
[97865.375907] Bluetooth: hci0: Failed to load rtl_bt/rtl8723b_fw.bin
[97865.397812] Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
[97865.397821] Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_fw.bin
[97865.397850] usb 3-3: firmware: failed to load rtl_bt/rtl8723b_fw.bin (-2)
[97865.397856] usb 3-3: Direct firmware load for rtl_bt/rtl8723b_fw.bin failed with error -2
[97865.397861] Bluetooth: hci0: Failed to load rtl_bt/rtl8723b_fw.bin
Si te ha sido de utilidad este post, nos gustaría que lo compartas con otros programadores y nos ayudes a extender nuestra información.