|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 27 Aug 2002 17:33:49
To : Valentin Nechayev
Subject : Re: lost interrupt !
--------------------------------------------------------------------------------
Valentin Nechayev wrote:
> Совет проктолога для покупки унитаза как раз может быть крайне важен.
> ;)
Hу это кому как ;)
>>> плачевным, я тебя AD> уверяю.
> AB> Hадо бы не уверять а книжки читать на уровне А-сертификации.
>
> Что имеется в виду?
Конкретно выпущенный учебник для подготовки к сертификации на элементарное
знание компьютерного оборудования. Я его сам не читал, но лет несколько
назад купил своему чаду после того, как ему на уроке информатики тупой
препод сгорбатил, обозвав "зерно" маски "семенами" ;))) После этих "семян
на экране монитора", я решил прибегнуть к "силе печатного слова".
>>> этих машин и покажу тебе результаты. А lost interrupt - оно по другой
>>> причине. Тем более, что у автора оригинальной мессаги после пересборки
>>> ядра все заработало.
> AB> По моему скромному мнению прерывания теряются не в девайсах, а в
> процессе их AB> обработки программным драйвером. При обработке запроса на
> прерывание AB> система должна перейти в состояние блокировки всех
> прерываний уровня AB> обрабатываемого и ниже. Hо триггер приема прерываний
> от девайсов все равно AB> будет их фиксировать.
>
> Вы говорите о чем-то таком, что на x86 никогда не применялось.
Стоп ! Далее вы совершенно правильно пишите о линуксе и применяемых там
режимах обработки. Я же указал имеено то, как это реализовано на x86 в
контроллере PIC. Кстати, способы обработки прерываний юниксов весьма
архаичны, как и дуальная система приоритетов выполнения супервизор/юзер.
Все выросло из примитивной системы преимущественно поллинговой обработки
прерываний в младших DEC и такого простого деления приоритетов выполнения в
расширители памяти тамже. Именно x86 , а точнее IA32 , предоставляет массу
неиспользованных никем (ну может в OS/2 попытались) возможностей
аппаратурной (точнее микропрограммной) обработки функций ядра ОС.
> В Linux система простая - или прерывания разрешены (все), или запрещены
> (тоже все). Слово "все" здесь не включает NMI, но включает таймерные (0,
> 8). В BSD так называемые уровни прерываний не вводят между ними иерархию
> (кроме понятных соотношений - hardnet, он же imp, закрывает и softnet),
> а дают пригодные для наложения маски; cli/sti применяются в редких случаях
> и только в коде, напрямую работающем с железом или с переключением задач.
>
> AB> И также будет фиксировать все двойные прерывания как
> AB> "потерянные". Все прерывания от девайсов mass-media являются
> AB> инициированными самим драйвером {ну разве кроме открытия трея CD}.
> Т.е. AB> обычно потеря прерывания это программная ошибка или отсутствие
> необходимой AB> проверки корректности завершения запрошенной операции
> девайсом.
>
> ide.c говорит, что lost interrupt пишется, когда таймер истек, устройство
> по истечении таймера показывает ready, а прерывания так и не было.
> Мне сложно представить себе, чтобы это была полностью программная ошибка
> (хотя кто знает?)
Где-то так я и написал : Устройство завершило команду, а прерывание
наложилось и потому не отмечено в системе, т.е. потеряно. Вопрос: почему
оно наложилось ? Если все команды инициированы драйвером, то и все
завершения должны им фиксироваться. Гонки сигналов от девайсов ловятся
аппаратными защелками. И по идее это все должно однозначно расшифровываться
драйвером. А вот таки не расшифровалось. Обращаю ваше внимание на то, что
пересбор ядра устранил эту проблему. Hе буду далее настаивать, ибо "кто его
знает", но по всему выходит, что проблема в кодах.
Bye.
--
Aleksey Barabanov <alekseybb@mtu-net.ru>
--- ifmail v.2.15dev5
* Origin: intranet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
