Your test work fine on my device.
I see that you run it from /media/mmc1so I guess you format your memory card with ext2.
Mine still vfat so I can't. If you got same error when running from internal memory then your device is broken.


Siarhei Siamashka a écrit :
Hello All,

I'm sorry for a long chunk of quoted text at the end of this message 
(it describes the sympthoms of the problem), but looks like I got an 
almost reliable proof that there is something wrong with the hardware 
of my device :(

I tried to find some software that could be used for benchmarking 
and LZMA SDK (http://www.7-zip.org/sdk.html) looked like an interesting 
option for doing it. But when run on Nokia 770, it sometimes works 
normally and sometimes fails with the following error message:

/media/mmc1 $ time ./lzma b -d19

LZMA 4.43 Copyright (c) 1999-2006 Igor Pavlov  2006-06-04

       Compressing                Decompressing


Error: CRC Error
Command exited with non-zero status 1
real    1m 37.14s
user    1m 36.10s
sys     0m 0.74s


As you see, it failed internal test and was unable to decompress data back
correctly. LZMA is an advanced compression algorithm and uses quite a lot of
memory (it shows ~20MB memory usage in top with '-d19' option). If any of the
bits within this memory block has problems, it can affect data integrity and
cause incorrect compression or decompression. So probably lzma can be also
used as some kind of memory checker.

But it may be also some problem in LZMA code and not in my Nokia 770 hardware,
so I would like to ask somebody to run the same test and check if  the same
problem can be reproduced. You can download the sources of LZMA SDK using this
link: http://prdownloads.sourceforge.net/sevenzip/lzma443.tar.bz2?download
Decompress this archive, change to 'C/7zip/Compress/LZMA_Alone' directory and
run 'make -f makefile.gcc' to compile it. Alternatively you can use my
compiled binary: http://ufo2000.xcomufo.com/files/lzma.gz

Considering that this test program works fine in scratchbox with qemu, LZMA
SDK page mentions performance on ARM and the existence of LZMA debian 
package for  ARM, I think that software bug theory is not very relevant, but
it still needs to be confirmed.

I will wait for feedback in order to confirm if the problem really exists in
my hardware. But looks like it is a high probability that I will have to make
some kind of more advanced memory checker, try to identify faulty memory
physical address and experiment with badram kernel patch.

On Wednesday 23 August 2006 23:09, you wrote:

  
Also I noticed that gstreamer is not very reliable, at least when using
it from mplayer. It can freeze or reboot the device sometimes. That's
not something that should be expected from high level API. If I detect
some reliable pattern in reproducing these bugs, I'll report it to
bugzilla for sure. But right now just using mplayer and lots of seeking
in video can cause these bugs reasonably fast.
        

...

  
Earlier I noticed problems with sound output getting blocked that could be
fixed by bult-in audio or video player. When trying to play anything it
first shows error message. After the second attempt either the sound got
fixed or the device rebooted. I suspected that something could get wrong
with dsp and standard  audio player is able to reset it. That was observed
when using fdsrc element for feeding data to the decoder in mplayer. On
stopping/resuming playback, probably partial audio frames could be feeded
to mp3 decoder and that might result in its misbehaviour.
    

...

  
Now only complete mp3 audio frames can be sent to dspmp3sink. Anyway, first
everything was ok and I even suspected that I will not encounter any
problems at all. But after a few hours I got several reboots. After the
last reboot even wifi started working strange (could not connect using ssh,
it just showed various errors). Turning the device off, waiting for a few
minutes and turning it on again got everything back to normal. Now I
suspect that it could probably be overheating or some other hardware
problem (the device worked with wifi on and heavy cpu usage because of
decoding video for a long time). I'll keep an eye on it and will report
again if the problems keep showing up and if their source becomes more
clear.
    

...

  
I tried swap a long time ago on IT2005, that was done in order to make gcc
work on Nokia 770 to try compiling something before I installed
scratchbox :) Anyway, I did not like the stability as gcc started to fail
with internal compiler errors. So I decided not to use swap as long as it is
enough memory for what I need. 

Also there was some swap related report about the problem with mplayer:
http://www.internettablettalk.com/forums/showpost.php?p=20068&postcount=96

But maybe I should give swap another try on IT2006 and see if it helps to
improve stability.

By the way, I already asked this question in the mailing list long time
ago, but are there any tools for hardware diagnostics on Nokia 770?
Something like memtest86 could probably be very useful.

Though availablility of hardware diagnostics tools could probably result in
more devices getting returned for replacement with otherwise undetected
problems and have negative impact on Nokia profit (just joking).
    
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
  

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Reply via email to