Re: [maemo-developers] defective memory? (was: problem with dspmp3sink)
On Tue, 2006-09-19 at 03:06, ext Siarhei Siamashka wrote: ... I would really like to hear something from Nokia regarding this problem. There may be a few other devices with faulty memory considering some browser crash reports, reboots and instability for some people, a possible example can be seen here (though the reporter did not run the memory test as adviced): https://garage.maemo.org/tracker/index.php?func=detailaid=84group_id=54atid=269 That's not a tragedy and software solution can probably resolve this problem. As you know, bad blocks are common for flash and jffs2 file system handles this issue. RAM can be probably treated in a similar way by using something like BadRAM kernel patch [2] We have noticed your e-mail and tried to reproduce the corruption, but still without success. I myself have noticed an apparent JFFS2 corruption once, but that too was not reproducible (and could have been caused by RAM). So, it's unclear yet if it is a software or hardware problem. BR, Kimmo [1] http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf [2] http://rick.vanrein.org/linux/badram/ ___ 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
Re: [maemo-developers] defective memory? (was: problem with dspmp3sink)
Kimmo Hämäläinen wrote: So, it's unclear yet if it is a software or hardware problem. Just few ideas: software - bug is swapping/pagefault code?, bad ram timings?, too high CPU clock? hardware - high power requirements - does it happen more when brightness is high or mem tester is run in ssh over wi-fi? Just tried with no application running, 20MB run fine, 30MB run very slow so it was probably swapping to card a lot. Turned off swap and could go only to 25MB. Test went fine, no errors. Done over bluetooth connection with full brightess on, battery almost full. Will try when battery is low (over wi-fi at home). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] defective memory? (was: problem with dspmp3sink)
On Tue, Sep 19, 2006 at 03:06:47AM +0300, Siarhei Siamashka wrote: I would really like to hear something from Nokia regarding this problem. There may be a few other devices with faulty memory considering some browser crash reports, reboots and instability for some people, a possible example can be seen here (though the reporter did not run the memory test as adviced): https://garage.maemo.org/tracker/index.php?func=detailaid=84group_id=54atid=269 I have experienced a nondeterministic segfault of a command-line application once: http://maemo.org/pipermail/maemo-developers/2006-August/005370.html Also, maemo_af_desktop crashes every now and then (/var/lib/dsme/lifeguard-resets tells me it crashed 35 times already), but this may be the fault of a buggy statusbar applet (I've osso-statusbar-cpu installed) rather than bad RAM. I'll try to find some time to run your version of memtester. Marius Gedminas -- This sentence does in fact not have the property it claims not to have. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Launching browser at startup
On Tue, 2006-09-19 at 12:54, ext Kalle Vahlman wrote: ... As you'll want it to run as user not root, you might want to add it to /etc/osso-af-init/ and edit real-af-base-apps to run the script so you'll get the environment setup for free. You can look at the other scripts there for examples. That seems to be the place but that script system sure is package manager unfriendly. Of course. It's not designed (period ;) to be a general user-configurable startup system. I didn't want that feature, because it would have been exploited by our internal developers (people would have added scripts there from all directions and nobody could be responsible of the outcome). But you are free to do as /etc/init.d/maemo-launcher: source /etc/osso-af-init/af-defines.sh and run the program as the 'user' user. BR, Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] defective memory?
Siarhei Siamashka wrote: On 9/19/06, Frantisek Dufka wrote: Just few ideas: software - bug is swapping/pagefault code?, bad ram timings?, too high CPU clock? That's an interesting idea, It seems to be worth trying to downclock the device and check if it improves stability. Does anybody know how to do this? Anybody is me, you forgot cc to the list. I think there is some table with clocks in kernel source. Some board specific file related to n770. I think there is some constant like 25000. request 40MB too early, it will fail. Did you run memtester with my last patch? It contains this gradually increasing allocation size trick automatically, so you don't need to run memtester many times and can specify 40MB at once. Yes, it starts at 20 and goes slowly up. But still 25 were the limit. After reboot 40MB is really possible (no error again). I was not runing anything special before reboot so that 15MB difference is strange. Surely it would be much better if memtester could access (almost) all the physical memory at once. Otherwise it can't provide reliable and trustworthy results. Probably boot time memtester similar to memtest86 that runs before the system loads can do this work best, but I wonder if it is easy to access framebuffer to print some results from it. Check /mnt/initfs/linuxrc source. There is text2screen binary or you can probably enable framebuffer console in kernel. Also when you install the BootMenu you can play with replacing /sbin/init or init scripts on mmc card and boot from it. In fact if you compile memtester as uclibc binary it can be included in initfs image and run without mounting rootfs. text2screen can display only parameters but it is not so hard to wrap it in 'for' loop in shell while reading file. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: [maemo-users] Flash to 2006 trouble
Hi, I was able to get Osso Xterm from the repository listed there installed, I had trouble with Osso Xterm (advanced) though I don't remember any more if it was a dependency problem or the Unable to install. Incompatible package. Usually it seems to say Incompatible package if the package Section is something else than user. Those packages you can install from the command line with dpkg -i. You can kludge around this by extracting the package contents: ar x package.deb Editing the control file Section field and repackaging the file: ar c package.deb control.tar.gz data.tar.gz debian-binary If the package has dependencies not present on the device you need repository that contains those dependencies. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] RE: defective memory?
On 9/19/06, Kimmo Hämäläinen [EMAIL PROTECTED] wrote: Yes, it would need to be reproducible in several different devices. The guy here that tried to reproduce it currently thinks that Siarhei's unit is broken. Yes, I also think that the probability of my device being broken is quite high. A certain (small) fraction of other Nokia 770 owners are probably having the same problem. Does it make the device completely useless? Of course no, my device works almost fine, it only crashes and reboots sometimes, I also has filesystem corruption several times (now even switched mmc filesystem to ext3, don't know if it would help much though). So the device can be surely used as a book reader, internet browser and serve other tasks. Other (small) fraction of users who got 'white screen of death' were surely less lucky. What can be done about this if the defective memory problem gets confirmed. I see three possible ways: 1. 'Ignorance is a bliss' - just do nothing, those who don't know about the problem will not worry about it :) The device will just crash or reboot occasionally, some more unlucky users having more annoying crashes will complain in the forums providing some bad PR. 2. Distribute some diagnostics software that will help to identify memory problems and repair/replace defective units, that will have some expences, but will improve overall reliability and reduce the number of negative publicity. 3. Add some (un)official support for working around bad memory regions using technology something similar to BadRAM, in this case most of such units will be completely usable. In general, bad memory problem is quite common for x86 pc's, but there is an excellent tool for memory diagnostics - memtest86. It helped me quite a number of times, also I always advice everyone having stability issues to run it first. I don't know how the reliability of memory chips used in embedded devices compares to the reliability of memory from normal desktop computers, but bad memory seems to be one of the most frequently encountered hardware problems. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: [maemo-users] Flash to 2006 trouble
Eero Tamminen wrote: I was able to get Osso Xterm from the repository listed there installed, I had trouble with Osso Xterm (advanced) though I don't remember any more if it was a dependency problem or the Unable to install. Incompatible package. Usually it seems to say Incompatible package if the package Section is something else than user. Those packages you can install from the command line with dpkg -i. But bear in mind that if one is trying to install something lots of people have already installed (xterm in this case) it's probably more likely to actually be the wrong package--and who knows how kludgy-fixes would break things. :-) --Phil. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] API of the DSP's avs_kernel
Hello, I'm playing a bit with the N770 DSP (I may write an Ogg Vorbis codec if I have the time), and I'd like to use the sound output. I figured out that hardware access was through avs_kernel, but apparently its API is not documented anywhere on the web. Does anyone have more information ? So far, I can compile and run code on the DSP (using the info from http://maemo.org/pipermail/maemo-developers/2006-January/002607.html) ; and I've disassembled avs_kernel a bit to get an idea of the API, and I have managed to power up the AIC23 audio chip (printing aic23 powering up and aic23_init_power() done in the dmesg) from the DSP by calling a function in avs_kernel. But concerning more advanced functions (audio streaming, ...) the API is quite a pain to figure out from disassembler output. Regards, Sebastien ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: [maemo-users] No windows-1252 support?
Marius Gedminas a écrit : Sometimes I get to edit text files encoded in Windows-1252 (a Latin-1 variant commonly used on Windows systems). I was very surprised when I discovered that iconv on the 770 does not support this encoding. iconv -l lists a bunch of names in the 125x series, except for 1252. I suppose I'd have to recompile libc6 to get cp1252 support? I've compiled vim 7.0 with the +encodings feature, but it uses the system iconv library, so it doesn't support cp1252 either. What is somewhat more fun: recode is present on the 770, and recode -l claims to support 1252, but recode 1252..UTF-8 filename.txt instead of recoding the text, erases it completely. Bug filed: https://maemo.org/bugzilla/show_bug.cgi?id=766 Marius Gedminas I have already filed a bug for that problem on 2006-08-30 and no response yet https://maemo.org/bugzilla/show_bug.cgi?id=752 (feel free to vote for it) You can use the same hack I use for Streamtuner (feel free to look how I deal with that in SVN https://garage.maemo.org/scm/?group_id=41) This hack will make your binary one mega bigger (size of libiconv_plug.so) ... I hope that in the next release libc6 will be recompiled with 1252 support to avoid bad hack like this. I cc this to maemo-developers which is a better place to talk about that. Olivier ROLAND ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RE: defective memory?
Siarhei Siamashka a écrit : On 9/19/06, Kimmo Hämäläinen [EMAIL PROTECTED] wrote: Yes, it would need to be reproducible in several different devices. The guy here that tried to reproduce it currently thinks that Siarhei's unit is broken. Yes, I also think that the probability of my device being broken is quite high. A certain (small) fraction of other Nokia 770 owners are probably having the same problem. Does it make the device completely useless? Of course no, my device works almost fine, it only crashes and reboots sometimes, I also has filesystem corruption several times (now even switched mmc filesystem to ext3, don't know if it would help much though). So the device can be surely used as a book reader, internet browser and serve other tasks. Other (small) fraction of users who got 'white screen of death' were surely less lucky. What can be done about this if the defective memory problem gets confirmed. I see three possible ways: 1. 'Ignorance is a bliss' - just do nothing, those who don't know about the problem will not worry about it :) The device will just crash or reboot occasionally, some more unlucky users having more annoying crashes will complain in the forums providing some bad PR. 2. Distribute some diagnostics software that will help to identify memory problems and repair/replace defective units, that will have some expences, but will improve overall reliability and reduce the number of negative publicity. 3. Add some (un)official support for working around bad memory regions using technology something similar to BadRAM, in this case most of such units will be completely usable. In general, bad memory problem is quite common for x86 pc's, but there is an excellent tool for memory diagnostics - memtest86. It helped me quite a number of times, also I always advice everyone having stability issues to run it first. I don't know how the reliability of memory chips used in embedded devices compares to the reliability of memory from normal desktop computers, but bad memory seems to be one of the most frequently encountered hardware problems. If your device is broken then mine is also. I don't think at all that we speak about (small) fraction because majority of users won't even notice the problem. My device seem stable until I stressed it. And stressed it is not a condition suffisante to make the problem happen. When I have time, I will make extensive test on my device to check exactly when the problem occur. My doubt about small fraction are probably driven by the fact that I was hit by 'white screen of death' 4 weeks after buying the device. So I guess that during the reparation my 770 was checked (again) by the conventional Nokia diagnostic. I conclude that the conventional Nokia diagnostic doesn't detect the problem. To make things clear, I don't want to make negative publicity at all. I enjoy this device a lot and I've ported Streamtuner on it with lot of great feedback from users. My 2 cents. PS: I don't know what is the conventional Nokia diagnostic but as far as I know there is always a conventional XXX diagnostic in reparation centers. Olivier ROLAND ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Garage website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferenc Szekely wrote: Hello, ext Kees Jongenburger wrote: On 9/17/06, Olivier ROLAND [EMAIL PROTECTED] wrote: Greg Morgan a écrit : Umm...so I looked. I don't see how to change a project's web page via the gForge/Garage web interface. Is this done another way such as ssh [EMAIL PROTECTED] If so, would someone please point me to the ssh URL? Hello Greg, I had the same problem, and i took me a while to realize that this was simply not possible (yet?). I really think that not having a website this is a big missing feature, specially if there is a link to the website telling the user that the developer has not yet created a website. On the other hand It is possible to create a wiki, but this does not help in publishing api docs or screen shots. Every garage project can maintain static web pages (ie. no scripting, CGIs etc). The only thing they need is to have a 'www' directory in their subversion root. The content of 'www' will be published automatically to the project's home area, similar to this: http://puchi.garage.maemo.org/ Regards, Ferenc Thanks Ferenc. It works great. You can see the mess I made getting started here https://garage.maemo.org/plugins/scmsvn/viewcvs.php/?root=m770cias . Some notes on how to make a mess have been started here http://www.maemo.org/maemowiki/MaemoGarageStartUp ;-) Regards, Greg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFELdWxyxe5L6mr7IRAlf9AJ9rXNzgYEsWvlN2WY5DsqYfjxNPHwCeO+Xw xghTYeEkYObumq5SshyhD0A= =SrFs -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RE: defective memory?
On Wednesday 20 September 2006 01:12, Olivier ROLAND wrote: If your device is broken then mine is also. I don't think at all that we speak about (small) fraction because majority of users won't even notice the problem. My device seem stable until I stressed it. And stressed it is not a condition suffisante to make the problem happen. That's exactly the point. The device is quite usable and most users will not detect any difference on most common operations. It is a very good sign as looks like in order to get rock solid stability, we only need to allocate and lock the problematic memory page early at boot time and do not let any applications use it. When I have time, I will make extensive test on my device to check exactly when the problem occur. Please do it, now with the lastest version of the tester and 40MB tested block, the coverage is almost 2/3 of physical memory. If that's a certain location in memory, the chances that it can be easily detected are quite high. Please verify that the offset of faulty address within 1KB page is reported to be always the same between different runs (it is equal to 1a5 for me). I'm trying to find a way to get a full physical address of that page. In my last tests I managed to mmap '/dev/mem' (just using 'read' function segfaults), but did not have enough time to experiment with it much yet. My doubt about small fraction are probably driven by the fact that I was hit by 'white screen of death' 4 weeks after buying the device. So I guess that during the reparation my 770 was checked (again) by the conventional Nokia diagnostic. I conclude that the conventional Nokia diagnostic doesn't detect the problem. To make things clear, I don't want to make negative publicity at all. I enjoy this device a lot and I've ported Streamtuner on it with lot of great feedback from users. My 2 cents. I don't want to make negative publicity either. My only goal now is to find some reliable technical solution for both diagnostics and workaround of such problems. After all, I have a good motivation for that :) I'm grateful to Nokia as they are also trying to investigate the problem. I'm quite confident that we can come up with some solution, and it will have some positive effect for Nokia 770 community as a result. This is a new device, software and tools for it are still being developed. We are all learning and getting more experience. PS: I don't know what is the conventional Nokia diagnostic but as far as I know there is always a conventional XXX diagnostic in reparation centers. By the way, when looking for additional information I found some Sharp Zaurus community forum and asked what they use for hardware diagnostics in the hope that I could use the same tools. Somebody replied me that hardware diagnostics tools are built in Zaurus firmware and are accessible from boot menu. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers