FreeBSD и CPU C-states - II
В продолжение к этому вот тексту и комментариям там:
Приехал Com2USB кабель, подключил, насладился BIOS-ом через VT100 emulation и вообще прикольная штука - последовательная консоль. Молодость вспомнил, всплакнул.....
Тем не менее, цель не достигнута: после отключения USB и VT-d (по совету из комментариев) - так и жрет 2+ ватта в простое (основное жрет uncore), а в счетчике использования C3 у dev.cpu.0 - все еще нули.
А с другой стороны, ну так и хрен с ним. За месяц использования этот ящик вообще никакого вмешательства не потребовал (после того как я ipfw rules привел в разумное состояние, не 6к правил, а ~500). Работает и работает, вообще ничего не просит, я даже уже плохо помню что он есть :)
Comments
+2 ватта...
Окупаемость считали? ;-)
Тут дело в интересе, а не в
Тут дело в интересе, а не в окупаемости
Debug
Sorry. Если вопрос по прежнему интересен, то я не вижу никакого другого пути его решения, кроме отладки. С serial console должно получиться.
Нужно выяснить, почему sys/dev/acpica/acpi_cpu.c:acpi_cpu_idle() отказывется заходить в C3. Функция проверяет n условий, нас интересует то, которое блокирует. Условия в основном статичные, поэтому можно проверить состояние переменных и понять почему. На этой системе запустите kgdb, из базовой (старый) или ports/devel/gdb (существенно новее):
# kgdb /boot/kernel/kernel /dev/mem
Это безопасно, оно только читает ядерную память. Ядро желательно собрать с
makeoptions DEBUG=-g
После этого вы просто можете читать значения переменных в памяти. Смысл условий не важен, найдите то, которое блокирует C3.
Спасибо!
Спасибо!
Поскольку эта штука обеспечивает интернет у меня в доме и если его временно прекратить, то озверевшие домашние со мной что-нибудь сделают, постольку лазить туда надолго не получается.
Попробую на след. неделе, пока дети будут в школах-университетах, иначе опасно....
Описанным способом kgdb
Описанным способом kgdb используется на живой системе, он не останавливает исполнение. Это такой удобный тул для чтения памяти.