linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Adamushko <dmitry.adamushko@gmail.com>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>, Ingo Molnar <mingo@elte.hu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Maciej Rutecki <maciej.rutecki@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	dbrownell@users.sourceforge.net
Subject: Re: 2.6.29-rc1 does not resume on Lenove T61
Date: Mon, 19 Jan 2009 16:59:08 +0100	[thread overview]
Message-ID: <b647ffbd0901190759l7a255005jdef3a927eb23f52b@mail.gmail.com> (raw)
In-Reply-To: <c4e36d110901190154y59436b74nbcd1c35712111741@mail.gmail.com>

2009/1/19 Zdenek Kabelac <zdenek.kabelac@gmail.com>:
> 2009/1/13 Zdenek Kabelac <zdenek.kabelac@gmail.com>:
>> 2009/1/13 Zdenek Kabelac <zdenek.kabelac@gmail.com>:
>>> 2009/1/12 Rafael J. Wysocki <rjw@sisk.pl>:
>>>> On Monday 12 January 2009, Zdenek Kabelac wrote:
>>>
>>>> Sure, good idea.  I've been running with this reverted recently.
>>>>
>>>>> PS: I'll do the above 'echo' trace later (being busy right now).
>>>>
>>>> That shouldn't be necessary if you can suspend-resume with
>>>> 7503bfbae89eba07b46441a5d1594647f6b8ab7d reverted and the USB controller
>>>> modules unloaded.
>>>>
>>>> Instead, with 7503bfbae89eba07b46441a5d1594647f6b8ab7d reverted, please write
>>>> 'disabled' to the /sys/devices/.../power/wakeup files of all USB controllers
>>>> and see if suspend-resume works in this configuration.
>>>>
>>>
>>> Hi
>>>
>>> So I've check some   find /sys/device | grep usb | grep power/wakeup
>>> and there was no difference.
>>> I've updated to latest git to be in sync
>>> (e0b325d310a6b11f1538413fd557d2eb98f2fae5)
>>> I'm still keeping reverted commit: 6fd9086a518d4f14213a32fe6c9ac17fabebbc1e.
>>>
>>> And I've figured out - the only  'modprobe -r ehci_hcd' is enough to
>>> keep my suspend/resume sequence working. (Though I would have say,
>>> that now it takes fairly noticable time to get keyboard and synaptics
>>> usable - but it might be connected with my move to evdev and hal... :)
>>> )
>>>
>>> So I'm adding cc: to David - maybe he has some suspected patches for
>>> ehci_hcd ? (as doing a bisect in such a broken merge window is going
>>> to give me probably a lot of unsable kernels nowdays....)
>>>
>>
>> And I've forget to append trace from supend /resume with INFO trace:
>> (which might be a part of problem??)
>
> Hi
>
>
> Just an update for  2.6.29-rc2 (f3b8436ad9a8ad36b3c9fa1fe030c7f38e5d3d0b)
>
> With this kernel I still have to keep reverted patch commit:
> 6fd9086a518d4f14213a32fe6c9ac17fabebbc1e.
> (otherwise I see the auto-wake-up immediately after suspend)
>
> I also keep module ehci_hcd away from my kernel - so the
> suspend-resume seems to be working.
>
> I've checked the ideas from thread: 2.6.29-rc1: [SOLVED] thinkpad
> problems during resume
> http://lkml.org/lkml/2009/1/17/181  and they seems to produce some
> ugly Ooops with my configuration.
> so for now I stay with my revert/ehci fix.
>
> Also I still get the INFO trace:
> processor ACPI_CPU:01: legacy suspend
> processor ACPI_CPU:00: legacy suspend
> button LNXPWRBN:00: legacy suspend
> acpi LNXSYSTM:00: legacy suspend
> ACPI: Preparing to enter system sleep state S3
> Disabling non-boot CPUs ...
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.29-rc2 #14
> -------------------------------------------------------
> pm-suspend/2873 is trying to acquire lock:
>  (&per_cpu(cpu_policy_rwsem, cpu)){----}, at: [<ffffffff8049a27b>]
> lock_policy_rwsem_write+0x4b/0x90
>
> but task is already holding lock:
>  (&cpu_hotplug.lock){--..}, at: [<ffffffff80246832>] cpu_hotplug_begin+0x22/0x60
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&cpu_hotplug.lock){--..}:
>       [<ffffffff80270ce6>] __lock_acquire+0x1416/0x1db0
>       [<ffffffff80271711>] lock_acquire+0x91/0xc0
>       [<ffffffff8053d99c>] mutex_lock_nested+0xec/0x360
>       [<ffffffff80246a4a>] get_online_cpus+0x3a/0x50
>       [<ffffffff802594b7>] work_on_cpu+0x67/0xb0
>       [<ffffffff8021e85e>] get_measured_perf+0x1e/0xb0


Ingo,


it looks like e39ad415ac15116df213dfa2aa2a4f1b0857af9c should have
been reverted together with 7503bfbae89eba07b46441a5d1594647f6b8ab7d.

In general, perhaps all "set_cpus_allowed_ptr() -> work_on_cpu()"
conversions - if they involve any cpu-hotplug callback paths - may
lead to similar reports (and possible lockups).


-- 
Best regards,
Dmitry Adamushko

  reply	other threads:[~2009-01-19 16:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-11 19:52 2.6.29-rc1 does not resume on Lenove T61 Zdenek Kabelac
2009-01-11 20:15 ` Maciej Rutecki
2009-01-11 22:59   ` Zdenek Kabelac
2009-01-12  8:03     ` Rafael J. Wysocki
2009-01-12  9:15       ` Maciej Rutecki
2009-01-12  9:23         ` Oliver Neukum
2009-01-12 12:14       ` Zdenek Kabelac
2009-01-12 12:40         ` Rafael J. Wysocki
2009-01-12 12:50           ` Zdenek Kabelac
2009-01-12 17:19             ` Rafael J. Wysocki
2009-01-13 22:36               ` Zdenek Kabelac
2009-01-13 22:41                 ` Zdenek Kabelac
2009-01-19  9:54                   ` Zdenek Kabelac
2009-01-19 15:59                     ` Dmitry Adamushko [this message]
2009-01-19 16:13                       ` Ingo Molnar
2009-01-19 16:41                         ` Dmitry Adamushko
2009-01-19 16:44                           ` Ingo Molnar
2009-01-19 19:25                             ` Rafael J. Wysocki
2009-01-19 22:31                               ` Zdenek Kabelac
2009-01-19 23:49                                 ` Ingo Molnar
2009-01-20 10:41                                   ` Zdenek Kabelac
2009-01-20 11:48                                     ` Zdenek Kabelac
2009-01-20 11:55                                       ` Ingo Molnar
2009-01-22 15:14                                         ` Zdenek Kabelac
2009-01-22 21:17                                           ` Rafael J. Wysocki
2009-01-28 11:05                                             ` Zdenek Kabelac
2009-02-02 14:41                                               ` Zdenek Kabelac
2009-01-13 14:04             ` Michal Hocko
2009-01-12  0:48   ` Heiko Carstens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b647ffbd0901190759l7a255005jdef3a927eb23f52b@mail.gmail.com \
    --to=dmitry.adamushko@gmail.com \
    --cc=dbrownell@users.sourceforge.net \
    --cc=hmh@hmh.eng.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.rutecki@gmail.com \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    --cc=zdenek.kabelac@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).