On 8/11/08, Pawel Kowalak [EMAIL PROTECTED] wrote:
It's not that easy. But IIRC somebody on OLPC tracker stated that
this problem no longer occurs in 2.4.26. We'll see when Andy switch
us to 2.4.26 ;)
That was me. OLPC is on 2.6.25 BTW, perhaps with upstream patches.
I also posted a
The trick may work. But I'm not sure booting from an SD works if the
first partition is a swap partition (as opposed to the vfat parition
it expects). Can you boot from SD with your setup? Or is that not
something you mess with?
-Steven
On Tue, Aug 12, 2008 at 1:27 PM, Andrew Burgess [EMAIL
It didn't occur to me to mount the card ro, but I will try it and see
if it helps.
not sure if it will help -- but why not unmount the sd card on suspend and
remount on resume?
___
Openmoko community mailing list
community@lists.openmoko.org
On Mon, Aug 11, 2008 at 12:00 PM, arne anka [EMAIL PROTECTED] wrote:
not sure if it will help -- but why not unmount the sd card on suspend and
remount on resume?
What if you've got some processes running of that SD card? You'll need
to kill them before unmounting the card.
And then, your
What if you've got some processes running of that SD card? You'll need
to kill them before unmounting the card.
we're speaking of a workaround, do we?
And then, your suspendresume will look more and more like
shutdownrestart.
why, atm it looks more like shutdown reinstall ...
On Aug 11, 2008, at 12:00 PM, arne anka wrote:
It didn't occur to me to mount the card ro, but I will try it and see
if it helps.
not sure if it will help -- but why not unmount the sd card on
suspend and
remount on resume?
It's not that easy. But IIRC somebody on OLPC tracker stated
I did try this. It doesn't help.
I added little scripts to /etc/apm/suspend.d and /etc/apm/resume.d.
Unless there's someplace else those should be.
I did find that slowing the SD clock (per ticket #1743 about the
Intenso SD card issue) had a positive effect. Kinda. See
I might've spoken too soon. I think it does help to unmout/remount.
I just noticed that the reason/method of the resume has an effect on
this issue. In my debugging, I added scripts to /etc/apm/suspend.d/
and /etc/apm/resume.d/ that would unmount and remount my partitions.
This didn't seem to
On Sun, Aug 10, 2008 at 11:12 AM, Yaroslav Halchenko site-openmoko.org@
onerussian.com wrote:
well -- correct me if I am wrong, but the irony of the situation is that
suspend/wakeup is handled by the kernel, and qtopia images use stock
kernel from OM. Thus whatever suspend/resume achievements
For reference, the Qtopia 4.32-080808 uses the kernel named
uImage-2.6.24+git30+436204281bcd1fe5999ad6589ea7ab1b5360c352-r2-om-gta0
2.bin
Ok, so I don't know what that really long name means or who wrote it .
:-) No one confirmed Yaroslav or corrected him either so this is
well -- correct me if I am wrong, but the irony of the situation is that
suspend/wakeup is handled by the kernel, and qtopia images use stock
kernel from OM. Thus whatever suspend/resume achievements you see - they
are solely due to OM developers.
qtopia relevant pros though: call/receive after
On Sun, 10 Aug 2008 13:12:36 -0400
Yaroslav Halchenko [EMAIL PROTECTED] wrote:
well -- correct me if I am wrong, but the irony of the situation is that
suspend/wakeup is handled by the kernel, and qtopia images use stock
kernel from OM. Thus whatever suspend/resume achievements you see - they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
| On Sun, 10 Aug 2008 13:12:36 -0400
| Yaroslav Halchenko [EMAIL PROTECTED] wrote:
|
| well -- correct me if I am wrong, but the irony of the situation is that
| suspend/wakeup is handled by the kernel, and
Yaroslav Halchenko wrote:
qtopia has 1 very annoying to me issue though -- if I receive a phone
call, and click on answer button -- it takes 2-4 seconds for the phone
to actually react -- thus I often lost some phone calls which is
annoying.
well... part of the problem is that the hangup
There is another problem that seems to plague not just all the OM
kernels but other projects (OLPC in particular, who have been trying
to solve this issue for a couple months) - the SD card partition being
trashed after a suspend/resume cycle.
My assumption is that this a problem with the Linux
I didn't track those -- is is trashed regardless if partition is mounted
read/only or read/write? I would assume that it should be safe in
read-only mount, thus just (re)mount your SD read-only and be happy
listening to the music ;-)
On Sun, 10 Aug 2008, Craig B. Allen wrote:
So while it's a
On Sun, Aug 10, 2008 at 5:45 PM, Yaroslav Halchenko
[EMAIL PROTECTED] wrote:
I didn't track those -- is is trashed regardless if partition is mounted
read/only or read/write? I would assume that it should be safe in
read-only mount, thus just (re)mount your SD read-only and be happy
listening
This problem has been around for ages, I remember when I was using
Linux on my iPaq H6315, the devs had the same problem. A quick
workaround was that they did not suspend the SD controller. Not
optimal, sure, but it seemed to work. What about calling sync before
suspend?
Cheers,
Federico
On Sun,
18 matches
Mail list logo
