alexwimage: box hangt beim 'freeing kernel memory: 60k init'

Wie blitze ich ein Bild - Permanent Outgoing Incomes
bablylon_nl
Interessierter
Interessierter
Beiträge: 21
Registriert: Dienstag 25. Juni 2002, 11:39

alexwimage: box hangt beim 'freeing kernel memory: 60k init'

Beitrag von bablylon_nl »

Hallo,

habe das alexw2xBaseimageV1.6.3. auf der nokia eines freund gespielt, und der box hangt sich beim 'freeing kernel memory: 60k init'. Verwende selbst der altere v1.6, und auch mit diese image gehts falsch auf gleiche punkt (sonst 64k statt 60k). Dies ist der log:


debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoMIPS
debug: BMon V1.0 mID 01
debug: feID dd gtxID 0b
debug: fpID 5a dsID 01-98.75.01.07.00.00-67
debug: HWrev X5 SWrev 0.81
debug: B/Ex/Fl(MB) 16/16/08
WATCHDOG reset enabled
dbox2:root> debug:
BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Given up BOOTP/TFTP boot
boot net failed

Flash-FS bootstrap loader (v1.5)

Found Flash-FS superblock version 3.1
Found file /root/platform/nokia-dbox2/kernel/os in Flash-FS
debug: Got Block #0044

will verify ELF image, start= 0x800000, size= 202996
verify sig: 262
Branching to 0x40000


PPCBoot 1.1.6 (TuxBox) (Aug 5 2002 - 09:06:03)

CPU: PPC823ZTnnA at 67.200 MHz: 2 kB I-Cache 1 kB D-Cache
*** Warning: CPU Core has Silicon Bugs -- Check the Errata ***
Watchdog enabled
Board: DBOX2, Nokia
I2C: ready
DRAM: 32 MB
FLASH: 8 MB
Scanning JFFS2 FS: . done.
LCD: ready
FB: loading - ready
In: serial
Out: serial
Err: serial

Options:
1: Console on null
2: Console on ttyS0
3: Console on framebuffer
Select (1-3), other keys to stop autoboot: 0
...............................................................
Un-Protected 63 sectors
### FS (cramfs) loading 'vmlinuz' to 0x100000
### FS load compleate: 577057 bytes loaded to 0x100000
## Booting image at 00100000 ...
Image Name: dbox2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 576993 Bytes = 563 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.4.19 (von alexW) Wer Kernels nachmacht, oder faelscht, wird best
raft ;-) #1 Son Sep 22 10:35:10 CEST 2002
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock2 console=ttyS0
Decrementer Frequency = 252000000/60
mpc8xx-wdt: active wdt found (SWTC: 0xFFFF, SWP: 0x1)
mpc8xx-wdt: keep-alive trigger activated (PITC: 0x1000)
Console: colour dummy device 80x25
Calibrating delay loop... 66.76 BogoMIPS
Memory: 30944k available (1008k kernel code, 356k data, 60k init, 0k highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12a (20020514) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis Communications
AB.
i2c-core.o: i2c core module
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
pty: 256 Unix98 ptys configured
eth0: CPM ENET Version 0.2 on SCC2, 00:50:9c:11:d1:75
D-Box 2 flash driver (size->0x800000 mem->0x10000000)
Using word write method
Creating 6 MTD partitions on "D-Box 2 flash memory":
0x00000000-0x00020000 : "BR bootloader"
0x00020000-0x00040000 : "flfs (ppcboot)"
0x00040000-0x00720000 : "root (cramfs)"
0x00720000-0x00800000 : "var (jffs2)"
0x00020000-0x00800000 : "flash without bootloader"
0x00000000-0x00800000 : "complete flash"
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (cramfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 60k init

Wer weist was dass sein konn? und naturlich: wie das zu loschen...

Schone grussen aus holland und vielen dank fur ihre muhe!
bablylon_nl
Interessierter
Interessierter
Beiträge: 21
Registriert: Dienstag 25. Juni 2002, 11:39

Beitrag von bablylon_nl »

Gibts wirklich keine kluge leute den etwas sagen konnen daruber?
bablylon_nl
Interessierter
Interessierter
Beiträge: 21
Registriert: Dienstag 25. Juni 2002, 11:39

Beitrag von bablylon_nl »

:cry: habe der box beim leveranzier zuruckgeschickt und hats zuruck bekommen: man wonscht nichts daran tun, weil er in debug modus ist...

gibts keiner den ein ahnung hatte wie dies zu losen?

bitte, vielen dank!
SoLaLa
Tuxboxer
Tuxboxer
Beiträge: 6119
Registriert: Mittwoch 3. April 2002, 00:32

Beitrag von SoLaLa »

hallöle,
flash halt mal das baseimage 1.6.0 auf die nokia, das läuft oft besser als das 1.6.3
never change a running system
maxg

Beitrag von maxg »

Das hilft bei dem Fehler auch nicht.
usul

Beitrag von usul »

SoLaLa hat geschrieben:flash halt mal das baseimage 1.6.0 auf die nokia, das läuft oft besser als das 1.6.3
Hast du da konkrete Infos. Meiner Meinung nach gibt es zwischen diesen Images keine Relevanten unterschiede. Lasse mich aber gerne eines besseren beleren.

BTW: eine Begründung hatte ich hier schon mal geliefert:
http://tuxbox.berlios.de/forum/viewtopi ... 9&start=15
SoLaLa
Tuxboxer
Tuxboxer
Beiträge: 6119
Registriert: Mittwoch 3. April 2002, 00:32

Beitrag von SoLaLa »

hallöle,
nö, _relevante_ infos hab ich keine, nur n bissi stochastik... ich hatte selber mal das problem, daß auf ner noki500 das 1.6.3 irgendwie nicht so wollte wie es sollte und mit nem 1.6 gings, warum weiß ich auch nicht.
die baseimages inhaltlich zu vergleichen hab ich mir auch nicht die mühe gemacht... wär vielleicht mal ne maßnahme
never change a running system
usul

Beitrag von usul »

SoLaLa hat geschrieben:nö, _relevante_ infos hab ich keine, nur n bissi stochastik... ich hatte selber mal das problem, daß auf ner noki500 das 1.6.3 irgendwie nicht so wollte wie es sollte und mit nem 1.6 gings, warum weiß ich auch nicht.
Ich vermute das ist einfach der *aufräumeffekt* durch das komplette neuinstallieren. Windows repariert man ja auch immer genau so ;-)
SoLaLa hat geschrieben:die baseimages inhaltlich zu vergleichen hab ich mir auch nicht die mühe gemacht... wär vielleicht mal ne maßnahme
Wie gesagt, beim flfs (ppcboot) hab ich mir mal die Mühe gemacht und es ist identisch (bis auf die Differenz im ASCII text).

Das jffs2 (/var) könnte man untersuchen, allerdings werden die Dateien dort ja immer wieder vom cramfs upgedated.

cu
usul