udev rules shipped don't work on my gentoo (2.6.28, udev-124)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. build and install from source on gentoo box
2. insert modem

What is the expected output? What do you see instead?
  Madwimax daemon should start automatically. It doesn't.

What version of the product are you using? On what operating system?
  0.1.1, more or less vanilla gentoo (well, to the extend there exists
vanilla gentoo), kernel 2.6.28 [tried others, i think], udev-124

Please provide any additional information below.
  http://pastie.org/534819 -- this is the patch i ship with my gentoo
ebuild for madwimax. It fixes the problem completely for me.

Original issue reported on code.google.com by dmitry.kim on 5 Jul 2009 at 6:28

[GoogleCodeExporter]

Надо узнать, что происходит с udev при 
втыкании модема. В том должны помочь
udevmonitor и udevtest. 

Original comment by gord...@gmail.com on 6 Jul 2009 at 1:42

[GoogleCodeExporter]

у меня нету udevmonitor и udevtest, но есть udevadm monitor и 
udevadm test. про test
если интересно, то пишите инструкций, я в 
этом ничего не понимаю. лог monitor-а
приаттачу сюда.

Original comment by dmitry.kim on 6 Jul 2009 at 5:43

Attachments:

• udevadm-monitor-log.txt

[GoogleCodeExporter]

кстати об именах интерфейсов: у меня оно 
иногда сочиняет вместо одного wimax0 два
устройства (wimax0 и wimax1). кроме того, оно 
иногда стартует по две или больше копии
madwimax. на работоспособности это никак не 
сказывается (всё отлично работаёт в любом
случае).
(да, всё вышеописанное происходит с 
патченым юдевным рулфайлом [ATTR --> ATTRS], без
него не стартует вообще)

Original comment by dmitry.kim on 6 Jul 2009 at 5:53

[GoogleCodeExporter]

Интсрукция:
1. sudo udevadm monitor --udev
2. втыкаем модем
3. запоминаем появившийся путь (/device/...) в 
первой строчке. будем считать, что он
содержится в переменной DEVPATH
4. sudo udevadm test "/sys/$DEVPATH"
5. результат сюда.

P.S. я тоже раньше этого не знал, маны рулят :)

Original comment by gord...@gmail.com on 6 Jul 2009 at 6:26

[GoogleCodeExporter]

Да, еще хорошо бы сюда же:
sudo udevadm info -a -p "$DEVPATH"

Original comment by gord...@gmail.com on 6 Jul 2009 at 6:31

[GoogleCodeExporter]

вот.

Original comment by dmitry.kim on 6 Jul 2009 at 6:35

Attachments:

• udevadm-test-log.txt
• udevadm-info-log.txt

[GoogleCodeExporter]

Так, проблем не вижу никаких пока. Не может 
быть, чтобы не запускался. Попробуйте
заменить опцию -q на -vv в udev правилах madwimax и 
посмотрите, что появится в
syslog-е. Или перенаправьте лог в файл опцией -l 
FILE.

Original comment by gord...@gmail.com on 6 Jul 2009 at 7:02

[GoogleCodeExporter]

Could not find/open device
Child exited with status 256

если после этого udevadm test-ом посмотреть, как 
оно собирается запускать madwimax, и
запустить его ручками с точно такими же 
параметрами, то всё работает.

Original comment by dmitry.kim on 6 Jul 2009 at 7:14

[GoogleCodeExporter]

а, ну собственно. если заменить вызов madwimax в 
руле на вызов нижеследующего
скрипта, то всё работает:

#! /bin/bash

sleep 1
exec /usr/sbin/madwimax $*

Original comment by dmitry.kim on 6 Jul 2009 at 7:22

[GoogleCodeExporter]

Вы точно добавили -vv ?
Видимо что-то с правами доступа тогда. 
Проверьте с какими правами работает udev,
какие права выставляются на файлы в /dev/bus/usb/ 
и /proc/bus/usb. Может быть,
устройство еще почему-то не 
инициализировалось, но такого происходить 
по идее не
должно. На всякий случай можно попробовать 
заменить команду на что-то типа (sleep 5;
madwimax ...) &.

Original comment by gord...@gmail.com on 6 Jul 2009 at 7:24

[GoogleCodeExporter]

> Вы точно добавили -vv ?
> Видимо что-то с правами доступа тогда.
[rest skipped]

да, я точно добавлял. и нет, это не что-то с 
правами доступа, потому что всё работает
с ATTRS, а также всё работает со sleep-ом.

Original comment by dmitry.kim on 6 Jul 2009 at 7:25

[GoogleCodeExporter]

Мда...
Ну, значит сделаем так: в случае отсутствия 
устройства madwimax будет возвращать
специальный exit code, а запускать его из udev 
будет скрипт, который будет несколько
раз подряд с промежутком в пару секунд 
пытаться запустить madwimax, пока тот
устройство не найдет. Такое решение, думаю, 
всех устроит.

Original comment by gord...@gmail.com on 6 Jul 2009 at 7:32

[GoogleCodeExporter]

for ((i = 0 ; i < 3; i ++)) do /usr/sbin/madwimax $* && exit 0; sleep 2; done; 
exit -1
? :)

Original comment by dmitry.kim on 6 Jul 2009 at 7:37

[GoogleCodeExporter]

А, я понял :)
ATTRS - это поиск атрибутов у предка. Значит, к 
моменту появления потомков у
основного устройства (интерфейсы, 
эндпоинты) девайс уже успевает
проинициализироваться. У меня на 
компьюетере промежуток между этими 
событиями
составляет 4 мс (посмотреть можно udevadm monitor). 
Кстати, у вас иногда madwimax
запускается несколько раз (и появлется 
несколько интерфейсов wimax*) т.к. потомков у
основного устройства много, так что 
правило получается слишком общим, под него
подходит каждый потомок, и для каждого 
запускается по копии madwimax. Потом они все
вместе борются за одно устройство :)

Original comment by gord...@gmail.com on 6 Jul 2009 at 7:40

[GoogleCodeExporter]

Ну да, вроде того, только с проверкой кода 
возврата :)
И еще скрипт должен сразу уходить в 
бэкграунд, иначе udev "подвиснет".

Original comment by gord...@gmail.com on 6 Jul 2009 at 7:46

[GoogleCodeExporter]

не правильнее ли будет прямо в madwimax 
вставить цикл со sleep-ом вокруг попыток
инициализации?
(а что, в udev-ном руле нельзя поймать 
собственно момент появления именно нужной
ноды? я про юдев ничего не знаю)

Original comment by dmitry.kim on 6 Jul 2009 at 7:51

[GoogleCodeExporter]

Неа, это неправильно. Эта проблема 
специфична для запуска madwimax с помощью udev.
Если пользователь запускает из командной 
строки, то делать несколько попыток
совершенно точно не надо.
Нужная нода - корневой девайс. Именно его 
ищет madwimax при запуске. Но, видимо,
корень не появляется в usbfs, пока не 
просканируются все потомки. Это вполне 
логично.
Видимо, в udev информация приходит быстрее. 
Так что нужно сначала дождаться появления
всех потомков в udev. Я пока не знаю _хорошего_ 
способа сделать это посредством udev.
Так что лучше пусть скрипт запускается.

Original comment by gord...@gmail.com on 6 Jul 2009 at 8:08

[GoogleCodeExporter]

Хотя можно попробовать 
поэкспериентировать с WAIT_FOR в принципе. Но 
это может
оказаться слишком сложно и не очень 
портабельно. :(
И к тому же у меня не воспроизводится, так 
что если только вы попробуете:
1. удостовериться, что в /proc/bus/usb 
смонтирована usbfs
2. в правилах вставить 
WAIT_FOR="/proc/bus/usb/00$attr{busnum}/00$attr{devnum}",
перед RUN+=...
Должно получиться так примерно:
ATTR{idVendor}=="04e8", ATTR{idProduct}=="6761",
WAIT_FOR="/proc/bus/usb/00$attr{busnum}/00$attr{devnum}", 
RUN+="@SBINDIR@/madwimax
-qd --exact-device=$attr{busnum}/$attr{devnum}"
...

Это правило пока не идеально, но для теста 
сойдет. Если у вас номер устройства уже
двузначный выдается, то уберите один 0 
перед $attr{devnum}

Original comment by gord...@gmail.com on 6 Jul 2009 at 8:25

[GoogleCodeExporter]

Пардон, оказывается оно попадает в 
переменную окружения DEVICE, так что можно 
вместо
/proc/bus/usb/... поставить $env{DEVICE}

Original comment by gord...@gmail.com on 6 Jul 2009 at 8:41

[GoogleCodeExporter]

ATTR{idVendor}=="04e8", ATTR{idProduct}=="6761", WAIT_FOR="$env{DEVICE}",
RUN+="/usr/sbin/madwimax -qd --exact-device=$attr{busnum}/$attr{devnum}"
ATTR{idVendor}=="04e9", ATTR{idProduct}=="6761", WAIT_FOR="$env{DEVICE}",
RUN+="/usr/sbin/madwimax -qd --exact-device=$attr{busnum}/$attr{devnum}"
ATTR{idVendor}=="04e8", ATTR{idProduct}=="6731", WAIT_FOR="$env{DEVICE}",
RUN+="/usr/sbin/madwimax -qd --exact-device=$attr{busnum}/$attr{devnum}"
ATTR{idVendor}=="04e8", ATTR{idProduct}=="6780", WAIT_FOR="$env{DEVICE}",
RUN+="/usr/sbin/madwimax -qd --exact-device=$attr{busnum}/$attr{devnum}"

вот так сейчас. вроде бы работает нормально.

Original comment by dmitry.kim on 6 Jul 2009 at 9:42

[GoogleCodeExporter]

Отлично! Поверьте, пожалуйста, еще один 
вариант с WAIT_FOR="/proc/bus/usb/004". Если
mdawimax не запустится, то можно это спокойно 
коммитить - это значит, что
действительно проблема была в том, что 
нужный файл не успевал появиться. Если
запустится, то непонятно, вдруг это просто 
сказалась дополнительная задержка при
проверке существования файла.
И хорошо бы еще потестировать, как можно 
больше раз перетыкая девайс и проверяя,
запустилось или нет.

Original comment by gord...@gmail.com on 6 Jul 2009 at 10:22

[GoogleCodeExporter]

всё верно, с WAIT_FOR="/proc/bus/usb/004" не запускается, 
tried multiple times.

Original comment by dmitry.kim on 6 Jul 2009 at 10:27

[GoogleCodeExporter]

Превосходно! Закрываю. Скоро WAIT_FOR появится 
в trunk. Если вдруг будут еще
аналогичные проблемы, откроем снова.

Original comment by gord...@gmail.com on 6 Jul 2009 at 10:34

• Changed state: Verified

[GoogleCodeExporter]

Открываю. Текущее решение не очень хорошее, 
к сожалению. Если отмонтировать
/proc/bus/usb, то udev подвисает на WAIT_FOR. Но, похоже 
можно привязаться к другому
событию udev - появлению /class/usb/usb_device/... Как 
перепишу правила, выложу для
тестирования.

Original comment by gord...@gmail.com on 7 Jul 2009 at 7:26

• Changed state: Started

[GoogleCodeExporter]

Протестиоуйте, пожалуйста, приложенный 
скрипт. Желательно как можно больше раз,
каждый раз должен появиться ровно 1 процесс 
madwimax и ровно один интерфейс wimax0.

Original comment by gord...@gmail.com on 7 Jul 2009 at 10:54

Attachments:

• z60_madwimax.rules.in

[GoogleCodeExporter]

seems to work as advertised.
одним из симптомов неправильности с моим 
патчем (ATTRS) было:
Jun 23 15:48:47 jsn kernel: usb 4-4: usbfs: process 18519 (madwimax) did not 
claim
interface 0 before use
(а также множественные копии madwimax / 
множественные интерфейсы).

сейчас ничего такого не происходит, всё 
вроде бы нормально. один интерфейс, одна
копия, чистый dmesg, picks up every time.

Original comment by dmitry.kim on 7 Jul 2009 at 11:14

[GoogleCodeExporter]

Спасибо, закрываю.

Original comment by gord...@gmail.com on 8 Jul 2009 at 11:14

• Changed state: Verified

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Помогите разобраться, система Debian Etch, 
драйвер собирал из сорцов последний 
0.1.1, libusb тоже собрал последний 1.0.2. Правило 
z60madwimax.rules не 
отрабатывает, вставляю модем, ничего не 
происходит. В /var/log/messages видно что 
система думает, что это некий сидиром. 
Пробовал перименовать правило в 
010_madwimax.rules, что-бы оно отрабатывалось 
первым, ничего не меняется, все то-же. 
Взял последнюю версию правила из trunk, все 
то-же. Прикладываю лог udevmonitor и 
результат udevtest. 

Original comment by amne...@gmail.com on 23 Jul 2009 at 11:52

Attachments:

• udevmonitor.txt
• udevtest.txt

[GoogleCodeExporter]

@amnesin: попробуйте собрать svn trunk вместо 
релиза, там вроде как внесены патчи,
обсуждённые здесь.

Original comment by dmitry.kim on 23 Jul 2009 at 12:42

[GoogleCodeExporter]

Подтверждаю наличие проблемы с debian etch и trunk 
версии с ревизией 171. Can not
find/open device из-за того, что udev вызывает madwimax с 
пустым attr${device/busnum}
(лог обёртки на madwimax):
Running madwimax with -vodf --exact-device=/9 params
Fri Sep 11 12:55:18 MSD 2009
Running madwimax with -vodf --exact-device=/10 params
Fri Sep 11 13:04:00 MSD 2009
Running madwimax with -vodf --exact-device=/11 params
Fri Sep 11 13:15:29 MSD 2009
Running madwimax with -vvodf --exact-device=/12 params

udev в etchе
%dpkg -l | grep udev
ii  udev                              0.105-4etch1

В debian lenny такой проблемы нет, udev там:
ii  udev                              0.125-7+lenny1

Т.о. это скорее всего проблема udev и/или ядра, 
которое в sysfs не экспортирует
нужную ветку.

Правильное решение заключается в 
обновлении udev и написании его 
разработчикам
толкового баг-репорта (хз куда это надо 
писать =)).
Работающее - в удалении параметра --exact-dev в 
правилах udev для madwimax. Правда
при этом у меня madwimax не выходит при 
выдёргивании свистка (засыпает на starting
if-down script..) - при повторном втыкании 
образовывается ещё один интерфейс.

Original comment by onehalf3...@gmail.com on 11 Sep 2009 at 9:39

[GoogleCodeExporter]

Issue 32 has been merged into this issue.

Original comment by gord...@gmail.com on 15 Sep 2009 at 8:51

[GoogleCodeExporter]

У меня под генту почему-то не определены 
$attr{device/busnum} и $attr{device/
devnum}. Зато есть $attr{devnum} и $attr{busnum}. После 
удаления "device/" всё стало 
работать. Только почему-то madwimax пытается 
запуститься трижды, и только в первый 
раз у него прописаны $attr{devnum} и $attr{busnum}. 
Кроме того, он ругается " * 
ERROR:  net.wimax0 is already starting." Версии udev-146-r1, 
madwimax-0.1.1-r1

Original comment by akrsch on 20 Jan 2010 at 10:10

[GoogleCodeExporter]

Здравствуйте!
Просьба помочь с установкой Yota USB на Puppy Linux 5.
Девайс VIA EPIA Samuel C3 533 mH MicroATX.
Автоматически не стартует, при ручном 
запуске madwimax ситуация стандартная Could not 
find/open device.
Пробовал менять параметры согласно 
вышеуказанным рекомендациям - не помогает.
В режиме udevadm monitor --udev ни чего не 
перехватывается . Только в режимах udevadm monitor 
--env и без параметров(файлы с выводом 
прилагаю).
Помогите разобраться - изгуглиля - нет 
ничего по теме, кроме этой страницы. 

Original comment by pao%ntel...@gtempaccount.com on 28 Jul 2010 at 7:48

Attachments:

• udevadm.log
• udevadm_env.log

[GoogleCodeExporter]

Здравствуйте!
Просьба помочь с установкой Yota USB на Puppy Linux 5.
Девайс VIA EPIA Samuel C3 533 mH MicroATX.
Автоматически не стартует, при ручном 
запуске madwimax ситуация стандартная Could not 
find/open device.
Пробовал менять параметры согласно 
вышеуказанным рекомендациям - не помогает.
В режиме udevadm monitor --udev ни чего не 
перехватывается . Только в режимах udevadm monitor 
--env и без параметров(файлы с выводом 
прилагаю).
Помогите разобраться - изгуглиля - нет 
ничего по теме, кроме этой страницы. 

Original comment by pao%ntel...@gtempaccount.com on 28 Jul 2010 at 7:49

Attachments:

• udevadm.log
• udevadm_env.log