[Problem] aktueller CVS Stand

[Steffi]

seife bemerkte ein klein wenig süffisant:

aber das scheint sich ja keiner anschauen zu wollen.

Das liegt - jedenfalls bei mir - nicht am Wollen, sondern am Können.

Ich gelte zwar in meiner engeren Umgebung als dBox-Kennerin, aber unter den Blinden ist auch eine Einäugige die Königin.

Steffi

PS: Sorry for OT

[wittinobi]

Ihr müßt schauen, warum der Watchdog anspringt. Ich vermute, daß der Kernelpatch nicht genau passt und an der falschen Stelle eingefügt wird, aber das scheint sich ja keiner anschauen zu wollen.

huhu,
wollen schon, aber bei meinen kenntnissen dauert das wohl noch ein weilchen bis ich da durchblick (wenn überhaupt, lol).
jedenfalls hab ich jetzt inzwischen auch die busybox1.8.2 getestet, auch ohne erfolg, hrhr.
also gut, dann muss ich mich halt doch mal an den kernelpatch wagen, auch wenn ich wenig hoffnung hab.

mfg
wittinobi

[AudioSlyer]

Sind ja Probleme wie bei den Overclockern ;o)
Geht die Box vielleicht baden, wenn IP over Eth0 angesprochen wird? Deaktiviert mal im Kernel IP und ETH0 um das zu testen.

[seife]

also gut, dann muss ich mich halt doch mal an den kernelpatch wagen, auch wenn ich wenig hoffnung hab.

Das ist evtl. langwierig, aber ich würde erstmal folgendes machen:
- den alten kernel auspacken und mit allen patches patchen
- den neuen kernel auspacken und mit allen patches patchen
- dann schauen, welche Stellen gepatched wurden, und diese bei beiden Kerneln vergleichen. Es kommt schon mal vor, daß in Dateien, wo ähnlicher Code an mehreren Stellen vorkommt, die falsche Stelle gepatcht wird, wenn der Diff von den Zeilennummern her nicht mehr stimmt.

Dazu muß man vom Code noch nicht allzu viel verstehen, dann ich vermute auch, daß sich der 2.4.35 und der 2.4.36 in den Bereichen, die für uns relevant sind, nicht groß unterscheiden. Man muß nur sorgfältig schauen (jeweils auch die Funktion vor und nach der gepatchten anschauen, um zu sehen, ob der Patch nicht in die Falsche reinkam).
Anfangen würde ich mit den Patches, die den Watchdog betreffen.

Wenn das zu nichts führt, muß der Watchdog instrumentiert werden, also dort, wo er getriggert wird (was vermutlich jede Sekunde oder so passieren muß) ein paar "printk("watchdog triggered!\n");" rein, damit man sieht, ob das passiert. Dazu sollte man rudimentäre C-Kenntnisse haben.

Evtl. ist es auch gar nicht der Watchdog. Das sieht man aber, so glaube ich, nach dem reboot im log, ob der Watchdog ausgelöst hatte oder nicht.

Bei mir tritt es nicht auf, da ich keine 2.4er box mit neuestem Kernel betreibe, drum ist mein Leidensdruck klein

[mohousch]

wenn man den linux-2.4.35.5-dbox2.diff 1:1 auf 2.4.36 verwendet hier ergiben sich die Interschiede

Code: Alles auswählen

--- m8xx_setup-2.4.35.5.c	2008-01-17 17:48:33.000000000 +0100
+++ m8xx_setup.c	2008-01-17 00:16:27.000000000 +0100
@@ -60,6 +60,14 @@
 extern void m8xx_cpm_reset(uint);
 extern void m8xx_wdt_handler_install(bd_t *bp);
 
+#if defined(CONFIG_DBOX2) && defined(CONFIG_VT)
+extern int pckbd_setkeycode(unsigned int scancode, unsigned int keycode);
+extern int pckbd_getkeycode(unsigned int scancode);
+extern int pckbd_translate(unsigned char scancode, unsigned char *keycode,
+                           char raw_mode);
+extern char pckbd_unexpected_up(unsigned char keycode);
+#endif
+
 void __init
 m8xx_setup_arch(void)
 {
@@ -413,15 +421,24 @@
 	ppc_md.find_end_of_memory	= m8xx_find_end_of_memory;
 	ppc_md.setup_io_mappings	= m8xx_map_io;
 
+#if defined(CONFIG_DBOX2) && defined(CONFIG_VT)
+	ppc_md.kbd_setkeycode		= pckbd_setkeycode;
+	ppc_md.kbd_getkeycode		= pckbd_getkeycode;
+	ppc_md.kbd_translate		= pckbd_translate;
+	ppc_md.kbd_unexpected_up	= pckbd_unexpected_up;
+#else
 	ppc_md.kbd_setkeycode		= NULL;
 	ppc_md.kbd_getkeycode		= NULL;
 	ppc_md.kbd_translate		= NULL;
 	ppc_md.kbd_unexpected_up	= NULL;
+#endif
 	ppc_md.kbd_leds			= NULL;
 	ppc_md.kbd_init_hw		= NULL;
 	ppc_md.ppc_kbd_sysrq_xlate	= NULL;
 
+#if defined(CONFIG_BLK_DEV_MPC8xx_IDE)
 #if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
 	m8xx_ide_init();
 #endif
+#endif
 }

und in /drivers/mtd/chips/cfi_cmdset_0001.c

[Steffi]

Bevor ich mich an eine Kernel-Patch-Analyse mache , hier erstmal der versprochene Rapport:

@Riker: Der letzte JtG-Snapshot läuft auf den "Problem"-Boxen ohne Probleme.

Ich gebe allerdings zu, so richtig zufrieden stellt mich das nicht...

Steffi

[seife]

Ich habe den gepatchten alten 2.4.35.5 und den gepatchten 2.4.36 gedifft und die einzigen Unterschiede waren ein paar PCI-IDs für IDE chipsätze und dieser "mmap low address" securityfix. Ich kann mir nicht richtig vorstellen, daß der schuld sein kann. Es ist also vermutlich irgendein "Dreckeffekt" evtl im Zusammenhang mit Differenzen irgendwo im Build-Environment (Host-Compilerversion oder sowas).

Wird nicht leicht zu finden sein

[Steffi]

Ich muss nochmal in mich gehen, ob sich die Mühe wirklich lohnt. Vielleicht sollte ich erstmal bei 2.4.35.5 bleiben und meine Energie dann bei passender Gelegenheit lieber gleich in Richtung Kernel 2.6 lenken.

Es ist ja nicht so, dass durch den Kernel 2.4.36 ungeahnte Fähigkeiten unserer betagten dBox2 hervorgerufen werden.

Steffi

[dietmarw]

evtl. sollte der 2.4.36 bis auf weiteres auch im cvs reverted werden?

[geko37]

evtl. sollte der 2.4.36 bis auf weiteres auch im cvs reverted werden?

Dann bleiben die Fehler auf ewig ? Das kann nicht der Weg sein !

[dietmarw]

evtl. sollte der 2.4.36 bis auf weiteres auch im cvs reverted werden?

Dann bleiben die Fehler auf ewig ? Das kann nicht der Weg sein !

blödsinn..

es sollte imo nur nicht über einen längeren zeitraum ein zustand
im cvs bestehen, der auf div. boxen probleme macht..

tests mit dem 2.4.36 kann man besser intensiver über diffs machen..

[geko37]

ups doppelt !

[geko37]

evtl. sollte der 2.4.36 bis auf weiteres auch im cvs reverted werden?

Dann bleiben die Fehler auf ewig ? Das kann nicht der Weg sein !

blödsinn..

es sollte imo nur nicht über einen längeren zeitraum ein zustand
im cvs bestehen, der auf div. boxen probleme macht..

tests mit dem 2.4.36 kann man besser intensiver über diffs machen..

Ja das währe natürlich was anderes ! Denn meine Kiste ( Nokia Avia 500 Sat ) fühlt sich recht gut mit dem von mir erstellten SquashFS Image ! ( Kernel 2.4.36 + Ubbot 1.3.1 + Busybox 1.2.1 )

[Hollo]

fehlt ja nur die Uboot 1.3.1 dann im aktuellen CVS

Busybox 1.2.1 ist ja schon ziemlich alt

[geko37]

fehlt ja nur die Uboot 1.3.1 dann im aktuellen CVS

Busybox 1.2.1 ist ja schon ziemlich alt

Ja das ist Sie aber bisher hat sich keiner Erbamt ne lösung zu nennen wie man mit der neuen Busybox von Enigma aus Cifs mounten kann !
Per Console okay per Enigma selbst geht es nicht ! Aber dies Thema habe ich schon so oft angesprochen ! Die meisten fummeln halt an diesem komischen Neutrino rum !

[seife]

Ja das ist Sie aber bisher hat sich keiner Erbamt ne lösung zu nennen wie man mit der neuen Busybox von Enigma aus Cifs mounten kann !
Per Console okay per Enigma selbst geht es nicht ! Aber dies Thema habe ich schon so oft angesprochen ! Die meisten fummeln halt an diesem komischen Neutrino rum !

Du kannst aber den Neutrino-Entwicklern nicht anlasten, daß die Enigma-Entwickler ihr Projekt aufgegeben haben

[Houdini]

an diejenigen bei denen der neue Kernel rumzickt:
habt ihr mal einen komplett neuen build von Anfang an gemacht.
Nicht dass da noch irgendwelche Relikte der alten Version dazwischenfunken.

[dietmarw]

dann bräuchte man nur einen build von mir zu testen.. die sind alle "komplett neu"

[seife]

Ich vermute ja immer noch Unterschiede im Host-System als Ursache - gcc Version etc....

[JtG-Riker]

Ich vermute ja immer noch Unterschiede im Host-System als Ursache - gcc Version etc....

Jo, ich auch bei ~ 1200 Downloads vom neuen Snap und keiner hat sich beschwert das der nicht bootet.

GRuß Riker

[wittinobi]

Ich vermute ja immer noch Unterschiede im Host-System als Ursache - gcc Version etc....

die vermutung hatte ich auch schon.
gab es nicht auch schonmal so einen ähnlichen effekt damals bei der umstellung auf glibc...blabla.
hab da noch sowas seltsames im hinterkopf.

hier mal mein system:

Code: Alles auswählen

cvs:                      1.12.13
autoconf >= 2.57a:        2.61
automake >= 1.8:          1.10
libtool >= 1.4.2:         1.5.22
gettext >= 0.12.1:        0.16.1
make >= 3.79:             3.81
makeinfo:                 4.8
tar:                      1.16
bunzip2:                  1.0.3
gunzip:                   1.3.5
patch:                    2.5.9
infocmp:                  5.5.20060422
gcc 2.95 or >= 3.0:       4.1.2
g++ 2.95 or >= 3.0:       4.1.2
flex:                     2.5.33
bison:                    2.3
pkg-config:               0.21
wget:                     1.10.2

achso, ich hatte auch komplett alles neu gemacht, ...angefangen bei "mkdir dbox2".

[Steffi]

Ich habe heute ein jffs2-Image von DietmarW geflasht. Auch das läuft ohne Probleme. Daher vermute ich jetzt auch ein Problem in meinem Host-System. Ich nutze eine Debian-Distri unter VMWare und werde morgen mal eine andere Distribution installieren.

Wir werden dem Problem schon auf die Schliche kommen. Wäre doch gelacht...

Ach ja ... ich hatte natürlich auch von Grund auf neu gebaut.

[ingrid]

Ich nutze eine Debian-Distri unter VMWare und werde morgen mal eine andere Distribution installieren.

Debian benutze ich auch... Und alles ok.

[wittinobi]

ich benutze auch debian, aber denke mal das ist eher nebensache.
mich würden vielmehr die "tools"-versionen interessieren die bei euch installiert sind.

[trulli]

dann bräuchte man nur einen build von mir zu testen.. die sind alle "komplett neu"

Hi,
entschuldige bitte, aber ich finde nur Images vom 14.01.2008.

Mach doch bitte mal ein jffs2 vom jetzigen Stand.

Dann haben wir einen Stand, den man vergleichen kann.

MfG