texas instruments ohci compliant ieee 1394a host controller что это такое
filecheck .ru
Вот так, вы сможете исправить ошибки, связанные с ohci1394.sys
Информация о файле ohci1394.sys
Процесс 1394 OpenHCI Port Driver или AGERE OHCI Compliant IEEE (версия 1394 Host Controller) или Texas Instruments OHCI Compliant IEEE (версия 1394 Host Controller) принадлежит программе AGERE OHCI Compliant IEEE (версия 1394 Host Controller) или Texas Instruments OHCI Compliant IEEE (версия 1394 Host Controller) или VIA OHCI Compliant IEEE (версия 1394 Host Controller) или OHCI Compliant IEEE (версия 1394 Host Controller) или 1394 OHCI Compliant Host Controller (Legacy) или NEC FireWarden OHCI Compliant IEEE (версия 1394 Host Controller) от Microsoft (www.microsoft.com).
Важно: Некоторые вредоносные программы маскируют себя как ohci1394.sys, особенно, если они расположены не в каталоге C:\Windows\System32\drivers. Таким образом, вы должны проверить файл ohci1394.sys на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.
Комментарий пользователя
Лучшие практики для исправления проблем с ohci1394
Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.
ohci1394 сканер
Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.
Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.
SpeedUpMyPC бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.
Архитектура ЭВМ
Компоненты ПК
Интерфейсы
Мини блог
Самое читаемое
Как рассчитать количество дезинфицирующего средства на помещение repair-school.com. Подшипник роликовый конический размеры: подбор подшипников по размерам sf2v.ru.
Шина IEEE 1394 — FireWire
«Открытый» хост-контроллер IEEE 1394 — OHCI
Общая информация об «открытом» хост-контроллере IEEE 1394 — OHCI
Со стороны шины 1394 хост — узел с контроллером OHC — выглядит как обычный узел шины, способный выполнять функции мастера циклов и диспетчера изохронных ресурсов. Контроллер позволяет хосту быть инициатором любых транзакций шины 1394 и отвечать на любые транзакции, адресованные узлу хоста.В адресном пространстве этого узла расположены архитектурные регистры CSR и память конфигурации; большая часть пространства доступна для обращений в виде обычных транзакций шины. Часть пространства узла может отображать пространство физических адресов памяти хоста. Часть обращений к хосту может отрабатываться исключительно аппаратными средствами контроллера; остальные обращения хост отрабатывает программно. Принимаемые пакеты запросов для программной отработки OHC своими каналами DMA помещает в буферы, размещенные в памяти хоста. Пакеты ответов программа размещает в других буферах, из которых OHC организует их передачу в шину, опять же с помощью каналов DMA.
Для асинхронных транзакций контроллер обеспечивает чтение пакетов из системной памяти хоста и их передачу в шину; пакеты, принимаемые из шины, контроллер записывает в системную память. Обмен производится с помощью каналов DMA. Контроллер может функционировать и как шинный мост, аппаратно отрабатывая запросы транзакций чтения и записи шины 1394 как обращения к пространству памяти хоста.
Для изохронных операций OHC может исполнять роль мастера циклов, синхронизируясь от внутреннего генератора синхронизации или (необязательно) от внешнего источника. Если OHC не исполняет роль мастера циклов, то он поддерживает синхронизацию внутреннего таймера циклов с таймером узла-мастера циклов (по приему пакетов начала цикла). Для изохронных операций OHC имеет два контроллера DMA — для приема и для передачи данных. Каждый из этих контроллеров может поддерживать до 32 каналов DMA, называемых контекстами DMA. Передающий контроллер в каждом цикле может передавать данные из каждого контекста для связанного с ним изохронного канала. Принимающий контроллер способен в каждом цикле принимать данные в каждый контекст из связанного с ним канала. Кроме того, один из принимающих контекстов может быть настроен на прием данных из множества каналов.
По обнаружении сброса на шине OHC автоматически очищает все очереди асинхронных пакетов для передачи; прием пакетов не прерывается, но в потоке пакетов запросов появляется маркер, индицирующий факт сброса. Новый физический идентификатор узла (PHY_ID), получаемый от PHY, контроллер записывает в соответствующий регистр. Контроллер возобновит асинхронные передачи только по указанию программы, при этом повторное использование старых запросов в общем случае невозможно: физический идентификатор узла назначения может измениться. Изохронный прием и передача по сбросу не прекращаются — они возобновляются сразу по завершении инициализации.
Устройство контроллера OHC
Упрощенная структурная схема OHC приведена на рисунке.
Интерфейс системной шины (Host Bus Interface) обеспечивает взаимодействие с контроллером в двух режимах:
Контроллеры DMA обеспечивают обмен данными между шиной и системной памятью. В OHC имеются семь типов контроллеров DMA:
равляющих работой канала и выборкой запросов из списков, расположенных в системной памяти. Контроллеры асинхронной передачи и приема имеют отдельные контексты для запросов и ответов шинных транзакций. Контроллеры изохронного приема и передачи могут иметь до 32 контекстов каждый. Назначение и работа контроллеров подробно описано ниже.
LINK-уровень OHC передает пакеты из FIFO-буферов передающих каналов и отдает в FIFO принятые пакеты с корректным адресом, предназначенные данному узлу. Уровень выполняет следующие действия:
Буферы FIFO, находящиеся между каналами DMA и LINK-уровнем, выполняют промежуточную буферизацию данных, считываемых из системной памяти для передачи в шину и принятых из шины для записи в память. Буферы FIFO обеспечивают и согласование выравнивания данных, побайтного для хоста и поквадлетного для шины 1394. При необходимости буферы FIFO вставляют байты-заполнители, выравнивающие данные до границ квадлетов. Переполнение (overflow) или переопустошение (underrun) буферов (по вине интерфейса системной шины и памяти), приводящее к потерям принимаемых или передаваемых пакетов, контролируется аппаратными средствами OHC.
Буферы могут «на лету» выполнять преобразование форматов представления квадлетов. Шина IEEE 1394 и, соответственно, LINK-eровень работают с квадлетами, представленными в формате Big Еndian (старший байт передается первым). Передача данных через хост-интерфейс может выполняться по выбору:
Для поддержки функций управления OHC имеет 64-битный регистр уникального идентификатора (GUID, он же IEEE EUI-64), автоматически загружаемый из энергонезависимой памяти по сбросу контроллера (или однократно программируемый в самом контроллере).
Для выполнения функций диспетчера изохронных ресурсов контроллер имеет четыре автономных регистра, реализующих блокированные операции (compare_swap) как со стороны шины, так и со стороны хоста.
Контроллеры DMA
Контроллеры DMA OHC по способу управления разделяются на два типа:
Контроллер асинхронной передачи (Asynchronous Transmit), AT DMA, имеет по одному контексту для передачи запросов (AT Request) и ответов (AT Responce). Для каждого отправленного пакета контроллер ожидает пакет квитирования; в случае получения квитанции ack_busy (занято) контроллер организует программно заданное число попыток повтора. Контроллер может реализовать однофазный или двухфазный протокол повторов. Если контроллер реализует изменение порядка исполнения, то он в случае занятости узла-получателя может продвигаться дальше по контекстной программе, возвращаясь к повтору данного пакета позже. Контроллер AT DMA отвечает и за ответы на запросы к физической памяти, обнаруженные принимающим контроллером DMA.
Прием асинхронных пакетов выполняют блок физических запросов и контроллер асинхронного приема.
Блок физических запросов, Physical Request Unit, включается в работу, когда приходит пакет запроса одного из трех типов:
Остальные асинхронные пакеты обслуживает контроллер асинхронного приема (Asynchronous Receive), AR DMA, который имеет по одному контексту для приема запросов (AR Request) и ответов (AR Responce). Этот же контроллер обслуживаети запросы блокированных транзакций, адресованных не к регистрам изохронных ресурсов, помещая их в контекст AR Request.
Контроллер DMA изохронной передачи (Isochronous Transmit), IT DMA, поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает передачу одного канала.
Контроллер DMA изохронного приема (Isochronous Receive) поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из контекстов можно запрограммировать на прием множества каналов.
Специальный контроллер, Self_ID DMA, принимает пакеты самоидентификации и укладывает их последовательно в один выделенный буфер. После каждого обнаруженного сброса контроллер начинает укладку пакетов с начала буфера, затирая предыдущие пакеты.
Фильтрация асинхронных запросов
Каждый приходящий асинхронный запрос, не относящийся к 1-килобайтной области памяти конфигурации, фильтруется трехступенчатым фильтром. Первая ступень фильтра по идентификатору узла-источника определяет судьбу запроса:
Запросы чтения памяти конфигурации принимаются от любых источников и отрабатываются аппаратно (если в хост-контроллере определен корректный образ памяти конфигурации).
Фильтрацией асинхронных запросов управляют 64-битные регистры AsynchronousRequestFilter и PhysicalRequestFilter, каждый из которых представлен регистрами установки и сброса старшей (Hi) и младшей (Lo) половин. Первая ступень фильтрации выполняется в соответствии с содержимым регистра AsynchronousRequestFilter. В этом 64-битном регистре единица в старшем бите (asynReqResourceAll) разрешает отработку асинхронных запросов от всех источников. При его нулевом значении остальные биты разрешают отработку запросов от узлов с PHY_ID, соответствующих номерам бит (младший бит соответствует PHY_ID = 0). Управление данным фильтром осуществляется через регистры AsynchronousRequestFilterHiSet (100h), AsynchronousRequestFilterHiClear (104h), AsynchronousRequestFilterLoSet (108h), AsynchronousRequestFilterLoClear (10Ch).
Вторая ступень фильтрует прошедшие запросы по адресу смещения, указанному в пакете запроса. Кандидатами на физическую отработку являются запросы, адресованные к нижней области памяти и к автономным регистрам. Граница нижней области задается регистром PhysicalUpperBound (120h) — в нем содержатся старшие 32 бита 48-разрядного адреса начала средней области памяти, которая уже не попадает в кандидаты на физическую отработку запросов. Младшие 16 бит считаются нулевыми. Если данный регистр отсутствует в OHC, то его чтение дает нули, что должно трактоваться как указание на размер нижней области 4 Гбайт.
Последний фильтр, управляемый регистром PhysicalRequestFilter, определяет способ обработки запроса-кандидата на физическую обработку. В этом 64-битном регистре единица в старшем бите (physReqResourceAllBuses) разрешает физическую обработку запросов от узлов всех шин. Остальные биты относятся к узлам локальной шины (на которой находится узел с OHC), они разрешают физическую отработку запросов от узлов с соответствующими номерами. Запросы, не прошедшие через данный фильтр, направляются в контекст AR_Request DMA и обрабатываются программно. Управление данным фильтром осуществляется через регистры PhysicalRequestFilterHiSet (110h), PhysicalRequestFilterHi-Clear (114h), PhysicalRequestFilterLoSet (118h), PhysicalRequestFilter-LoClear (11Ch).
Контексты DMA
Контекст DMA, образующий независимый канал DMA, состоит из контекстной программы и регистров контроллера. Контекстная программа — это список команд, отрабатываемых контроллером для передачи и приема пакетов данных. Каждый контекст DMA представлен в контроллере своим блоком регистров, в который входят регистры ContextControl (управление и состояние) и CommandPtr (указатель на команду). В дополнение к этому контексты изохронного приема имеют свои регистры шаблонов совпадений ContextMatch и общий регистр масок мультиканального приема. В последующем описании указывается смещение регистров относительно начального адреса своего блока регистров.
Управляющий регистр ContextControl контекста представлен парой регистров ContextControlSet (+0h) и ContextControlClear (+4h), обеспечивающих установку, сброс и чтение битов и полей. Формат регистра для асинхронных контекстов приведен на рисунке ниже, форматы регистров для изохронных контекстов описаны в соответствующем разделе. Назначение полей, используемых в регистрах всех контекстов, приведено далее:
Таблица. Коды событий для контекстов DMA
| Код | События | Контексты |
| 00 | evt_no_status, нет индикации события | AT, AR, IT, IR |
| 01 | reserved | |
| 02 | evt_long_packet, длина данных в принятом пакете больше, чем размер буфера | IR |
| 03 | evt_missing_ack, потерян пакет подтверждения ack | AT |
| 04 | evt_underrun, недостаточно данных в FIFO, переданный пакет усечен | AT |
| 05 | evt_overrun, переполнение FIFO при изохронном приеме | IR |
| 06 | evt_descriptor_read, неисправимая ошибка при чтении дескриптора контроллером | AT, AR, IT, IR |
| 07 | evt_data_read, неисправимая ошибка при чтении контроллером из памяти данных для передачи | AT, IT |
| 08 | evt_data_write, неисправимая ошибка при записи данных в память хоста | AR, IR, IT |
| 09 | evt_bus_reset, признак приема пакета, синтезированного по обнаружении сброса на шине | AR |
| 0A | evt_timeout, не удалась своевременно отправка пакета асинхронного ответа или изохронный контекст не смог записать число пропущенных циклов | AT, IT |
| 0B | evt_tcode_err, неверный код транзакции в принятом пакете | AT, IT |
| 0C-0D | Резерв | |
| 0E | evt_unknown, неизвестная ошибка | AT, AR, IT, IR |
| 0F | evt_flushed, пакет был отброшен из-за сброса шины | AT |
| 10 | Резерв | |
| 11 | ack_complete, пакет запроса или ответа от хоста успешнопринят узлом назначения и на этом транзакция завершена. Для пакетов, не требующих подтверждений, этот признак устанавливается автоматически | AT, AR, IT, IR |
| 12 | ack_pending, пакет запроса от хоста принят успешно узлом назначения, субакция ответа последует позже | AT, AR |
| 13 | Резерв | |
| 14 | ack_busy_X, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_X | AT |
| 15 | ack_busy_A, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_A | AT |
| 16 | ack_busy_B, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_B | AT |
| 17-1A | Резерв | |
| 1B | ack_tardy, узел назначения не может принять пакет, поскольку его LINK приостановлен (в состоянии suspended) | AT |
| 1C | Резерв | |
| 1D | ack_data_error, AT-контекст принял пакет ack_data_error или изохронный контекст обнаружил ошибку CRC или длины данных (при приеме каждого пакета в отдельный буфер) | AT, IR |
| 1E | ack_type_error, недопустимый тип транзакции | AT, AR |
| 1F | Резерв |
Регистр CommandPtr (+Ch) содержит указатель на блок дескрипторов (старшие 28 бит адреса в поле descriptorAddress) и индикатор длины этого блока (поле Z). Длина (поле Z) указывается в 16-байтных блоках; дескрипторы выровнены по границе параграфа (младшие 4 бита — нулевые). Индикатор Z = 0 означает недействительность указателя — признак окончания контекстной программы. Допустимое число блоков в дескрипторе зависит от типа контекста. При инициализации контекста в регистр заносится указатель на начальный блок дескрипторов и их число в блоке. Дальнейшая программная модификация регистра допустима лишь при нулевом значении признаков run и active. Чтение регистра, в зависимости от состояния признаков run, dead, active и wake, дает различные значения указателей:
Инициализация контекста начинается с проверки состояния — биты run, active и dead должны быть сброшены. При этом условии в регистр CommandPtr помещается указатель на блок дескрипторов (и длина блока), после чего можно программно установить бит run.
Добавление дескрипторов в список возможно в любое время. Для этого в памяти формируется дескриптор или связанный список дескрипторов, и указатель на него (и поле Z) помещается в адрес перехода, находящийся в последнем дескрипторе прежнего списка. После этого необходимо программно установить бит wake — указать контроллеру на обновление списка.
Остановка контекста выполняется программным сбросом бита wake, но это может и не привести к немедленной остановке. Признаком остановки контекста после сброса run является обнуленный бит active.
1394 Ohci совместимый хост контроллер windows 7
Подробнее о пакете драйверов:
OHCI Compliant IEEE 1394 Host Controller. Характеристики драйвера
Драйвер OHCI Compliant IEEE 1394 Host Controller для Windows от Microsoft. Ручная установка драйвера.
Внимание! Перед установкой драйвера OHCI Compliant IEEE 1394 Host Controller рекомендутся удалить её старую версию. Удаление драйвера особенно необходимо – при замене оборудования или перед установкой новых версий драйверов для видеокарт. Узнать об этом подробнее можно в разделе FAQ.
Файлы для скачивания (информация)
Рейтинг: 2.9/5 ( Проголосовало: 18 чел.)
Драйверы для VIA 1394 OHCI Compliant Host Controller собраны с официальных сайтов компаний-производителей и других проверенных источников. Официальные пакеты драйверов помогут исправить ошибки и неполадки в работе VIA 1394 OHCI Compliant Host Controller (устройства ввода). Скачать последние версии драйверов на VIA 1394 OHCI Compliant Host Controller для компьютеров и ноутбуков на Windows.
Windows Driver Download Center
Use the links on this page to download the latest version of LSI 1394 OHCI Compliant Host Controller drivers. All drivers available for download have been scanned by antivirus program. Please choose the relevant version according to your computer’s operating system and click the download button.
Your machine is currently running: Windows (Detect)
LSI 1394 OHCI Compliant Host Controller Drivers Download
Please enter verification code, then click the download button.
Please enter verification code, then click the download button.
Please enter verification code, then click the download button.
Please enter verification code, then click the download button.
Please enter verification code, then click the download button.
Texas instruments ohci compliant ieee 1394a host controller что это такое
Загрузить драйверы
TI VIA OHCI Compliant IEEE 1394 Host Controller
Инструкции по обновлению драйвера VIA OHCI Compliant IEEE 1394 Host Controller вручную:
Эти стандартные драйверы VIA OHCI Compliant IEEE 1394 Host Controller можно найти в %%os%% или загрузить из обновления Windows®. Встроенные драйверы будут поддерживать основные функциональные возможности вашего Disk Controller, но, как правило, не более расширенные функции. Наши инструкции по обновлению драйверов Texas Instruments содержат все необходимые шаги.
