4250 replies to this topic

[theparasol]

WIe zegt dat de ET drivers dit niet in orde heeft..... Volgens mij begrijp jij het helemaal niet... Zie het commentaar van pieterg. En omdat de DM500 iets nodig heeft moet het ineens voor de ETs niet werken?

Waarom de ATR uitlezen tot een ERROR? Eigenlijk wil je die hele ERROR niet....?

dat kan wel, maar dan moet oscam al readende de ATR verwerken en exact aantal historical bytes uitlezen en dan klaar.

Precies... zo hoort dat eigenlijk.... dan hoef je ook niet op een ERROR of iets dergelijks te wachten....

Ik gok dat het verschil in de kernel zit. Ik heb al eens geprobeert met pselect maar dan had diezelfde dm500 powerpc issues, die snapte pselect niet.
Waar kan ik PieterG zijn opmerkingen vinden, wellicht dat ik er wat tips uit kan halen om het spulletje te verbeteren zonder die hele ATR code in oscam aan te moeten passen.

[littlesat]

Zie dit draadje: http://openpli.org/f...and-et9x00-box/

Not having looked at the code, only browsing through the discussion in the ticket, the solution when EAGAIN occurs seems to be to go back into the poll/select loop, instead of having a tight loop around the read.

EAGAIN = EWOULDBLOCK, which indicates "I have no data, I would block if I were in blocking mode".

And "no data" could of course still be "no data" after an infinite number of retries.
Going back to the poll/select would probably show the filedescriptor is no longer readable.

Note that EAGAIN is not the same as EINTR.
EINTR requires just the interrupted call to be restarted.
For EAGAIN, when it occurs in a read, it would not be a very good idea to just keep restarting the system call.

Ik had het ook al in het ticket gezet bij oscam...

Maar ik denk eerder dat je niet afhankelijk moet zijn van elke error melding dan ook....

Edited by littlesat, 7 August 2012 - 19:46.

[littlesat]

Maar eerlijk gezegt zie ik nu ook bij CCcam dat die een 10 sec timeout nodig heeft... Misschien ook iets voor Oscam... dan start het tenminste wel altijd goed door...

Edited by littlesat, 7 August 2012 - 19:53.

[theparasol]

Maar eerlijk gezegt zie ik nu ook bij CCcam dat die een 10 sec timeout nodig heeft... Misschien ook iets voor Oscam... dan start het tenminste wel altijd goed door...

Die 10 seconden timeout had oscam ook icm et boxen, echter nu is die 10 seconden oneindig geworden. Die klotereader returned gewoon continue EAGAIN status ipv ERROR.
Ik blijf erbij dat clarketech gewoon error moet returnen ipv EAGAIN. Die reader wordt nu inmiddels zelfs geopend in blocking mode, dit was non-blocking maar het maakt geen kont uit.
Geen read meer mogelijk? return dan error en niet probeer het later nog eens.
Lijkt erop dat CCcam EAGAIN niet gebruikt, zoals oscam eerder ook niet. Vandaar dat het daar wel ok gaat.

[littlesat]

Maar waarom had je EAGAIN dan nodig perse voor de DM500??

Is het mogelijk daar weer een timeout bij te zetten (3sec of zo) om het "hufterproof" te krijgen?

Edited by littlesat, 7 August 2012 - 20:23.

[theparasol]

Maar waarom had je EAGAIN dan nodig perse voor de DM500??

Is het mogelijk daar weer een timeout bij te zetten (3sec of zo) om het "hufterproof" te krijgen?

Nou die dm500 zijn niet van die vlotte boxjes, dus die geven nogal eens terug: ff wachten, straks weer proberen (EAGAIN)
Enfin, dat kan ik ook ondervangen door een langere timeout waarde igv ppc toe te kennen maar van de andere kant, daar is EAGAIN juist voor.
Echter omdat xtrend zijn readercode ook ten onrechte EAGAIN retourneert terwijl ze eigenlijk ERROR hadden moeten returnen werkt dat dus niet.
Ik kan ook een ifdef _POWERPC_ oid maken zodat alleen dan de EAGAIN gebruikt wordt maar beste is natuurlijk dat xtrend de boel oplapt en niet alle applicaties voor de readers workarounds moeten implementeren toch?
Enfin, door dat nu es ff live te zetten gaan gebruikers als vanzelf mauwen en is hopelijk clarketech wat sneller tot handelen te bewegen, zo moeilijk is dat niet om het even voor altijd goed aan te passen.

[pieterg]

Als je portable unix code wilt schrijven, kan je het beste voor een read van een device altijd een poll/select doen. En als die readable returned, precies 1 read doen, nooit meer (tenzij de read onderbroken wordt door een signal, dan moet je hem restarten).
Dit ongeacht of je het device in blocking mode of in nonblocking mode geopend hebt.

Bij het lezen en schrijven van files maakt het allemaal niet zoveel uit, die kan je gewoon op blocking of nonblocking zetten, en leveren altijd data, tot je een EOF conditie krijgt.

Maar een device is anders. Sommige devices willen niet in nonblocking mode, andere niet in blocking mode. Sommige proberen het opgegeven aantal bytes te lezen voordat read returned, en andere returnen de data in (schijnbaar) willekeurige chunks. Dat komt door de manier waarop een device z'n data aangeleverd krijgt.
Dus dan is het belangrijk om de te pollen voor elke read, en nooit meer dan 1 read achter elkaar te doen. Want anders zou het device wel eens oneindig kunnen blocken (hoewel je bij het openen opgegeven had dat je liever nonblocking mode wilde), of EAGAIN returnen (hoewel je bij het openen opgegeven had dat je liever blocking mode wilde).
Een poll (of select) resultaat blijft dan de enige betrouwbare indicatie of het handig is nog een read te starten.

[theparasol]

De ATR wordt byte voor byte uitgelezen.
Voorafgaand aan elke daadwerkelijke read wordt er een select met timeout gedaan.
Als dat succesvol slaagt wordt er exact 1 byte gelezen... En die ET-9200 reader geeft juist daarna een EAGAIN aan... wat moet je dan nog meer (huil)

Edited by theparasol, 7 August 2012 - 20:48.

[pieterg]

De ATR wordt byte voor byte uitgelezen.
Voorafgaand aan elke daadwerkelijke read wordt er een select met timeout gedaan.
Als dat succesvol slaagt wordt er exact 1 byte gelezen... En die ET-9200 reader geeft juist daarna een EAGAIN aan... wat moet je dan nog meer (huil)

gewoon terug naar je select, ipv naar de read.
Wachten op data doe je met een poll/select, nooit met een read.

[theparasol]

Er wordt dus eerst een select gedaan, als die aangeeft dat er wat te readen valt wordt er pas een read gedaan. En als je dan read doet dan komt die readercode van ET retour met EAGAIN.
Dat klopt toch niet?!

Maar ik ben al weer bezig om probleem in oscam te zoeken... nu niet in ioserial maar in phoenix reader code.
Daar stinkt het ook behoorlijk, kan maar zo zijn dat daar nog wat knullige code inzit.

Edited by theparasol, 7 August 2012 - 21:08.

[pieterg]

Er wordt dus eerst een select gedaan, als die aangeeft dat er wat te readen valt wordt er pas een read gedaan. En als je dan read doet dan komt die readercode van ET retour met EAGAIN.
Dat klopt toch niet?!

EAGAIN is eigenlijk hetzelfde als een read die 0 returned, oftwel, ik heb geen data.
(EAGAIN is wellicht zelfs minder vreemd dan 0, omdat 0 in feite EOF betekent, terwijl het device vast niet weet of er nog meer data gaat komen)
Kortom, gewoon wachten op meer data in de poll/select.

Wat inderdaad raar is, is dat hoewel je select readable aangeeft, de read toch EAGAIN returned.
Maar verboden is dat niet (readable garandeert alleen dat read niet zal blocken, NIET dat er ook echt data aanwezig is).
Het wordt pas vervelend als de volgende select ook readable returned, met een read die weer EAGAIN geeft.
Want dan zou je in een EAGAIN lus kunnen komen.

[theparasol]

Kreun, dus alleen om die *^%$%#$% et-9200 moet de select ook in de eagain lus komen.
Eens kijken of dat vlot ingepast kan worden...

[theparasol]

Inmiddels gedaan in rev 7246, als het nu nog niet ok gaat op de et-9200 is er idd sprake van een EAGAIN lus.
Dan houdt het wel een beetje op of zijn er nog wat andere listige truukjes toe te passen?

http://www.streamboa.../changeset/7246#

[pieterg]

Kreun, dus alleen om die *^%$%#$% et-9200 moet de select ook in de eagain lus komen.

nee, die had er sowieso al bij in moeten staan

Maar ik ben benieuwd of dit afdoende is. Ik neem aan van wel, anders had het met andere softcams ook wel problemen gegeven.

Edited by pieterg, 8 August 2012 - 00:13.

[theparasol]

Het lijkt er op dat je het bij het rechte eind had. Op streamboard is al een user "Rotarum" die je enthousiast bedankt.
De ervaring leert dat er binnen 48 uur weer anderen gaan klagen dat er wat broke is... but hey thats life

[Erik Slagter]

Maar inderdaad ben ik met Pieter eens, altijd eerst een poll of een select doen, een read doe je niet om te kijken of er al data is. Voordeel van een select/poll is ook nog dat je meerdere fd's kunt monitoren en dat je een timeout kunt opgeven. Wat ik eigenlijk wilde zeggen, bij een blocking fd (niet specifiek op non-blocking gezet) mag een read eigenlijk geen EAGAIN teruggeven. Als dat wel zo is, dan zit er wat mij betreft een bug in de driver (of kernel, want volgens mij hoort die read op de achtergrond te blijven proberen in dat geval).

Maar meen je dat nou dat je die ATR per sé byte-voor-byte moet lezen?

[pieterg]

Maar meen je dat nou dat je die ATR per sé byte-voor-byte moet lezen?

nee, het aantal volgende interface bytes kan je telkens afleiden uit de huidige interface bytes. Dus je leest een ATR zeg maar in een stuk of 3 blokken.

[theparasol]

Maar inderdaad ben ik met Pieter eens, altijd eerst een poll of een select doen, een read doe je niet om te kijken of er al data is.

Er wordt altijd al eerst een select gedaan en die geeft aan dat er groen licht is voor een read. Alleen als er dan een read wordt gedaan komt de EAGAIN.

Voordeel van een select/poll is ook nog dat je meerdere fd's kunt monitoren en dat je een timeout kunt opgeven

Dat gebeurt dus ook.

Wat ik eigenlijk wilde zeggen, bij een blocking fd (niet specifiek op non-blocking gezet) mag een read eigenlijk geen EAGAIN teruggeven.

En de read levert dus wel een EAGAIN terug in geval van ET-9200 (!)
Vandaar dat we al met het vingertje naar de fabrikant liepen te wijzen

Maar meen je dat nou dat je die ATR per sé byte-voor-byte moet lezen?

Vast niet noodzakelijk maar zo is dat historisch geimplementeerd. Zoveel tijd win je er ook niet mee, ATR lees je alleen tijdens init van de kaart

[theparasol]

nee, het aantal volgende interface bytes kan je telkens afleiden uit de huidige interface bytes. Dus je leest een ATR zeg maar in een stuk of 3 blokken.

Zo zou ik het ook gedaan hebben als ik van schratsch moest beginnen. Maar goed, als je dat nu nog wilt doen heb je enkel een peut werk en een verhoogt risico op gemekker dat een of andere knollenkaart "ineens" niet meer werkt.

[Henksat]

Maar goed, als je dat nu nog wilt doen heb je enkel een peut werk en een verhoogt risico op gemekker dat een of andere knollenkaart "ineens" niet meer werkt.

Tsja, dat is het nadeel als er met zovelen aan een open source project gewerkt wordt, maar wel goed om te lezen dat jullie er toch weer een oplossing in hebben weten te brengen.