Что делать, на QEMU всё летает, а реальный Celeron D умирает?

Question

[Кирилл Ларченко]

С марта пишу операционную систему на C/C++ и ассемблере под x86. Прошел классический путь: от вывода первой строчки в текстовом режиме до самописного GUI с грязными прямоугольниками, двойной буфферизацией , кастомными шрифтами и тасками в голубых тонах. Раньше тестировал сборки исключительно на реальном железе с Intel Celeron D 326 и встроенной графикой, которая старше меня. Чтобы не бегать постоянно с флешкой и dd, в свежей версии 3.17.9 решил вернуть поддержку QEMU. Попытка усидеть на двух стульях закончилась проблемой, которую я не могу расковырять уже несколько дней.

В чем суть бага?
В QEMU система работает идеально. Но на реальном Celeron D начинается нервотрёпка:
1. Система работает примерно в два раза медленнее, чем должна. Причем тормозит в полном покое, даже если мышь и клава вообще не двигаются. Любое мгновенное действие занимает секунду.
2. При этом системный динамик (PC Speaker / пищалка), который настроен пропищать ровно 2 секунды, отрабатывает за 1 секунду. То есть звук ускорился в два раза, а ядро замедлилось в два раза.
3. Графика работает нормально, но курсор мыши даже не отрисовывается также как и время на экране.
Если закомментировать инициализацию мыши (mouse_init), звук пищалки пролетает еще быстрее.

Ссылка на мой гитхаб: https://github.com/larcenkokirill91-max/AnalOS.git

Comments

[jcmvbkbc]

git bisect, как очевидный подход, уже пробовал?

[rPman]

с помощью какого агента и каких моделей ИИ ты ведешь разработку? рекомендую это указать где-нибудь в readme в репозитарии.

p.s. https://habr.com/ru/articles/1054342/ современный ИИ не очень подходит для качественного вайбкодинга сложных проектов

[Дмитрий]

А есть полная уверенность в работоспособности 20 летнего рабочего станда?

[Кирилл Ларченко]

rPman, Для разработки я не использую ИИ, я использую Geminy только если натыкаюсь на сложный баг, обычно помогоет но тут ни я, ни он не помог

[Кирилл Ларченко]

Дмитрий, Да, ранее всё прекрасно работало

Answer 1

[Андрюха Фростморн]

Я проанализировал твой проект, что могу сказать:

Симптомы 100% указывают на кривую настройку таймера (PIT / APIC), конфликт прерываний и закомментированный `hlt`.

Разбор симптомов:

1. Ускорение спикера и замедление системы
Ты настраиваешь PIT (или APIC timer) под определенную частоту, но, скорее всего, рассчитываешь делитель неправильно. Базовая частота PIT — строго 1193182 Гц. Если твой математический расчет делителя в коде глючит (или ты берешь другую базовую частоту), прерывания таймера (IRQ 0) срабатывают в 2 раза чаще.
В итоге планировщик (scheduler) получает тики в 2 раза чаще, система захлебывается в обработчиках прерываний (ISR) и переключениях контекста. Отсюда дикая просадка производительности даже в покое.
PC Speaker использует канал 2 того же PIT. Если базовая частота или делитель завышены в 2 раза, он пищит ровно в 2 раза быстрее (2 секунды превращаются в 1).

2. Влияние мыши на таймер
PS/2 мышь использует IRQ 12, таймер использует IRQ 0. И то, и другое идет через контроллер прерываний (PIC).
Если инициализация мыши меняет маску PIC или переназначает векторы, она ломает обработку IRQ 0. Ты пишешь, что закомментировал mouse_init, и звук стал пролетать еще быстрее. Значит, мышь как-то маскировала часть прерываний таймера (или генерировала спурайные прерывания), а без нее таймер срабатывает еще чаще.

3. Курсор и время не отрисовываются
Отрисовка времени и курсора у тебя, очевидно, завязана на тики ядра. Раз таймер работает криво, тики не доходят до нужного обработчика, либо ты зависаешь в ISR, и графическая подсистема не получает квант времени на перерисовку (dirty rects).

Что чинить:
1. Проверь расчет делителя для PIT (порт 0x40). Делитель = 1193182 / желаемая_частота.
2. Проверь инициализацию PIC (порта 0x20 и 0xA0). Убедись, что маскирование IRQ 0 (таймер) и IRQ 12 (мышь) сделано правильно.
3. Отключи APIC (если включал), работай только через старый 8259 PIC, пока не починишь базовый таймер.
4. Проверь, не генерирует ли мышь спурайные прерывания (spurious interrupts), которые блокируют очередь PIC.

Comments

[Кирилл Ларченко]

К сожалению не помогло, я всё сделал и если вам не сложно проверьте пожалуйста мойй гитхаб. Всё также, полосы из-за шага были и ранее (на реальном intel celeron их нету) но главное то что все проблемы остались, пищалка быстрая а на qemu не работает alt+f4, у меня Linux Fedora 44 на KDE Plasma. На тестовом пк с Intel Celeron D 326 даже окно клавиатура перестала работать.
Ссылка на репо: https://github.com/larcenkokirill91-max/AnalOS.git

[Андрюха Фростморн]

Тут сходится сразу несколько жестких багов:

1. Главный убийца реального железа: баг в `mouse_wait`
В файле `keyboard.c` у тебя написано:

void mouse_wait (unsigned char type) {
	if (type = 0) {
		while ((inb(0x64) & 2) != 0);
	} else {
		while ((inb(0x64) & 1) == 0);
	}
}

У тебя тут не сравнение `==`, а присваивание `=`. Выражение `type = 0` всегда возвращает `false` (ноль), поэтому функция **всегда** уходит в ветку `else` и крутит `while ((inb(0x64) & 1) == 0);`.
То есть, когда ты вызываешь `mouse_wait(0)`, чтобы дождаться готовности контроллера к *записи*, система тупо ждет, пока в буфере не появятся данные на *чтение*. На реальном железе это убивает инициализацию мыши и клавы, вешает PIC и ломает прерывания таймера. Замени `type = 0` на `type == 0`.

2. Почему пищалка ускоряется в 2 раза (APIC)
Если у тебя в BIOS включен APIC, а ты используешь старый 8259 PIC, на новых процессорах прерывание от таймера может приходить дважды (один раз от APIC, второй от legacy PIC). В QEMU APIC обычно отключен или эмулируется иначе, а Celeron D может гонять прерывания дважды.
Решение: отключи APIC в ядре. Запиши ноль в SVR (Spurious Interrupt Vector Register):
`*(volatile unsigned int*)(0xFEE000F0) = 0;` перед инициализацией PIC.

3. Почему мышь и время не отрисовываются (Маскировка PIC)
В `idt.c` в функции `pic_remap` ты пишешь:
`outb(0x21, 0xFC);` (в бинарте это `11111100`).
Ты размаскировал только IRQ0 (таймер) и IRQ1 (клава). Но бит 2 (IRQ2) остался замаскированным!
IRQ2 — это каскадный канал, который соединяет Slave и Master PIC. Мышь висит на IRQ12 (Slave PIC). Поскольку IRQ2 замаскирован, прерывания от мыши тупо не доходят до процессора!
Нужно писать `outb(0x21, 0xF8);` (`11111000`), чтобы открыть IRQ2. А на Slave PIC (`0xA1`) нужно написать `0xEF` (`11101111`), чтобы открыть IRQ12.

4. Почему отваливается клавиатура (Переполнение буфера)
В `keyboard_handler_c` ты читаешь только один байт: `current_scancode = inb(0x60);`.
На реальном железе при быстром нажатии или удержании клавиши контроллер генерирует несколько сканкодов подряд. Если ты не вычитываешь их все из порта 0x60, буфер контроллера переполняется, он ставит флаг ошибки и блокирует шину. Клава умирает, пока ты не сделаешь сброс.
Нужно читать в цикле:

void keyboard_handler_c(void) {
    while (inb(0x64) & 1) { // Читаем, пока есть данные
        current_scancode = inb(0x60);
        kbd_ready = 1;
    }
    outb(0x20, 0x20);
}

5. Порядок инициализации
В `kernel.c` у тебя:
`mouse_init();` вызывается **до** `idt_init();`.
`mouse_init` включает прерывания мыши на контроллере. Если мышь в этот момент дернется, она сгенерирует IRQ, а IDT еще не настроен. Процессор улетит в Stage 2 или получит General Protection Fault. Перенеси `mouse_init()` строго **после** `idt_init()`. А вообще лучше вызывать инициализацию мыши уже после того, как прерывания включены (`sti`), иначе ты блокируешь таймер во время долгих циклов ожидания мыши.

Что чинить прямо сейчас:
1. Исправь `type = 0` на `type == 0` в `keyboard.c`.
2. Замени маски PIC на `0xF8` и `0xEF`.
3. Вычитывай клаву в цикле внутри ISR.
4. Поменяй местами `mouse_init` и `idt_init`.

[brar]

Кирилл Ларченко, Если что, то пользователь "Андрюха Фростморн" копипастит выхлоп чата гпт. С тем же успехом Вы сами можете спросить у какого-либо ИИ.

[Андрюха Фростморн]

brar, если тебе так проще — можешь считать, что я попросил ИИ проанализировать чужой код. Только вот ни один ИИ сам по себе не полезет в репозиторий, не найдет там баг с присваиванием type = 0 вместо == в mouse_wait, не разберется в маскировке каскадного PIC и не заметит, что инициализация мыши вызывается до настройки IDT.

Если у тебя есть, что сказать по существу проблемы (почему Celeron D умирает) — пиши. Если просто пришел написать "это нейросеть", то ты опоздал, этот билет уже кто-то пробил.

[brar]

Андрюха Фростморн, и это тоже комент от нейронки.

[Алексей Черемисин]

brar, Я нейросеть (шучу). Так вот, как бывший разработчик всяких RTOS и программист со стажем, очень большим,и что немаловажно, успешным, считаю, что Андрюха Фростморн очень даже прав, и на счет циклов и на счет прерываний.
Вообще-то принято в циклах ставить счетчик и не насиловать чтением регистры до бесконечности, а считать, например до 10 раз и отвалиться с ошибочкой, или просто выйти из функции.
Ну и маскирование прерываний - отдельная тема. В хороших системах делают единый обработчик всех прерываний, а в основном цикле делают отдельный шедулер по обработчикам прерываний (так например в линуксе и qnx и os-9000, что в vxworks уже не помню).

[brar]

Алексей Черемисин, суть в том, что его все ответы на этом сайте, а их 3 штуки всего, все написаны нейронкой - это видно по семантике легко. Или Вы действительно этого не определяете? Он даже не редактировал ответы.

И ни один из его ответов никому не помог, Вам в том числе, о чём Вы сами написали выше.
Но, есесно, дело Ваше - верить этому копипастеру или самому поставить задачу агентам.

[res2001]

brar, Какая разница, дает он ответы от ИИ или из головы, если ответ правильный?
Если не правильный - есть смысл закидать тухлыми яйцами хоть человека хоть ИИ, но аргументируя. Аргумент - "это копипаст ИИ" - не аргумент.

Я плохо разбираюсь в железе. Но ошибка if(type=0) явно присутствует. Об этой ошибке должен и современный компилятор сообщать в предупреждениях (при включенной опции -Wall). По остальным ошибкам в ответе Андрюха Фростморн судить не берусь.

Кирилл Ларченко, Вообще рекомендую как минимум опции -Wall -Wextra всегда использовать при сборке и добиваться сборки без предупреждений. Можно дополнительно использовать -Werror что переведет все предупреждения в разряд ошибок. Коротенько тут описаны основные регулировки предупреждений компилятора: https://habr.com/ru/articles/490850/

Помимо компилятора подобную ошибку заметит любой статический анализатор. Ну и адекватный ИИ то же должен бы ее увидеть - это довольно простая и часто встречающаяся ошибка.