From: "Alexander Bokovoy" <ab@altlinux.org> To: "Ivan Adzhubey" <iadzhubey@rics.bwh.harvard.edu> Cc: ALT Linux Sisyphus discussions <sisyphus@lists.altlinux.org> Subject: Re: [sisyphus] Обновление libusb и nut Date: Sun, 21 Sep 2008 08:33:01 +0400 Message-ID: <6062a6e60809202133o36c4b44fxe527fb3f022f45b0@mail.gmail.com> (raw) In-Reply-To: <200809202340.05860.iadzhubey@rics.bwh.harvard.edu> 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
prev parent reply other threads:[~2008-09-21 4:33 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-09-20 22:01 Ivan Adzhubey 2008-09-21 3:20 ` Alexander Bokovoy 2008-09-21 3:40 ` Ivan Adzhubey 2008-09-21 4:33 ` Alexander Bokovoy [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=6062a6e60809202133o36c4b44fxe527fb3f022f45b0@mail.gmail.com \ --to=ab@altlinux.org \ --cc=iadzhubey@rics.bwh.harvard.edu \ --cc=sisyphus@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Sisyphus discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \ sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru public-inbox-index sisyphus Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sisyphus AGPL code for this site: git clone https://public-inbox.org/public-inbox.git