[ltp] APMD and Standby on the TP-T21

D. Sen linux-thinkpad@www.bm-soft.com
Mon, 12 Mar 2001 00:39:05 -0500


I finally found some time to look at arch/i386/kernel/apm.c...(kernel 2.4.2). The
relevant code to receive the SYSTEM STANDBY event would seem to be in the
check_events function. I added some printk functions to detect APM events. The
BIOS never seems to send a SYSTEM_STANDBY notices to the kernel. So, this
vindicates my suspicion that the apmd_proxy function is really never called for a
Fn+F3 key-press.

I need to look further to see if I can find a solution to my more important "hda:
lost interrupt" problem in the event of a resume from standby event.


Here is the function (with my printk statements):

static void check_events(void)
{
 apm_event_t  event;
 static unsigned long last_resume;
 static int  ignore_bounce;

 while ((event = get_event()) != 0) {
  if (debug) {
   if (event <= NR_APM_EVENT_NAME)
    printk(KERN_DEBUG "apm: received %s notify\n",
           apm_event_name[event - 1]);
   else
    printk(KERN_DEBUG "apm: received unknown "
           "event 0x%02x\n", event);
  }
  if (ignore_bounce
      && ((jiffies - last_resume) > bounce_interval))
   ignore_bounce = 0;
  if (ignore_normal_resume && (event != APM_NORMAL_RESUME))
   ignore_normal_resume = 0;

  switch (event) {
  case APM_SYS_STANDBY:
   printk("apm: received SYS_STANDBY\n"); //DS added
  case APM_USER_STANDBY:
   printk("apm: received USER_STANDBY\n"); //DS added
   if (send_event(event)) {
    queue_event(event, NULL);
    if (standbys_pending <= 0)
     standby();
   }
   break;

  case APM_USER_SUSPEND:
   printk("apm: received USER_SUSPEND\n"); /DS added
#ifdef CONFIG_APM_IGNORE_USER_SUSPEND
   if (apm_info.connection_version > 0x100)
    apm_set_power_state(APM_STATE_REJECT);
   break;
#endif
  case APM_SYS_SUSPEND:
   printk("apm: received SYS_SUSPEND\n"); //DS added
   if (ignore_bounce) {
    if (apm_info.connection_version > 0x100)
     apm_set_power_state(APM_STATE_REJECT);
    break;
   }
   /*
    * If we are already processing a SUSPEND,
    * then further SUSPEND events from the BIOS
    * will be ignored.  We also return here to
    * cope with the fact that the Thinkpads keep
    * sending a SUSPEND event until something else
    * happens!
    */
   if (waiting_for_resume)
    return;
   if (send_event(event)) {
    queue_event(event, NULL);
    waiting_for_resume = 1;
    if (suspends_pending <= 0)
     (void) suspend();
   }
   break;

  case APM_NORMAL_RESUME:
   printk("apm: received NORMAL_RESUME\n"); //DS added
  case APM_CRITICAL_RESUME:
   printk("apm: received CRITICAL_RESUME\n"); //DS added
  case APM_STANDBY_RESUME:
   printk("apm: received STANDBY_RESUME\n"); //DS added
   waiting_for_resume = 0;
   last_resume = jiffies;
   ignore_bounce = 1;
   if ((event != APM_NORMAL_RESUME)
       || (ignore_normal_resume == 0)) {
    set_time();
    send_event(event);
    queue_event(event, NULL);
   }
   break;

  case APM_CAPABILITY_CHANGE:
   printk("apm: received CAPABILITY_CHANGE\n"); //DS added
  case APM_LOW_BATTERY:
   printk("apm: received LOW_BATTERY\n");
  case APM_POWER_STATUS_CHANGE:
   printk("apm: received POWER_STATUS_CHANGE\n"); /DS added
   send_event(event);
   queue_event(event, NULL);
   break;

  case APM_UPDATE_TIME:
    printk("apm: received UPDATE_TIME\n"); //DS added
   set_time();
   break;

  case APM_CRITICAL_SUSPEND:
   printk("apm: received CRITICAL_SUSPEND\n"); //DS added
   send_event(event);
   /*
    * We can only hope it worked - we are not allowed
    * to reject a critical suspend.
    */
   (void) suspend();
   break;
  }
 }
}


Thomas Hood wrote:

> I suggest you read arch/i386/kernel/apm.c to see how
> the apm driver handles system standbys.  I'll look myself
> once I get home to my ThinkPad.  If it sends out system
> standby notifications then the problem must be in apmd.
>
> Thomas
>
> --- "D. Sen" <dsen@research.att.com> wrote:
> > Thomas Hood wrote:
> > > > *However*, in my machine 2c doesnt seem to be happening for the Fn+F3
> > (tpctl
> > > > --standby) case. apmd_script is called but without the "standby
> > user/system"
> > > > parameters. So, I dont have control over what commands are called before
> > > > standby for that sequence.
> > >
> > > That sounds like a problem I had with the original apmd_proxy
> > > script shipped with apmd 3.0final in Debian.  For some strange
> > > reason the apmd maintainer wrote the apmd_proxy script so that
> > > it would ignore system suspends while the machine was on AC
> > > power.  I reported this as a bug and the maintainer replied
> > > that he found this "feature" useful, but he agreed that it
> > > should be disable-able and shouldn't be the default.  However
> > > he hasn't uploaded a new version of the apmd package with
> > > the change.  I was able to remove the "reject the suspend
> > > if it's a system suspend and we're on AC power" bit of code
> > > from apmd_proxy myself, quite easily.
> >
> > Nope, its definitely *not* the apmd_proxy script. I modified the script to
> > log the
> > parameters its receiving from apmd. I see things like "suspend system",
> > "suspend
> > user", "start", "stop", "resume suspend"......but *never* a "standby system".
> > I do
> > see "standby user" for when I run apm -S.  Either apmd is ignoring the
> > "standy
> > system" event or the APM BIOS isnt doing things right in the first place.
> >
> > >
> > >
> > > > Thats the first problem. The second is that even if I did have control
> > over
> > > > the commands, (as in (1) with the apm -S command), I still see 'hda: lost
> > > > interrupt" unless I use 'cardctl eject' before the machine is put on
> > standby.
> > >
> > > Probably what is going wrong is that a device driver is being
> > > suspended before apmd_proxy is able to do the "cardctl eject",
> > > resulting in the error message.  If it's a pcmcia device driver
> > > that's causing the problem then the proper way to get a
> > > "cardctl eject" is not to put this command in the apmd_proxy
> > > script but to set APM=eject in /etc/pcmcia/apm.opts .
> > >
> >
> > Well, during a standby event I *dont want* a cardctl eject. (I do want a
> > 'cardctl
> > eject' for suspend but this is not where the problem lies). However, unless I
> > do a
> > 'cardctl eject' with my standby, I see the "hda: lost interrupt" message.
> >
> > DS
> >
> > >
> > > Thomas
> > >
> > > ____________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> > > or your free @yahoo.ie address at http://mail.yahoo.ie
> > >
> > > ----- The Linux ThinkPad mailing list -----
> > > The linux-thinkpad mailing list home page is at:
> > > http://www.bm-soft.com/~bm/tp_mailing.html
> >
> > --
> > D. Sen, Room E167
> > AT&T Labs-Research
> > Shannon Laboratory
> > 180 Park Ave.
> > Florham Park NJ 07932-0971
> > Ph: 973-360-8546
> > http://www.research.att.com/~dsen
> >
> >
> >
> > ----- The Linux ThinkPad mailing list -----
> > The linux-thinkpad mailing list home page is at:
> > http://www.bm-soft.com/~bm/tp_mailing.html
>
> ____________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> or your free @yahoo.ie address at http://mail.yahoo.ie
>
> ----- The Linux ThinkPad mailing list -----
> The linux-thinkpad mailing list home page is at:
> http://www.bm-soft.com/~bm/tp_mailing.html

--
D. Sen, Room E167
AT&T Labs-Research
Shannon Laboratory
180 Park Ave.
Florham Park NJ 07932-0971
Ph: 973-360-8546
http://www.research.att.com/~dsen



----- The Linux ThinkPad mailing list -----
The linux-thinkpad mailing list home page is at:
http://www.bm-soft.com/~bm/tp_mailing.html