Bug 3851 - kworker overload CPU
: kworker overload CPU
Status: RESOLVED WORKSFORME
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: i586 Linux
: Normal normal
: ---
Assigned To: ROSA Linux Bugs
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-16 20:52 MSK by Sergey Kalinin
Modified: 2016-01-17 19:48 MSK (History)
4 users (show)

See Also:
RPM Package:
ISO-related:
Bad POT generating:
Upstream:


Attachments
screenshot (64.04 KB, image/png)
2014-03-16 20:52 MSK, Sergey Kalinin
Details
jouranalctl -ab (323.18 KB, text/plain)
2014-03-18 19:20 MSK, Sergey Kalinin
Details
jouranalctl -ab №2 (277.66 KB, text/plain)
2014-03-20 23:42 MSK, Sergey Kalinin
Details
journalctl -ab №3 (123.85 KB, text/plain)
2014-03-27 11:34 MSK, Sergey Kalinin
Details
cat /proc/29/stack (958 bytes, text/plain)
2014-03-27 16:10 MSK, Sergey Kalinin
Details
kworker stack (101.99 KB, image/png)
2014-03-27 17:51 MSK, Sergey Kalinin
Details
jouranalctl -ab №4 without fglrx (155.02 KB, text/plain)
2014-03-28 11:34 MSK, Sergey Kalinin
Details
jouranalctl -ab №5 without fglrx (151.40 KB, text/plain)
2014-03-28 19:14 MSK, Sergey Kalinin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Kalinin 2014-03-16 20:52:44 MSK
Created attachment 2710 [details]
screenshot

Description of problem:
see attachment
[serge@serge ~]$ cat /etc/release 
ROSA Desktop Fresh R2 release 2012.1 for i586
[serge@serge ~]$ uname -a
Linux serge 3.10.27-nrj-desktop-pae-1rosa #1 SMP PREEMPT Thu Jan 16 19:59:01 MSK 2014 i686 i686 i686 GNU/Linux
[root@serge serge]# lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7520G]
00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port
00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port
00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11)
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11)
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 14)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 01)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11)
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge (rev 40)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 5
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7500M/7600M Series]
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)
03:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
Comment 1 Eugene Shatokhin 2014-03-18 12:51:51 MSK
Please collect and attach the output of 'journalctl -ab' (run as root) when the problem happens.

kworker (kernel worker threads) are used for many tasks like delayed IO, deferred interrupt handling, etc. It's hard to say what exactly that kworker was doing without additional info. The system log may shed some light on that.

Besides, does the problem happen all the time? In what conditions?
Comment 2 Sergey Kalinin 2014-03-18 19:20:52 MSK
Created attachment 2712 [details]
jouranalctl -ab

output of 'journalctl -ab' (run as root) when the problem happens.
Comment 3 Sergey Kalinin 2014-03-18 19:36:52 MSK
It's happens in 100% after "start" and "suspend to disk/ram".  And potentially in working flash-player-plugin. This bug is present during operation Firefox and Opera,  but not in Google Chrome.
Output of 'journalctl -ab' in attachment.
Comment 4 Sergey Kalinin 2014-03-18 20:20:26 MSK
По английски мне писать сложновато. 
В общем это точно случается после старта, гибернации и ждущего режима, и продолжается несколько минут или часов, от чего это зависит не знаю. Во время такой активности я не могу запустить Konsole (просто висит с застывшим курсором), не могу запустить Firefox, выключить компьютер (пялюсь в черный экран), бывает отваливается Network Manager.Насчет флеша не знаю, может он и не причем.
Comment 5 Postnikov Dmitry 2014-03-18 21:42:25 MSK
kworker грубо выражаясь процесс ядра, дочерний процес kthreadd (потоки ядра, рабочий процесс, обслуживающий запросы на ввод-вывод).
http://rflinux.blogspot.ru/2010/04/kthreadd.html
Наведите мышой на любой kworker и подождите, и вы увидите описание kthread.

1. Поставьте iotop и понаблюдайте несколько минут, что сьедает ваше "винчестерное время/мегабайты".
iotop -Pao
2. Проверьте файловую систему, диск.
3. Переставьте ядро (urpmi --replacepkg; dracut-f и т.д.)
Comment 6 Eugene Shatokhin 2014-03-19 11:35:15 MSK
kworker'ы и для многих других целей используются, это основной механизм отложенного выполнения кода в ядре. Но операции ввода/вывода - да, для этого они тоже часто используются.

Судя по выводу journalctl, много чего странного в системе происходит: сервисы с segfault'ами падают, система на ошибки firmware ругается и пр.

Так что да, согласен с Дмитрием, стоит сначала диск и файловую систему проверить. 

Полезно ещё и память проверить memtest'ом (на несколько часов хотя бы проверку запустить). Memtest есть у нас и на установочных образах ROSA Fresh: при загрузке с установчного диска или флэшки выберите "Troubleshooting", затем - "Run memory test".

Если все эти проверки ошибок не выявят, а проблема продолжит проявляться, выложите вывод journalctl -ab ещё раз. Посмотрим, что там будет.
Comment 7 Eugene Shatokhin 2014-03-19 11:58:06 MSK
Кстати, как минимум, одна из всплывших в логе проблем у нас должна быть уже исправлена в ядре 3.10.33 (соотв. обновление сейчас готовится):
"cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu"

Не думаю, что это связано с основной проблемой с kworkers и сервисами, но всё же. 

Тем не менее, если проверка диска и памяти ошибок не выявит, можно попробовать поставить ядро 3.10.33 и посмотреть, будут ли проблемы с kworker на нём.

Для установки достаточно подключить соотв. репозиторий, а затем выполнить обновление ПО в системе, как обычно.

Для 32-битных систем:
urpmi.addmedia kernel3_10_33 http://abf-downloads.rosalinux.ru/rosa2012.1/container/1696110/i586/main/release/
urpmi.addmedia kernel3_10_33_aux http://abf-downloads.rosalinux.ru/rosa2012.1/container/1697244/i586/main/release/
Comment 8 Alexander Burmashev 2014-03-19 12:01:12 MSK
Раз уж пошло такое обсуждение, Евгений, как думаешь, может быть имеет смысл попросить воспроизвести проблему на ванильном ядре, без наших специфических nrj/nrjql патчей вообще ? Я в других багах как-то просил, но до тестов дело так и не дошло.
Comment 9 Eugene Shatokhin 2014-03-19 13:08:13 MSK
(In reply to comment #8)
> Раз уж пошло такое обсуждение, Евгений, как думаешь, может быть имеет смысл
> попросить воспроизвести проблему на ванильном ядре, без наших специфических
> nrj/nrjql патчей вообще ? Я в других багах как-то просил, но до тестов дело
> так и не дошло.

Разумно. Если на 3.10.33-nrj-desktop проблема воспоизведётся, можно будет попробовать на 3.10.33-desktop (т.е. без NRJ-патчей). Это ядро у нас так и так собирается и сейчас в том же контейнере лежит.
Comment 10 Sergey Kalinin 2014-03-19 22:17:35 MSK
Переустановка ядра прошла у меня криво, и систему пришлось переустанавливать. На чистом и только что обновленном R2 проблема отсутствует, до тех пор пока не установил fglrx. Сейчас таких жестких тормозов нет, но kworker изредка проявляет свою активность. Память и диск проверю позже.
Новое ядро тестить?
Comment 11 Eugene Shatokhin 2014-03-20 10:47:20 MSK
(In reply to comment #10)
> kworker изредка проявляет свою активность.

Это нормально.

> Новое ядро тестить?

Раз пока проблема не проявляется, можно новое ядро не ставить. Если проявится, тогда можно будет поставить, посмотреть, что на нём будет. А так - оно потом само с обновлениями придёт, когда мы их выпустим.
Comment 12 Sergey Kalinin 2014-03-20 11:15:06 MSK
Обрадовался рано, всетаки баг снова проявил себя.
диск проверил
[root@localhost live]# fsck.ext4 -f /dev/sda1
e2fsck 1.42.5 (29-Jul-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 181982/788416 files (0.1% non-contiguous), 1365383/3148484 blocks
[root@localhost live]# fsck.ext4 -f /dev/sda6
e2fsck 1.42.5 (29-Jul-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda6: 248678/29483008 files (2.7% non-contiguous), 95780875/117924744 blocks

проверка памяти прошла без ошибок

поставлю новое ядро
Comment 13 Sergey Kalinin 2014-03-20 23:42:37 MSK
Created attachment 2720 [details]
jouranalctl -ab №2

ядро обновил, попытался изменить яркость экрана, сразу вылезла эта ошибка
Comment 14 Eugene Shatokhin 2014-03-21 11:59:52 MSK
Если bluetooth отключить (лучше - аппаратно), проблема проявляется?
Comment 15 Sergey Kalinin 2014-03-21 13:16:00 MSK
аппаратно не могу
да, ошибка присутствует
Comment 16 Sergey Kalinin 2014-03-21 13:20:23 MSK
не знаю важно это или нет, у меня еще ноут неправильно реагирует на отключение/подключение питания, например, сейчас он отключен, а значок батареи показывает что работает от сети
Comment 17 Eugene Shatokhin 2014-03-21 14:03:15 MSK
Т.е. даже в BIOS Bluetooth controller отключить нельзя? Если можно, попробуйте временно выключить его там.
Comment 18 Eugene Shatokhin 2014-03-21 14:08:14 MSK
И если проблема воспроизведётся и при этом, выложите вывод journalctl -ab ещё раз.

Что касается питания, всякое может быть. Помимо массы странных сообщений от bluetoothd, в логе есть ещё ошибки, связанные с ACPI - это может иметь отношение к питанию. А кроме этого там ничего особо критичного не видно. Посмотрю, может, что-то удастся тут прояснить.
Comment 19 Postnikov Dmitry 2014-03-21 14:56:59 MSK
(In reply to comment #15)
> аппаратно не могу
> да, ошибка присутствует

Хм... у вас ноутбук? Если ноут, то в ноутах обычно один совмещенный модуль wifi+bluetooth стоит. Отключите в BIOS wifi карту (или кнопками/клавишами) и у вас bluetooth должен отрубитья.
Comment 20 Sergey Kalinin 2014-03-21 15:15:07 MSK
просто в bluedevil отключил, теперь в выводе jouranalctl -ab появилась запись

марта 21 14:18:37 serge bluetoothd[3790]: bluetoothd[3790]: Unknown command complete for opcode 19
марта 21 14:18:37 serge bluetoothd[3790]: Adapter /org/bluez/3790/hci0 has been enabled
марта 21 14:18:37 serge bluetoothd[3790]: Unknown command complete for opcode 19
марта 21 14:18:37 serge bluetoothd[3790]: bluetoothd[3790]: hci0: Get Connections (0x0015) failed: Not Powered
марта 21 14:18:37 serge bluetoothd[3790]: hci0: Get Connections (0x0015) failed: Not Powered (0x0f)
Comment 21 Postnikov Dmitry 2014-03-21 15:19:52 MSK
(In reply to comment #20)
> просто в bluedevil отключил, теперь в выводе jouranalctl -ab появилась запись
> 
Ну и отключите (пока на время) сервис:
systemctl stop bluetooth.service
systemctl disable bluetooth.service
reboot
Comment 22 Sergey Kalinin 2014-03-23 21:08:28 MSK
Аппаратно выключить блютус совсем никак нельзя. Удалил bluez, добавил в /etc/modprobe.d/blacklist-compat.conf ath3k, bluetooth, btusb - проблема осталась
Comment 23 Eugene Shatokhin 2014-03-24 11:02:17 MSK
Ясно. Попробуйте тогда установить ядро 3.10.33-desktop и проверить, воспроизведётся ли проблема на нём, как предлагал Александр Бурмашев.

Если воспроизведётся, ещё раз приложите вывод journalctl -ab.

Ядро 3.10.33-desktop ближе к тому, что на kernel.org, чем наше стандартное 3.10.33-nrj-desktop. Проверим таким образом, возникла ли эта проблема из-за каких-то наших дополнений к ядру.
Comment 24 Sergey Kalinin 2014-03-24 14:50:39 MSK
на 3.10.33-desktop не грузится, зависает при загрузке, последний пункт при загрузке это "запуск логин менеджера"
Comment 25 Eugene Shatokhin 2014-03-24 15:38:01 MSK
(In reply to comment #24)
> на 3.10.33-desktop не грузится, зависает при загрузке, последний пункт при
> загрузке это "запуск логин менеджера"

В вирт. консоль при этом можно войти (по ctrl-alt-f2, например)? Если да, то попробуйте залогиниться в вирт. консоли и сохранить вывод 'journalctl -ab' в файл. Этот файл, а также /var/log/Xorg.0.log потом выложите сюда.
Comment 26 Eugene Shatokhin 2014-03-24 15:47:44 MSK
Ещё такой момент: Вы ведь поставили и kernel-desktop-3.10.33-1rosa, и kernel-desktop-devel-3.10.33-1rosa, так? 
Просто если '-devel' пакет не поставили, то видеодрайвер fglrx мог не пересобраться после перезагрузки и графика не поднялась в итоге.
Comment 27 Sergey Kalinin 2014-03-24 16:49:50 MSK
Про devel я знаю, и научен горьким опытом :( Так что desktop-devel-3.10.33-1rosa установлен, а в логе пишет "fglrx already at this kernel"
Comment 28 Eugene Shatokhin 2014-03-24 16:57:49 MSK
(In reply to comment #27)
А в вирт. консоль можно зайти? Хотелось бы взглянуть на вывод journalctl и на Xorg.0.log.
Comment 29 Sergey Kalinin 2014-03-26 14:55:50 MSK
в виртуальную консоль не заходит
Comment 30 Eugene Shatokhin 2014-03-26 18:11:20 MSK
Хорошо, давайте тогда попробуем такой вариант. Загрузите систему с ядром 3.10.33-nrj-desktop как обычно.

Можно попробовать включить стандартный disk queue scheduler (CFQ) вместо того, что у нас в nrj-desktop-ядрах используется (BFQ). Может он чего-то мудрит, тем более, его недавно обновляли.

Чтобы задать disk queue scheduler, нужно от root выполнить след. команду:
    echo cfq > /sys/block/<имя диска>/queue/scheduler

<имя диска> - sda, sdb, и т.д. У Вас в системе они могут и по-другому называться.

Для каждого диска тогда поставьте CFQ таким образом. Если будете перезагружать систему, то после этого CFQ нужно будет установить таким же образом снова (эти настройки не сохраняются при перезагрузке).

Посмотрим, воспроизведётся ли проблема при этом. Если воспроизведётся - выложите вывод journalctl -ab ещё раз.
Comment 31 Postnikov Dmitry 2014-03-26 18:15:49 MSK
(In reply to comment #30)
> Можно попробовать включить стандартный disk queue scheduler (CFQ) вместо
> того, что у нас в nrj-desktop-ядрах используется (BFQ). Может он чего-то
> мудрит, тем более, его недавно обновляли.
> 
> Чтобы задать disk queue scheduler, нужно от root выполнить след. команду:
>     echo cfq > /sys/block/<имя диска>/queue/scheduler
> 

Чтобы при каждой перезагрузке не делать эту операцию, можно в меню Граба, где задаются параметры ядра, добавить:
elevator=cfq

Тогда при каждой перезагрузке будет включать CFQ шедулер вместо BFQ.
Comment 32 Eugene Shatokhin 2014-03-26 18:20:47 MSK
Ещё, кстати, хорошо бы проверить сам диск, не только файловую систему. Чем-нибудь наподобие Victoria (http://forum.ru-board.com/topic.cgi?forum=5&topic=35147#1) или MHDD. Мало ли.
Comment 33 Sergey Kalinin 2014-03-27 11:34:59 MSK
Created attachment 2732 [details]
journalctl -ab №3

планировщик сменил, добавив параметры в груб [serge@serge ~]$ dmesg | grep scheduler
[    1.461326] io scheduler noop registered
[    1.461330] io scheduler deadline registered
[    1.461359] io scheduler cfq registered (default)
[    1.461366] io scheduler bfq registered
[    1.461369] BFQ I/O-scheduler version: v7r2
[serge@serge ~]$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq] bfq 
[serge@serge ~]$ uname -a
Linux serge 3.10.33-nrj-laptop-pae-1rosa #1 SMP PREEMPT Wed Mar 12 15:36:36 UTC 2014 i686 i686 i686 GNU/Linux

И все то же самое, просто отключив ноутбук от сети, kworker начинает грузить процессор.
Может дело в ACPI?
Comment 34 Eugene Shatokhin 2014-03-27 12:16:11 MSK
(In reply to comment #33)
Так, значит, это не scheduler. Идём дальше.

> И все то же самое, просто отключив ноутбук от сети, kworker начинает грузить
> процессор.
> Может дело в ACPI?

Запросто. 

1. Можно попробовать задать в параметрах ядра acpi_osi="Linux" и посмотреть, будет ли проблема воспроизводиться после этого.

Ещё укажите, пожалуйста, название производителя и модель ноутбука, а также - вывод след. команд (от root):

dmidecode -s system-manufacturer
dmidecode -s system-product-name

Посмотрим, может, есть какие-то особенности в управлении питанием для таких моделей.

2. Да, и диск всё-таки стоит проверить на физическом уровне. Мало ли.

3. Ещё. Когда проблема проявится в очередной раз, попробуйте определить PID того kworker'а, который есть много CPU time, сохраните куда-нибудь содержимое файла
/proc/<PID kworker'a>/stack и выложите сюда.

Если таких kworker'ов несколько - то для каждого.

Это может помочь понять, что именно этот kworker в данный момент делает в ядре. Может, яснее будет, в чём проблема.
Comment 35 Sergey Kalinin 2014-03-27 16:10:27 MSK
Created attachment 2733 [details]
cat /proc/29/stack

Вот активность kworker'a
Comment 36 Eugene Shatokhin 2014-03-27 16:37:03 MSK
Какое-то странное содержимое /proc/<PID>/stack. Как будто не полностью вывелось. Если ещё раз его вывести в подобной ситуации, что будет? Тоже только одна строка с 0xfffffff?

А для других kworker'ов в /proc/<PID>/stack что?
Comment 37 Sergey Kalinin 2014-03-27 17:51:31 MSK
Created attachment 2734 [details]
kworker stack

Да была одна строка. Вот тот же kworker, только уже не нагружающий процессор
[root@serge serge]# cat /proc/29/stack
[<c0159937>] worker_thread+0x197/0x320
[<c015f324>] kthread+0x94/0xa0
[<c065e337>] ret_from_kernel_thread+0x1b/0x28
[<ffffffff>] 0xffffffff
Comment 38 Sergey Kalinin 2014-03-27 17:59:45 MSK
вот еще один голодный до процессора
[root@serge serge]# cat /proc/23159/stack
[<ffffffff>] 0xffffffff
[root@serge serge]#
Comment 39 Eugene Shatokhin 2014-03-27 18:08:30 MSK
Понятно. В общем, совсем плохо этим "голодным" kworker'ам, похоже. Странно, что в логе это не отражается.

Стоит всё же проверить железо:

1. Если память Memtest'ом проверяли меньше, чем 3-4 часа, лучше запустить проверку ещё раз на несколько часов хотя бы.

2. S.M.A.R.T. для жёстких дисков проверить, может, там о каких-то ошибках будет информация.

3. Как я уже писал, стоит и на физическом уровне диски проверить Victoria'ей, MHDD или чем-то аналогичным.
Comment 40 Sergey Kalinin 2014-03-28 11:17:41 MSK
удалил fglrx и восстановил bleutooth - голодные kworker'ы пропали
Comment 41 Sergey Kalinin 2014-03-28 11:34:15 MSK
Created attachment 2737 [details]
jouranalctl -ab №4 without fglrx

У меня Samsung 355V5X-S01
Этот патч есть в ядре? http://www.linux.org.ru/news/hardware/10259547
Comment 42 Eugene Shatokhin 2014-03-28 12:24:45 MSK
(In reply to comment #41)
> У меня Samsung 355V5X-S01
Хорошо. Ещё дайте вывод dmidecode, как я писал выше:

dmidecode -s system-manufacturer
dmidecode -s system-product-name

Это может потребоваться, например, если нужно будет добавить поддержку Вашей модели ноутбука в те или иные патчи в ядре.

> Этот патч есть в ядре? http://www.linux.org.ru/news/hardware/10259547

Пока нет. Там группа патчей, на самом деле. В 3.10 про них почему-то забыли. Я посмотрю сегодня, если получится адаптировать их для 3.10, то соберу ядро с ними, чтоб попробовать можно было.
Comment 43 Sergey Kalinin 2014-03-28 13:45:09 MSK
[root@serge serge]# dmidecode -s system-manufacturer
SAMSUNG ELECTRONICS CO., LTD.
[root@serge serge]# dmidecode -s system-product-name
355V4C/355V4X/355V5C/355V5X/356V4C/356V4X/356V5C/356V5X/3445VC/3445VX/3545VC/3545VX
[root@serge serge]#
Comment 44 Eugene Shatokhin 2014-03-28 15:58:58 MSK
(In reply to comment #43)
> [root@serge serge]# dmidecode -s system-manufacturer
> SAMSUNG ELECTRONICS CO., LTD.
> [root@serge serge]# dmidecode -s system-product-name
> 355V4C/355V4X/355V5C/355V5X/356V4C/356V4X/356V5C/356V5X/3445VC/3445VX/3545VC/
> 3545VX
> [root@serge serge]#

Спасибо, может пригодиться.

Тем временем я подготовил ядро с тем патчем + изменениями, необходимыми для этого патча. Варианты nrj-desktop и nrj-laptop-pae для 32-битных систем можно взять тут:

http://abf-downloads.rosalinux.ru/spectre_personal/container/1725765/i586/main/release/
Comment 45 Sergey Kalinin 2014-03-28 19:14:47 MSK
Created attachment 2739 [details]
jouranalctl -ab №5 without fglrx

Обновился, пока fglrx не ставил, но ноутбук стал работать потише, и меньше греется
Comment 46 Sergey Kalinin 2014-03-29 11:21:50 MSK
после установки fglrx kworker снова нагружает процессор
Comment 47 Alexander Burmashev 2014-03-29 13:07:03 MSK
А попробуйте aticonfig --acpi-services=off и рестартануть иксы или ребутнуть комп. При установленном fglrx естественно.
Comment 48 Sergey Kalinin 2014-03-29 14:01:22 MSK
не помогло
Comment 49 Postnikov Dmitry 2014-03-29 23:08:32 MSK
Судя по journalctl у вас ДВЕ видеокарты ATI HD. Одна встроенная в процессор, вторая дискретная.
И похоже, fglrx при выключении питания как-то пытается отключить дискретную видяху, чтобы экономить энергию аккумулятора. А это fglrx видимо не удается сделать. Отсюда и подвисоны с kworker. 
Наверняка fglrx пытается задействовать SLI. А он кривоват.
Comment 50 Sergey Kalinin 2014-03-29 23:55:57 MSK
не помню какая там команда, давно пробовал, но кандидатов на SLI не обнаруживает, видно видеокарты неподходящие, к тому же на релизном образе R2 все работало.
Comment 51 Sergey Kalinin 2014-03-29 23:57:35 MSK
у AMD не SLI, а CrossFire
Comment 52 Denis Silakov 2016-01-17 19:40:24 MSK
Каков у нас статус этого бага? НАблюдается ли проблема во Fresh R6?
Comment 53 Sergey Kalinin 2016-01-17 19:47:00 MSK
Нет такого давно, причиной было расширение Яндекса доя Файрфокса
Comment 54 Denis Silakov 2016-01-17 19:48:24 MSK
Ok.