278 replies to this topic

[Meega]

hier zit al vanaf ik de dm8000 heb een cf kaartje in de box

nooit bootproblemen gehad

Ik vraag het ook aan mensen die wel bootproblemen hebben.
Maar het zal wel toeval zijn.


Meega

[ni_hao]

@Meega: Hier ook een cf kaart er in en daarnaast ook nog eens 6x usb aangesloten, geen problemen.
Toeval bestaat niet bij wat jij beschrijft. Daarnaast heeft hetgeen je schrijft (het wel of geen beeld hebben afhankelijk of je cf kaart er in zit of niet) helemaal niets met bootproblemen te maken. Je systeem is al opgestart en zelfs enigma2 is al geladen/gestart. Lijkt me meer een mount- en/of herkennings- en/of formatprobleem.

[Meega]

@Meega: Hier ook een cf kaart er in en daarnaast ook nog eens 6x usb aangesloten, geen problemen.

Toeval bestaat niet bij wat jij beschrijft. Daarnaast heeft hetgeen je schrijft (het wel of geen beeld hebben afhankelijk of je cf kaart er in zit of niet) helemaal niets met bootproblemen te maken. Je systeem is al opgestart en zelfs enigma2 is al geladen/gestart. Lijkt me meer een mount- en/of herkennings- en/of formatprobleem.

Mee eens alleen als de cf er bij mij inzit heb ik geen tweede plilogo en geen beeld.
Verder start tie prima op net als bij bootproblemen,ik kan gewoon zappen en in het menu.
Maar ik ondervondt dit alleen en zal straks nog een paar keer booten met cf.

Meega

[pieterg]

misschien dat de mensen die bootproblemen hebben, eens een 15-20s delay kunnen introduceren, ipv de 3s die we nu hebben
in /etc/modutils/dreambox
de msdelay veranderen:
module-sleep msdelay=15000

dan
update-modules

Onze image boot ca 15s sneller dan andere images, onder andere vanwege het mdev vs udev verhaal. Misschien is de hardware (zoals tpm) nog iets voor zichzelf aan het doen op het moment dat wij de drivers willen laden.

de boel weer lekker traag maken is misschien de 'oplossing'...

[littlesat]

Wie weet zullen we het spoedig horen....

Maken we er een config van :-D kan ieder zijn eigen delay instellen (LOL)

[Henksat]

misschien dat de mensen die bootproblemen hebben, eens een 15-20s delay kunnen introduceren, ipv de 3s die we nu hebben
in /etc/modutils/dreambox
de msdelay veranderen:
module-sleep msdelay=15000

dan
update-modules

Zojuist gedaan, rapportjes volgen nog.

[littlesat]

Ben benieuwd.... Tja... is PLi misschien simpelweg "te Snel"????

[amigo]

misschien dat de mensen die bootproblemen hebben, eens een 15-20s delay kunnen introduceren, ipv de 3s die we nu hebben
in /etc/modutils/dreambox
de msdelay veranderen:
module-sleep msdelay=15000

dan
update-modules

Zojuist gedaan, rapportjes volgen nog.

En?

Hier al zo'n 10 keer geboot, 100% goed nu

[amigo]

Na een update, toch weer mis. Na 4 keer booten nog geen beeld.

Nog ff gecheckt, staat nog steeds op 15 s na de update.

Vreemd, voor de update leek het opgelost

[amigo]

En als je na de softwareupdate na 5 a 6 keer eindelijk beeld hebt, is de score weer 100% met beeld ook na tig keer booten.

Was mij nog nooit eerder opgevallen.

[beebee]

misschien dat de mensen die bootproblemen hebben, eens een 15-20s delay kunnen introduceren, ipv de 3s die we nu hebben
in /etc/modutils/dreambox
de msdelay veranderen:
module-sleep msdelay=15000

dan
update-modules

Onze image boot ca 15s sneller dan andere images, onder andere vanwege het mdev vs udev verhaal. Misschien is de hardware (zoals tpm) nog iets voor zichzelf aan het doen op het moment dat wij de drivers willen laden.

de boel weer lekker traag maken is misschien de 'oplossing'...

module-sleep msdelay=15000
alps_bsbe1
alps_bsbe1_c01a
alps_bsbe2
bcm4501
bcm4506
bcm7400
cu1216mk3
cxd1981
dreambox_keyboard
dreambox_rc2
fpga
lcd
lnb_ctrl
max4397
stb-core
tu1216

1e goed
2e fout
3e goed
4e fout
5e fout
6e goed

Flash Size 256 MB
Production Date (YYYY/MM/DD) 2009/05/26
mID 10
Serial Number 8450
MAC Address 00:09:34:1c:*****
Printed Serial Number 952610140008***

Moet ik ook nog een keer 20 sec. uitproberen???

[Frenske]

Net als mijn voorgangers diverse scenario's uitgeprobeerd met (helaas) niet de gehoopte resultaten.

Na de wijziging naar 15sec en update-modules en diverse herstarts verschillende resultaten.

1e herstart beeld (in begon stilletjes te hopen :wink:)
2e herstart geen beeld
3e herstart geen beeld
4e herstart geen beeld
5e herstart geen beeld
6e herstart beeld
7e herstart geen beeld
8e herstart geen beeld
9e herstart weer beeld

Daarna gewijzigd naar 20 sec met eigenlijk bijna identieke resultaten.

1e herstart geen beeld
2e herstart geen beeld
3e herstart geen beeld
4e herstart beeld
5e herstart beeld
6e herstart geen beeld
7e herstart beeld

De invloed van deze wijzigingen lijkt mij helaas nagenoeg nihil.

[Henksat]

Hier ook getest met 15 sec. delay.
Na een update geen beeld, 2e boot hangt zelfs helemaal in het begin met Dream Multimedia in het display, een hard reset gaf eindelijk beeld.
4e boot gaf gelijk beeld, 5e boot hangt weer zoals hierboven, hard reset gaf wederom geen beeld.
Het lijkt er toch op dat we in de verkeerde richting zoeken.

[littlesat]

Misschien moeten we wel iets doen aan de volgorde waarin de drivers geladen worden. Net nog in een ander image gekeken en daar is de volgorde toch echt anders. Bij ons gaat dat netjes alphabetisch... maar in de bootup van vroeger is een bepaalde volgorde... Tís maar een gedachte en wie weet als we de juiste vooraan zetten werkt het ook al...

Wat ik in ieder gevaal zie is dat het keyboard in iedergeval voor de bcm-etjes gaat.

Is het niet zo dat je ook zo races kunt triggeren?

[mail]root@dm8000[/mail] /etc/init.d # cat bootup
echo 10 > /proc/progress
[ -e /dev/dbox/oled0 ] && ln -s /dev/dbox/oled0 /dev/dbox/lcd0
mount -t sysfs sysfs /sys
echo 11 > /proc/progress
depmod -Ae
echo 12 > /proc/progress
for mod in cdfs ntfs; do
	   modprobe $mod
done
echo 13 > /proc/progress
(sleep 10; cat /etc/fscking.raw > /dev/dbox/oled0; sleep 1d) &
pid=$!
mount -at nonfs,nosmbfs,noncpfs,nocifs
kill $pid
echo 14 > /proc/progress
swapon -a
echo 15 > /proc/progress
tar xzf /etc/var.tar.gz -C /
echo 16 > /proc/progress
# sleep after 10min
hdparm -S120 /dev/sda
echo 17 > /proc/progress
# set UDMA66, enable dma
hdparm -d1 /dev/sda
hdparm -X66 /dev/sda
# accustic management
hdparm -M128 /dev/sda
echo 18 > /proc/progress
for mod in dreambox_keyboard fp bcm7400; do
	   modprobe $mod
done
echo 19 > /proc/progress
cat /etc/videomode > /proc/stb/video/videomode
echo 20 > /proc/progress
echo "loading madwifi modules"
for x in wlan ath_rate; do
	   for mod in `ls /lib/modules/$(uname -r)/net | grep $x | cut -d . -f 0`; do
			 modprobe $mod
	   done
done
modprobe ath_pci
echo 21 > /proc/progress
[ -e /etc/dropbear/dropbear_rsa_host_key ] && /usr/bin/showiframe /boot/bootlogo.mvi || /usr/bin/showiframe /boot/bootlogo_wait.mvi
hostname -F /etc/hostname
echo 23 > /proc/progress
[ -e "/etc/sysctl.conf" ] && /sbin/sysctl -p "/etc/sysctl.conf"
echo 24 > /proc/progress
ldconfig
echo 25 > /proc/progress
ipkg-cl configure
[mail]root@dm8000[/mail] /etc/init.d #

[pieterg]

nogmaals, wij doen niks verkeerd.
Het is een bug in de drivers, en als je het mij vraagt, is het eentje uit de categorie beginnersfout.
Het is dat het dmm is, dus we geven ze nog maar even het voordeel van de twijfel, al duurt het naar mijn zin nu al veel te lang voordat er een fix komt.
Tot die tijd kunnen we hooguit wat spelen met timings en volgordes, om te kijken of iets er invloed op heeft.

En ik verwijs nogmaals naar de 1.0 beta, waar /etc/init.d/bootup er precies zo uitziet als je hierboven laat zien, en waar de problemen net zo erg waren.

Maar als je perce wilt, kan je dit nog proberen in je /etc/modutils/dreambox, alleen deze drie modules:

dreambox_keyboard
fp
bcm7400

Eventueel dan nog module-sleep msdelay=3000 of langer, bovenaan het lijstje, of juist onderaan.

Na elke wijziging
update-modules

Maar onze mogelijkheden zijn wel zo ongeveer uitgeput, er zit niks anders op dan te wachten op de echte fix, en die zal niet van ons komen.

[littlesat]

Dat wil toch eigenlijk zeggen dat ook in de huidige beta's van DMM dit probleem moet zitten... Inderdaad het blijft prutsen...

[pieterg]

Dat wil toch eigenlijk zeggen dat ook in de huidige beta's van DMM dit probleem moet zitten...

nee, dat wil alleen maar zeggen dat het dus niet in het verschil met /etc/init.d/bootup zit

[littlesat]

[Henksat]

Dat wil toch eigenlijk zeggen dat ook in de huidige beta's van DMM dit probleem moet zitten...

nee, dat wil alleen maar zeggen dat het dus niet in het verschil met /etc/init.d/bootup zit

Eerlijk gezegd snap ik deze ook effe niet.

[littlesat]

Ik wel... wat je ook doet... de oplossing is een driver fix... al het andere is je geluk beproeven. Maar de volgorde aanpassen.... (met eventueel pauzes ertussen) wie weet gaat het dan minder vaak mis???

Wat je ook kunt doen is met sleeps e.d. werken in de /etc/rcS.d/S20modutils.sh en eventueel door rechtstreeks te editen in /etc/modules daar de volgorde aan te passen....