240 replies to this topic

[Zuppelan]

Dat hele verhaal van fragmentatie en linux. Fragmentatie heb je alleen in de kernel. Drivers draaien binnen de kernel (omdat dat nou eenmaal niet anders kan omdat ze

allemaal directe i/o moeten kunnen doen) en dus hebben die "last" van fragmentatie.

 

Fragmentatie

 

En ongetransleerd geheugen = fragmentatie.

 

Ja, maar, het garanderen van aaneengesloten stukken fysiek geheugen is altijd een zwak punt van Linux geweest. Een bekend voorbeeld is de kernelstack: Die was vroeger 8KB groot en vereiste twee aaneengesloten geheugenpagina's. Maar dat was een bedreiging voor de stabiliteit van het systeem, zodra er geen twee pagina's aaneengesloten meer waren, was het afgelopen.

 

Oorspronkelijk probeerde men met slimme algoritmes die situatie te voorkomen, maar dat heeft men op een bepaald moment opgegeven en men is overgestapt op stack van 4KB, waarbij men overal in de kernel wijzigingen heeft gemaakt om het stackgebruik te beperken. Dat heeft ook zo zijn nadelen, ik ben een paar maanden geleden een hoop tijd kwijt geraakt aan een supercomputer waarbij stackoverflows in de infinibanddrivers optraden.... de eerste reflex van fabrikanten is altijd ontkennen of vingertje wijzen... Deze fabrikant koos voor het laatste, ik mocht de driver zelf debuggen. Na debuggen bleek een workaround mogelijk met moduleparameters bepaalde arrays in de driver te verkleinen. Tja.. is het dan een driverbug of niet? Ik vond van wel.

 

Maar goed, dat fragmentatieprobleem is wel iets specifieks voor Linux. Je hebt gelijk dat bij ongetransleerd geheugen het fragmentatiespook loert, maar daar kun je op anticiperen door te weigeren geheugen uit te geven als die uitgave je in de toekomst in problemen brengt. Er is bij Linux op een bepaald moment besloten dat niet meer te doen, maar dat betekent niet dat andere systemen dezelfde keuzes maken.

[pieterg]

Deze fabrikant koos voor het laatste, ik mocht de driver zelf debuggen. Na debuggen bleek een workaround mogelijk met moduleparameters bepaalde arrays in de driver te verkleinen. Tja.. is het dan een driverbug of niet? Ik vond van wel.

Inderdaad, vind ik ook.
Een linux driver ontwikkelaar hoort te weten hoe hij hier mee om dient te gaan.

[doddema]

Maar heeft iemand toevallig de fabrieksimage al eens geprobeerd met de laatste drivers? Mogelijk dat daar een fix in zit die de fouten opvangt van de drivers.
De meeste VU image bouwers gebruiken deze toch als basis, dan hoeven ze zelf dus niets te fixen.

[Rob van der Does]

Kan je dan niet beter VTi proberen? Dat is een aangeklede fabrieks image en dat scheelt je dus een hoop werk (de fabrieks image is wel heel erg kaal).

En als je daar problemen tegenkomt, kan je die gelijk op hun forum melden. Ik volg dat forum, maar dit probleem kan ik me van daar niet herinneren.

[doddema]

Ik heb op alle forums van bekende VU image bouwers gezocht naar deze problemen, maar niets over gevonden.
Echter word er op sat4all wel over gesproken, zie: http://www.sat4all.c...ivers-miskleun/

[littlesat]

Mogelijk dat daar een fix in zit die de fouten opvangt van de drivers.

Dat blijft een work-a-round.... zeker als je een enigma2 wilt bouwen die feitelijk onafhankelijk is wat betreft de box waarop het hoort te draaien....

Inderdaad heeft VU het hiermee iets makkelijker. Hun enigma2 en ook het hele image is feitelijk nog gebaseerd op DMM... en kwa enigma2 nog op een relatieve oude van voordat DMM closed source ging. Een punt waar VU is stil blijven staan en OpenPli en daardoor mede ook de OpenPli gebaseerde images zijn doorgegaan... Dit maakt het eigenlijk nog een stapje erger.

[Erik Slagter]

Nog even over die kernel stack, dat is al weer een tijdje geleden, maar volgens mij waren daar meer overwegingen bij. Voor een stack geldt uiteindelijk hetzelfde als geheugen wat je allokeert (met __get_free_pages e.d.), een driver moet kunnen omgaan het kleine brokjes geheugen en niet zomaar alles op de stack plempen. Ik weet zeker dat dat windows net zo is.

 

Wat bij onze Broadcom-bases-STB'en ook niet helpt is dat de nic-driver die broadcom levert (en die is gelukkig dan wel open source) geen scatter-gather ondersteunt (in tegenstelling tot zo'n beetje alle andere drivers), waardoor die ook stukken aaneengesloten geheugen nodig heeft. Daar zou nog eens een liefhebber in moeten duiken

[Erik Slagter]

Maar goed, dat fragmentatieprobleem is wel iets specifieks voor Linux. Je hebt gelijk dat bij ongetransleerd geheugen het fragmentatiespook loert, maar daar kun je op anticiperen door te weigeren geheugen uit te geven als die uitgave je in de toekomst in problemen brengt.

Dat kun je precies met de min_free_kbytes proc entry forceren. Alleen kernel en drivers worden samen als kernel gezien, wat ook niet gek is. Een driver kan áltijd de hele kernel plat leggen, op tig manieren...

[doddema]

Ik begin die driver probleem te begrijpen:
Vu heeft een eigen fabrieks image, deze wordt bijna door iedere image bouwer gebruikt als basis. Vu stopt in zijn fabrieks image diverse work-a-rounds in om de fouten van de drivers op te vangen.
De image bouwers hoeven zelf geen work-a-rouds te maken en hebben zo geen problemen met de drivers. (ik zie geen klachten van gebruikers bij andere image bouwers over de drivers of slecht afspelen van MKV's)
Behalve die (voor Vu) lastige OpelPLI (gebruikers), die hebben altijd wat te klagen.
Hierdoor kun je de andere image bouwes ook niet beschuldigen van struisvogel politiek, er zijn immers voor hun geen problemen die ze moeten oplossen. Je staat dan als OpenPLI ook niet sterk tegenover Vu, ok al heb je gelijk.

Bij Xtrend is het anders, die heeft geen eigen fabrieks image, hun drivers moeten wel goed zijn voor diverse image bouwers.

Het was beter geweest als Vu ook geen eigen fabrieks image had, dan moesten ze wel goede drivers leveren.

[Rob van der Does]

Vu heeft een eigen fabrieks image, deze wordt bijna door iedere image bouwer gebruikt als basis. Vu stopt in zijn fabrieks image diverse work-a-rounds in om de fouten van de drivers op te vangen.

Nou: wijs mij eens een paar van die work-arounds aan?

 

Bij Xtrend is het anders, die heeft geen eigen fabrieks image, hun drivers moeten wel goed zijn voor diverse image bouwers.

Jawel hoor; maar dat image is op PLi gebaseerd.

 

Het was beter geweest als Vu ook geen eigen fabrieks image had, dan moesten ze wel goede drivers leveren.

Dat hebben ze ook: dat gaf je in je eerste zin zelf aan .....

[Henksat]

Satkiekerd,

 

Stop nu eens met VU+ een hand boven de kop te houden. Met jouw opmerkingen blijf je mensen triggeren hierop te reageren, ook ik erger mezelf daar aan.

VU+ laat gewoon steken vallen met hun drivers, en als je het daarmee niet eens bent helaas pindakaas.

[doddema]

@Erik:
Gisteren 3 MKV's afgespeeld zonder problemen met de drivers van februari. Ook nog geen andere problemen ondervonden met deze drivers.

[littlesat]

Bedankt voor de test...

[Erik Slagter]

Yep, klinkt allemaal goed. Ben wel binnenkort een tijdje op vakantie, dus kan wel even duren voordat de revert heeft plaatsgevonden.

[Erik Slagter]

Bij Xtrend is het anders, die heeft geen eigen fabrieks image, hun drivers moeten wel goed zijn voor diverse image bouwers.

Nou dat laatste nog niet eens per sé, maar het is voor ons natuurlijk wel heel makkelijk en prettig als een fabrikant OpenPLi as basis gebruikt

[Rob van der Does]

Satkiekerd,

 

Stop nu eens met VU+ een hand boven de kop te houden. Met jouw opmerkingen blijf je mensen triggeren hierop te reageren, ook ik erger mezelf daar aan.

VU+ laat gewoon steken vallen met hun drivers, en als je het daarmee niet eens bent helaas pindakaas.

Dan lees je mijn posting wel heel erg verkeerd. Als er iets is dat ik niet doe is het het goedpraten van driverproblemen van VU+.

Ik snap werkelijk niet hoe je dat ergens in een bijdrage van mij kunt lezen of zelfs maar vermoeden.

En ik zal de laatste zijn om te ontkennen dat VU+ eens aan de bak moet.

 

Maar er wordt langzamerhand zo ontzettend veel klinkklare onzin geschreven; en ja, daar heb ik wel iets tegen.

Edited by SatKiekerd, 27 July 2013 - 10:48.

[adrouven]

@Erik:
Gisteren 3 MKV's afgespeeld zonder problemen met de drivers van februari. Ook nog geen andere problemen ondervonden met deze drivers.

@Erik

Hier voor de Duo nog steeds met 1 stap terug van de driver (versie 6 mei 2013) dit samen met de niet elegante cacheflush plugin maakt wel dat het hele systeem weer loopt als een zonnetje. Diverse soorten MKV's afgespeeld (1080p, 720p) en AVI alsmede eigen opnames. Tussendoor openwebif gebruikt en er liep ook nog een opname. Geen hapering gezien.

Blijkbaar moet de Ultimo een stap verder terug dan de DUO.

 

Ook leuk om de hele uitleg rondom de diverse images eens te lezen. Verklaard inderdaad een heleboel.

Dan een vraag uit nieuwsgierigheid, die drivers opensource maken kan Vu dat doen of is dat eigenlijk voorbehouden aan broadcom?

[Erik Slagter]

Voor alle fabrikanten geldt eigenlijk dat ze het niet willen en niet kunnen. Broadcom levert de specs van de SoC onder "NDA" (geheim dus).

 

Maar als de drivers hypothetisch open source zouden zijn, dan zouden daarmee in één klap een heleboel problemen kunnen worden opgelost. Dan zou elke ontvanger op de nieuwste linux kernel kunnen draaien.

[Roymar]

Werk hier ook met de duo en de mei drivers werken hier zonder cacheflush niet goed en de februaridrivers wel

[HPPli]

@Erik:
Gisteren 3 MKV's afgespeeld zonder problemen met de drivers van februari. Ook nog geen andere problemen ondervonden met deze drivers.

@Erik

Hier voor de Duo nog steeds met 1 stap terug van de driver (versie 6 mei 2013) dit samen met de niet elegante cacheflush plugin maakt wel dat het hele systeem weer loopt als een zonnetje. Diverse soorten MKV's afgespeeld (1080p, 720p) en AVI alsmede eigen opnames. Tussendoor openwebif gebruikt en er liep ook nog een opname. Geen hapering gezien.

Blijkbaar moet de Ultimo een stap verder terug dan de DUO.

 

Ook leuk om de hele uitleg rondom de diverse images eens te lezen. Verklaard inderdaad een heleboel.

Dan een vraag uit nieuwsgierigheid, die drivers opensource maken kan Vu dat doen of is dat eigenlijk voorbehouden aan broadcom?

 

Wil je dat ipk-tje van de (niet) elegante cacheflush plugin hier eens plaatsen ?

Ik heb geen last van moeilijk afspeelbare MKV's, maar ben gewoon nieuwsgierig wat deze plugin werkelijk verbeterd.