9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: [9fans] bitsy bootldr 2.18.1 suspend/resume: the saga continues
Date: Wed, 12 Feb 2003 23:48:56 +0100	[thread overview]
Message-ID: <200302122248.h1CMmuw00550@zamenhof.cs.utwente.nl> (raw)

Just to continue an old thread on suspend/resume problems
with a H 3630 bitsy with bootldr 2.18.1, with some (for me)
new observations, hoping that this gives some inspiration
on the quest to the solution...

As I mentioned before, suspend/resume works ok if I suspend
just a short while (few seconds).

If I suspend (even only once) for a longer period,
it looks like on resume only the screen returns,
with backlight turned off. Also, no input is possible
(no reaction to buttons or touch screen; did not try
 playing audio while suspend/resume).
Also, via the serial cradle I do not see the
'resuming execution' debugging print statement that
should follow the 'entering suspend mode' one - actually
after that I see no debugging output at all.

However, something seems to resume ok, which is new for me.
Just noticed that if I draw a window before suspending,
in which I leave the following running:

  while () { date; sleep 2}

then on resume it continues, with the right time
(longest suspend time I tried was ca. 30 minutes).
Also, the window in which it runs does autoscroll
as usual when the end of the screen is reached
while printing the output.
Also, as usual, the screen is blanked after a period of no
activity (but now I have to suspend/resume to redraw it).

Results are the same with and without double pcmcia sleeve;
when used with sleeve: without (pcmcia) cards in the sleeve
(if I use a wavelan with the double sleeve the bitsy does not
 suspend at all; would not be surprised if that's my fault
 in the double pcmcia code)

So, why this long story?
I did not realise before that programs continued to run,
I thought that the returning screen image was just the
result of a video buffer that survived. Also, I was afraid
that maybe dram refresh during suspend did not work.
However, now seeing that some things do work, I hope that
this (for me) new information may give somebody smart an
intuition of where it may pay off for me to continue looking...

Axel.
(of course I can try the bootldr that is know to work,
 but this is more... err... interesting? :-)


                 reply	other threads:[~2003-02-12 22:48 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200302122248.h1CMmuw00550@zamenhof.cs.utwente.nl \
    --to=axel.belinfante@cs.utwente.nl \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).