2003-08-06 22:15:32

by Russell King

[permalink] [raw]
Subject: 2.6.0-test2: unable to suspend (APM)

Hi,

I'm trying to test out APM on my laptop (in order to test some PCMCIA
changes), but I'm hitting a brick wall. I've added the device_suspend()
calls for the SAVE_STATE, DISABLE and the corresponding device_resume()
calls into apm's suspend() function. (this is needed so that PCI
devices receive their notifications.)

However, APM is refusing to suspend. I'm seeing the following kernel
messages:

Suspending devices
hdb: start_power_step(step: 0)
hdb: completing PM request, suspend
hda: start_power_step(step: 0)
hda: start_power_step(step: 1)
hda: complete_power_step(step: 1, stat: 50, err: 0)
hda: completing PM request, suspend
Suspending devices
Suspending devices
apm: suspend: Unable to enter requested state
Devices Resumed
hda: Wakeup request inited, waiting for !BSY...
hda: start_power_step(step: 1000)
blk: queue c03a845c, I/O limit 4095Mb (mask 0xffffffff)
hda: completing PM request, resume
hdb: Wakeup request inited, waiting for !BSY...
hdb: start_power_step(step: 1000)
hdb: completing PM request, resume
Devices Resumed
Devices Resumed

The "apm: suspend: Unable to enter requested state" occurs about 20
seconds afterwards.

(Note that APM worked fine with 2.2 and 2.4 kernels.)

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html


2003-08-07 02:48:04

by Charles Lepple

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

Russell King wrote:

> I'm trying to test out APM on my laptop (in order to test some PCMCIA
> changes), but I'm hitting a brick wall. I've added the device_suspend()
> calls for the SAVE_STATE, DISABLE and the corresponding device_resume()
> calls into apm's suspend() function. (this is needed so that PCI
> devices receive their notifications.)

Are those calls required even if the corresponding driver is not
compiled into the kernel? That is, would an unconfigured Yenta prevent
the PCI bus from going to sleep?

> However, APM is refusing to suspend. I'm seeing the following kernel
> messages:

Looks awfully familiar:

http://marc.theaimsgroup.com/?t=105949038200001&r=1&w=2

I saw a regression between 2.5.31 and 2.5.32, but couldn't pin the
problem down any further. I haven't looked too far into the driver model
power management code, but I don't think it's in apm.c.

Also saw your post about the 3c59x cardbus adapter. I can't recall ever
being able to suspend the machine with that card inserted (including
under 2.4-- I always had to eject the card before suspend or hibernate).
Not sure if that's the exact model I have, but the name sounds similar.

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

2003-08-07 10:47:29

by Stephen Rothwell

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

On Wed, 06 Aug 2003 22:46:59 -0400 Charles Lepple <[email protected]> wrote:
>
> Also saw your post about the 3c59x cardbus adapter. I can't recall ever
> being able to suspend the machine with that card inserted (including
> under 2.4-- I always had to eject the card before suspend or hibernate).

The IBM Thinkpad documentation mentions this (or used to) you cannot
suspend a Thinkpad (using APM?) while there is a card powered in the
PCMCIA/Cardbus slot. You could try doing "cardctrl eject" before
suspending - I find that this works for me (Thinkpad T22).

The message "apm: suspend: Unable to enter requested state" is an
indication of an error from the BIOS.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/

2003-08-07 11:01:07

by Russell King

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

On Thu, Aug 07, 2003 at 08:45:53PM +1000, Stephen Rothwell wrote:
> On Wed, 06 Aug 2003 22:46:59 -0400 Charles Lepple <[email protected]> wrote:
> >
> > Also saw your post about the 3c59x cardbus adapter. I can't recall ever
> > being able to suspend the machine with that card inserted (including
> > under 2.4-- I always had to eject the card before suspend or hibernate).
>
> The IBM Thinkpad documentation mentions this (or used to) you cannot
> suspend a Thinkpad (using APM?) while there is a card powered in the
> PCMCIA/Cardbus slot. You could try doing "cardctrl eject" before
> suspending - I find that this works for me (Thinkpad T22).
>
> The message "apm: suspend: Unable to enter requested state" is an
> indication of an error from the BIOS.

Well, it all works fine with 2.4, even with a 3c59x in the slot (except
for the resume problem.) Even ejecting the card before suspending with
2.6 doesn't fix the problem though.

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2003-08-07 12:32:39

by Charles Lepple

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

On Thursday, August 7, 2003, at 07:00 AM, Russell King wrote:

> On Thu, Aug 07, 2003 at 08:45:53PM +1000, Stephen Rothwell wrote:
>> On Wed, 06 Aug 2003 22:46:59 -0400 Charles Lepple <[email protected]>
>> wrote:
>>>
>>> Also saw your post about the 3c59x cardbus adapter. I can't recall
>>> ever
>>> being able to suspend the machine with that card inserted (including
>>> under 2.4-- I always had to eject the card before suspend or
>>> hibernate).
>>
>> The IBM Thinkpad documentation mentions this (or used to) you cannot
>> suspend a Thinkpad (using APM?) while there is a card powered in the
>> PCMCIA/Cardbus slot. You could try doing "cardctrl eject" before
>> suspending - I find that this works for me (Thinkpad T22).

OK, I didn't realize that powering down the card was a
Thinkpad-specific requirement.

One thing that had me confused was that some people indicated that it
should be possible to do the 'cardctl eject' or 'cardctl suspend' from
within the script invoked by apmd-- however, I guess the Thinkpad BIOS
doesn't let the APM suspend event propagate that far when there is a
card powered up.

>> The message "apm: suspend: Unable to enter requested state" is an
>> indication of an error from the BIOS.
>
> Well, it all works fine with 2.4, even with a 3c59x in the slot (except
> for the resume problem.) Even ejecting the card before suspending with
> 2.6 doesn't fix the problem though.

<aol>Same here</aol> (although I assumed that the problems I was seeing
when reinserting the card were due to an older hotplug package that was
misinterpreting the insertion events... I'll have to eliminate that
possibility.)

Russell, I am curious as to whether any of the early 2.5.x (x <= 31)
kernels still work for you, or whether suspend on your machine was
broken in a different version.

--
Charles Lepple <[email protected]>
http://www.ghz.cc/charles/

2003-08-07 13:56:51

by Alan

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

On Iau, 2003-08-07 at 12:00, Russell King wrote:
> Well, it all works fine with 2.4, even with a 3c59x in the slot (except
> for the resume problem.) Even ejecting the card before suspending with
> 2.6 doesn't fix the problem though.

The 2.4 apm scripts handled a lot of this, could it be the 2.6 PCMCIA
suspend simply isnt turning off enough things to convince the BIOS ?

2003-08-11 10:14:22

by Pavel Machek

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

Hi!

> I'm trying to test out APM on my laptop (in order to test some PCMCIA
> changes), but I'm hitting a brick wall. I've added the device_suspend()
> calls for the SAVE_STATE, DISABLE and the corresponding device_resume()
> calls into apm's suspend() function. (this is needed so that PCI
> devices receive their notifications.)

Can you verify that it is not device "vetoing" the suspend?
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

2003-08-11 11:31:46

by Russell King

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

On Mon, Aug 11, 2003 at 12:14:03PM +0200, Pavel Machek wrote:
> > I'm trying to test out APM on my laptop (in order to test some PCMCIA
> > changes), but I'm hitting a brick wall. I've added the device_suspend()
> > calls for the SAVE_STATE, DISABLE and the corresponding device_resume()
> > calls into apm's suspend() function. (this is needed so that PCI
> > devices receive their notifications.)
>
> Can you verify that it is not device "vetoing" the suspend?

Well, the pm_send_all(PM_SUSPEND) in suspend() doesn't trigger the "veto"
messages, and I don't see any errors reported from device_suspend().

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2003-08-11 12:50:54

by Stephen Rothwell

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

On Mon, 11 Aug 2003 12:14:03 +0200 Pavel Machek <[email protected]> wrote:
>
> Hi!
>
> > I'm trying to test out APM on my laptop (in order to test some PCMCIA
> > changes), but I'm hitting a brick wall. I've added the device_suspend()
> > calls for the SAVE_STATE, DISABLE and the corresponding device_resume()
> > calls into apm's suspend() function. (this is needed so that PCI
> > devices receive their notifications.)
>
> Can you verify that it is not device "vetoing" the suspend?

The error logged by the apm driver indicates an error from the BIOS. So
the BIOS thinks the machine is in a state that it cannot suspend from.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/

2003-08-17 16:23:18

by Russell King

[permalink] [raw]
Subject: Re: 2.6.0-test2: unable to suspend (APM)

On Wed, Aug 06, 2003 at 11:15:19PM +0100, Russell King wrote:
> I'm trying to test out APM on my laptop (in order to test some PCMCIA
> changes), but I'm hitting a brick wall. I've added the device_suspend()
> calls for the SAVE_STATE, DISABLE and the corresponding device_resume()
> calls into apm's suspend() function. (this is needed so that PCI
> devices receive their notifications.)
>
> However, APM is refusing to suspend. I'm seeing the following kernel
> messages:

I've just been doing further testing.

The kernel test setup consists of booting a kernel with init=/bin/sh,
and after the shell prompt appears, hitting the BIOS-magic "suspend to
RAM" key combination.

I can suspend to RAM under these circumstances:

- from LILO
- under RH7.2 2.4.9-31 kernel (with custom hacks to the APM code to allow
NFS mounts to be unmounted before we shut down CardBus - search LKML
for details on this)

I can't suspend under these circumstances:

- under a 2.6 kernel running any configuration, even with every driver
including CONFIG_INPUT turned off (Kconfig hacked to allow that)
leaving only IDE enabled, with the IDE power management disabled.
I've even tried without IDE.

I've tried all the steps from a full configuration down to nothing with
2.6, turning off one driver or subsystem at a time.

Please note that this is my only x86 system, so I'm currently unable
to test my PCMCIA/Cardbus changes as fully as I would like to under
2.6 kernels.

The machine is an IBM Thinkpad 380XD, 64MB. The BIOS does not have
the necessary ACPI tables so ACPI is of no use. lspci output:

00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
00:02.0 CardBus bridge: Texas Instruments PCI1250 (rev 02)
00:02.1 CardBus bridge: Texas Instruments PCI1250 (rev 02)
00:03.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] (rev 01)
00:06.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01)
00:06.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:06.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:06.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 01)

The last config I tried (with no drivers) is below.

CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_EXPERIMENTAL=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_X86_PC=y
CONFIG_M586MMX=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_BUG=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_CPUID=y
CONFIG_EDD=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_PM=y
CONFIG_APM=y
CONFIG_APM_RTC_IS_GMT=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_HOTPLUG=y
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
CONFIG_PCMCIA_PROBE=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IPV6_SCTP__=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_PCI=y
# Token Ring devices (depends on LLC=y)
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_PCNET=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_UNIX98_PTYS=y
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_FS_POSIX_ACL=y
CONFIG_AUTOFS4_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_UDF_FS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_NFS_FS=y
CONFIG_NFSD=y
CONFIG_LOCKD=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_FRAME_POINTER=y
CONFIG_X86_BIOS_REBOOT=y


--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html