Кажется, проблема уже обсуждалась неоднократно, но всё-таки хотелось бы подытожить, что в настоящее время по этому вопросу решено.
Имеется: WL500gP
На борту контроллер: 2+2 USB1.1, они же 4 USB2.0
Если втыкать любые устройства (USB1.1 или USB 2.0) непосредственно в сам контроллер, то они функционируют без проблем.
Для тестов рассмотрена следующая иерархия:
К разъёму 1 роутера подключен Bluetooth Broadcom USB Dongle.
К разъёму 2 - хаб, в него подключен USB HDD, UPS (HID) и ещё кабель USB-COM PL2303 (который не работает, об этом ниже)
К разъёму 4 подключена USB Flash, с которой роутер и грузится
Code:
lsusb -t
Bus# 2
`-Dev# 1 Vendor 0x0000 Product 0x0000
Bus# 1
`-Dev# 1 Vendor 0x0000 Product 0x0000
`-Dev# 2 Vendor 0x0a5c Product 0x2123 (usb bluetooth broadcom)
Bus# 3
`-Dev# 1 Vendor 0x0000 Product 0x0000
|-Dev# 2 Vendor 0x05e3 Product 0x0608 (hub)
| |-Dev# 6 Vendor 0x05e3 Product 0x0608 (hub)
| | `-Dev# 8 Vendor 0x051d Product 0x0002 (ups hid)
| `-Dev# 7 Vendor 0x152d Product 0x2339 (usb hdd)
`-Dev# 3 Vendor 0x0951 Product 0x1603 (usb flash)
Как видно из иерархии:
Code:
Bus# 1
`-Dev# 1 Vendor 0x0000 Product 0x0000
`-Dev# 2 Vendor 0x0a5c Product 0x2123
USB Bluetooth прекрасно себя чувствует, находясь на разъёме корневого контроллера, причём функционирует он по USB1.1, о чём говорит Bus#1 (UHCI)
Остальные устройства функционируют по USB 2.0, о чём говорит Bus#3 (EHCI)
Кабель USB-COM PL2303 (который изначально и всегда был USB 1.1) не определяется, если подключен к концентратору, поэтому в иерархии о нём нет упоминания, зато есть ошибка в логе:
Code:
Aug 23 11:37:24 kernel: hub.c: new USB device 01:03.2-2.3, assigned address 55
Aug 23 11:37:24 kernel: usb.c: unable to get device descriptor (error=-32)
Если к порту 1 конревого концентратора подключить вместо USB Bluetooth кабель USB-COM PL2303, то система успешно обнаружит его.
Если этот кабель воткнуть назад в USB-2.0 хаб, то произойдёт вышеуказанная ошибка. Аналогичная ошибка возникает при попытке подключения к USB2.0 хабу USB Bluetooth.
Если отключить модуль ядра ehci-hcd, который отвечает за USB 2.0, то все устройства, включая хаб и то, что воткнуто в него, садятся на Bus#2 (UHCI) и функционируют по протоколу USB 1.1. При этом отлично определяется и USB-COM PL2303, подключенный через хаб, и USB Bluetooth.
Если отключить модуль ядра usb-uhci, который отвечает за USB 1.1, то в системе определяются лишь USB2.0 устройства. Подключенные к корневому концентратору USB-COM PL2303 не определяется, USB-Bluetooth не определяется. Если вышеуказанные кабель и блютус втыкать в USB2.0 хаб, то снова возникает та же самая ошибка.
Конфиругация пот отключенном UHCI выглядит так:
Code:
Bus# 3
`-Dev# 1 Vendor 0x0000 Product 0x0000
|-Dev# 2 Vendor 0x05e3 Product 0x0608
| |-Dev# 6 Vendor 0x05e3 Product 0x0608
| | `-Dev# 8 Vendor 0x051d Product 0x0002
| `-Dev# 7 Vendor 0x152d Product 0x2339
|-Dev# 52 Vendor 0x05e3 Product 0x0608
`-Dev# 3 Vendor 0x0951 Product 0x1603
Аналогичный эксперимент был проведён на Ubuntu 8.10 (2.6.24). Были получены очень интересные результаты, а именно:
В общем и целом поведение при отключении-подключении модулей было аналогичным, за исключением того, что подключенные к USB2.0 хабу устройства USB 1.1 (USB-COM и USB Bluetooth) превосходно определялись и работали при загруженном лишь одном модуле ehci-hcd. В этом случае при подключении вышеназванных устройств напрямую к корневому концентратору наблюдалась полная тишина (устройство не опознавалось, вообще).
Из всего этого были сделаны следующие выводы:
1. на корневом концентраторе (без хабов):
а) USB 1.1 устройства работают через модуль UHCI
б) USB 2.0 устройства работаю через модуль EHCI
2. через USB 2.0 хаб - все устройства работаю через модуль EHCI
3. через USB 1.1 хаб - все устройства работаю через модуль UHCI
Однако, в отличие от ББ (Ubuntu) на роутере через USB 2.0 хаб устройства USB 1.1 отказываются функционировать с ошибкой unable to get device descriptor (error=-32).
Если отключить USB 2.0 в принципе на роутере (смонтировать /dev/null в /lib/modules/..../ehci-hcd.o), то все устройства начинают функционировать по протоколу 1.1, при этом определяются и работаю без особых затыков.
Исключение составляет лишь USB HDD при работающем торренте. В данном случае возникает экстремальная загрузка процессора (до 5 ждущих процессов), однако top упорно показывает, что система занята на 10-12%. Обмен данными с диском в этом случае не превышает 10-25кБайт/сек (то есть затык не по пропускной способности USB1.1). Есть догадка, что систему грузят постоянные прерывания от USB-контроллера, которые мешают работать. Собственно, если бы не последнее явление, то можно было бы оставаться на USB1.1.
А теперь вопросы:
1. может быть есть решение проблемы подключения USB1.1 устройств в USB2.0 хаб под linux 2.4.20 или хотя бы патч?
2. есть ли способ избавиться от "тормозов" при активной работе с USB HDD в режиме 1.1?