Странное поведение РS/2 контроллера

Имеется собственный фильтр РS/2 трафика. Реализован как обработчик прерывания клавиатуры, который читает даные из порта 60h, обрабатывает и возвращает их обратно в порт. Имеется синхронизация с i8042, маскировка APIC и т.д. Данный код совершенно безпроблемно работает на огромном количестве компьютеров. К сожалению, есть небольшой процент компютеров (порядка 0.1%) где он не работает. Все данные возвращаемые в 60h безвозвратно исчезают. То есть приходит прерывание, мой драйвер обрабатывает его, возвращает данные в порт РS/2 и они пропадают. Данная проблема очень "устойчива", т.е., есть компьютеры на которых она проишодит всегда. К сожалению, у меня нет физического доступа к проблемным компам. "Проблемными" могут оказатся как ноутбуки так и десктопы, разных производителей: бренды и самоделки.

Логично предположить, что есть конфликт с определеным типом железа. Но не удается восоздать конфликт на системе с такой-же материнкой.

Может есть на форуме знатоки железа. В какую сторону можно покопать? Может ли проблема быть вызванна настойками биос?

 

А ничего, что 60h порт по чтению и по записи имеет разные назначения?

 

ничего

 

Глупая идея : порт 60 связан с реальной клавиатурой. Может клавиатура виновата?

 

gektor
Может у них USB клавиатура?

 

valterg
Не совсем он связан с PS/2, то есть по сути со всеми устройствами, на нем висящими. Может с мышей конфликтует?

 

1. Клавиатура однозначно PS/2.
2. Порты 60/64 не связан напрямую с клавиатурой. Он связан с контроллером i8042. Поэтому можно предположить, что проблема не зависит от типа клавиатуры

Посмотрел реализацию kbdclass в WinDDK и обнаружил, что порт 60 не упоминается в явном виде. Может существуют PS/2 с портом отличным от 60?

 

Кстати, не думаю, что есть какя-либо проблема с мышью которая тоже использует порт 60, так как мышь висит на другом прервании. В любом случае, я пробовал PS/2 мышь - проблем не возникает.

 

лучше наверное посмотри реализацию драйвера i8042 (тоже в примерах ддк)

 

Посмотрел - видно, что используется исключительно порт 60.

 

Какая разница. Клавиатура это не простой набор кнопок : там стоит свой контроллер и они по PS/2 общаются друг с другом. Если клавиатура кривая, то i8042 тоже может глючить. Кстати i8042 давно уже нет, а есть кусок чипа, который его реализует. А стало быть некоторые редкие вещи могут глючить - дефект проектирования. Чего проще : заменить клаву и проверить.
С чипом тяжелее - тут надо статистику набирать. А одна из причин ошибки : i8042 в момент записи в 60-й порт чем-то "занят" и игнорирует запрос. Найти это - ОХ ТЯЖЕЛО. Попробуй парочку nop перед записью поставить, например. Еще одна неубиенная причина - проц/мама/видео разогнаны по частоте.
А 60-го порта может не быть по той причине, что он оставлен для совместимости с PC XT(!).
И везде рекомендуется использовать порт 64.

 

2 совсем разные функциональности у портов ведь, и что значит занят

 

valterg

Тебе под учиться не мешает.
64h используется для других целей.

Элементарно. Есть бит который говорит разрешена запись или нет.

 

Как данные возвращаешь? Надеюсь не простой записью в порт 60h?

 

глупые вопросы?
говорит же что 99% поддержано
ясное дело команда пишется

без машины на которой это все можно повторить врядли выйдет найти такой бок
а как вобще узнали, что на каких-то машинах не работает? и 0.1% и 99% это сколько в физических машинах (в смысле в штуках)?
проблемы могут быть с задержками иногда запись разрешена (буфер пуст и готов всмысле) бывало но данные в порт не ложились увы

 

Узнал, так как был доступ к "проблемному компьютеру" через системы удаленной администрации. Напихал логи в драйвер. Видно, что драйвер получает прерывание, вытаскивает из порта байт данных, возвращет его назад (проделав перед этим все необходимые манипуляции с синхронизацией контроллера) и он исчезает.

Обнаружилась еще более интересная и редко возникающая проблема. Любая попытка записать байт в порт 60 "убивает" клавиатуру и мышь (которая тоже подключена к рс/2). То есть клавиатура и мышь полностью перестают реагировать на действия пользователя. Я почти уверен, что проблема исключительно хардверная (или, может быть связанная с настройками биос), так как она начала появлятся после того как пользовател сменил материнскую плату.

 

Узнал, так как был доступ к "проблемному компьютеру" через системы удаленной администрации. Напихал логи в драйвер. Видно, что драйвер получает прерывание, вытаскивает из порта байт данных, возвращет его назад (проделав перед этим все необходимые манипуляции с синхронизацией контроллера) и он исчезает.

Обнаружилась еще более интересная и редко возникающая проблема. Любая попытка записать байт в порт 60 "убивает" клавиатуру и мышь (которая тоже подключена к рс/2). То есть клавиатура и мышь полностью перестают реагировать на действия пользователя. Я почти уверен, что проблема исключительно хардверная (или, может быть связанная с настройками биос), так как она начала появлятся после того как пользовател сменил материнскую плату.

 

Узнал, так как был доступ к "проблемному компьютеру" через системы удаленной администрации. Напихал логи в драйвер. Видно, что драйвер получает прерывание, вытаскивает из порта байт данных, возвращет его назад (проделав перед этим все необходимые манипуляции с синхронизацией контроллера) и он исчезает.

Обнаружилась еще более интересная и редко возникающая проблема. Любая попытка записать байт в порт 60 "убивает" клавиатуру и мышь (которая тоже подключена к рс/2). То есть клавиатура и мышь полностью перестают реагировать на действия пользователя. Я почти уверен, что проблема исключительно хардверная (или, может быть связанная с настройками биос), так как она начала появлятся после того как пользовател сменил материнскую плату.

 

может все таки не совсем верно тут что-то?

ты по какой спецификации делал? (всмысле выбирал задержки как)
я просто в разной документации встречал разные указания на этот счет

 

Ты уверен в том что вопрос глупый?
Ещё раз спрашиваю автора - как возвращаешь данные?
И имеется ввиду не проверка готовности контроллера.

Вот судя по этому я вижу что данные как раз просто выводятся в 60h порт с проверкой готовности.
А это неправильно, и то что где-то это работает факта неправильности не меняет.