[REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Charles Lepple]

Summary of tested versions:

Version          APM Works?
2.4.18-24.8.0    yes
2.4.20-18.9      yes
2.4.21           yes
2.5.26           yes
2.5.30           yes
2.5.31           yes
2.5.32           no
2.5.35           no
2.5.40           no
2.5.45           no
2.5.63           no
2.5.66           no
2.6.0test1       no
2.6.0test2       no

Removing AC power (suggested by Thomas Hood) did not make suspend work on
the later versions.

Also, when a PCMCIA card is active, and suspend is attempted (under a
working version), the computer would respond with a high-low tone
sequence.

With the later versions, the only indication is a blinking suspend light
(blinks for 30-60 seconds; sometimes the console blanks during this
period) and the subsequent "Unable to enter requested state" message on
the console.

I found some possibly relevant changes in arch/i386/kernel/apm.c:

http://linus.bkbits.net:8080/linux-2.5/diffs/arch/i386/kernel/apm.c@1.36?nav=index.html|src/|src/arch|src/arch/i386|src/arch/i386/kernel|hist/arch/i386/kernel/apm.c

but I am not very familiar with the APM calling conventions, or what the
end effect of these changes is.

Thanks in advance.

---------------------------- Original Message ----------------------------
Subject: "apm: suspend: Unable to enter requested state" in
2.5.x/2.6.0test1 From:    "Charles Lepple" <clepple@ghz.cc>
Date:    Mon, July 21, 2003 11:14 am
To:      linux-kernel@vger.kernel.org
--------------------------------------------------------------------------

I have a ThinkPad 770, and under 2.4.x (including .21 and several RedHat
.18-x kernels, FWIW), it would suspend and even hibernate nicely (if all
PCMCIA cards were removed).

In 2.5.x (where x > 66, and maybe earlier) and 2.6.0test1, the machine
doesn't suspend. If I either press the suspend hotkey (Fn-F4), close the
lid, or invoke "apm --suspend", the suspend LED starts to blink, and I get
these messages:

Jul 19 10:46:32 lemur apmd[587]: System Suspend
Jul 19 10:46:52 lemur kernel: uhci-hcd 00:01.2: suspend to state 3 Jul 19
10:46:52 lemur kernel: apm: suspend: Unable to enter requested state

followed by a few beeps, and then the LEDs indicate a non-suspended state.
After a couple of seconds, the screen returns to normal.

Here are the powr mgmt configuration options I used for 2.6.0test1:

  # Power management options (ACPI, APM)
  #
  CONFIG_PM=y
  # CONFIG_SOFTWARE_SUSPEND is not set

  #
  # ACPI Support
  #
  # CONFIG_ACPI is not set
  CONFIG_APM=m
  # CONFIG_APM_IGNORE_USER_SUSPEND is not set
  CONFIG_APM_DO_ENABLE=y
  CONFIG_APM_CPU_IDLE=y
  # CONFIG_APM_DISPLAY_BLANK is not set
  # CONFIG_APM_RTC_IS_GMT is not set
  # CONFIG_APM_ALLOW_INTS is not set
  # CONFIG_APM_REAL_MODE_POWER_OFF is not set

CONFIG_APM_ALLOW_INTS doesn't seem to matter, as the APM code detects that
it is an IBM machine, and enables interrupts during APM calls
unconditionally:

  lemur:~$ dmesg|grep -iw apm
  IBM machine detected. Enabling interrupts during APM calls.
  apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16)

I have diddled with a few of the other options with no noticeable effect.
Also, I have tried reducing the number of loaded drivers (booting
single-user, not loading any modules but those needed for disk and console
I/O).

As time permits, I will try and test this on other kernel versions.
However, I feel like I am poking around in the dark. Any ideas as to what
may be preventing suspend from working? I'm not too familiar with the
details of APM, but my impression was that APM is BIOS-driven. So there
should not be any random device drivers preventing suspend (as could
happen with ACPI), right?

ACPI doesn't even work with this hardware in Win98 or Win2k, (plain 770s;
later 770s supposedly support it) and the latest kernels won't even
attempt to work with it. Otherwise, I'd be bugging the linux-acpi people.

Any advice would be appreciated. I am more than willing to pepper the
kernel APM code with printks if necessary to debug this, but I am going to
need a bit of guidance to do that effectively.

-- 
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/



-- 
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/

Re: [REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Alan Cox]

Does it work any better if you change the 0x0, 0x00409200 to

0x00109300, 0x00409200 ?

Re: [REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Charles Lepple]

Alan Cox said:
> Does it work any better if you change the 0x0, 0x00409200 to
>
> 0x00109300, 0x00409200 ?

Is this what you're referring to?

--- arch/i386/kernel/apm.c.orig 2003-07-27 12:57:00.000000000 -0400
+++ arch/i386/kernel/apm.c      2003-07-29 11:18:52.000000000 -0400
@@ -424,7 +424,7 @@
 static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
 static struct apm_user *       user_list;
 static spinlock_t              user_list_lock = SPIN_LOCK_UNLOCKED;
-static struct desc_struct      bad_bios_desc = { 0, 0x00409200 };
+static struct desc_struct      bad_bios_desc = { 0x00109300, 0x00409200 };
 static char                    driver_version[] = "1.16ac";    /* no
spaces */

I tried this on top of 2.6.0-test2, and it didn't work. Where does the
first number in that initializer come from?

In case it has something to do with the APM entry points:

  apm: entry fcd4:0 cseg16 f000 dseg 9f80 [...]

thanks,

-- 
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/

Re: [REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Alan Cox]

On Maw, 2003-07-29 at 17:05, Charles Lepple wrote:
> > 0x00109300, 0x00409200 ?
> 
> Is this what you're referring to?

Yes

> -static struct desc_struct      bad_bios_desc = { 0, 0x00409200 };
> +static struct desc_struct      bad_bios_desc = { 0x00109300, 0x00409200 };
>  static char                    driver_version[] = "1.16ac";    /* no
> spaces */
> 
> I tried this on top of 2.6.0-test2, and it didn't work. Where does the
> first number in that initializer come from?

I wasnt sure if the kernel code was initialising all the flag and control bits
of the segment entry. That should have set the bits required anyway just in
case if I got it right (Pentium pro dev manual vol III chapter 7)

It might be 0x00009300, it might be set already, or it might be some other
effect thats breaking your laptop of course

Re: [REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Stephen Rothwell]

Hi Charles,

I may have missed this, but do you have the APIC or IO-APIC enabled?

The patch in question merely moved where the 0x40 descriptor was installed
in the descriptor table.

On 29 Jul 2003 19:10:42 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > -static struct desc_struct      bad_bios_desc = { 0, 0x00409200 };
> > +static struct desc_struct      bad_bios_desc = { 0x00109300, 0x00409200 };
> >  static char                    driver_version[] = "1.16ac";    /* no
> > spaces */
> > 
> > I tried this on top of 2.6.0-test2, and it didn't work. Where does the
> > first number in that initializer come from?
> 
> I wasnt sure if the kernel code was initialising all the flag and control bits
> of the segment entry. That should have set the bits required anyway just in
> case if I got it right (Pentium pro dev manual vol III chapter 7)
> 
> It might be 0x00009300, it might be set already, or it might be some other
> effect thats breaking your laptop of course

The 0 above initialises the base and limit parts of the descriptor and
should be zero as it is filled in later (or should be).

The 0x00409200 means this is a byte granularity (0x800000 not present)
32-bit (0x400000) present (0x8000) memory (0x1000) read/write (0x200)
descriptor.  The 32-bit part should be irrelevent as this descriptor
should only be loaded into the DS register (that bit only affect code and
stack segments).

The base and limit parts of the descriptor get initialised at run time by
the code:

	set_base(bad_bios_desc, __va((unsigned long)0x40 << 4));
	_set_limit((char *)&bad_bios_desc, 4095 - (0x40 << 4));

These could be set statically, but it was easier to use the availble
macros.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: [REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Charles Lepple]

On Tuesday, July 29, 2003, at 09:05  PM, Stephen Rothwell wrote:

> I may have missed this, but do you have the APIC or IO-APIC enabled?

Not sure that I have one on this system... it's pre-i686 (Pentium MMX).

I left the laptop at work, so I don't have dmesg output nearby.

> The patch in question merely moved where the 0x40 descriptor was 
> installed
> in the descriptor table.

You mean it appears at a different table index? For some reason, I 
thought that was a different patch (but I can't seem to find anything 
else from that time period).

[snip]
> The base and limit parts of the descriptor get initialised at run time 
> by
> the code:
>
> 	set_base(bad_bios_desc, __va((unsigned long)0x40 << 4));
> 	_set_limit((char *)&bad_bios_desc, 4095 - (0x40 << 4));
>
> These could be set statically, but it was easier to use the availble
> macros.

Do you think it's worth checking the initialized value of the 
bad_bios_desc fields in a 2.5 kernel with working APM? Or do you have 
any other ideas on where to look?

thanks for taking the time to explain this,

-- 
Charles Lepple <ghz.cc!clepple>
http://www.ghz.cc/charles/

Re: [REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Stephen Rothwell]

On Tue, 29 Jul 2003 21:38:25 -0400 Charles Lepple <clepple@ghz.cc> wrote:
>
> On Tuesday, July 29, 2003, at 09:05  PM, Stephen Rothwell wrote:
> 
> > I may have missed this, but do you have the APIC or IO-APIC enabled?
> 
> Not sure that I have one on this system... it's pre-i686 (Pentium MMX).

OK.

> > The patch in question merely moved where the 0x40 descriptor was 
> > installed
> > in the descriptor table.
> 
> You mean it appears at a different table index? For some reason, I 
> thought that was a different patch (but I can't seem to find anything 
> else from that time period).

I meant that it puts it on the same place in the descriptor table, but the
insertion is done for each APM call instead of once at initialisation
time.

> Do you think it's worth checking the initialized value of the 
> bad_bios_desc fields in a 2.5 kernel with working APM? Or do you have 
> any other ideas on where to look?

I have appended two test patches - both are against 2.6.0-test2.

You could see if this matters at all by applying the first patch below. Be
warned, though, that if your BIOS is broken enough to need the
bad_bios_desc workaround, then this change will cause your machine to OOPS
and burn ... :-)

If you get no OOPS from running the above, then you could try the second
patch below. If your machine still behaves the same way, then you have
completely ruled out that change to the apm code ... so we need to look
elsewhere.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

-------------------first patch----------------------------------------
diff -ruN 2.6.0-test2/arch/i386/kernel/apm.c 2.6.0-test2-apm.1/arch/i386/kernel/apm.c
--- 2.6.0-test2/arch/i386/kernel/apm.c	2003-05-27 12:12:46.000000000 +1000
+++ 2.6.0-test2-apm.1/arch/i386/kernel/apm.c	2003-07-30 12:06:30.000000000 +1000
@@ -425,6 +425,7 @@
 static struct apm_user *	user_list;
 static spinlock_t		user_list_lock = SPIN_LOCK_UNLOCKED;
 static struct desc_struct	bad_bios_desc = { 0, 0x00409200 };
+static struct desc_struct	dummy_bios_desc = { 0, 0};
 
 static char			driver_version[] = "1.16ac";	/* no spaces */
 
@@ -601,7 +602,7 @@
 	
 	cpu = get_cpu();
 	save_desc_40 = cpu_gdt_table[cpu][0x40 / 8];
-	cpu_gdt_table[cpu][0x40 / 8] = bad_bios_desc;
+	cpu_gdt_table[cpu][0x40 / 8] = dummy_bios_desc;
 
 	local_save_flags(flags);
 	APM_DO_CLI;
@@ -644,7 +645,7 @@
 	
 	cpu = get_cpu();
 	save_desc_40 = cpu_gdt_table[cpu][0x40 / 8];
-	cpu_gdt_table[cpu][0x40 / 8] = bad_bios_desc;
+	cpu_gdt_table[cpu][0x40 / 8] = dummy_bios_desc;
 
 	local_save_flags(flags);
 	APM_DO_CLI;
-------------------second patch----------------------------------------
diff -ruN 2.6.0-test2/arch/i386/kernel/apm.c 2.6.0-test2-apm.2/arch/i386/kernel/apm.c
--- 2.6.0-test2/arch/i386/kernel/apm.c	2003-05-27 12:12:46.000000000 +1000
+++ 2.6.0-test2-apm.2/arch/i386/kernel/apm.c	2003-07-30 12:14:02.000000000 +1000
@@ -594,23 +594,15 @@
 	APM_DECL_SEGS
 	unsigned long		flags;
 	unsigned long		cpus;
-	int			cpu;
-	struct desc_struct	save_desc_40;
 
 	cpus = apm_save_cpus();
 	
-	cpu = get_cpu();
-	save_desc_40 = cpu_gdt_table[cpu][0x40 / 8];
-	cpu_gdt_table[cpu][0x40 / 8] = bad_bios_desc;
-
 	local_save_flags(flags);
 	APM_DO_CLI;
 	APM_DO_SAVE_SEGS;
 	apm_bios_call_asm(func, ebx_in, ecx_in, eax, ebx, ecx, edx, esi);
 	APM_DO_RESTORE_SEGS;
 	local_irq_restore(flags);
-	cpu_gdt_table[cpu][0x40 / 8] = save_desc_40;
-	put_cpu();
 	apm_restore_cpus(cpus);
 	
 	return *eax & 0xff;
@@ -636,24 +628,16 @@
 	APM_DECL_SEGS
 	unsigned long		flags;
 	unsigned long		cpus;
-	int			cpu;
-	struct desc_struct	save_desc_40;
 
 
 	cpus = apm_save_cpus();
 	
-	cpu = get_cpu();
-	save_desc_40 = cpu_gdt_table[cpu][0x40 / 8];
-	cpu_gdt_table[cpu][0x40 / 8] = bad_bios_desc;
-
 	local_save_flags(flags);
 	APM_DO_CLI;
 	APM_DO_SAVE_SEGS;
 	error = apm_bios_call_simple_asm(func, ebx_in, ecx_in, eax);
 	APM_DO_RESTORE_SEGS;
 	local_irq_restore(flags);
-	cpu_gdt_table[smp_processor_id()][0x40 / 8] = save_desc_40;
-	put_cpu();
 	apm_restore_cpus(cpus);
 	return error;
 }

Re: [REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Alan Cox]

On Mer, 2003-07-30 at 02:05, Stephen Rothwell wrote:
> > It might be 0x00009300, it might be set already, or it might be some other
> > effect thats breaking your laptop of course
> 
> The 0 above initialises the base and limit parts of the descriptor and
> should be zero as it is filled in later (or should be).

I thought the descriptor bits came in the first long word and the 16bit
base/limit in the second ?

Re: [REPOST] "apm: suspend: Unable to enter requested state" after 2.5.31 (incl. 2.6.0testX)

[Stephen Rothwell]

On 30 Jul 2003 15:43:18 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Mer, 2003-07-30 at 02:05, Stephen Rothwell wrote:
> > > It might be 0x00009300, it might be set already, or it might be some other
> > > effect thats breaking your laptop of course
> > 
> > The 0 above initialises the base and limit parts of the descriptor and
> > should be zero as it is filled in later (or should be).
> 
> I thought the descriptor bits came in the first long word and the 16bit
> base/limit in the second ?

Not according to my book ... parts of the base and limit are spread around
in the second long word.

The 2.4 version of this is static in arch/i386/kernel/head.S and looks
like this:

        .quad 0x0040920000000000        /* 0x40 APM set up for bad BIOS's */

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: [REPOST] "apm: suspend: Unable to enter requested state" after2.5.31 (incl. 2.6.0testX)

[Charles Lepple]

Stephen Rothwell said:
> If you get no OOPS from running the above, then you could try the second
> patch below. If your machine still behaves the same way, then you have
> completely ruled out that change to the apm code ... so we need to look
> elsewhere.

I guess it wasn't using that descriptor. The machine behaved the same way
as before when I tested each patch ("unable to enter requested state", and
system comes back to normal).

While experimenting, I noticed something else: in the cases where a system
suspend failed ('apm -s', closing the lid, or activating IBM's hibernate
mode), a 'system standby' request worked. Trying to transition from
standby to suspend does not work, however-- the laptop wakes up, and
eventually prints the same error message as for a normal suspend.

thanks for the patch,

-- 
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/