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 P
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 wo
>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 i
On Sun, Aug 10, 2008 at 11:12 AM, Yaroslav Halchenko 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
> are solely due
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 ma
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
http://docs.openmoko.org/
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 s
> 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 suspend&resume will look more and more like
> "shutdown&restart".
why, atm it looks more like shutdown & reinstall ...
__
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
> 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
http
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,
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
> liste
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 pl
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 ke
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
-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, an
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 - t
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 re
Hi fellows,
I tested a few minutes ago with my Neo Freerunner the new qtopia image
(4.32-080808) which was released yesterday. And I can report that the suspend
problem is nearly completly fixed:
* I can suspend
* I can wakeup (pressing the startbutton)
* After suspend I can make and recieve call
19 matches
Mail list logo
