From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 6 Sep 2006 15:23:20 +0400 From: "A.Kitouwaykin" To: hardware@lists.altlinux.org Message-Id: <20060906152320.771a6582.cetus@newmail.ru> Organization: Radioavionika X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: [Hardware] =?koi8-r?b?7c7Px88gVVNCIC0gUlMyMzI=?= X-BeenThere: hardware@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: hardware@altlinux.ru List-Id: ALT Linux hardware support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2006 11:23:29 -0000 Archived-At: List-Archive: List-Post: Добрый день. Есть проблема. Для подключения к внешней аппаратуре через RS232 с использованием minicom и, иногда, tcp/ip через slip, к специальному компьютеру беспорядочно подключены несколько переходников USB - RS232C, опознаваемые как PL-2303. Аппаратуры много, и, поскольку USB-выводов недостаточно, все это хозяйство, опять же беспорядочно, подключается через некоторое количество USB-хабов (были также вариации с дополнительными USB-контроллерами). При этом обычно непонятно, какой /dev/ttyUSBx какому хвосту соответствует. Обычная практика определять это эмпирически, исследуя сообщения на 12 консоли в связи с выдергиванием и обратным подключением нужного переходника PL-2302. В какой то момент это перестает работать. При этом может отвалиться часть портов, а часть останется работать, могут отвалиться все. Может проскочить сообщение о том что группа портов отвалилась (disconnect), причем устройства тут же обнаруживаются и активизируются, но уже с совершенно другим номером /dev/ttyUSBx. При этом связь с открытым ранее устройством теряется, но процесс (minicom, slip) никогда об этом не узнает. Все это совершенно непонятно, почему. И совершенно непонятно, почему после каких-то плясок с бубнами, перезагрузками и перетыканием хвостов потом снова что-то начинает работать. Система не самая свежая, мастер 2.2, но активно используемая, поэтому до существенного обновления "руки не доходят". К тому же на соседней, чуть менее загруженной машине с мастером 2.4 подобные глюки тоже бывают. Кто-нибудь что-нибудь может посоветовать полезного? Есть ли какие-то требования к топологии такой USB-сети, или рекомендации по ее построению? Есть ли какие-то ограничения на количество RS-портов (помимо ограничения, обходимого, на количество /dev/ttyUSBx)? Есть ли возможность установить однозначное соответствие между шнурком и номером устройства /dev/ttyUSBx? Где то мелькало, что в ядрах 2.6... Что смотреть в логах? Вот маленький пример, возможно не самый удачный: Sep 6 11:26:50 burro kernel: usb.c: USB disconnect on device 00:11.3-1.3.2 address 7 Sep 6 11:26:50 burro kernel: usbserial.c: PL-2303 converter now disconnected from ttyUSB1 Sep 6 11:26:52 burro kernel: hub.c: new USB device 00:11.3-1.3.2, assigned address 10 Sep 6 11:26:52 burro kernel: usb-uhci.c: interrupt, status 2, frame# 989 Sep 6 11:26:52 burro kernel: usb.c: couldn't get all of config descriptors Sep 6 11:26:52 burro kernel: usb.c: unable to get device 10 configuration (error=-84) Sep 6 11:26:52 burro kernel: hub.c: new USB device 00:11.3-1.3.2, assigned address 11 Sep 6 11:26:52 burro kernel: usb.c: couldn't get all of config descriptors Sep 6 11:26:52 burro kernel: usb.c: unable to get device 11 configuration (error=-84) Sep 6 11:27:08 burro kernel: usb.c: USB disconnect on device 00:11.3-1.3.4 address 9 Sep 6 11:27:08 burro kernel: usbserial.c: PL-2303 converter now disconnected from ttyUSB3 Sep 6 11:27:09 burro kernel: usb.c: USB disconnect on device 00:11.3-1.3.1 address 6 Sep 6 11:27:09 burro kernel: usbserial.c: PL-2303 converter now disconnected from ttyUSB0 Sep 6 11:27:09 burro kernel: hub.c: new USB device 00:11.3-1.3.1, assigned address 12 Sep 6 11:27:14 burro kernel: usb_control/bulk_msg: timeout Sep 6 11:27:34 burro last message repeated 4 times Sep 6 11:27:34 burro kernel: usb.c: couldn't get all of config descriptors Sep 6 11:27:34 burro kernel: usb.c: unable to get device 12 configuration (error=-110) Sep 6 11:27:35 burro kernel: usb_control/bulk_msg: timeout Sep 6 11:27:36 burro kernel: usb_control/bulk_msg: timeout -- Китайкин Анатолий Константинович ОАО "Радиоавионика", СПб