[sisyphus] Обновление libusb и nut

Alexander Bokovoy =?iso-8859-1?q?ab_=CE=C1_altlinux=2Eorg?=
Вс Сен 21 08:33:01 MSD 2008


2008/9/21 Ivan Adzhubey <iadzhubey на rics.bwh.harvard.edu>:
>> Рекомендую проверить права на соответствующие устройства.
> Какие устройства? И как их проверять, если их все равно нет и не может быть в
> чруте? Или вы имеете в виду, что в режиме чрута оно вообще работать не может?
> А как раньше работало?
Сам удивляюсь.

>> Сообщения от libusb -- нормальная реакция на невозможность открыть
>> несвязанные с нашей работой устройства на запись.
> Странно, но до апдейта никаких сообщений о permission denied от libusb я не
> наблюдал. А как выставлять права на устройство, оно же создается динамически
> udev'ом? Это надо в скрипты настройки udevd лезть? Кошмар...
libusb сканирует шину USB. Делается это дважды: вначале сканируются
/dev/bus/usb/*/*, затем -- если ничего не найдено -- сканируется
/proc/bus/usb/*. При попытке получить информацию об устройстве,
newhidups вначале открывает его, а затем читает дескриптор устройства.
Для этого ему нужно открыть устройство на запись (он посылает в
устройство запрос о его состоянии). В libusb 0.1 позволялось открывать
устройства, для которых нет прав на запись, а потом получить
невозможность записать при первой же записи. На самом деле, для чтения
дескриптора вообще не надо открывать его на запись, о чем libusb 0.9.3
и говорит. Раньше такое сообщение в libusb 0.1.12 отсутствовало,
потому его Вы и не видели. Это нормальное поведение, оно отражено в
описании разницы libusb-compat и libusb 0.1.12, и не представляет
проблемы.

Права естественно надо настраивать. Например, вот так:
/etc/udev/rules.d/60-nut-usb.rules
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<
ACTION!="add", GOTO="nut_end"
SUBSYSTEM!="usb|usb_device", GOTO="nut_end"

GROUP="upsdrv"
MODE="0660"
SYSFS{idVendor}=="051d", SYSFS{idProduct}=="0002"
SYSFS{idVendor}=="0764", SYSFS{idProduct}=="0005"
SYSFS{idVendor}=="0764", SYSFS{idProduct}=="0501"
SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="2005"
SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="1003"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0980"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0900"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0912"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0551"
SYSFS{idVendor}=="050d", SYSFS{idProduct}=="0751"
SYSFS{idVendor}=="0592", SYSFS{idProduct}=="0002"
SYSFS{idVendor}=="06da", SYSFS{idProduct}=="0002"
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="0001"
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff"

LABEL="nut_end"
--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8

Предлагаю прислать идентификаторы (в багзилу) и собрать их как список
SYSFS(idVendor} и SYSFS{idProduct} в пакете nut-driver-usb. В
указанном файле нужно только добавлять строчки с SYSFS, все
поддерживаемое текущим nut я уже добавил.

>> После чего все работает, но регулярное сканирование шины реализовано в
>> newhidups некорректно, из-за этого там утекает память:
>> Out of memory: kill process 27946 (newhidups) score 652587 or a child
>> Killed process 27946 (newhidups)
>>
>> Я сейчас разбираюсь с кодом drivers/libusb.c в NUT.
>
> Утечек памяти у меня тоже не наблюдалось, по крайней мере таких, чтобы оно
> отваливалось по недостатку памяти. Платформа x86_64 если это имеет значение.
В данном случае платформа роли не играет. Я разбираюсь с кодом.

-- 
/ Alexander Bokovoy


Подробная информация о списке рассылки Sisyphus