Империя наносит ответный удар
Тест последнего USB-ядра на eBox-3310MX (Vortex86MX+).
Загрузка с USB-flash Sandisk 8GB FAT32. Были подключены также USB keyboard, USB mouse.
После загрузки все работает (флешка, мышка, клавиатура). На флешку файлы записываются, и потом в Windows открываются. Вот boardlog.txt, в частности, был записан на флешку из Колибри.

Кроме мышки, клавиатуры и флешки, не было подключено ничего. Однако система нашла еще: И если можно, добавь, пожалуйста, '\r' после "K : USB mass storage device detected", а то в Windows это пишется в одну строчку: "K : USB mass storage device detectedK : 1 CPU detected"

Некоторые клавиатуры с выделенными мультимедиа-кнопками представляются как составные устройства из двух: первое - 03/01/01, клавиатура с обычными кнопками для непродвинутых клиентов, типа того же BIOS, второе - 03/00/00 с дополнительными кнопками и HID-дескриптором, описывающим такие кнопки.

Извини - совсем забыл, что ты уже писала это (и даже именно мне) 1.5 года назад (22/06/2011):

CleverMouse wrote:два разных HID-интерфейса на одной физической клавиатуре - это нормально, даже Microsoft использует это в качестве примера к своим иллюстрациям, в качестве второго интерфейса выступают "power keys".

Тестировал горячее подключение-отключение мышек, клавиатур и флешек на eBox-3310MX.

Флешка подключается и отключается неограниченное число раз без проблем. Клавиатура и мышка после отключения обратно больше не подключаются в те же порты, от которых были отключены. Если отключить флешку и в тот порт, где она была подключена, подключить клавиатуру или мышку, то подключается нормально. Если отключить клавиатуру или мышку и в тот же порт попытаться подключить флешку, то тоже не подключается. Т.е. если подытожить, после отключения клавиатуры или мышки, в порт занятый ими ранее уже больше ничего не подключается. Лог прилагаю.

Тестил kernel.mnt. Получил информацию о том, что в системе есть хабы. Мышки, клавы, джойстики, флешки, беспроводные мышки и клавы - не работают. Собственно, весь лог довольно короткий. Прикрепил дополнительно вывод lspci и lsusb в verbose.

Я обновила ядро http://ftp.kolibrios.org/users/CleverMo ... kernel.mnt и драйвер http://ftp.kolibrios.org/users/CleverMo ... sbstor.obj . В драйвере косметическое изменение отладочного вывода с \n на \r\n по заявке yogev_ezra, его можно даже не обновлять. В ядре - исправления ошибок.
У 0CodErr AMI BIOS старой версии, которая ставит флажок "я владею контроллером, перед использованием сообщи мне", но забывает подписаться на сообщения о смене владельца. Обходится методом "проверяем, подписана ли BIOS на наше сообщение, если нет, то забираем контроль над устройством без спроса". Ну, или перехватом контроля без спроса по истечении таймаута, но зачем ждать, если можно не ждать?
У Leency тоже AMI BIOS, но поновее лет этак на 6, так что предыдущий баг в нём исправлен. Но есть куда более тонкая проблема:
* исходная ситуация: при загрузке подключено HighSpeed MassStorage-устройство типа флешки; в ходе POST BIOS назначает ему какой-то номер диска;
* ядро получает список USB-контроллеров и начинает их инициализировать. Инициализация EHCI-контроллеров идёт перед компаньонами, чтобы код ядра для компаньонов даже не видел устройств, которые заберёт EHCI;
* инициализация начинается с посылки сообщения BIOS о желании контроля над устройством;
* BIOS получает сообщение, останавливает, деконфигурирует EHCI-контроллер, освобождает все внутренние структуры и забывает про него. В принципе, могла бы и не останавливать, но имеет право;
* код ядра продолжает инициализацию EHCI;
* тем временем, поскольку EHCI-контроллер деконфигурирован, владение флешкой переходит к компаньону;
* контроллер-компаньон всё ещё находится под контролем BIOS. Та обнаруживает новое устройство и начинает работать с ним;
* BIOS обнаруживает, что это MassStorage-устройство, которому уже назначен номер диска. BIOS умная и делает вывод, что это то же самое устройство, только заново переподключённое;
* ...а потому нужно использовать уже заполненные структуры данных;
* ...в одной из которых содержится старый указатель на данные контроллера. Того самого, который остановлен, деконфигурирован и забыт;
* в ходе дальнейшей инициализации BIOS пытается послать команду флешке посредством забытого EHCI-контроллера, используя уже освобождённые области памяти, забитые нулями при освобождении. Упс;
* далее, естественно, код быстро начинает ехать крышей, а поскольку это код BIOS внутри SMM, заканчивается это зависанием системы.
Непостоянность проявления связана с тем, что компаньон - UHCI, который не посылает события о подключениях/отключениях. Чтобы обойти это, BIOS поддерживает фейковую транзакцию чтения одного байта от устройства с несуществующим адресом, которая происходит каждые 256 миллисекунд, всегда завершается ошибкой, о которой контроллер посылает событие. Такой специфический SMM-таймер, при срабатывании которого BIOS перечитывает состояние портов UHCI-контроллеров. Ядро в ходе инициализации EHCI выжидало 50 миллисекунд - сейчас уже нет, но выжидало - для двух контроллеров получается окно в 100 миллисекунд. Если одно событие от 256-миллисекундного таймера попадает в окно - получаем зависание, если нет - ядро успевает отобрать контроль над UHCI.
Лечится путём разделения обработки контроллеров на захват контроля и собственно инициализацию, после чего захват контроля происходит в порядке "сначала компаньоны, потом EHCI", а инициализация - в обратном порядке.

Ошибка с невидимыми устройствами на порту, из которого вытащили LowSpeed-устройство, - техническая, при обновлении статуса порта код EHCI задевал бит питания. При отключении LowSpeed-устройства контроллер возвращал владение в EHCI, обнаруживал, что в EHCI-статусе бит питания сброшен, и честно отключал питание порта. Её я исправила.

Кроме того, теперь ядро не включает USB-накопители в список /bd*. По крайней мере, теоретически.

Какие устройства имеет смысл тестировать? У меня из предполагаемого есть: мышки, клавиатура, флешки, внешний усб-хост. Другие устройства не имеет смысла втыкать? При подключении внешнего хоста нужно втыкать в него мышки, клавиатуру, флешки?

Другие устройства включать тоже можно для проверки того, что они определяются и что с ними идёт обмен информацией. Свои функции они выполнять, конечно, не будут.
Для внешнего хаба пока что должен опознаваться только сам хаб и число портов на нём, но не подключённые через него устройства.

Взял kolibri.img r3377, взял: kernel.mnt, usbhid.obj, usbstor.obj, заменил в образе kernel.mnt, и запихнул usbhid.obj и usbstor.obj в /sys/drivers/, сохранил образ, скопировал на усб-флешку, гарантированно работающую с ночной сборкой.

Dell Inspiron N7010 (Intel i5)

Spoiler:

dell.jpg (102.04 KiB)

Viewed 3605 times

Флешка, мышка, клава не работают.

Roverbook U800

Spoiler:

u800.png (95.4 KiB)

Viewed 3605 times

ASRock M3A770DE Athlon II x2 245

Spoiler:

asus.png (84.9 KiB)

Viewed 3605 times

В первом логе большая часть ожидаемая - конфигурация "EHCI без компаньонов, но с виртуальными хабами", только напрягают строка про "something terrible" и падения kfm. Судя по второму и третьему логу, что-то я поломала, только непонятно, что именно. Ядро, дублирующее отладочный лог на экран: http://ftp.kolibrios.org/users/CleverMo ... el_dbg.mnt

Roverbook U800

Spoiler:

u800.png (33.84 KiB)

Viewed 3575 times

Падения KFM это на TMP диске, два раза пробовал, два раза падало. Возможно последствия использования ф.64. Или кривой мой кривой код работы с именами. А может код ядра чего неправильно выдает - в остальных случаях F70 отрабатывает нормально.

С KFM всё понятно, там сортировка предполагала, что папка непуста, это я исправила в r3378.
С контроллерами ничего не понятно. Я добавила больше отладочного вывода в http://ftp.kolibrios.org/users/CleverMo ... kernel.mnt , может быть, он прояснит ситуацию.

Попрбовал http://ftp.kolibrios.org/users/CleverMo ... el_dbg.mnt
Были падения KFM и Kfar, но как-то от случая к случаю, после этого ничего больше не запускалось.
Пробовал чтение\запись — работает.
Грузился с /usbhd0/1.

При падении kfar или kfm нужно записывать куда-нибудь данные с доски отладки. По сообщению "что-то где-то упало" диагностику поставить невозможно. По доске отладки, строго говоря, тоже не всегда можно, но хотя бы шансы появляются.