[maemo-developers] [maemo-developers] defective memory? (was: problem with dspmp3sink)

[From: Olivier ROLAND]

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 at maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maemo.org/pipermail/maemo-developers/attachments/20060910/6089ee0f/attachment.htm