soros port bajok

 ( tovis | 2017. október 19., csütörtök - 23:42 )

Van egy jó kis Brain Box -os 4 soros portot tartalmazó kártyám. Évek óta használom, jól működött, eddig.
Mivel így a soros portok száma megnő, a következő stringet szoktam a bootba beilleszteni: "8250.nr_uarts=8"
Így a lehetséges device -ok ttyS0 ... ttyS7 -ig.
A setserial csomaggal építem be a rendszerbe, manuális beállítással:
/etc/serial.conf
/dev/ttyS4 uart 16750 port 0xd100 irq 20 baud_base 115200 spd_normal skip_test ^fourport
...
/dev/ttyS7 uart 16750 port 0xd118 irq 20 baud_base 115200 spd_normal skip_test ^fourport

A címeket és az irq -t az lspci -v sorból olvasom ki, tudva hogy a portok címei 8 címet foglalnak el.

Stretch a legfurcsább, sima user -ként a setserial -a /dev/ttyS7 -re azt dobja invalid argument. Csak root -ként tudok infót kapni. A user tagja a dial grpűoup -nak. Ha mondjuk elindítom a minicom -ot -D /dev/ttyS7 -b 9600 opcióval zárom a 2-3 pint a csatlakozón (Rx-Tx) nem veszi a begépelt karaktereket.
Elővettem a még nem törölt Jessie -met és azzal is hasonlóakat csinál, de nem panaszkodik, hogy invalid argument.
Win10 rendszer is van ehhez a géphez, azon csont nélkül működik.
Csak a kernel -re tudok gyanakodni. Lehet valami opciót nem forgattak bele? Valami ötlet? Egyelőre kifogytam :(

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

/proc/tty/driver/serial-ban mi van?

/proc/tty/driver/serial
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
1: uart:unknown
2: uart:unknown
3: uart:unknown
4: uart:TI16750 port:0000D100 irq:20 tx:0 rx:0
5: uart:TI16750 port:0000D108 irq:20 tx:0 rx:0
6: uart:TI16750 port:0000D110 irq:20 tx:0 rx:0
7: uart:TI16750 port:0000D118 irq:20 tx:0 rx:0

Úgy tűnik a driver akár jó is lehetne, a "^fourport" opciót nem tudom hogy láthatnánk.

* Én egy indián vagyok. Minden indián hazudik.

Csak a ttyS7-re dob invalid argumentet? A másik három port (4-6) működik?

A kártyához kapcsolódó mind a négy port azonosan viselkedik.
ttyS4 ... ttyS7 -ig Invalid argument.

* Én egy indián vagyok. Minden indián hazudik.

Csak vaktában lövök: történik változás, ha a fourportot leveszed a konfigban? (A 8250_fourport be van töltve amúgy?)

ez is a Soros terv resze...

O"o", biztos hogy a brainboxos bovoitokartyaban TI16750-es UART host controller van?

Jó kérdés.
brainboxes
a 16750 -es beállítást már a Debian 5(?) óta használom, sőt biztos vagyok benn, hogy a Jessie -vel eredetileg működött.
Most sem a frissített Jessie sem a Stretch :(

* Én egy indián vagyok. Minden indián hazudik.

Most nézem újra a spcekót:
"UART Compatibility 16750/16550/16450 backwards compatible as well as an enhanced 950 mode"
Megpróbálom valamelyik másikat, bár most a kernel is 16750 -nek érzékeli.

* Én egy indián vagyok. Minden indián hazudik.

Én a következőt tapasztaltam Ubuntu 16.10-tól kezdve amikor valamit rádugok a soros portra és gtkterm-el elkezdem birizgálni akkor van egy pár mp. time-out valamiért ami alatt a kernel csinál valamit az eszközzel, aztán (rá jön :) ) hogy nincs miért birizgálnia és akkor már tudom kezelni... lehet, hogy ennek nincs semmi köze a te esetedhez, de én hasonlónak tartom a problémát, mert rootként nekem is megy az a setserial valamint egy kis ideig nem tudok rajta keresztül kommunikálni függetlenül, hogy root vagyok vagy sem...
Neked bármikor a bekapcsolás után ugyanaz a jelenséged ?

--
www.autosys.hu

Elvileg az usb-modeswitch tud ilyet csinálni, ha minden igaz, ttyACM-eszközöknél.
Gyakorlatilag megpróbálja átváltani a potenciális USB-s modemet adat üzemmódba.

Én is tapasztaltam ezt a jelenséget jó ideje, aztán nem túl rég kommunikáltam saját ACM-eszközzel (mikrokontroller natív USB interfészével foglalkoztam), és akkor tűnt fel, hogy ezzel próbálkozik a rendszer az eszköz észlelése után közvetlenül, ekkor találtam rá a fentire.

Az usb-modeswitch meghívása lehet a systemd ModemManager.service része?

* Én egy indián vagyok. Minden indián hazudik.

nekem okozott problémákat a ModmeManager ttyACM-es eszköznél, amikor irni akrtam az eszközbe, egy sima disable megoldotta a dolgot nálam.

Én most a modem managert tiltottam le, de nem változott semmi :(
Egyébként a kernel logban nincs nyoma semmilyen beavatkozásnak.
A kernel jelzi, hogy "felpiszkálja" ttySx devic -ket, több szó kimondottan a ttyS -ről nem esik.

* Én egy indián vagyok. Minden indián hazudik.

Teljesen következetes. Nincs különbség két bekapcsolás között.
A Jessie most épp nem manuális, hanem a kernel -re hagytam a beállítást, és a $ setserial -a /dev/ttyS7 "Invalid argumentum2 üzenetet dob. A minicomot, userként ugyan ez, el sem indul.
(Az sem világos, hogy root -ként miért nem kapok ilyen üzenetet, akkor csak egyszerűen nem működik)

* Én egy indián vagyok. Minden indián hazudik.

Soros György kedveli ezt.

Csak próbaképpen, elindítottam "single" -ben. Persze ez sem teljesen szabad a systemd garázdálkodásától de kicsit tisztább képet adhat.
1. A /dev/ttyS0 (alaplap standard) 0x03f8 be van konfigurálva. A setserial a szokásos beállításokat mutatja.
2. A /dev/ttyS4 ... /dev/ttyS7 -ig semmi - UART: unknown
Az lspci nem változik, bázis cím 0xd100 és irq 20
Ha ráeresztem az /etc/init.d/setserial start scriptet kiírja:
[ ok ] Starting setserial (vis systemctl: setserial.service.
Nem történik semmi - persze, hiszen előtte töröltem a /var/lib/setserial/ könyvtárban mindent.
# dpkg-reconfigure setserial - manuában - "OK"
Hát ez kicsit fura: törölte az /etc/serial.conf file -t?
Létrehozott a /var/lib/setserial könyvtárban két állományt:
autoserial.conf
###AUTOSAVE-ONCE###
###AUTOSAVE###
etc.serial.conf.
###AUTOSAVE-ONCE###
###AUTOSAVE###
itt az /etc/serial.conf file
/dev/ttyS0
...
/dev/ttyS7
A portok továbbra sem álltak fel, setserial -a /dev/ttyS4 ... ttyS7
Megint megpróbálom az /etc/init.d/setserial start -ot
A portok még mindig nincsenek beállítva.
# systemctl | grep ttyS*
sys-devices-platform-serial8250-tty-ttyS1.device
--- loaded active plugged --- /sys/devices/platform/serial8250/tty/ttyS1
...
sys-devices-platform-serial8250-tty-ttyS0.device
--- loaded active plugged --- /sys/devices/pnp0/00:03/tty/ttyS0

Hááát ettől sem lettem kosabb :(

* Én egy indián vagyok. Minden indián hazudik.

Legalább azt el kellen e dönteni, hogy most a kernellel van a hiba, vagy az inicializáló scriptek systemd, udev stb.
Hogy tudnám ezt eldönteni?

* Én egy indián vagyok. Minden indián hazudik.

stty -F /dev/ttyS7 elszáll, ha megpróbálod?

$ stty -F /dev/ttyS7
stty: /dev/ttyS7: Invalid argument
# stty -F /dev/ttyS7
stty: /dev/ttyS7: Input/Output error

(Furcsa. Mint feljebb jeleztem "single" -módban piszkáltam a rendszert. Töröltem a /var/lib/setserial könyvtárban lévő összes bejegyzést, és újra futtattam a dpkg-reconfigure setserial -t, mire az megint létrehozta a fájlokat a a /var/lib/setserial könvytárban, viszont törölte az /etc/serial.conf fájlt - mikor úrja indítottam, már nem piszkálta fel a portokat, akkor visszamásoltam az /etc/serial.conf -ot és akkor újraindítás után már beállította a portokat - ugyan úgy nem működnek)

* Én egy indián vagyok. Minden indián hazudik.

Meg kéne próbálni egy live Debian Jessie alól piszkálni a dolgot. Ha megy, akkor valami beállítási mizéria lesz. Ha nem, akkor ki kéne próbálni egy live Debian Wheezy alól is. Ha megy, akkor a Jessie-ben lesz elszabva valami. Jobb ötletem nincs. :/

Találtam még valamit. A gyártó honlapján (link fent) szó nem esik a Linux támogatásról, aztán ahogy tovább kutakodtam mégis van Latest driver for Linux
Jessie van telepített (legfeljebb előtte menteni kell).
Sajnos a megadott "driver" egy script, ami módosítgat a konfigurációs beállításokon - jobban örültem volna egy leírásnak is.

* Én egy indián vagyok. Minden indián hazudik.

Én szűz live Jessie-vel próbálnám meg, ahol minden default még.

Meg eszembe jutott, hogy ha megpróbálod a portot 16750 helyett 16550-ként használni, akkor történik valami érdemleges változás?

uart 16550 próbáltam - semmi változás :(
Először megpróbálom az egyszerűt (nálam általában nm jött be az ilyesmi) aztán jöhet a szkanderezés a live -al, aztán ha kell kernelt forgatok.
(A Debian live cuccokkal valahogy nekem mindig gondom volt - mondjuk leginkább rescue -nak akartam volna használni, de mindig kiderült hogy csak ez mag az hiányzik hozzá belőle)

* Én egy indián vagyok. Minden indián hazudik.

Hát jöhetnek az újabb ötletek - pl. a live.
A nagy elvárás az valójában annyi, hogy bevágták a setserial parancsokat a rc.local -ba:
/bin/setserial /dev/ttyS4 uart 16550A port 0xd100 auto_irq baud_base 115200 spd_normal skip_test
/bin/setserial /dev/ttyS5 uart 16550A port 0xd108 auto_irq baud_base 115200 spd_normal skip_test
/bin/setserial /dev/ttyS6 uart 16550A port 0xd110 auto_irq baud_base 115200 spd_normal skip_test
/bin/setserial /dev/ttyS7 uart 16550A port 0xd118 auto_irq baud_base 115200 spd_normal skip_test

Érdekes: uart 16550A, auto_irq (azaz a kernelre/driverre bízzák) és nem kell a ^fourport - ot sem tiltani.
De ugyanúgy nem működik és még mindig nem tudom egyértelműen azonosítani a hiba forrását. :(
Mit is kellene megnézni a live verziókban? Mi a telepítetthez képest a különbség?
Úgy nézem, egy júliusi Debian live akadt a kezembe kernel 4.9.0-3-amd4 (ez a stretch old kernel verziója).

* Én egy indián vagyok. Minden indián hazudik.

> Mit is kellene megnézni a live verziókban? Mi a telepítetthez képest a különbség?

Az esetleges rossz konfig. Live Debian Wheezyvel kéne még kipróbálni. Ha azzal se jó, akkor az azt jelenti, hogy már a default konfig sem jó. Vagy, valami miatt nincs betöltve a modul. lsmod | grep 8250_fourport szerint be van töltve?

A ^fourport pont azt jelenti, hogy nem az ATS fourport konfiguráció kell.
Megnéztem a Jessie 8.7 - 2017.05. arra még esküdni mertem volna hogy jó, de nem - vagy valamit benéztem.
Aztán ha ez sem, akkor jöjjön a Wheezy.
Elvileg a gyártó azt mondja a scriptjére, hogy 8.3 Debiannal ellenőrizték.

* Én egy indián vagyok. Minden indián hazudik.

A Debian Live Stretch kernel vesion 4.9.0-3-amd64 pontosan ugyanolyan rossz (invalid argument és nem kommunikál)

setserial /dev/ttyS3 uart 16550A port 0xd118 auto_irq baud_base 115200 spd_normal skip_test

(Azért bosszantó, hogy "lokalizál" magyarra de a billentyűzet angol)

* Én egy indián vagyok. Minden indián hazudik.

Megkerdezhetem, hogy mire hasznalsz 2017-ben 2x4 db. RS232-es soros portot?

Mikrokontrollerekkel valo kapcsolatnal meg megertem, meg ha messze viszel jelet 485/422 atalakitas utan. De egyebkent mi a konkret funkcio, es miert kell ennyi?

(egyebkent sub, en meg nem uzemeltem be a pci-soros kartyamat, de azon nincs is ennyi)

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Annyira azért nem csak 1x4 port. Egyrészt ez adottság (anno darabját 300,- Ft ért vettem egy ócskásnál persze rögtön 5 db).
Mikrokontrollerek és velük felépített különféle kütyüket szoktam piszkálni, programozni.
Momentán csak két (régi de profi) GSM modult kell piszkálnom, viszont az alaplapon csak egy soros port van.
Lehet egy egyszerűbb két portos kártyával nem lesz ilyen gondod. Majd azért szólj mire jutsz.

* Én egy indián vagyok. Minden indián hazudik.

A 8250 alapú driver a kernelbe be van forgatva. (Gondolom azért is, mert a kernel debug konzol is ezzel mehget)
A kernel konfigurációja szerintem évekre visszamenőleg azonos:
#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_FINTEK=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_FSL is not set
CONFIG_SERIAL_8250_DW=y
# CONFIG_SERIAL_8250_RT288X is not set
# CONFIG_SERIAL_8250_LPSS is not set
CONFIG_SERIAL_8250_MID=y
CONFIG_SERIAL_8250_MOXA=m

A 16550, a 16750 mind ide tartozik és alapból be van forgatva.
Hacsak nem rondítottak bele akkor ennek működni kéne.
A probléma valahol a scriptek tájékán lesz.

* Én egy indián vagyok. Minden indián hazudik.

Már megint a Sorosozás... ;)

Orwell az 1984-et regénynek írta és nem használati utasításnak!

Egyre titokzatosabb a hiba.
Nem hagyott nyugodni a dolog és kipróbáltam mi van ha az "alapértelmezett" ttyS0 -val próbálkozom - meglepi, az sem működik, se root se user.

MEGJEGYZÉS:
Általában úgy szoktam ellenőrizni, hogy fogok egy (9 vagy 25 pólusú) DSUB csatlakozót aminek a 2-3 pinje össze van kötve és elindítok egy minicom -D /dev/ttySx -b 9600 ha gépeléskor visszakapom a karaktereket akkor első körben OK.

A következő körben, kipróbáltam egy (pl2303 alapú) USB soros átalakítót. A kernel logban szépen látszik hogy megtalálja és rátestálja a /dev/ttyUSB0 -ra. minicom - ez sem működik!?

Mi az ördög van?
Semmilyen soros port nem elérhető a gépen?
Mi lehet a kernelen kívül a közös?
Az alaplap BIOS működik (win10 alól minden port hasít).
Valaki meghackelte a sorost?

* Én egy indián vagyok. Minden indián hazudik.

flow control nem kavar bele alapbol a minicomban?

Ki szoktam kapcsolni, de azért ránézek.

* Én egy indián vagyok. Minden indián hazudik.

> a 2-3 pinje össze van kötve

A 9 pólusú csatlakozóban szerencsés lenne még két rövidzárat feltenned, akkor nem kell foglalkoznod azzal, hogy a minicomnál éppen hogyan van beállítva a hardver handshake:

(DTR) 4 -- 6 (DSR)
(RTS) 7 -- 8 (CTS)

Esetleg még a DCD-t (1. láb) is meghajthatod a DTR-ről, abból baj nem lehet.

A jó öreg null modem kábel. A handshek controlt kiszoktam kapcsolni de ellenörzöm.

* Én egy indián vagyok. Minden indián hazudik.

Debian/Testing-nél egy régebbi notinál ugyanezt a hibát kaptam.
Az smsc_ircc2 modult kellet blaklistelnem.

Nincs valami modulod betöltve ami szintén a soros portokkal foglakozik?

Régebben is volt ilyen hibám, akkor braille írásért felelős modult kellet blaklistelnem. A modul nevére már nem emlékszem.

A biztonság kedvéért ismét megnéztem mi a helyzet windows 10 alatt. Minden soros port köszöni szépen, működik - nemcsak visszacsatolva, de egy másik PC soros porttal szembeállítva.
Stretch a négy portos kártya nem működik.
$ setserial /dev/ttyS7
Invalid argument
root -ként vissza adja a beállított paramétereket, de minicom alatt meg sem nyikkan.
Viszont az alaplapi soros ttyS0 és az USB0 működik - benéztem valamit. (Valószínűleg, amikor -D és -b opciókkal meghívom a minicom -ot nem kapcsolja ki a handshake opciókat)
A net nincs tele hibajelentésekkel - elvétve egy-kettő hasonló van. Nem tudok mást feltételezni mint, hogy a setserial beállításokkal van gond cím vagy irq. Viszont nincs másom mint az lspci.
A házi szerverkémben is működik egy ilyen kártya, ott is ezeket a beállításokat használom (0xd100,0xd108,0xd110,0xd118 és irq 20), ott rendben működik, viszont az debian 6.0.10 verzió - nem szeretnék ahhoz visszatérni.
Nem tudja valaki hogy lehet a beállításokat (cím/irq) a windows10 -ből kinyerni?

* Én egy indián vagyok. Minden indián hazudik.

Valószínűleg, amikor -D és -b opciókkal meghívom a minicom -ot nem kapcsolja ki a handshake opciókat

El tudod menteni, hogy mi legyen a default, és akkor onnantól kezdve azt használja a minicom mindig.

minicom -s -o, beállítod, hogy mit szeretnél, aztán a főmenüben 'Save setup as dfl'.

hogy lehet a beállításokat (cím/irq) a windows10 -ből kinyerni?

Gondolom, mint a többi Windowsban: devmgmt.msc, aztán jobb klikk és Properties.

De ha PCI-os a kártya (márpedig így 2017-ben mi más lehetne), akkor ezeket automatán kéne kezelnie a gépnek.

Köszönöm! Általában a setserial/minicom kombóbeállításába nálam beletartozik egy ilyesmi - mondjuk a default -ot nem szoktam bántani, lehet hiba.
devmgmt.msc ? - évek alatt nem tanultam meg hogy az ms ilyen fura dolgokat használ. Az "eszközkezelő" applet(?) meg csak arra nem jó amire szánták :(
A kártya PCI, de a gyári Linux "driver" ami valójában csak annyi, hogy a setserial parancsot a local.rc -be beépíti, érdekes módon az irq beállításhoz az "auto_irq" opciót jelöli meg. A kernel opciókban viszont az áll, hogy
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
Nekem kicsit ellentmondásos.

* Én egy indián vagyok. Minden indián hazudik.

# CONFIG_SERIAL_8250_DETECT_IRQ

Ez nem ellentmondás: a 8250 egy őskövület, már az eredeti PC-ben is létezett, lassan 40 éve. A PCI óta van stabil autokonfig, előtte gyakorlatilag próba-szerencse alapon lehetett ilyet csinálni - na ez az opció pont ezt csinálja - viszont a PCI-os cuccoknál erre sem szükség nincsen, sem pedig értelme (ugyanis a PCI hw leíró pontosan tartalmazza, hogy milyen címeket használ az a cucc - azokat, és pontosan azokat kell használnia a drivernek).

Szóval a devmgmt.msc nem más mint az "Eszközkezelő".
Klassz, már azt is tudom mikor telepítettem, de sem IO címet sem IRQ adatot nem látok :(
Továbbra is csak annyit tudok, hogy win10 alatt jól működik.

* Én egy indián vagyok. Minden indián hazudik.

Azért nem Device Managert írtam, mert az lokalizációfüggő, továbbá verziónként random átnevezgetik, meg még át is pakolják, hogy honnan érhető el.

7-esen van Resources fül, valami ilyesminek kéne lennie a későbbiekben is, na ott fel van sorolva, hogy milyen hw címeket érzett magáénak a driver.

Megint tanultam valamit!
Az "Eszközkezelő" "Nézet" menüpontjában mindent megtaláltam.
Viszont ez pontosan ugyan az amit a Linux -nak adtam, illetve az lspci -on kaptam io 0xD100 -tól és irq 20
Minden stimmel, de nem működik. A kör bezárult :(
Az egyetlen kapaszkodó, ha megnézem a kernel forrást és megkeresem, az "Invalid argument" melyik paraméterről szól, szólhat.

* Én egy indián vagyok. Minden indián hazudik.

A kernel hibakódok neve nem szól semmiről; van egy relatíve rövid listája a hibakódoknak, és minden hibaesetre próbál a driver/kernel részegység írója valami ahhoz kb. hasonlító hibakódot visszaadni - ebből nem következik, hogy egy invalid argument az bármilyen konkrét paraméterre utalna.

Jelen esetben szerintem a "nem tudtam inicializálni a kártyát" hibakódja ez lesz, ha tippelnem kéne.

Nem várok nagy meglepit, de hátha megtalálom melyik ponton is küldi a hibát. Illetve, zavaró, hogy a kernel nem jelez hibát.
(Baráti körben mindig erős érvem a Linux mellett hogy mindenféle hibát naplóz, jelez. Ha még sincs napló bejegyzés akkor fatális hiba van - mondjuk kikapcsolták)

* Én egy indián vagyok. Minden indián hazudik.

Ez amúgy általában igaz is szokott lenni. Van pár interfész, ahol nehézkesen jön ki információ, és pl. a kernel modul betöltés, az pont ilyen: egy szál integer return code van; a dmesg szokott még értékes infókat tartalmazni. Sajnos ilyenkor sok más opció nem marad, mint a forrás böngészése. Azzal sem tudsz sok mindent kezdeni, ha egyszerűen csak nem kezeli a driver a hw-edet.

Nagyon furcsa.
A forrásban még nem mélyedtem el, de elkezdtem piszkálni a paramétereket úgy, hogy a setserial manual beállításait "kinulláztam". Majd bootolás után kézileg beállítottam:
# setserial /dev/ttyS4 uart 16550A port 0xd100 auto_irq skip_test autoconfig
'x sikerült! -de azóta sem :(
Mindezt egy X window nélküli telepítésen.
Az X window -s telepítésnél úgy tűnik, már a /dev/ttyS4 -re a setserial kijelenti, hogy invalid paraméter, csak a /dev/ttyS1 -re hagyja és nem állítja be az irq -t (irq:0).
A további "játszadozás" (pl. a set_multiport beállítással) core dumpot dob.

* Én egy indián vagyok. Minden indián hazudik.

Egyelőre feladom. Küldtem egy bugreportot a Debiannak és egy emailt a debian-user fórumba.
Megpróbálom áthidalni a problémát.

* Én egy indián vagyok. Minden indián hazudik.

Sikerült a kártyát működésre bírnom Debina 9.2 kernel Linux 4.9.0-4-amd64
A "megoldás" finoman szólva sajátságos.
Portonként a következő parancsokat kell kiadni:

# /bin/setserial /dev/ttyS4 uart 16550A port 0xd100 irq 20 baud_base 115200 spd_normal skip_test ^fourport
# /bin/setserial /dev/ttyS4 uart unknown
# /bin/setserial /dev/ttyS4 uart 16550A port 0xd100 auto_irq autoconfig

Vagyis először "megetetem" a régi beállításokkal (linux 2.6.x)
Ha ebben az állapotban, mint user lekérem a beállításokat, "Invalid argument" az eredmény.
Utána "törlöm" az uart beállítást - ekkor már megint működik userként setserial, viszont nem működik a port.
Végül kiadom a gyártó által javasolt beállítások egy részét. Ettől fogva minden zöld. pl.
$ setserial /dev/ttyS4 -a
/dev/ttyS4, Line 4, UART: 16750, Port: 0xd100, IRQ: 0
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq

(ugyan ilyen a többi port is csak más az IO cím)

sudo cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
1: uart:unknown port:000002F8 irq:3
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:TI16750 port:0000D100 irq:0 tx:20 rx:12 RTS|DTR
5: uart:TI16750 port:0000D108 irq:0 tx:21 rx:11 RTS|DTR
6: uart:TI16750 port:0000D110 irq:0 tx:21 rx:13 RTS|DTR
7: uart:TI16750 port:0000D118 irq:0 tx:21 rx:11 RTS|DTR

Leellenőriztem visszahurkolva és másik gép sorosával, minden OK.
Gondolom kiszúrtátok, hogy az irq 0 felhasználásával működik, már abból ítélve amit mutat. Biztos lehetne a megoldáson finomítani, de végül is ez (egyelőre) működik :)
Most kellene egy kernel guru, mert ennek így nem szabadna működnie!
Megoldottam?

* Én egy indián vagyok. Minden indián hazudik.

Erre hogy jöttél rá? (Bugreportot küldtél nekik?)

Abból indultam el, hogy az "Invalid argument" üzenetet magára a /dev/ttyS4..7 -re kaptam (bármi mást vettem ki adtam hozzá módosítottam nem volt változás). Elkezdtem parciálisan piszkálni a beállításokat (pl. auto_irq), akkor próbaképpen töröltem az uart -ot (unknown) - akkor már nem kaptam az "Invalid argument" hibaüzenetet, de persze nem működött egyáltalán.
Több napja vissza-vissza térek ehhez problémához és emlékszem, hogy volt hogy működött, de akkorra már annyi mindent piszkáltam, hogy nem tudtam reprodukálni mi volt a sorrend.
Így elővettem a "gyári" beállító szkriptet és azt használtam fel amiből a legfurább az auto_irq és az autoconfig volt és az első próba után beindult.
Csak hab a tortán, hogy a kernel konfigurációban az van hogy
"# CONFIG_SERIAL_8250_DETECT_IRQ is not set"
Az egész egyre értelmetlenebb :(
(A 16550, 16750 és társait mind a 8250 -es driver kezeli.)

* Én egy indián vagyok. Minden indián hazudik.

Hát ez tényleg elég értelmetlen. Kéne küldeni a Debian levlistára bugreportot. Meg meg kéne próbálni egy másik disztróval, mondjuk Slackware-rel, hogy a probléma Debian specifikus, avagy belefutottál valami kernel mizériába.

Elvileg a Debian -nak küldtem egy hiba jelzést. De az a Debian reporting bug izé kifogott rajtam, egy zagyvaság lett belőle - a setserial csomagra testáltam. Viszont egyre inkább a kernel -re gyanakszom, szerintem /proc/tty/driver/serial -file -t a kernel kezeli, illetve a setserial sem csinál mást mint akernel api -t hívogatja.
A kernel.org -on viszont a 4.9.0 már nem támogatott.
Össze-vissza googliztam magam, nem igen van erre a jelenségre panasz - lehet már nem használja senki, vagy csak nálam van valami anomália.
Nem tudom mit higgyek, Teszek egy próbát a stcakexchange -el?

* Én egy indián vagyok. Minden indián hazudik.

A setserial fejlesztőjétől is kérhetsz tanácsot szerintem. Ha másban nem is, abban, hogy mit kéne csinálnod, hogy neki a debuggoláshoz infót adj.

Végül kikötöttem a Debian fórumban. Talán ott kapok valamit amivel pontosíthatok, szűkíthetek.

* Én egy indián vagyok. Minden indián hazudik.