Re: [linux-pm] Linux 2.6.21-rc6

2007-04-25 Thread Tobias Diedrich 
Rafael J. Wysocki wrote:
> On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> > > > > > > I think using the 'shutdown' mode of suspend would be better.  
> > > > > > > There's a little
> > > > > > > point in using 'platform' on desktop systems anyway.
> > > > > > > 
> > > > > > > Frankly, I don't know what to do about it.  If we move 
> > > > > > > platform_finish() after
> > > > > > > device_resume(), some systems may be broken ...
> > > > > > 
> > > > > > What I'm curious about is exactly why the patch matters.  What ACPI
> > > > > > magic is being invoked to confuse, or unconfuse, those controllers?
> > > > > 
> > > > > I think the patch helps, because it makes the ACPI magic be done 
> > > > > while the
> > > > > i8042's .resume() is being executed.
> > > > > 
> > > > > Which makes me think the following patch might help:
> > > > 
> > > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.
> > > 
> > > Well, this means i8042 can be ruled out, so the problem probably is 
> > > related
> > > to the ACPI resume which makes it _much_ more difficult to debug.
> > > 
> > > Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. 
> > > as
> > > modules, boot the kernel with init=/bin/bash and see if the problem is 
> > > still
> > > present (please keep CONFIG_SERIO_I8042 unset just in case)?
> > > 
> > > Rafael
> > 
> > I first tried it with acpi+cpufreq completely disabled (works).
> > Then I tried it with acpi enabled, but everything as modules and
> > those not loaded (init=/bin/bash, hangs at second suspend).
> 
> Have you tried with ACPI and without cpufreq?

Yes, the second one was with ACPI enabled and cpufreq disabled
(CONFIG_X86_ACPI_CPUFREQ is not set).

-- 
Tobias  PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Linux 2.6.21-rc6

2007-04-25 Thread Rafael J. Wysocki 
On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> > > Rafael J. Wysocki wrote:
> > > > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> > > > > > I think using the 'shutdown' mode of suspend would be better.  
> > > > > > There's a little
> > > > > > point in using 'platform' on desktop systems anyway.
> > > > > > 
> > > > > > Frankly, I don't know what to do about it.  If we move 
> > > > > > platform_finish() after
> > > > > > device_resume(), some systems may be broken ...
> > > > > 
> > > > > What I'm curious about is exactly why the patch matters.  What ACPI
> > > > > magic is being invoked to confuse, or unconfuse, those controllers?
> > > > 
> > > > I think the patch helps, because it makes the ACPI magic be done while 
> > > > the
> > > > i8042's .resume() is being executed.
> > > > 
> > > > Which makes me think the following patch might help:
> > > 
> > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.
> > 
> > Well, this means i8042 can be ruled out, so the problem probably is related
> > to the ACPI resume which makes it _much_ more difficult to debug.
> > 
> > Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as
> > modules, boot the kernel with init=/bin/bash and see if the problem is still
> > present (please keep CONFIG_SERIO_I8042 unset just in case)?
> > 
> > Rafael
> 
> I first tried it with acpi+cpufreq completely disabled (works).
> Then I tried it with acpi enabled, but everything as modules and
> those not loaded (init=/bin/bash, hangs at second suspend).

Have you tried with ACPI and without cpufreq?

Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Linux 2.6.21-rc6

2007-04-25 Thread Tobias Diedrich 
Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> > > > > I think using the 'shutdown' mode of suspend would be better.  
> > > > > There's a little
> > > > > point in using 'platform' on desktop systems anyway.
> > > > > 
> > > > > Frankly, I don't know what to do about it.  If we move 
> > > > > platform_finish() after
> > > > > device_resume(), some systems may be broken ...
> > > > 
> > > > What I'm curious about is exactly why the patch matters.  What ACPI
> > > > magic is being invoked to confuse, or unconfuse, those controllers?
> > > 
> > > I think the patch helps, because it makes the ACPI magic be done while the
> > > i8042's .resume() is being executed.
> > > 
> > > Which makes me think the following patch might help:
> > 
> > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.
> 
> Well, this means i8042 can be ruled out, so the problem probably is related
> to the ACPI resume which makes it _much_ more difficult to debug.
> 
> Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as
> modules, boot the kernel with init=/bin/bash and see if the problem is still
> present (please keep CONFIG_SERIO_I8042 unset just in case)?
> 
> Rafael

I first tried it with acpi+cpufreq completely disabled (works).
Then I tried it with acpi enabled, but everything as modules and
those not loaded (init=/bin/bash, hangs at second suspend).

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc7
# Sun Apr 22 09:26:07 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VSMP is not set
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HPET_TIMER=y
# CONFIG

Re: [linux-pm] Linux 2.6.21-rc6

2007-04-15 Thread Rafael J. Wysocki 
On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> > > 
> > > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > > > > single core CPU.
> > > 
> > > And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
> > > would be to disable the EHCI (high speed USB) support in BIOS, to make
> > > for a simpler hardware configuration, and see if that makes BIOS happier.
> > > (Or better, just take EHCI out of your Linux config.)  Likewise, taking
> > > the 8042 drivers out of Linux.
> > > 
> > > I wouldn't be surprised if those factors didn't matter, but it'd be good
> > > to rule them out.
> > 
> > I think the disabling of i8042 support might help.
> 
> Still hangs with "# CONFIG_SERIO_I8042 is not set".
> 
> > > > Dmitry, could you please have a look?
> > > > 
> > > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long
> > > > > as USB legacy support is disabled (however without legacy support I
> > > > > can't use the USB keyboard to control grub).
> > > > 
> > > > I think using the 'shutdown' mode of suspend would be better.  There's 
> > > > a little
> > > > point in using 'platform' on desktop systems anyway.
> > > > 
> > > > Frankly, I don't know what to do about it.  If we move 
> > > > platform_finish() after
> > > > device_resume(), some systems may be broken ...
> > > 
> > > What I'm curious about is exactly why the patch matters.  What ACPI
> > > magic is being invoked to confuse, or unconfuse, those controllers?
> > 
> > I think the patch helps, because it makes the ACPI magic be done while the
> > i8042's .resume() is being executed.
> > 
> > Which makes me think the following patch might help:
> 
> Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.

Well, this means i8042 can be ruled out, so the problem probably is related
to the ACPI resume which makes it _much_ more difficult to debug.

Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as
modules, boot the kernel with init=/bin/bash and see if the problem is still
present (please keep CONFIG_SERIO_I8042 unset just in case)?

Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Linux 2.6.21-rc6

2007-04-15 Thread Tobias Diedrich 
Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> > 
> > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > > > single core CPU.
> > 
> > And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
> > would be to disable the EHCI (high speed USB) support in BIOS, to make
> > for a simpler hardware configuration, and see if that makes BIOS happier.
> > (Or better, just take EHCI out of your Linux config.)  Likewise, taking
> > the 8042 drivers out of Linux.
> > 
> > I wouldn't be surprised if those factors didn't matter, but it'd be good
> > to rule them out.
> 
> I think the disabling of i8042 support might help.

Still hangs with "# CONFIG_SERIO_I8042 is not set".

> > > Dmitry, could you please have a look?
> > > 
> > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long
> > > > as USB legacy support is disabled (however without legacy support I
> > > > can't use the USB keyboard to control grub).
> > > 
> > > I think using the 'shutdown' mode of suspend would be better.  There's a 
> > > little
> > > point in using 'platform' on desktop systems anyway.
> > > 
> > > Frankly, I don't know what to do about it.  If we move platform_finish() 
> > > after
> > > device_resume(), some systems may be broken ...
> > 
> > What I'm curious about is exactly why the patch matters.  What ACPI
> > magic is being invoked to confuse, or unconfuse, those controllers?
> 
> I think the patch helps, because it makes the ACPI magic be done while the
> i8042's .resume() is being executed.
> 
> Which makes me think the following patch might help:

Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.

>  drivers/input/serio/i8042.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
> ===
> --- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07 
> 12:15:19.0 +0200
> +++ linux-2.6.21-rc6/drivers/input/serio/i8042.c  2007-04-15 
> 18:30:01.0 +0200
> @@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
>  static int i8042_suspend(struct platform_device *dev, pm_message_t state)
>  {
>   if (dev->dev.power.power_state.event != state.event) {
> - if (state.event == PM_EVENT_SUSPEND)
> + if (state.event == PM_EVENT_SUSPEND
> + || state.event == PM_EVENT_PRETHAW)
>   i8042_controller_reset();
>  
>   dev->dev.power.power_state = state;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
Tobias  PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Linux 2.6.21-rc6

2007-04-15 Thread David Brownell 
On Sunday 15 April 2007 9:37 am, Rafael J. Wysocki wrote:
> 
> Which makes me think the following patch might help:
> 
>  drivers/input/serio/i8042.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
> ===
> --- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07 
> 12:15:19.0 +0200
> +++ linux-2.6.21-rc6/drivers/input/serio/i8042.c  2007-04-15 
> 18:30:01.0 +0200
> @@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
>  static int i8042_suspend(struct platform_device *dev, pm_message_t state)
>  {
>   if (dev->dev.power.power_state.event != state.event) {
> - if (state.event == PM_EVENT_SUSPEND)
> + if (state.event == PM_EVENT_SUSPEND
> + || state.event == PM_EVENT_PRETHAW)

Yeah, lack of PRETHAW support could be an issue.  As you may recall,
it was added because otherwise statically linked USB host controllers
came up under the mistaken belief that they were getting a real resume
event rather than a restart-after-power-off ... and there needed to be
a way to force a hard reset.  Seems like a similar issue here.

- Dave


>   i8042_controller_reset();
>  
>   dev->dev.power.power_state = state;
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Linux 2.6.21-rc6

2007-04-15 Thread Rafael J. Wysocki 
On Sunday, 15 April 2007 17:14, David Brownell wrote:
> On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> 
> > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > > single core CPU.
> 
> And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
> would be to disable the EHCI (high speed USB) support in BIOS, to make
> for a simpler hardware configuration, and see if that makes BIOS happier.
> (Or better, just take EHCI out of your Linux config.)  Likewise, taking
> the 8042 drivers out of Linux.
> 
> I wouldn't be surprised if those factors didn't matter, but it'd be good
> to rule them out.

I think the disabling of i8042 support might help.

> > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
> > > > that the second suspend hangs at "i8042 i8042: EARLY resume".
> > > > This is kinda interesting because I'm normally using a USB keyboard
> > > > and sure enough, if I hook up a normal keyboard and disable USB
> > > > legacy support in the BIOS, then suspend to disk works multiple
> > > > times. I'd still rather like to use my USB keyboard though. ;)
> > 
> > Well, I think that when you're using the USB keyboard and the USB legacy
> > support, the i8042 driver thinks it has a keyboard to handle and tries to
> > handle it during the suspend, which fails.  I don't know why it fails during
> > the second suspend, though.
> 
> The "legacy" support in at least some cases involves BIOS having a
> small USB stack -- enough to handle a keyboard or mouse in "boot mode"
> (plus sometimes a USB disk or CDROM) -- and poking the i8042 chip to
> act as if *IT* received the data bytes that really came over USB.

That's what happens here, I think.

> I sure don't know the ins-and-outs of such schemes (ISTR there are
> others), but my guess is that either the 8042 or OHCI got confused,
> at least in conjunction with the lowlevel magic ACPI was doing.

Yes.

> That's all black magic though, as far as I can understand it ...

Well, my theory is the following:

Without the patch, platform_finish() runs before the i8042's .resume() which is
done as though a real keyboard were present, but the ACPI magic is not done
and this confuses the heck out of the controller.  Still, it doesn't go mad at
this point just yet (it probably isn't fully functional either, although we
don't see that, because it's not really used), but next, during the subsequent
suspend, it gets poked while device_power_up() is running and goes belly
up.

> > Dmitry, could you please have a look?
> > 
> > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long
> > > as USB legacy support is disabled (however without legacy support I
> > > can't use the USB keyboard to control grub).
> > 
> > I think using the 'shutdown' mode of suspend would be better.  There's a 
> > little
> > point in using 'platform' on desktop systems anyway.
> > 
> > Frankly, I don't know what to do about it.  If we move platform_finish() 
> > after
> > device_resume(), some systems may be broken ...
> 
> What I'm curious about is exactly why the patch matters.  What ACPI
> magic is being invoked to confuse, or unconfuse, those controllers?

I think the patch helps, because it makes the ACPI magic be done while the
i8042's .resume() is being executed.

Which makes me think the following patch might help:

 drivers/input/serio/i8042.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c   2007-04-07 
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c2007-04-15 
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
 static int i8042_suspend(struct platform_device *dev, pm_message_t state)
 {
if (dev->dev.power.power_state.event != state.event) {
-   if (state.event == PM_EVENT_SUSPEND)
+   if (state.event == PM_EVENT_SUSPEND
+   || state.event == PM_EVENT_PRETHAW)
i8042_controller_reset();
 
dev->dev.power.power_state = state;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Linux 2.6.21-rc6

2007-04-15 Thread David Brownell 
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:

> > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > single core CPU.

And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
would be to disable the EHCI (high speed USB) support in BIOS, to make
for a simpler hardware configuration, and see if that makes BIOS happier.
(Or better, just take EHCI out of your Linux config.)  Likewise, taking
the 8042 drivers out of Linux.

I wouldn't be surprised if those factors didn't matter, but it'd be good
to rule them out.


> > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
> > > that the second suspend hangs at "i8042 i8042: EARLY resume".
> > > This is kinda interesting because I'm normally using a USB keyboard
> > > and sure enough, if I hook up a normal keyboard and disable USB
> > > legacy support in the BIOS, then suspend to disk works multiple
> > > times. I'd still rather like to use my USB keyboard though. ;)
> 
> Well, I think that when you're using the USB keyboard and the USB legacy
> support, the i8042 driver thinks it has a keyboard to handle and tries to
> handle it during the suspend, which fails.  I don't know why it fails during
> the second suspend, though.

The "legacy" support in at least some cases involves BIOS having a
small USB stack -- enough to handle a keyboard or mouse in "boot mode"
(plus sometimes a USB disk or CDROM) -- and poking the i8042 chip to
act as if *IT* received the data bytes that really came over USB.

I sure don't know the ins-and-outs of such schemes (ISTR there are
others), but my guess is that either the 8042 or OHCI got confused,
at least in conjunction with the lowlevel magic ACPI was doing.

That's all black magic though, as far as I can understand it ...


> Dmitry, could you please have a look?
> 
> > And I can now confirm that unpatched 2.6.21-rc6 works fine as long
> > as USB legacy support is disabled (however without legacy support I
> > can't use the USB keyboard to control grub).
> 
> I think using the 'shutdown' mode of suspend would be better.  There's a 
> little
> point in using 'platform' on desktop systems anyway.
> 
> Frankly, I don't know what to do about it.  If we move platform_finish() after
> device_resume(), some systems may be broken ...

What I'm curious about is exactly why the patch matters.  What ACPI
magic is being invoked to confuse, or unconfuse, those controllers?

- Dave



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/