Svenska ElektronikForumet

Det är lite kryptiskt att skriva udev-regler men det finns massor med webbsidor om det (just eftersom det är kryptiskt så har många skrivit sidor om det).

Jag TROR att /etc/udev/rules.d körs före /lib/udev/rules.d, det är i alla fall mest logiskt. Och sen körs de i nummer ordning där.

Om du tittar på reglerna i /lib/udev/rules.d så har nästan alla av dem nån slags "if XXXXX hoppa över resten av filen", så de reglerna gör bara saker om ingen tidigare regel har lyckats identifiera devicen.

Det finns en README-fil under /usr/Share/doc/udev där det hänvisas till http://www.kernel.org/pub/linux/utils/k ... plug/udev/ fast den sidan verkar vara redirectad...

Det finns också en README.Debian där som säger:

The /etc/udev/rules.d/ directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The files are read and processed in alphabetical order, and the directives
of matching rules are applied in order.
If a file with the same name is present in more than one of the
/run/udev/rules.d/, /etc/udev/rules.d/ and /lib/udev/rules.d/ directories
then the latter(s) file will be ignored.
Since the order may be important, files have a specific name which
must be considered when adding custom rules. So far have been defined:

- 60: path_id and the other *_id programs are run. persistent links
are set.

- 70: network interfaces are renamed and generated rules for persistent
links are processed.

- 75: the rules generators are run if needed.

- 80: drivers are loaded.

- 91: the default permissions and owners are set.


- 95: $REMOVE_CMD is run, and then processing of tty devices
is stopped with last_rule.

The persistent-*.rules files are generated by the *-generator.rules files
using the /lib/udev/write_*_rules scripts when new devices are detected.
They set stable names for network interfaces and optical devices aliases.

I den finns också en referens till http://www.reactivated.net/writing_udev_rules.html som verkar innehålla bra info om att skriva regler.

Som ett av de första korta exempel på den sidan hittar man t.ex.

KERNEL=="hdb", NAME="my_spare_disk"

The above rule says: match a device which was named by the kernel as hdb, and instead of calling it hdb, name the device node as my_spare_disk. The device node appears at /dev/my_spare_disk.

Nu kanske det inte är KERNEL som är bäst att matcha på här utan vendor/device ID, men det är alltså enkelt att sätta ett "eget" namn på devicen så den slipper autodetekteringen.

Har provat att lägga till udev-rules, men det är precis som om den inte finns där. Har även kört udevadm control --reload och ingen skillnad. Startat om och ingen skillnad.
Skulle vara bra att få reda ut det här och kanske lyckas lösa problemet på ett snyggt sätt. Den nuvarande lösningen att låta enheten ignorera allt som inte börjar på fyra extra bytes fungerar, men känns som att ge upp och det vill jag inte. Är så irriterande att behöva vänta på att autodetect skall sluta tugga.

Min USB-dokumentation är gammal. Finns det kanske tillkommit någon bättre class än CDC att använda där systemet bara skapar en ny device och sedan låter denna vara ifred? Behöver bulk- eller möjligen interrupt-xfers i båda riktningarna med 64B längd. Helst längre, men standarden sätter väl fortfarande stopp vid 64 när 12Mbit/s används.

Det är skitjobbigt att debugga udev-regler minns jag...

Litet long shot här, men har du testat att köra 'lsof /dev/ttyACM0' medan autodetekteringen (eller vad det nu är) pågår, för att se vad det är som håller devicen?

MTP bör väl för övrigt vara Media Transfer Protocol, d.v.s. ett protokoll för att prata med t.ex. smartphones på ett låst sätt (det var tydligen för flexibelt att kunna montera dem som USB-diskar ).

Du kan också använda för att hitta regler som rör ACM-devices. (Testa också andra foldrar som /usr/lib, /lib etc). Jag hittade en fil /lib/udev/rules.d/60-persistent-serial.rules som har regler för ACM-devices (men kan inte direkt se något där som skulle sabba i ditt fall).

systemd skapar automatiskt "device units" för alla enheter som taggas med systemd i udev; se t.ex. http://www.freedesktop.org/software/sys ... evice.html. Du bör kunna se om detta händer för din device genom att helt enkelt köra 'systemctl' och söka efter ACM.

Om det inte finns några udev-regler som matchar, och inte heller någon device unit i systemd, ja då vete sjutton vad som sker...

Sidospår:

Att montera t.ex. en smartphone som USB storage device är en rätt usel idé. Dels kan bara en enhet montera en "disk" så telefonen blir utan sin lagring medan datorn accessar den, och dels så blir det i det läget upp till datorn att se till att filsystemet inte blir korrupt. Med icke-journalfilsystem så blir filsystemet lätt korrupt om man rycker usb-kabeln (eller drabbas av tappad kontakt på annat sätt) när skrivning pågår.

MTP är inte perfekt, det verkar t.ex. vara enkeltrådat och (iaf med t.ex. Win XP) inte stödja sådana grundläggande saker som att flytta filer (flytt = kopiera till datorn, radera, skriva nytt verkar det som) men det är ändå bättre än "usb storage device". En riktigt usel grej med att det är enkeltrådat är om enheten blir full så kan man inte radera en annan fil utan att avbryta skrivningen som stoppats på grund av att enheten blivit full.

Med MTP så blir enheten alltså en "filserver" över USB, medan med storage device så blir enheten en "diskserver". Det finns en anledning till att det nästan aldrig används diskservers och nästan alltid används filservers när datalagring ska delas på olika sätt. (Enda vettiga sättet att dela en "diskserver" är att varje klient ingår i någon slags klusterliknande grej där klienterna pratar med varandra och en av klienterna har huvudansvar för filsystemhanteringen och de andra bara väljer de sektorer som huvudansvarklienten pekar ut, eller liknande).

hur ser din udev-regel ut? Har du t.ex. bara kopierat Glenns så kommer det inte funka.

Givetvis är det ingen direkt avskrift, jag är inte helt tappad bakom en vagn..

Här är den rule som testats:
SUBSYSTEMS=="usb",ATTRS{idVendor}=="dead",ATTRS{idProduct}=="beef",NAME="specialACM0",GROUP="marta",OWNER="marta"

Efter att rule sparats som /etc/udev/rules.d/04-eget_pahitt.rules root:root -rw-r--r-- kördes udevadm control --reload utan felmeddelanden efteråt.

Förhoppningen var att den skulle komma upp som specialACM0 alltid och under mitt username. Fult, men _något_ borde väl hända? Om inte annat så error av något slag.

Här är en del av udevadm info --attribute --name /dev/ttyACM0 :
looking at parent device '/devices/pci0000:00/0000:00:1d.2/usb4/4-1':
KERNELS=="4-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{devpath}=="1"
ATTRS{idVendor}=="dead"
ATTRS{speed}=="12"
ATTRS{bNumInterfaces}==" 2"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{busnum}=="4"
ATTRS{devnum}=="5"
ATTRS{configuration}==""
ATTRS{bMaxPower}=="2mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="c0"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="0"
ATTRS{bcdDevice}=="0001"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{serial}=="1234567890"
ATTRS{version}==" 2.00"
ATTRS{urbnum}=="14"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="Upper Duckwater Group"
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="beef"
ATTRS{bDeviceClass}=="02"
ATTRS{product}=="Quack State USB Test Device"

Här är udevadm monitor när enheten pluggas in:
KERNEL[6934.356632] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1 (usb)
KERNEL[6934.367138] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0 (usb)
KERNEL[6934.386213] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/tty/ttyACM0 (tty)
KERNEL[6934.386447] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.1 (usb)
UDEV [6934.443054] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1 (usb)
UDEV [6934.446507] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.1 (usb)
UDEV [6934.447286] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0 (usb)
UDEV [6934.449822] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/tty/ttyACM0 (tty)

Har du provat udevtest som beskrivs här?
http://www.reactivated.net/writing_udev ... ml#testing

Tack för rådet att köra test, nu kom det en bit på väg.

Tydligen kan ttyACM? inte namnas om, men kan jag få den att sluta kräka symlinks till denna? Det kanske skulle göra så den fick vara ifred? Den kör ju alla rules även om den redan har hittat en som matchar. Men nog måste det väl gå att få den att hejda sig? Rules efteråt som river bort dessa skitlänkar hjälper väl föga, för innan udevd hinner dit kan väl en annan process i en annan tråd hugga skitlänken och börja på autodetect?

Här är utskriften från udevadm test /sys/class/tty/ttyACM0 :
calling: test
version 208
load module index
read rules file: /etc/udev/rules.d/04-eget_pahitt.rules
----Lång lista borttagen
read rules file: /lib/udev/rules.d/50-udev-default.rules
----Lång lista borttagen
read rules file: /lib/udev/rules.d/60-persistent-serial.rules
----Lång lista borttagen
rules contain 393216 bytes tokens (32768 * 12 bytes), 30344 bytes strings
32921 strings (265197 bytes), 29595 de-duplicated (238180 bytes), 3327 trie nodes used
OWNER 1000 /etc/udev/rules.d/04-eget_pahitt.rules:17
GROUP 1000 /etc/udev/rules.d/04-eget_pahitt.rules:17
NAME="/dev/specialACM0" ignored, kernel device nodes can not be renamed; please fix it in /etc/udev/rules.d/04-eget_pahitt.rules:17
GROUP 20 /lib/udev/rules.d/50-udev-default.rules:22
IMPORT builtin 'path_id' /lib/udev/rules.d/60-persistent-serial.rules:9
LINK 'serial/by-path/pci-0000:00:1d.2-usb-0:1:1.0' /lib/udev/rules.d/60-persistent-serial.rules:10
IMPORT builtin 'usb_id' /lib/udev/rules.d/60-persistent-serial.rules:13
/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0: if_class 2 protocol 0
LINK 'serial/by-id/usb-Upper_Duckwater_Group_Quack_State_USB_Test_Device_1234567890-if00' /lib/udev/rules.d/60-persistent-serial.rules:17
IMPORT builtin skip 'usb_id' /lib/udev/rules.d/75-tty-description.rules:6
IMPORT builtin 'hwdb' /lib/udev/rules.d/75-tty-description.rules:6
handling device node '/dev/ttyACM0', devnum=c166:0, mode=0660, uid=1000, gid=20
preserve permissions /dev/ttyACM0, 020660, uid=1000, gid=20
preserve already existing symlink '/dev/char/166:0' to '../ttyACM0'
found 'c166:0' claiming '/run/udev/links/\x2fserial\x2fby-id\x2fusb-Upper_Duckwater_Group_Quack_State_USB_Test_Device_1234567890-if00'
creating link '/dev/serial/by-id/usb-Upper_Duckwater_Group_Quack_State_USB_Test_Device_1234567890-if00' to '/dev/ttyACM0'
preserve already existing symlink '/dev/serial/by-id/usb-Upper_Duckwater_Group_Quack_State_USB_Test_Device_1234567890-if00' to '../../ttyACM0'
found 'c166:0' claiming '/run/udev/links/\x2fserial\x2fby-path\x2fpci-0000:00:1d.2-usb-0:1:1.0'
creating link '/dev/serial/by-path/pci-0000:00:1d.2-usb-0:1:1.0' to '/dev/ttyACM0'
preserve already existing symlink '/dev/serial/by-path/pci-0000:00:1d.2-usb-0:1:1.0' to '../../ttyACM0'
unload module index
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

ACTION=add
DEVLINKS=/dev/serial/by-id/usb-Upper_Duckwater_Group_Quack_State_USB_Test_Device_1234567890-if00 /dev/serial/by-path/pci-0000:00:1d.2-usb-0:1:1.0
DEVNAME=/dev/ttyACM0
DEVPATH=/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/tty/ttyACM0
ID_BUS=usb
ID_MM_CANDIDATE=1
ID_MODEL=Quack_State_USB_Test_Device
ID_MODEL_ENC=Quack\x20State\x20USB\x20Test\x20Device
ID_MODEL_ID=beef
ID_PATH=pci-0000:00:1d.2-usb-0:1:1.0
ID_PATH_TAG=pci-0000_00_1d_2-usb-0_1_1_0
ID_REVISION=0001
ID_SERIAL=Upper_Duckwater_Group_Quack_State_USB_Test_Device_1234567890
ID_SERIAL_SHORT=1234567890
ID_TYPE=generic
ID_USB_CLASS_FROM_DATABASE=Communications
ID_USB_DRIVER=cdc_acm
ID_USB_INTERFACES=:020200:0a0000:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=Upper_Duckwater_Group
ID_VENDOR_ENC=Upper\x20Duckwater\x20Group
ID_VENDOR_ID=dead
MAJOR=166
MINOR=0
SUBSYSTEM=tty
TAGS=:systemd:
USEC_INITIALIZED=7125069

Marta skrev:Givetvis är det ingen direkt avskrift, jag är inte helt tappad bakom en vagn..

Det trodde jag inte heller, men det blir så mycket lättare att hjälpa när man ser det du ser.

Tyvärr är mina udev-kunskaper slut

Ber om ursäkt för min ohövliga kommentar, mitt dåliga humör skall stanna på min sida av tangentbordet.

Nu har jag provat att lägga till mera rules på nivå 51 och nu stannar group kvar och även mode=000, men den biter ju inte på något med rootprivilegier. Dessvärre ingen effekt, autodetect stånkar igång precis som innan

Tillägg: Nu har det blivit visst resultat. killall colord förhindrar att libsane-colord stånkar igång och det visade sig vara den värsta. Nu är ttyACM? ledig att öppna inom tre sekunder från att enheten har enumererat och det är någorlunda drägligt. Den får fortfarande ta emot en massa crap, men efter den tidigare justeringen av firmware så händer inget. Såhär får det vara tills vidare i varje fall.

Det är aldrig kul att bli dumförklarad

Prova detta på din udevregel: ENV{ID_MM_DEVICE_IGNORE}="1"

Det tycks funka för vissa.

Som jag skrev tidigare, det är skitsvårt att felsöka udev-regler:)

Syntaxen är ju inget under av tydlighet direkt.

Jag hamnade också i ett sånt läge att jag inte lyckades få den att skippa att kalla kortläsare för ttySxx utan fick nöja mig med en symlänk som heter /dev/cardreader så jag inte behöver bry mig om att den får olika namn.

Gjorde inte mycket skillnad att sätta ENV---, däremot gjorde apt-get remove modemmanager* en hel del. Visste inte ens att detta elände var installerat. Så blir det av att göra misstag (läs vara för slö) vid installationen. Nu verkar den vara redo inom en sekund efter att ha kommit upp under /dev

Stort Tack till alla som hjälpt till att lösa detta problem.

Skönt att det verkar ha löst sig.

Lite annat smått och gott:

Detta ska tydligen fungera för att hindra skapandet av en kernel-döpt device:
Detta enligt https://forum.manjaro.org/index.php?topic=15275.0 (sista inlägget).

För att hindra efterföljande regler att köras så ska det gå att använda GOTO för att hoppa till en LABEL senare i reglerna (även om GOTOs till andra filer inte är snyggt, så går det tydligen). Lämplig LABEL kanske är tty_end i /lib/udev/rules.d/75-tty-description.rules?

Fast detta är ju riktiga fulfixar och ingenting som jag skulle vilja använda i produktion...