| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <c4e36d110901190154y59436b74nbcd1c35712111741@mail.gmail.com>
Date: Mon, 19 Jan 2009 10:54:54 +0100
From: "Zdenek Kabelac" <zdenek.kabelac@...il.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: "Maciej Rutecki" <maciej.rutecki@...il.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Henrique de Moraes Holschuh" <hmh@....eng.br>,
dbrownell@...rs.sourceforge.net
Subject: Re: 2.6.29-rc1 does not resume on Lenove T61
2009/1/13 Zdenek Kabelac <zdenek.kabelac@...il.com>:
> 2009/1/13 Zdenek Kabelac <zdenek.kabelac@...il.com>:
>> 2009/1/12 Rafael J. Wysocki <rjw@...k.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
[<ffffffff80499ec8>] __cpufreq_driver_getavg+0x78/0x80
[<ffffffff8049bf4c>] do_dbs_timer+0x2ac/0x390
[<ffffffff80258625>] run_workqueue+0x105/0x240
[<ffffffff8025880f>] worker_thread+0xaf/0x130
[<ffffffff8025cd49>] kthread+0x49/0x90
[<ffffffff8020d5fa>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
-> #0 (&per_cpu(cpu_policy_rwsem, cpu)){----}:
[<ffffffff80270eac>] __lock_acquire+0x15dc/0x1db0
[<ffffffff80271711>] lock_acquire+0x91/0xc0
[<ffffffff8053e2a8>] down_write+0x48/0x80
[<ffffffff8049a27b>] lock_policy_rwsem_write+0x4b/0x90
[<ffffffff8053b8ad>] cpufreq_cpu_callback+0x6d/0x90
[<ffffffff805432b5>] notifier_call_chain+0x65/0xa0
[<ffffffff80261c29>] __raw_notifier_call_chain+0x9/0x10
[<ffffffff8052a469>] _cpu_down+0xa9/0x2f0
[<ffffffff8024692d>] disable_nonboot_cpus+0xbd/0x140
[<ffffffff8027e805>] suspend_devices_and_enter+0x115/0x1c0
[<ffffffff8027ea46>] enter_state+0x166/0x1e0
[<ffffffff8027eb7a>] state_store+0xba/0x100
[<ffffffff803a1e07>] kobj_attr_store+0x17/0x20
[<ffffffff8033526a>] sysfs_write_file+0xca/0x140
[<ffffffff802db34b>] vfs_write+0xcb/0x190
[<ffffffff802db500>] sys_write+0x50/0x90
[<ffffffff8020c51b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
4 locks held by pm-suspend/2873:
#0: (&buffer->mutex){--..}, at: [<ffffffff803351e3>]
sysfs_write_file+0x43/0x140
#1: (pm_mutex){--..}, at: [<ffffffff8027e951>] enter_state+0x71/0x1e0
#2: (cpu_add_remove_lock){--..}, at: [<ffffffff802468c3>]
disable_nonboot_cpus+0x53/0x140
#3: (&cpu_hotplug.lock){--..}, at: [<ffffffff80246832>]
cpu_hotplug_begin+0x22/0x60
stack backtrace:
Pid: 2873, comm: pm-suspend Not tainted 2.6.29-rc2 #14
Call Trace:
[<ffffffff8026f430>] print_circular_bug_tail+0xe0/0xf0
[<ffffffff80270eac>] __lock_acquire+0x15dc/0x1db0
[<ffffffff8053fa82>] ? _spin_unlock_irq+0x32/0x50
[<ffffffff8026edaa>] ? trace_hardirqs_on_caller+0x16a/0x1d0
[<ffffffff803a0689>] ? __next_cpu+0x19/0x30
[<ffffffff80258ed9>] ? __cancel_work_timer+0x129/0x230
[<ffffffff80258e22>] ? __cancel_work_timer+0x72/0x230
[<ffffffff80271711>] lock_acquire+0x91/0xc0
[<ffffffff8049a27b>] ? lock_policy_rwsem_write+0x4b/0x90
[<ffffffff8053e2a8>] down_write+0x48/0x80
[<ffffffff8049a27b>] ? lock_policy_rwsem_write+0x4b/0x90
[<ffffffff8049a27b>] lock_policy_rwsem_write+0x4b/0x90
[<ffffffff8053b8ad>] cpufreq_cpu_callback+0x6d/0x90
[<ffffffff805432b5>] notifier_call_chain+0x65/0xa0
[<ffffffff80261c29>] __raw_notifier_call_chain+0x9/0x10
[<ffffffff8052a469>] _cpu_down+0xa9/0x2f0
[<ffffffff8024692d>] disable_nonboot_cpus+0xbd/0x140
[<ffffffff8027e805>] suspend_devices_and_enter+0x115/0x1c0
[<ffffffff8027ea46>] enter_state+0x166/0x1e0
[<ffffffff8027eb7a>] state_store+0xba/0x100
[<ffffffff803a1e07>] kobj_attr_store+0x17/0x20
[<ffffffff8033526a>] sysfs_write_file+0xca/0x140
[<ffffffff802db34b>] vfs_write+0xcb/0x190
[<ffffffff802db500>] sys_write+0x50/0x90
[<ffffffff8020c51b>] system_call_fastpath+0x16/0x1b
Broke affinity for irq 9
Broke affinity for irq 17
Broke affinity for irq 29
kvm: disabling virtualization on CPU1
CPU 1 is now offline
lockdep: fixing up alternatives.
SMP alternatives: switching to UP code
CPU0 attaching NULL sched-domain.
CPU1 attaching NULL sched-domain.
CPU0 attaching NULL sched-domain.
CPU1 is down
thinkpad_hwmon thinkpad_hwmon: LATE suspend
thinkpad_acpi thinkpad_acpi: LATE suspend
Zdenek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists