1176 replies to this topic

[rytec]

.. heb ik nu op deze nieuwe installatie nog slechts 2,7Mb ram free ..

Dat is wel heel weinig, maar ik neem aan dat je nog tientallen MB's cached hebt staan.

na een nacht volgende uitvoer van geheugen :

total used free shared buffers
Mem: 138244 131280 6964 0 2664
-/+ buffers: 128616 9628
Swap: 0 0 0

[Rob van der Does]

..... tenzij 't voor de Ultimo anders is dan voor de Duo.

Volgens mij is dat inderdaad het geval. Als je alle postings op de diverse forum zo eens doorneemt, zie je dat het echt de DUO is die hier stelselmatig last van heeft. Alle meldingen over andere boxen zijn incidenteel, en gaan bovendien vaak (inderdaad: niet altijd) over een E2-crash. Het probleem waarover we het hier hebben is echt een systeem-crash.

[Erik Slagter]

Ik kom uit op de precies dezelfde getallen (overigens testen wij nu een Ultimo en niet een Duo). Daarna heb ik de box gereboot, die heeft 8 dagen continu gedraaid, en kom weer op precies dezelfde getallen uit. Geheugenproblemen in de kernel modules kunnen we zo wel uitsluiten, tenzij 't voor de Ultimo anders is dan voor de Duo.

IMHO betekent dat alleen maar dat de "size" parameter van lsmod niet geschikt is al benchmark, weten we dat ook weer. Dat is kennelijk alleen "text" size, geen "data". Erg jammer.

[Erik Slagter]

Volgens mij is dat inderdaad het geval. Als je alle postings op de diverse forum zo eens doorneemt, zie je dat het echt de DUO is die hier stelselmatig last van heeft. Alle meldingen over andere boxen zijn incidenteel, en gaan bovendien vaak (inderdaad: niet altijd) over een E2-crash. Het probleem waarover we het hier hebben is echt een systeem-crash.

Ik denk dat het op de Duo gewoon sneller optreedt omdat UItimo meer geheugen heeft, heel bot dus.

[Rob van der Does]

Volgens mij is dat inderdaad het geval. Als je alle postings op de diverse forum zo eens doorneemt, zie je dat het echt de DUO is die hier stelselmatig last van heeft. Alle meldingen over andere boxen zijn incidenteel, en gaan bovendien vaak (inderdaad: niet altijd) over een E2-crash. Het probleem waarover we het hier hebben is echt een systeem-crash.

Ik denk dat het op de Duo gewoon sneller optreedt omdat UItimo meer geheugen heeft, heel bot dus.

Dat klinkt logisch, maar dan zou het op de Solo nog (veel) eerder moeten gebeuren.

[Erik Slagter]

Wie weet? Wie heeft er een Solo?

[rytec]

Wie weet? Wie heeft er een Solo?

ikke en die herstart ook regelmatig nu maar dat deed ie ook al soms met de vorige kernel versie maar in mindere mate.

momenteel op de solo :
total used free shared buffers
Mem: 106076 102008 4068 0 0
-/+ buffers: 102008 4068
Swap: 0 0 0

en lsmod :

Module Size Used by
zd1211rw 53117 0
usbserial 29783 0
rtl8192cu 95238 0
rtl8192c_common 54939 1 rtl8192cu
rtlwifi 96448 1 rtl8192cu
rtl8187 54031 0
rt73usb 24248 0
rt2800usb 12993 0
rt2800lib 44195 1 rt2800usb
rt2500usb 18089 0
rt2x00usb 10169 3 rt73usb,rt2800usb,rt2500usb
rt2x00lib 37784 5 rt73usb,rt2800usb,rt2800lib,rt2500usb,rt2x00usb
r8712u 164906 0
ipv6 303650 8
carl9170 80558 0
ath9k_htc 60871 0
mac80211 203349 10 zd1211rw,rtl8192cu,rtl8192c_common,rtlwifi,rtl8 187,rt2800lib,rt2x00usb,rt2x00lib,carl9170,ath9k_htc
ath9k_common 1426 1 ath9k_htc
ath9k_hw 307676 2 ath9k_htc,ath9k_common
ath 16163 3 carl9170,ath9k_htc,ath9k_hw
brcmfb 1127 2
dvb_bcm7325 4837933 2 brcmfb
procmk 1397 1 dvb_bcm7325

[pieterg]

lsmod hoef je niet naar te kijken, die geeft simpel de size van de ko die geladen is

[Erik Slagter]

Ja kwam ik al achter

[Rob van der Does]

Wie weet? Wie heeft er een Solo?

Velen hebben een Solo. als ik kijk naar de meldingen op de diverso forums, kom ik echt alleen de DUO tegen die structureel aan systeemcrashes lijdt.

[Erik Slagter]

Dat is dan destemeer een aanwijzing dat het om een driverprobleem gaat...

[doglover]

Op een VU+ duo met swap file:


Mem: 138244 135088 3156 0 792
-/+ buffers: 134296 3948
Swap: 98300 2532 95768

Deze heeft nauwelijks vastlopers (reeds enkele weken geen enkele). Moet er wel bij vertellen dat ik iedere dag de box herstart.

Willy

[Rob van der Does]

Wie weet? Wie heeft er een Solo?

Velen hebben een Solo. als ik kijk naar de meldingen op de diverso forums, kom ik echt alleen de DUO tegen die structureel aan systeemcrashes lijdt.

Dat is dan destemeer een aanwijzing dat het om een driverprobleem gaat...

Het is natuurlijk interpretatiewerk en geen wetenschappelijk onderzoek, maar de DUO springt er echt uit als probleem box (sinds de nieuwe kernel).
Het blijft wel raar dat niet iedereen er last van heeft (hoewel een regelmatige herstart waaschijnlijk wel een probate kuur is).

[Bramboos]

Als feedback wil ik jullie graag meedelen dat mijn Vu+ Duo eigenlijk zo goed als nooit crasht.
Bovendien ben ik met de komst van de nieuwe kernel (begin dit jaar) bijzonder tevreden aangezien mijn USB Wifi stick eindelijk werkt.
Wel moet ik er bij zeggen dat ik na het TV-kijken sowieso mijn ontvanger volledig uitzet (geen stand-by).
Het enige waar ik momenteel heel af en toe problemen mee heb, is heel af en toe eens blokvorming die plots verschijnt bij het afspelen van een opname. Nu kan dit laatste wel te maken hebben met mijn experimenten met Oscam waardoor er misschien iets verkeerd liep tijdens de opname.

[BBsat]

Het is natuurlijk interpretatiewerk en geen wetenschappelijk onderzoek, maar de DUO springt er echt uit als probleem box (sinds de nieuwe kernel).
Het blijft wel raar dat niet iedereen er last van heeft (hoewel een regelmatige herstart waaschijnlijk wel een probate kuur is).

Vind het ook nogal vreemd dat ik nu minder problemen ervaar sinds ik mijn box recent geheel opnieuw geflashed heb.
Want dat heb ik begin januari ook gedaan; 'start from scratch'
En nu heb ik eigenlijk nog maar 1 probleem over; het zo nu en dan raadselachtige vastlopen zonder crashlog.
Voorheen had ik meerdere verschillende problemen en vaker
????

Satkiekerd waarom zou de herstart een probate kuur kunnen zijn?

Edited by BBsat, 16 February 2012 - 22:11.

[Rob van der Does]

Als feedback wil ik jullie graag meedelen dat mijn Vu+ Duo eigenlijk zo goed als nooit crasht.....
Wel moet ik er bij zeggen dat ik na het TV-kijken sowieso mijn ontvanger volledig uitzet (geen stand-by).

En dat verklaart gelijk alles: het opnieuw opstarten is precies het enige dat helpt dit probleem te omzeilen.
Eigenlijk zeg je nu dat de motor van je auto niet warm loopt als je hem regelmatig uit zet

Vind het ook nogal vreemd dat ik nu minder problemen ervaar sinds ik mijn box recent geheel opnieuw geflashed heb......
En nu heb ik eigenlijk nog maar 1 probleem over; het zo nu en dan raadselachtige vastlopen zonder crashlog.

LoL: dat is nu precies het (behoorlijk ernstige) probleem waar het om gaat

Satkiekerd waarom zou de herstart een probate kuur kunnen zijn?

Het is hier al een paar maal gezegd: het 'vastlopen' (eigenlijk dus een systeemcrash) is vrijwel altijd het gevolg van geheugen problemen (het langzaam vollopen van het geheugen). Door het systeem uit te schakelen voordat het geheugen helemaal vol zit, loop je dus per definitie niet tegen dit probleem aan. Na de nieuwe start begint je uiteraard weer met een 'leeg' geheugen, en begint het proces van langzaam vollopen weer.

[Pedro_Newbie]

Ook de oude driver van 22-11-2011 heeft geen verbetering gebracht zojuist om 6.30 uur zag ik dat de klok op 6.17 uur stond, deze was dus zojuist vastgelopen.
Niets meer mogelijk, de VU+ was niet te pingen en uiteraard was telnet ook niet op te starten.
De VU+ was gisteren om 6.50 het laatst geupdate volgens de update log dus de box heeft nog geen 24 uur kunnen draaien zonder problemen.

Nu toch maar weer eens terug naar een oudere versie van begin dit jaar om te testen hoelang die draait zonder crash.

[BBsat]

Blijft dan vreemd dat de ene box dan sneller vol en dus vastloopt dan de andere
Dit uiteraard afgezien van het gebruik, plug-ins e.d.

en er is zoals ik begrijp ook niet echt een goede mogelijkheid om dat vollopen van het geheugen te monitoren?
Anders doe ik dat een paar dagen en stuur dan een overzichtje naar de heren van VU+

[Erik Slagter]

en er is zoals ik begrijp ook niet echt een goede mogelijkheid om dat vollopen van het geheugen te monitoren?
Anders doe ik dat een paar dagen en stuur dan een overzichtje naar de heren van VU+

Wat pieterg al zie, cat /proc/slabinfo. Maar het probleem is dat daar dan wel weer juist veel te veel informatie in staat. Daarbij is ook weer het probleem dat geheugen binnen in de linux kernel lang niet altijd een eigenaar heeft.

Edited by Erik Slagter, 17 February 2012 - 11:05.

[pieterg]

en er is zoals ik begrijp ook niet echt een goede mogelijkheid om dat vollopen van het geheugen te monitoren?

Jawel, alleen je kan beter niet naar 'free' kijken (de free van busybox althans), die mist de 'cached' hoeveelheid.
Voorbeeld hier:

root@et9x00:~# free
			 total		 used		 free	   shared	  buffers
Mem:		291692	   285692		 6000			0		  296
-/+ buffers:			 285396		 6296
Swap:			0			0			0

Dan zou je normaal naar free + shared + buffers kijken, en concluderen dat de box nog maar 6296 kB vrij heeft.

Maar dat is niet het hele verhaal, kijk naar het eerste stuk van /proc/meminfo:

root@et9x00:~# cat /proc/meminfo
MemTotal:		 291692 kB
MemFree:			5984 kB
Buffers:			 296 kB
Cached:		   189996 kB

En als je dan free + buffers + cached bij elkaar op telt, kom je nog op 196276 kB, dus meer dan genoeg.

Kijk je dan nog verder, dan kan je eventueel ook nog zien hoeveel van die cache nog actief in gebruik is, en hoeveel daarvan file cache is, etc

SwapCached:			0 kB
Active:		   161668 kB
Inactive:		  96104 kB
Active(anon):	  67700 kB
Inactive(anon):	  436 kB
Active(file):	  93968 kB
Inactive(file):	95668 kB

Maar de eerste 4 velden zijn voldoende om te zien hoeveel geheugen je werkelijk nog vrij hebt;

MemFree + Buffers + Cached.

Leg daarnaast de utime

root@et9x00:~# uptime
11:01:04 up 3 days, 11:01, load average: 0.02, 0.03, 0.04

en hou bij hoe het geheugen verbruik over meerdere dagen verloopt