Board.KolibriOS.org

О, 48-битные номера секторов.
1. Создавать событие нужно до подачи команды. KolibriOS - многозадачная система, и при таком коде прерывание от таймера может переключиться на другую задачу после подачи команды, но до создания события, и если железо закончит работать до переключения назад, событие будет пропущено.
2. Хорошо бы проверить, что kernel_alloc вернула что-то ненулевое - памяти может и не оказаться. То же самое для create_event.
3. Метка DMA как название процедуры какая-то слишком неспецифичная, может совпасть с чем-нибудь, лучше переименовать.

Есть ещё некоторые некритичные вещи:
* вместо mov eax, 0 / sbb eax, 0 можно сделать sbb eax, eax
* ide_read и ide_write сильно похожи, можно их вообще сделать переходниками к общей функции - mov al, 0 / jmp ide_read_write в ide_read и mov al, 1 / jmp ide_read_write в ide_write. На allow_dma_access вообще можно забить, исторический артефакт.
* имена локальных переменных типа [hd_data] недоступны вне функций, но сами переменные продолжают существовать на время вызова вложенных функций - если объявить ide_hd_data equ hd_data, то во вложенных функциях можно вместо копирования туда-сюда использовать [ide_hd_data].

Pathoswithin wrote:Только с PIO так и не понял, если прерывание сбрасывается чтением из порта, то зачем что-то делать в обработчике?

KolibriOS - многозадачная система, и железо может закончить работу во время исполнения другой задачи, которая, конечно, постоянно из порта ничего не читает. Впрочем, при реализованном DMA можно сказать, что так и было, код настройки IDE просто не включает прерывания IDE, если хотя бы один из master/slave не поддерживает DMA.

Ну теперь, наверно, православно, канонично и кошерно. В 2 раза меньше, чем было. Надеюсь, с Марио ничего плохого не случится, когда он это увидит.
Удалил буфер IDE_DMA, перенёс две переменные в bd_drv.inc .
2. Что-то слабо верится, что может не найтись ни одной страницы памяти. Да и что делать, если диску уже дана команда.
Подумал по поводу PIO... Ещё в начале, когда пытался заглушить прерывания, экспериментально установил несколько фактов (в моём случае): прерывания не выключаются, посылаются с интервалом, чтобы избежать высокой нагрузки на процессор, но непрерывно, без таймаута, до тех пор, пока не начнётся передача данных. Так что чтение порта в обработчике ничего не изменит, только начало передачи.
Думаю, это последняя версия от меня, по мелочам можешь сама подправить. Можно ещё объединить ide_read и ide_write, если сможешь сделать это изящно.

Ну и если, внезапно, кто-то захочет по-тестировать, вся запись работает быстро благодаря кэшу, чтение пока только ntfs.

Всё-таки настраивать DMA нужно строго до подачи команды диску, как в транке. Так, как у тебя, иногда не работает как минимум под Bochs - когда следующее чтение/запись начинается там же, где закончилось предыдущее, диск успевает сделать seek и сказать DMA-части о готовности перед тем, как DMA-часть поймёт, в какую часть памяти читать/писать, с ошибкой чтения/записи как результатом.

Как у вас всё весело! Сначала драйвер тормозил файловые системы. Почему PIO работает медленно и зависает вместе с кэшем - не понятно до сих пор. А теперь начались чудеса: fat работает быстро на старых вызовах! Медленней, чем ntfs, но быстрей в windows xp! Структура fat не способствует блочным операциям, я провозился и сделал новый цикл, а ничего не изменилось - всё и так быстро! Bochs наверно не эмулирует реальные задержки, жёсткий диск так быстро не может - у меня всё работает прекрасно. Может как раз из-за такого подхода чтение по 16 секторов умудряется работать непрерывно?
В любом случае, я переделал чтение fat, начиная со строки 1820.

Pathoswithin wrote:Почему PIO работает медленно и зависает вместе с кэшем - не понятно до сих пор.

Я не измеряла скорость, но у меня-то оно не зависает - и под Bochs, и на реальной машине. Другие тоже не жаловались, хотя наверняка просто никто больше не тестировал. Поэтому я и уточняла, выключаешь ли ты настройку прерываний в init_ata.inc при замерах PIO или просто форсируешь вызовы PIO-вариантов в hd_drv.inc. Как бы то ни было, я не могу отладить проблему, которая у меня не проявляется, без содействия кого-то, у кого она проявляется. Если у тебя есть интерес - можно продолжить.

Pathoswithin wrote:Bochs наверно не эмулирует реальные задержки, жёсткий диск так быстро не может - у меня всё работает прекрасно.

При чтении - скорее всего, да. При записи - я не удивлюсь, если какие-то модели дисков начинают забирать данные от DMA себе в буфер немедленно, ещё до завершения seek, даже если конкретно твоя модель так не делает.
По опыту, другие эмуляторы часто даже не пытаются эмулировать задержки.

kiv, ты не понял, fat работает гораздо быстрее, чем ожидалось.

CleverMouse wrote:Другие тоже не жаловались, хотя наверняка просто никто больше не тестировал. Поэтому я и уточняла, выключаешь ли ты настройку прерываний в init_ata.inc при замерах PIO

О_о Не уточняла. И я не знаю, как это делать. Меня лично не особо интересует, но у hidnplayr возникали какие-то проблемы, может связано?

CleverMouse wrote:я не удивлюсь, если какие-то модели дисков начинают забирать данные от DMA себе в буфер немедленно

А Bus Master включить? Я думал, это начало передачи.

1. FAT бывает разный, точнее
2. как проверял
3. готовлюсь к тестированию скорости завтра (уже, сегодня), если будут какие пожелания к тесту...
4. UDF ведь не поддерживается?

kiv
1. FAT32, естественно.
2. Копировал и засекал время — 100 Мб за несколько секунд.
3. Проверить нужно жёсткий диск, файловые системы ntfs, fat, можно ext и xfs. Если всё работает быстро, сравни с текущей сборкой. И осторожно с данными.

1 + 2. простые операции с одним файлом в 100Мб, естественно будут быстрей. если еще использовать кластер в 16Кб и больше, так вообще в космос полетит...
3. да, я две версии заготовил: со старым kernel.mnt; и новым (он больше т.к. не пожат?)

Этот драйвер должен быть совсем кошерным.
kiv, если на том ядре fat всё-таки будет работать медленно, можешь проверить ещё и это ядро.

Pathoswithin: I have been following this topic as close as I can. What is it you want me to test?
I assume you are talking about the HP omnibook 2100 which hangs with current kernel when accessing the harddisk.

ок, у нас сейчас интернета нет, что-то чинят на линии...

Линух разбивает настройку DMA на два шага, ide_dma_setup перед подачей команды и ide_dma_start после подачи команды, единственное действие последней - включить младший бит.

Теперь у меня работает, кроме одного древнего диска, не поддерживающего LBA48 и закономерно возвращающего HD read error. Поскольку больше никто не жаловался, я предлагаю коммитить. Выдать логин/пароль на запись svn или мне закоммитить?