Linux USB ttyACM och, tror jag, systemd?

[Marta]

Har ett litet hembygge med USB-pic som enumereras som communications device, På min förra installation av linux var det inget problem, men på en nyinstallerad med Debian testing/jessie har det hänt saker.

Efter att enumrering är klar börjar det nya systemet att bråka med ttyACM* där enheten finns. Ändrade firmware så inget obra händer, men vore bra om systemet kunde ge f*n i att bråka med ttyACM* varje gång denna device kommer upp. Antar att det är den nya systemd som skapar detta nya problem.

Skulle vara bra att som innan kunna komma åt enheten omedelbart utan väntan på att detta nya sk*t ska ge upp och släppa enheten. Någon som har en lösning på detta?

[sm7tix]

Kan du inte göra en udevregel?

[Nerre]

Nu har jag inte riktigt hundra koll på vad som händer här men det finns väl två approacher:

1. Konfigurera vilka tty:er som systemd (om det nu är den) får pilla på
2. Skriva en udev-regel som döper devicet till nåt annat än tty

Är du säker på att det är systemd som bråkar med porten? Det bör ju synas i syslog eller dmesg vad som händer, så loggutdrag från när enheten ansluts är väl första steget i problemlösningen.

[PHermansson]

"Bråka med" är ingen särskilt bra felbeskrivning, vad är det som händer?

[Nerre]

Jag antar att det som görs är nån form av försök att autodetektera vad som sitter där, kanske skickas några AT-kommandon eller nåt.

[Marta]

Här är syslog:
Feb 7 12:02:03 test kernel: [ 357.292034] usb 4-1: new full-speed USB device number 2 using uhci_hcd
Feb 7 12:02:03 test kernel: [ 357.493933] usb 4-1: New USB device found, idVendor=dead, idProduct=beef
Feb 7 12:02:03 test kernel: [ 357.494127] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 7 12:02:03 test kernel: [ 357.494324] usb 4-1: Product: Quack State USB Test Device
Feb 7 12:02:03 test kernel: [ 357.494474] usb 4-1: Manufacturer: Upper Duckwater Group
Feb 7 12:02:03 test kernel: [ 357.494626] usb 4-1: SerialNumber: 1234567890
Feb 7 12:02:03 test mtp-probe: checking bus 4, device 2: "/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1"
Feb 7 12:02:03 test mtp-probe: bus: 4, device: 2 was not an MTP device
Feb 7 12:02:04 test kernel: [ 357.596233] cdc_acm 4-1:1.0: This device cannot do calls on its own. It is not a modem.
Feb 7 12:02:04 test kernel: [ 357.596565] cdc_acm 4-1:1.0: ttyACM0: USB ACM device
Feb 7 12:02:04 test kernel: [ 357.598357] usbcore: registered new interface driver cdc_acm
Feb 7 12:02:04 test kernel: [ 357.598544] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Där stånkar också igång något som har med scanners att göra, om det nu inte är detta som är MTP-device. Syns på en snabb ps -e. saned colord tror jag det var som startades.

[Nerre]

Som jag misstänkte är det en massa försök till autodetektering, jag har dock ingen koll på vad det är som initierar dessa, men jag skulle gissa på att det är udev som använder det för att försöka lista ut vad den ska sätta för beteckning. En egen udev-regel borde alltså kunna fungera.

Det udev gör är att det tittar på nya devices (som hamnar som "råa" devices under /sys) och försöker identifiera dem för att sen lägga in dem som rätt typ av device under /dev.

De regler som styr autodetekteringen verkar ligga under /lib/udev/rules.d, egna regler lägger man under /etc/udev/rules.d/.

Fast ska jag vara ärlig hittar jag inte exakt var t.ex. anropet till mtp-probe görs... Men egen udev-regel borde lösa det hela.

[hanzibal]

Att sätta Vid pid=dead beef är humor men det kan väl inte vara så dumt att det redan används av ngn förvisso icke-komersiell men ändå vedertagen enhet?

[Marta]

Har provat annat VID/PID, men det är dessvärre samma resultat.

Det enklaste och bästa hade varit om det gick att svartlista ttyACM*. Eller är den råa ttyACM något som väljs när den inte känner igen enheten som något annat? Svartlista VID "dead" borde i så fall hjälpa. Hur? Eller ignoreras den då helt så ttyACM inte kommer upp?


Linux börjar bli för mycket som Window$ och hitta på icke ombedda "hjälpsamheter". Kanske dags att överväga en annan dist än Debian, eller t.o.m. ta sig tid för en LFS. Skall det nu bli en massa bloatware utöver deras licenstrams så börjar måttet bli rågat hur mycket annat bra de än har.

[lillahuset]

Jo det har en tendens att bli jobbigt när OSet blir för "hjälpsamt".

Det har ju varit en viss debatt om systemd är så lyckat, bla på svenska debianlistan.

[Nerre]

Svartlistar du den kommer du väl inte få nån /dev/XXXX alls?

Det är därför du ska skriva en egen udev-regel som gör att den blir tilldelad en lämplig /dev/XXXX-beteckning direkt och inte passerar alla olika autodetekterings-steg.

[Glenn]

Ja, att skriva en egen udevregel är absolut rätt väg att gå. ..Är det en dator, en användare och en enhet så brukar det vara rätt lätt att få till, värre när man ska detektera en familj av enheter, på flera maskiner, för alla användare osv.

Fast jag håller med om att det är lite jobbigt när saker sker automagiskt utan att man ber om det :/

[Marta]

Här är jag osäker på hur det fungerar. Tar svartlistning bort enheten helt eller bara låter den vara ifred för försök till autodetect? Tas den bort helt så är det ju ingen framkomlig väg.

Jag har aldrig haft anledning att rota med udev. Hur skall raden som tilldelar enheten ttyACM* (eller annan motsvarande /dev/*) utan föregående tjafs se ut och i vilken fil skall den in?

[Glenn]

skapa en egen regel i /etc/udev/rules.d/

Du kan ju titta på dom andra filerna där och se hur dom ser ut, det finns nån bra util för att lista ut exkt hur
din enhet presenterar sej, sen får man peta in det i filen (ev med lämpliga regexpar) så den tilldelar enheten ett
annat namn, eller vad man nu vill göra. udevmonitor kanske ?

Denna skrev jag tex för massor av år sen för att vanliga users på jobbet skulle kunna använda en specifik aten USBserieadapter

Kod: Markera allt

[glenn@zooey ~]$ cat /etc/udev/rules.d/52-atenserial.rules
# ATEN serial adapter, accessable for everyone, made by glenn@xxxxxx 2006
#
BUS=="usb",SYSFS{idVendor}=="0557",SYSFS{idProduct}=="2008",MODE="0666",RUN+="/bin/chmod 0666 /dev/ttyUSB0"
[glenn@zooey ~]$

Den är väl i princip så enkel den kan bli, I princip kör den ju bara chmod på devicen så fort den matchar idvendor och idproduct, jag vet att jag skrev en regel som döpte om (eller möjligen länkade ?) nåt devkorts device från ttyUSBx som den hittades som, till vad nu mjukvaran förväntade sej också, men självklart hittar jag inte den filen efterssom jag uppenbarligen inte lade den på min egen maskin.. dessutom vete 17 om jag skulle posta den ändå då jag vet att den innehöll nån uberful regexp


..Iofs in ser jag ju att detta kanske körs EFTER att udev har försökt lista ut vad det är för något ? hmm..

[Marta]

Nu kanske jag är lat, men vad gör de olika delarna av raden? Först MODE=0666, vad är det som tilldelas rw-rättighet där? Sedan tilldelar Du det till enheten med chmod, men hur vet Du att enheten blir just ttyUSB0? En ful ompluggning så blir den lätt ttyUSB1 o.s.v....

Har /etc/udev/rules.d och lib/udev/rules.d samma prioritet som om det var samma directory? Om den läggs med lägst nummer av allt så borde den köras först väl och få prioritet över allt tjafsande? Eller hela paketet med udev-rules kommer efter autodetect?

Finns det någon instruktion hur man arkiverar systemd i /dev/null och installerar de gamla scriptfilerna istället? Antar det inte är helt trivialt att göra detta.