При выполнении команды modprobe usb-ohci (или service usb start) происходит полное зависание системы. Никаких диагностических сообщений не выводится, даже если все сообщения ядра перенаправлены на текущую консоль. Клавиатура и мышь отключаются полностью, курсор в framebuffer'ной консоли перестаёт мигать. Перезагрузка возможна только с помощью кнопки "Reset". Ошибка присутствует в ядрах серии 2.4 начиная, по крайней мере, с 2.4.20 (проверялись 2.4.20, 2.4.22 и 2.4.25) и отсутсвует в ядрах серии 2.2. Steps to Reproduce: 1. Исполнить команду modprobe usb-ohci на системе, в состав которой входит материнская плата на базе чипсета Ali Aladdin V. Actual Results: Полное зависание системы. Expected Results: Нормальная работа подсистемы usb.
Created attachment 361 [details] lspci -vv output Вывод команды lspci -vv системы, на которой проявляется ошибка.
А в BIOS есть какие-нибудь опции по поводу USB? Отличается ли вывод lspci -vv для 2.2 и 2.4? Что в /proc/interrupts? Опция pci=biosirq не меняет ситуацию?
Created attachment 367 [details] lspci -vv output for kernel 2.2.22
Created attachment 368 [details] cat /proc/interrupts output at 2.4.25
Created attachment 369 [details] cat /proc/interrupts output at 2.2 series kernel (see comments)
Created attachment 370 [details] lsmod output at 2.2.19 kernel 1) Содержимое /proc/interrupts для ядер серии 2.2 получено слегка нечестно: установленное ядро 2.2.22 не имеет модулей usb (на момент его компиляции они мне были не нужны), а времени скомпилировать их пока не было. Поэтому был взят вывод cat /proc/interrupts для 2.2.22 и добавлена строчка про usb из содержимого /proc/interrupts для ядра 2.2.19, запускающегося при инсталляции Junior 1.1. Если надо, я могу скомпилировать модули usb для 2.2.22 и проверить. 2) опция pci=biosirq при загрузке ядер серии 2.4 ничего не меняет (всё как висло, так и продолжает :( ). 3) как видно, вывод lspci для ядер 2.4.25 и 2.2.22 отличается. Главное, что я заметил -- IRQ 0 для контроллера IDE в 2.2.22 вместо IRQ 5 в 2.4.25. Кстати, для ядер серии 2.4 у меня наблюдалась ещё одна ошибка: происходило зависание (с выбросом oops и миганием светодиодов клавиатуры) при загрузке модуля ALSA для моей звуковой карты (причём в 2.2.22 было все нормально, при той же верии ALSA). Её удалось устранить перестановкой зв. карты в соседний разъём PCI. При этом её прерывание сменилось с 5(!) на 11.
Created attachment 374 [details] A fragment of dmesg output for 2.2.22
Created attachment 375 [details] cat /proc/bus/usb/devices output Собрал модули USB для 2.2.22. Как и ожидал, они загрузились без проблем, причём содеожимое /proc/interrupts полностью совпало с приведённым выше ("нечестным"). usbfs смонтировалась успешно, содержимое /proc/bus/usb/devices прилагается. P.S. Пробовал следующую фишку: в BIOS'е запретил использование IRQ 5 для PCI, в рез-те чего контроллер USB пересел на IRQ 9 (согласно табличке, выдаваемой при включении машины), однако 2.4.25 продолжает виснуть при загрузке модуля usb-ohci (равно как с pci=biosirq, так и без).
А если запретить и IRQ9? Может быть, удастся загнать USB на какое-то из работающих прерываний (если тут дело в прерываниях). И давайте полный вывод dmesg от 2.2.22 и 2.4.25. Ещё интерес представляет поведение ядер 2.6.x на этой машине. В 2.6.x предусмотрена защита от "залипших" прерываний: обработчики прерывания, зарегистрированные драйверами, возвращают статус - действительно ли их устройство выставляло прерывание; если запрос прерывания не обработал ни один драйвер, после некоторого количества вызовов IRQ отключается полностью - устройства, использовавшие эту линию, перестают работать, но хотя бы система полностью не виснет.
Created attachment 378 [details] dmesg from 2.2.22 kernel (after usb modules loaded and usbdevfs mounted)
Created attachment 379 [details] dmesg from 2.4.25 kernel Если запретить 5 и 9 прерывания в BIOS, USB садится на 10 (туда же, куда и SCSI host adapter). При загрузке 2.4.25 в этом случае имеем мёртвый вис (машина реагирует только на кнопочку "Reset") после строчки "ncr53c810-0: ID 7, Fast-10, Parity Checking".
Created attachment 383 [details] dmesg output from 2.6.5 kernel
Created attachment 384 [details] lspci -vv output under 2.6.5 kernel runned
Created attachment 385 [details] cat /proc/bus/usb/devices output with 2.6.5 kernel run and usbdevfs mounted С ядром 2.6.5 наблюдается следующая картина: modprobe ohci-hcd <задержка на долю секунды> disabling IRQ #5 При этом модули usbcore и ohci-hcd загружаются и usbdevfs монтируется. В dmesg появляется некая трассировка вызовов (см.). Если в BIOS запретить IRQ5, usb пересаживается на 9, ситуация остаётся той же с точностью до замены номера 5 на 9. Если заретить и 9, usb cадится на 10, туда же, куда и SCSI. При загрузке ядра имеем красоту, аналогичную приведённую в dmesg, а за ней: <0> Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing И мёртвый вис... Я подумал бы, что глючит железо, если бы не 2.2.22 -- оно нормально работает, даже если usb сидит на IRQ10, причём в /proc/interrupts так и сказано: IRQ10 ncr53c8xx, usb-ohci
Created attachment 397 [details] PIRQ table dumper Нашёл программку для анализа PCI IRQ routing: http://www.kernelnewbies.org/scripts/dump_pirq.pl (её нужно немного подправить - lspci у нас лежит не в /sbin; прицеплен уже исправленный вариант). Попробуйте прогнать её под разными ядрами и покажите вывод.
Created attachment 408 [details] Output of the above script at kernel 2.2.22
Created attachment 409 [details] the same for 2.4.22 and 2.6.5 kernels (no difference) Для ядер 2.4.22 и 2.6.5 вывод PIRQ table dumper'а идентичен. После загрузке модуля usb-ohci (для ядра 2.2.22) или ohci-hcd (для 2.6.5) монтирования usbdevfs ничего не меняется.
OK, ещё представляет интерес вывод lspci -vv -xxx -s 00:07.0 для 2.2 и 2.6. Также попробуйте на 2.6 перед modprobe ohci-hcd сделать setpci -s 00:07.0 4a.b=00
Да, lspci (и тем более setpci) необходимо запускать от root.
Created attachment 417 [details] lspci -vv -xxx -s ... result at 2.2.22 kernel
Created attachment 418 [details] the same for 2.6.5 kernel
Created attachment 419 [details] 2.6.5, "setpci" command applied
Created attachment 420 [details] dmesg from 2.6.5 kernel after "setpci" command implementation, ohci-hcd loading and usbdevfs mounting Итак, после прогона команды setpci с указанными параметрами при загрузке модуля ohci-hcd перестали появляться сообщения "disabling IRQ" и сопровождающий их вывод некоей трассировки в dmesg. Также и на ядре 2.4.22 после применения команды setpci загрузка модулей стала происходить без зависания и каких-либо сообщений об ошибках. Реальная работоспособность подсистемы USB ещё не проверялась.
2.6.16 -- всё как было, так и осталось...
Проблема в том, что BIOS содержит неверную таблицу прерываний PCI, где для устройства 00:0f.0 (IDE) указано использование link 0x05 (INT5), в то время как чип M1533 имеет только 4 входа для PCI IRQ (точнее, там есть и режим, в котором поддерживается подключение 8 входов IRQ, но для этого требуются внешние компоненты, и в данном случае такой режим не используется). При этом собственно для USB прерывание указано правильно (link 0x59 соответствует младшим 4 битам регистра 0x74). В принципе можно попробовать придумать по этому поводу какую-то проверку (например, запретить установку векторов для link 5..8, если не включен режим работы с использованием 8 входов PCI IRQ).
Created attachment 1469 [details] 01_pci-ali-m1533-check-pirqs.patch Например, можно попробовать такой патч (для 2.6.16, но ложится и на 2.6.14). У вас есть возможность собрать локально ядро с этим патчем для тестирования, или мне где-то выложить собранную версию?
Юр, это всё та же причудливая мамка?
Сорри за несвоевременную реакцию! В ближайшее время попробую приложить патч к альтовскому 2.6.16 (есть 2.6.16-wks26-up-alt3, думаю, что если заработает на нём, то и на alt8, а также std26-up-alt9 тоже должно) и проверю. Отвечаю Мише: да, мамка у меня аж с 2000 года, и в общем-то пока устраивает :) Если ещё usb на 2.6 заработает -- совсем хокей будет.
Created attachment 1618 [details] dmesg от пропатченного 2.6.16 С патчем не виснет, но и не работает. Модули загружаются, но если подключить usb-устройство, то ядро жалуется на обрубленное прерывание (см. dmesg), и дальше этого ничего не идёт. В то же время если произнести заклинание "setpci... ", и дальше грузить модули usb, то устройства работают нормально (проверял на флэшке, файлы читаются и пишутся с нормальной скоростью).
(In reply to comment #29) > С патчем не виснет, но и не работает. А что выдаёт lspci -vv -xxx -s 00:07.0 на пропатченном ядре (без setpci)?
Created attachment 1633 [details] Вывод lspci от пропатченного 2.6.16 Это вывод lspci от пропатченного 2.6.16(-wks26-up-alt3). Он оказался ровно таким же, как и от непропатченного ядра после прокатывания команды setpci. Другое дело, что на непропатченном ядре после setpci usb начинает работать...
(In reply to comment #28) > Отвечаю Мише: да, мамка у меня аж с 2000 года, и в общем-то пока устраивает :) Просто мне кажется, что она уже больше времени съела, чем стоит. Может, тебе KT133+Duron 800 посадить на поезд?
Знаешь, я ничего не хочу менять в своей машинке чисто из эстетических соображений :-) (Вроде АТ'шного корпуса образца 9х года, к которому привык как к родному) К тому же вырабатывается полезная привычка не пользоваться жирным тормозным софтом... а для остального она меня устраивает на 100%! И, главное, сразу видно, в какую сторону изменилось то или иное приложение после очередного обновления. А так, проапгрейдиться я мог бы давно кучу раз практически на холяву... но не хочу! Вот такой я, северный олень! ;-D
Знаешь, тогда это IMHO INVALID. :) (не, я помню, что 2.2.22 нормально работает -- вот как вариант и :)
(я понимаю, что на НГ ты багзилу не читал, но -- му-та-бор! :)
Я уже давно подставил рекомендованный костылик в виде запуска setpci перед hotplug и с тех пор счастлив настолько, что даже забыл про существование костыля. А лезть самому в ядро с каждым днём хочется всё меньше. Кстати, если бы в 2.2.22 работало всё, что мне нужно (или не нужно, но приходится ставить, чтобы не отставать от моды), то я, пожалуй был бы ещё более счастлив, прямо как слон после ведёрной клизЬмы.
Ну вот и аюшки, предлагаю WORKSFORME. :)
Ладушки, если будет время и дойдут руки, то попробую что-нибудь предпринять в этом направлении... хотя бы потрепать нервы kernel.org'у ;-D А раз ни у кого не вылезло, значит, действительно это мнуспецифичное дело.
