APMD-List:
Archives

  From: Avery Pennarun <apenwarr@worldvisions.ca>
  To  : David Brownell <david-b@pacbell.net>
        <apmd-list@worldvisions.ca>
  Date: Thu, 17 Jun 1999 22:59:37 -0400

Re: apmd 3.0beta8 is released

On Thu, Jun 17, 1999 at 04:25:39PM -0700, David Brownell wrote:

> Craig Markwardt wrote:
> > 
> > I agree totally here.  I'm not sure myself why the clock setting logic
> > was in apmd to begin with.  Probably because the kernel code used to
> > lack it.  Can we just comment it out?

If we want to assume everyone is running 2.2 kernels, yes.  I don't think
that's a good assumption, however.  (My laptop isn't :))

It seems to me that at least some 2.0 kernels didn't do the clock update
correctly.  At least, my laptop kept getting the wrong time.  I haven't
checked on that in awhile.

> A quick glance at the kernel BIOS driver suggests it'd merit an
> update first:  it should figure out any time zone delta nearer to
> system initialization time, so that any APM_UPDATE_TIME events
> delivered before the first suspend will be dealt with correctly.

Remember that the delta has to be measured after the system clock has
actually been set correctly and the time zone has been set from userspace. 
Also keep in mind daylight savings time and so on.  It's very dangerous to
NOT record the difference immediately before suspending, and if you're
unlucky, you still mess up with daylight savings time.

However, it's still important to deal with APM_UPDATE_TIME events before
the first suspend.  Maybe link into the kernel clock setting code?

> Anything's possible!  But I'm not convinced there would be any
> problems associated with a sensible default policy; certainly,
> I think there will be fewer problems overall with one that pays
> attention to power management than one that ignores it.  (Unless
> the power management is notably buggy, in which case it'd be a
> fine way to flush and fix the bugs!  ;-)
> 
> That is, why comment it out?  Most users don't edit /etc/ files and
> frankly they shouldn't need to.

I don't really have an opinion on what should be in apmd_proxy by default. 
Most likely, each Linux distribution will roll their own.  Personally I like
the way Debian does it -- the pcmcia tools install an apmd "plug in" that
suspend/resume the cards.  That's why the Debian package has a totally
different apmd_proxy implementation.  By the way, check that one out and see
if you like it.  It's not _really_ Debian-specific.  (It's in the debian/
subdirectory of the source.)

I've heard that some cards respond extremely badly to being suspended.  I
think SCSI cards are one kind.

> >	 What if "cardmgr suspend" causes excessive disk
> > access, which causes the BIOS to reconsider the suspend event?  I
> > think these issues crop up once in awhile.  I was hoping we could put
> > the apmd_proxy on a ramdisk to avoid disk accesses.
> 
> My reading of the APM BIOS spec says that the BIOS concludes it'd
> be a good time to suspend (or standby), and starts the operation.
> Application level code that the BIOS driver talks to is expected to
> do I/O, before it tells the driver to finish the suspend/standby
> (or reject it).

Yeah, I think that's the idea.  But reality doesn't always match the spec :)

My laptop used to refuse to suspend sometimes, especially when apmd is
running.  That hasn't happened in a while.

Have fun,

Avery