101 replies to this topic

[theparasol]

 een file in /etc/modprobe.d die zegt dat welke modules geladen moeten worden, dan wordt het lastiger.

 

in etc/modules-load.d/_xp1000.conf staan de modules in gelist.

 

_xp1000.conf

 

xp1000_1
xp1000_2
xp1000_3
xp1000_4

 

hmmm.... ik zie dat ik het wat handiger had kunnen fixen.

 

in /etc/init.d/modutils.sh

 

eval "$LOAD_MODULE $module $args >/dev/null 2>&1"

 

vervangen door

 

sleep 3
eval "$LOAD_MODULE $module $args >/dev/null 2>&1"

[WTE]

Daar ging het mij om. Dan wordt het wel heel lastig debuggen.

 

Volgens mij is het een timing-probleem (aka race condition). Het zou dan misschien wel werken als je een sleep voor de load en erna opneemt (en ertussen, als er meerdere modules zijn). Ik zit even te denken hoe die modules ingeladen worden op de xp1000, misschien is het een init.d script, dan is het simpel, maar ik vermoed eerder een file in /etc/modprobe.d die zegt dat welke modules geladen moeten worden, dan wordt het lastiger.

 

Je zou /sbin/modprobe kunnen renamen naar iets anders en een script /sbin/modprobe maken (wel beginnen met #! /bin/sh en executable maken!) die modprobe-alternatief aanroep met een sleep ervoor en erna.

 

 

 

@parasol: ik begrijp uit jouw output (is niet helemaal 100% duidelijk), dat het laden van de drivers geen output oplevert in dmesg. Dan wordt het wel heel lastig om er iets over te zeggen.

 

Klopt, er staat alleen output als de driver goed geladen is. Is het niet goed gegaan dan zijn beide logfiles 0

MAW drivers rapporteren niet wat er fout is gegaan dus je haalt er geen extra aanwijzingen uit.

 

@WTE met die "nieuwe" drivers zelfde resultaat.

 

 

 

Als je iets wilt proberen dan download hd1100 image en plaats de kernel.bin in /tmp

Daarna met telnet/putty

 

flash_eraseall /dev/mtd1

nandwrite -p /dev/mtd1 /tmp/kernel.bin

[theparasol]

Begrijp ik je nu goed... de Mutant HD1100 is feitelijk een XP1000 zonder CI module

[Erik Slagter]

 

 een file in /etc/modprobe.d die zegt dat welke modules geladen moeten worden, dan wordt het lastiger.

 

in etc/modules-load.d/_xp1000.conf staan de modules in gelist.

 

_xp1000.conf

xp1000_1
xp1000_2
xp1000_3
xp1000_4

hmmm.... ik zie dat ik het wat handiger had kunnen fixen.

 

in /etc/init.d/modutils.sh

eval "$LOAD_MODULE $module $args >/dev/null 2>&1"

vervangen door

sleep 3
eval "$LOAD_MODULE $module $args >/dev/null 2>&1"

Ik zou een sleep van 1 doen en dan ervoor en erna. En dan ook iets laten schrijven in /tmp, zodat je zeker weet dat het script gebruikt wordt.

[theparasol]

Sleep 1 had ik al getest, dat werkt niet, sleep 2 ook niet.

Ik heb ze ook al eens experimenteel weggelaten voor bepaalde modules maar ze lijken er allemaal mee behept te zijn. Dat spul draait allemaal in "cascade"

1 moet eerst, dan moet 2, dan moet 3 en tot slot 4.

 

Aangezien de module ipv6 ook vergelijkbare problemen heeft en die wordt elders ingeladen blijkbaar laat ik het maar even zoals het nu is want ik had gisteren nadat het leek te werken een box zonder werkende nic en dan kun je direct weer opnieuw flashen.

 

Wat ik ook niet snap: /lib/modules/4.0.1/modele.dep (ingekort, gaat om laatste stukje)

extra/xp1000_4.ko: extra/xp1000_3.ko extra/xp1000_1.ko
extra/xp1000_1.ko:
extra/cdfs.ko:
extra/xp1000_2.ko: extra/xp1000_1.ko
extra/xp1000_3.ko: extra/xp1000_1.ko

moet dat niet zijn

extra/xp1000_4.ko: extra/xp1000_3.ko extra/xp1000_2.ko extra/xp1000_1.ko
extra/xp1000_1.ko:
extra/cdfs.ko:
extra/xp1000_2.ko: extra/xp1000_1.ko
extra/xp1000_3.ko: extra/xp1000_1.ko extra/xp1000_2.ko

xp1000_4 kun je nl niet laden als 1,2 en 3 niet actief zijn

xp1000_3 kun je nl niet laden als 1 en 2 niet actief zijn

 

verder als /lib/modules/4.0.1/modules.dep er niet is (zoals direct na verse flash) dan reageert depmod -Ae als volgt:

root@xp1000:/lib/modules/4.0.1# depmod -Ae
depmod: ERROR: could not fstatat(/lib/modules/4.0.1, modules.dep): No such file or directory
depmod: WARNING: -e needs -E or -F

Daar deugd dus ook iets niet!

die depmod -Ae staat letterlijk zo in /etc/init.d/modutils.sh

Edited by theparasol, 12 January 2016 - 19:42.

[HPPli]

Wat is nu de beste en/of definitieve oplossing voor dit specifieke probleem, dus geen reboot mogelijk na een verse flash ?

[WanWizard]

Het is een beetje kastje-muur op dit moment.

 

De fabrikant vind dat het ons probleem is en wij het maar moeten oplossen, maar het moet in de BSP worden opgelost (als je de timing wilt aanpakken) of in de drivers (als je de race conditie echt wilt wegwerken) en beide kunnen alleen maar door de fabrikant worden aangepast.

[HPPli]

Okay thanks, misschien kan 1 van de mede board gebruikers melden wat hun momenteel goed werkende workaround is met de XP-1000 ?

[Jan Gruuthuse]

Momenteel is dit diry_fix.zip van theparasol en dit bestand ermee overschrijven

/etc/init.d/modutils.sh

[theparasol]

En een keer overschrijven en daarna dan kun je alles: image updaten, rebooten... bedenk het maar!

Loopt bij mij al meer dan een week stabiel, ik durf het nog bouter te zeggen: reboot en opstarten gaat zelfs sneller

[HPPli]

Dank @Jan Gruuthuse voor de bevestiging en @theparesol voor de modificatie, loopt bij mij nu ook weer prima.

 

Had het een paar dagen terug ook geprobeerd maar kreeg GS - afwisselend met bootlogo. Kennelijk had ik toen te snel (al tijdens eerste boot na/tijdens verse flash) de file modutils.sh overschreven.

[Jan Gruuthuse]

Wordt er hier nog aan gesleuteld?

[hemertje]

het probleem is bekend gemaakt bij de fabrikant

 

 

Het is een beetje kastje-muur op dit moment.

 

De fabrikant vind dat het ons probleem is en wij het maar moeten oplossen, maar het moet in de BSP worden opgelost (als je de timing wilt aanpakken) of in de drivers (als je de race conditie echt wilt wegwerken) en beide kunnen alleen maar door de fabrikant worden aangepast.

[HPPli]

Ik vind het vervangen van vele instructie regels binnen /etc/init.d/modutils.sh door een aantal "sleep 3"  regels helemaal geen bezwaar en/of onoverkomelijk.

 

 

sleep 3

modprobe ipv6

sleep 3

modprobe xp1000_1

sleep 3

modprobe xp1000_2

sleep 3

modprobe xp1000_3

sleep 3

modprobe xp1000_4

exit 0

 

Geeft ons toch via een korte omweg gebruik te maken van de Firmware version: 4.0 in de combinatie OpenPli / XP1000 en de laatste nightly-builds van OpenPli.

Edited by HPPli, 23 January 2016 - 13:43.

[WanWizard]

Het toevoegen van 15 seconden opstarttijd vind ik nu niet direct de schoonheidsprijs verdienen.

 

Als je iets hackt, dan neem je daarmee elke reden weg voor de fabrikant om met een deugdelijke oplossing te komen. Dus prima als je dit voor jezelf doet, maar ik vind (persoonlijk) niet dat wij dit moeten implementeren...

[Erik Slagter]

Ik had iets opgevangen dat er door de fabrikant naar gekeken wordt.

[HPPli]

Het toevoegen van 15 seconden opstarttijd vind ik nu niet direct de schoonheidsprijs verdienen.

 

Als je iets hackt, dan neem je daarmee elke reden weg voor de fabrikant om met een deugdelijke oplossing te komen. Dus prima als je dit voor jezelf doet, maar ik vind (persoonlijk) niet dat wij dit moeten implementeren...

 

De hack vind ik een prima oplossing indien je wenst OpenPli te blijven gebruiken incl. de Nightly updates van jullie. Gelijk heb je dat niet OpenPli de hack (lees: vervanging door een paar instructie-regels) maar de fabrikant beter kan komen met de juiste instructies ter verbetering van hun product.

Edited by HPPli, 23 January 2016 - 13:54.

[Jan Gruuthuse]

na de flash van OpenPLi-4.0-beta-xp1000-20160205_usb.zip: nog steeds nodig:

/etc/init.d/modutils.sh

overschrijven met inhoud van dirty_fix.zip van theparasol

[Erik Slagter]

Ik heb nog niet gehoord vanuit de leverancier dat het opgelost is. Zolang je niet ziet dat de drivers zijng geupdate, heeft het geen zin om vanalles te proberen (flashen al helemaal niet).

Edited by Erik Slagter, 5 February 2016 - 18:00.

[Jan Gruuthuse]

de flash is nodig als je dat andere probleem wil verhelpen: http://forums.openpl...ndpost&p=529291