Вопрос конечно глупый, но так, на всякий случай.
Ни что не мешает воткнуть в роутер усб хаб и использовать больше устройств?
Printable View
Вопрос конечно глупый, но так, на всякий случай.
Ни что не мешает воткнуть в роутер усб хаб и использовать больше устройств?
Сколько влезет ;)
Только не советую втыкать в usb2 хаб некоторые usb1 устройства. В частности, проблемы есть у USB-COM адаптеров на pl2303
а конкретнее, что за проблемы у pl2303 с usb2 хабами?Quote:
Originally Posted by al37919
в зависимости от реальзации, хабы могут устанавливать скорость работы по всем портам как у смого медленного - т.е. попался девайс который на 12мбит работает - просели все остальные висящие на этом хабе. Узнать это можно, зачастую, только разобрав хаб и посмотрав на каком чипе он собран.
поиск по конфе, однако, рулит.
2Duke
с pl2303 дело не в этом. Он вообще через usb2 не включается. А напрямую или через usb1 все ОК
Но это не исключает того, о чем написал я ;)
Странные вещи Вы говорите. Я лишь напомню, что те порты, которые Вы видите - тоже порты хаба, пусть даже интегрированного. :)Quote:
Originally Posted by al37919
Видимо не все хабы одинаково полезные, но обощать не стоит. :)
Нда, здорово это Вы меня в лужу посадили, спасибо за поправку. Я об этом как то не задумался :)
В общем, уточню так, что лично у меня есть два разных usb2 хаба и 2 pl2303 шнурка в разных корпусах. Ни одна комбинация не работает. Все выдают одну и ту же ошибку в логе, причем такую же на какую жалятся еще несколько клиентов в этой конфе. Никаких обобщений больше чем это :) На уровне слухов --- шнурки на FTDI работают с большей вероятностью, чем на pl2303, только их что то не видать.
А потянет ли внутренний хаб + внешний пассивный повешенных на них принтер+флешку+камеру+возможно, ещё Usb-хард? неохота лишнюю розетку с проводами занимать..
с hdd могут быть проблемы, насчет камеры не в курсе, остальное вроде много не потребляет.
Кажется, проблема уже обсуждалась неоднократно, но всё-таки хотелось бы подытожить, что в настоящее время по этому вопросу решено.
Имеется: 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)
USB Bluetooth прекрасно себя чувствует, находясь на разъёме корневого контроллера, причём функционирует он по USB1.1, о чём говорит Bus#1 (UHCI)Code:Bus# 1
`-Dev# 1 Vendor 0x0000 Product 0x0000
`-Dev# 2 Vendor 0x0a5c Product 0x2123
Остальные устройства функционируют по USB 2.0, о чём говорит Bus#3 (EHCI)
Кабель USB-COM PL2303 (который изначально и всегда был USB 1.1) не определяется, если подключен к концентратору, поэтому в иерархии о нём нет упоминания, зато есть ошибка в логе:
Если к порту 1 конревого концентратора подключить вместо USB Bluetooth кабель USB-COM PL2303, то система успешно обнаружит его.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)
Если этот кабель воткнуть назад в 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 выглядит так:
Аналогичный эксперимент был проведён на Ubuntu 8.10 (2.6.24). Были получены очень интересные результаты, а именно: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
В общем и целом поведение при отключении-подключении модулей было аналогичным, за исключением того, что подключенные к 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?
При подключении к WL-500GP(1.9.2.7-10) USB колонок Dialog AC-01 столкнулся с такой проблемой- колонки не определяются при подключении к активному HUB USB 2.0(к нему включен USB HDD),второй порт USB роутера занят принтером(он тоже не хочет определяться на HUB USB 2.0).Поиском узнал,что вероятно это из-за того,что колонки и принтер(Epson С91) USB 1.1 .Через HUB USB 1.1(сидит на мониторе LG) и колонки и принтер определяются нормально, но при одновременном включении проигрывания и принтера(даже не в режиме печати) звук искажается и дребезжит.Я так понимаю,что из-за конфликта USB колонок и принтера.При том работа флешки,воткнутой в этот же HUB USB 1.1 на звук никак не влияет даже при копировании больших файлов.Объясните пожалуйста причину конфликтов и как это можно разрулить?Много инфы на английском,но у меня с ним никак и в Linux я пока только осваиваюсь,так что если можно для чайников.В русской ветке тема поднималась,но к сожалению без внятных комментариев.
Удивительно,но проблема решилась заменой HUB USB1.1 из монитора на X-Storm ST1015.Видимо в LG Flatron F700P кривоватый HUB,хотя клава с мышью через него нормально пашут.Теперь через 2.0 подключаю HDD и флеху,а в 1.1 включен принтер и колонки.Я доволен.
Подниму-ка я тему, может кто из знающих проглядел, и добавит что по сути вопроса.Quote:
Originally Posted by namiri
- Готового решения я пока не знаю, поэтому решил покопаться сам. Предварительно, очень смахивает именно на ошибку в коде hub.c, сейчас сравниваю с веткой 2.6. Похоже, после инициализации порта, нужно бы выполнить несколько дополнительных действий, чего не сделано в старом ядре.
- Боюсь что нет, и это окончательно :(