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
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?
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
[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
[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
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
Re: [maemo-developers] Re: [maemo-users] Flash to 2006 trouble
On Tue, 19 Sep 2006 15:20:10 +0300 Eero Tamminen <[EMAIL PROTECTED]> wrote: > 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". I would also try to look for error messages in the log window. > Those packages you > can install from the command line with "dpkg -i". Or by enabling the "red pill" mode in the application manager, according to http://maemo.org/maemowiki/ApplicationManagerRedPillMode > If the package has dependencies not present on the device > you need repository that contains those dependencies. Marius Gedminas -- America and England are two countries separated by a common language. pgpG1vxPyJ6ES.pgp Description: PGP signature ___ 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
On Tue, 2006-09-19 at 15:20:10 +0300, ext Eero Tamminen wrote: > 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 ITYM ar rcu package.deb debian-binary control.tar.gz data.tar.gz regards, guillem ___ 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] defective memory? (was: problem with dspmp3sink)
On 9/19/06, Frantisek Dufka <[EMAIL PROTECTED]> 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? hardware - high power requirements - does it happen more when brightness is high or mem tester is run in ssh over wi-fi? I run all my tests from ssh run over wi-fi. Will try some other combinations later. 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. The test locks memory immediately after allocation (man mlock), so it should not swap pages out of RAM, and that's why it requires to be run as root. As for memory limits, I tried to explain in one of the prevoious posts, initially the tester can't allocate more than ~20MB of memory. But the next time you launch memtester, it can allocate 25MB, so increasing memory allocation size in small steps allows it to allocate up to 40MB in the end with swap turned off! Probably the system sees that more memory is required and begins to stop some of the unneeded services to free memory (that's just only a guess, did not do much experiments here yet). It can't do that fast, so if you 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. Of course you should not run any other application at the same time :) 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). In my tests this error is also not always reproducible. If I could identify physical address of a bad page (the system should have properly working /dev/mem for this), I could collect some statistics. For example I could check if its physical location is always the same and whether supposedly successful tests did actually allocate this part of memory. 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. One more (weird) idea is to try adding some syscall for allocation of physical memory at any address (moving its original content to some other place if it is occupied), so it would be able to access and test (almost) all the physical memory while running the system at the same time. ___ 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
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
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? (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=detail&aid=84&group_id=54&atid=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
2006/9/18, Michael Wiktowy <[EMAIL PROTECTED]>: On 9/18/06, Kalle Vahlman <[EMAIL PROTECTED]> wrote: > 2006/9/18, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > We are developing a Flash application to run on Nokia 770 devices and we > > would like this application to be launched automatically when the device is > > switched on. How can we launch opera browser (in fullscreen mode) at > > startup? We've tried editing .profile and .ashrc but it does not work. Any > > help would be appreciate. Thank you in advance. Tomàs > > The usual (linux/debian) way of startup scripts are in /etc/init.d and > then a link to /etc/rc2.d (with name like "S99xx"). Actually, that would be the place to put system-wide daemon/services startup scripts that have no UI. And no user UI is launched there either in the desktop world (login managers are not user GUI:s as they don't run as the actual user). In fact, there is no "linux" way to start a user GUI which is not specific to ones session manager, which are abundant and mostly incompatible. There should be a script in there that runs the desktop manager and within the desktop manager there should be mechanisms in place to start things up in a particular users session so that all the proper environment variables and user contexts are set. The rc startup scripts are a very wrong place to put a command to start up the browsers in a user's desktop. .ashrc is also not entirely proper either as that is the script that is fired when an ash shell is started up to get a virtual terminal, AFAIK. Not something that happens automatically at Maemo desktop startup. I would say it's not proper at all to launch GUIs in shell rc:s, but AFAIK maemo-af-desktop doesn't have session management for this kind of purposes. > 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. Other distros typically have a script that will call any script placed in an /etc/something.d/ directory. That way a .deb (or rpm or whatever) can add or remove their hooks into the main startup sequence without having to parse (and possibly corrupt) the main start script. The osso-af-init scripts are called from /etc/init.d/ which are called by init from the links in rc2.d. I only pointed out the af-init-dir as it already is run as 'user' and has th environment set up already. Are there other mechanisms around like this or maybe some gconf-2 variables that can be poked that act on the session level rather than system level? I don't know (of any atleast). Please someone correct me if I'm wrong. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ 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, 2006-09-19 at 11:47, ext Frantisek Dufka wrote: > 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). 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. BR; Kimmo > > Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] libusb dependency problem
When updating Sardine I can't upgrade programs like osso-application-installer and maemo-af-desktop because they depend on libusb-0.1.4>=2:0.1.10a. This version of libusb isn't available in the repository? - Niels ___ 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] Garage website
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 ___ 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, 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=detail&aid=84&group_id=54&atid=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] Garage website
On 9/17/06, Olivier ROLAND <[EMAIL PROTECTED]> wrote: Greg Morgan a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > 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. greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
