Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759954AbZASXuN (ORCPT ); Mon, 19 Jan 2009 18:50:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754511AbZASXt6 (ORCPT ); Mon, 19 Jan 2009 18:49:58 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:52430 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753394AbZASXt5 (ORCPT ); Mon, 19 Jan 2009 18:49:57 -0500 Date: Tue, 20 Jan 2009 00:49:05 +0100 From: Ingo Molnar To: Zdenek Kabelac Cc: "Rafael J. Wysocki" , Dmitry Adamushko , Maciej Rutecki , Linux Kernel Mailing List , Henrique de Moraes Holschuh , dbrownell@users.sourceforge.net Subject: Re: 2.6.29-rc1 does not resume on Lenove T61 Message-ID: <20090119234905.GC452@elte.hu> References: <20090119164440.GA20754@elte.hu> <200901192025.37711.rjw@sisk.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 11654 Lines: 246 * Zdenek Kabelac wrote: > 2009/1/19 Rafael J. Wysocki : > > On Monday 19 January 2009, Ingo Molnar wrote: > >> > >> * Dmitry Adamushko wrote: > >> > >> > 2009/1/19 Ingo Molnar : > >> > > > >> > > * Dmitry Adamushko wrote: > >> > > > >> > >> 2009/1/19 Zdenek Kabelac : > >> > >> > 2009/1/13 Zdenek Kabelac : > >> > >> >> 2009/1/13 Zdenek Kabelac : > >> > >> >>> 2009/1/12 Rafael J. Wysocki : > >> > >> >>>> 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: [] > >> > >> > lock_policy_rwsem_write+0x4b/0x90 > >> > >> > > >> > >> > but task is already holding lock: > >> > >> > (&cpu_hotplug.lock){--..}, at: [] 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){--..}: > >> > >> > [] __lock_acquire+0x1416/0x1db0 > >> > >> > [] lock_acquire+0x91/0xc0 > >> > >> > [] mutex_lock_nested+0xec/0x360 > >> > >> > [] get_online_cpus+0x3a/0x50 > >> > >> > [] work_on_cpu+0x67/0xb0 > >> > >> > [] 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). > >> > > > >> > > Guys, could you please try the patch below? It improves work_on_cpu() to > >> > > not be dependent on the kevent workqueue. > >> > > >> > I guess, the following patch should also be applied (since > >> > get_online_cpus() is a culprit here): > >> > > >> > [PATCH 1/3] work_on_cpu: dont try to get_online_cpus() in work_on_cpu > >> > > >> > the patch is available here: > >> > > >> > http://lkml.indiana.edu/hypermail/linux/kernel/0901.2/00375.html > >> > >> yeah - also attached below. > > > > In fact I believe all three patches in the series at > > http://lkml.org/lkml/2009/1/16/377 > > are necessary. > > So I've made so far 2 tests - I've removed revert of the USB commit > (6fd9086a518d) - obvisously this result > in immediate wakeup after resume. > > The first Ingo's proposal patch resulted in this oops message (before suspend): > > usb 1-1: uevent > general protection fault: 0000 [#1] SMP > last sysfs file: /sys/power/state > CPU 0 > Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 > nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp > iptable_filter ip_tables x_tables bridge stp llc rfcomm sco l2cap > autofs4 sunrpc ipv6 binfmt_misc dm_snapshot dm_mirror dm_region_hash > dm_log dm_mod rtc_cmos rtc_core rtc_lib kvm_intel kvm i915 drm > i2c_algo_bit uinput arc4 ecb snd_hda_codec_analog cryptomgr aead > snd_hda_intel crypto_blkcipher btusb snd_hda_codec crypto_hash > crypto_algapi snd_seq_oss bluetooth iwl3945 sdhci_pci > snd_seq_midi_event sdhci mmc_core snd_seq snd_seq_device snd_pcm_oss > thinkpad_acpi snd_mixer_oss snd_pcm backlight snd_timer rfkill > led_class evdev snd i2c_i801 iTCO_wdt mac80211 button psmouse > soundcore e1000e i2c_core iTCO_vendor_support sr_mod battery serio_raw > nvram cdrom lib80211 ac intel_agp snd_page_alloc cfg80211 uhci_hcd > ohci_hcd usbcore [last unloaded: microcode] > Pid: 2244, comm: NetworkManager Not tainted 2.6.29-rc2 #15 > RIP: 0010:[] [] wait_for_common+0x131/0x190 > RSP: 0018:ffff88006ae6b730 EFLAGS: 00010296 > RAX: 7fffffffffffffff RBX: ffff88006ae6b748 RCX: 0000000000000003 > RDX: ffffffff80a8b1f0 RSI: ffff88006f908728 RDI: ffff88006f908000 > RBP: ffff88006ae6b738 R08: 0000000000000000 R09: 0000000000000000 > R10: ffff88006f908728 R11: 0000000000000001 R12: ffff880079ca1d98 > R13: 0000000000000000 R14: ffff880079d66000 R15: 0000000000000000 > FS: 00007faf7fca9740(0000) GS:ffffffff80914040(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000006c3444 CR3: 000000007c50d000 CR4: 00000000000026e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process NetworkManager (pid: 2244, threadinfo ffff88006ae6a000, task > ffff88006f908000) > Stack: > 7d6ddc008053cde8 ffff8800ffff8800 ffffffff8025a695 ffff88006b050e90 > ffffffff8025a580 0000000000000000 dead4ead00000303 ffffffffffffffff > ffffffffffffffff ffffffff80970c08 0000000000000000 ffffffff805f9e8e > Call Trace: > [] synchronize_rcu+0x35/0x40 > [] ? wakeme_after_rcu+0x0/0x10 > [] ? wait_for_common+0x16f/0x190 > [] ? local_bh_enable+0xa4/0x110 > [] ? dev_deactivate+0x151/0x1d0 > [] ? dev_close+0x6d/0xd0 > [] ? ieee80211_stop+0x562/0x570 [mac80211] > [] ? ieee80211_stop+0x79/0x570 [mac80211] > [] ? _spin_unlock_bh+0x2f/0x40 > [] ? dev_deactivate+0x1aa/0x1d0 > [] ? dev_close+0x7c/0xd0 > [] ? dev_change_flags+0x9d/0x1e0 > [] ? do_setlink+0x2b5/0x440 > [] ? _read_unlock+0x26/0x30 > [] ? rtnl_setlink+0x115/0x160 > [] ? mutex_lock_nested+0x284/0x360 > [] ? rtnetlink_rcv+0x1a/0x40 > [] ? rtnetlink_rcv_msg+0x18d/0x240 > [] ? rtnetlink_rcv_msg+0x0/0x240 > [] ? netlink_rcv_skb+0x89/0xb0 > [] ? rtnetlink_rcv+0x29/0x40 > [] ? netlink_unicast+0x2c4/0x2e0 > [] ? __alloc_skb+0x6e/0x150 > [] ? netlink_sendmsg+0x214/0x310 > [] ? sock_sendmsg+0x127/0x140 > [] ? autoremove_wake_function+0x0/0x40 > [] ? lock_release_non_nested+0x9b/0x2e0 > [] ? fget_light+0x106/0x110 > [] ? move_addr_to_kernel+0x57/0x60 > [] ? verify_iovec+0x3f/0xe0 > [] ? sys_sendmsg+0x189/0x320 > [] ? sys_sendto+0xff/0x120 > [] ? mntput_no_expire+0x2a/0x170 > [] ? __fput+0x17a/0x1f0 > [] ? trace_hardirqs_on_caller+0x16a/0x1d0 > [] ? audit_syscall_entry+0x17e/0x1a0 > [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [] ? system_call_fastpath+0x16/0x1b > Code: 04 24 b8 01 00 00 00 48 0f 44 d8 4c 89 ef e8 87 2d 00 00 48 89 > d8 4c 8b 65 e0 48 8b 5d d8 4c 8b 6d e8 4c 8b 75 f0 4c 8b 7d f8 c9 > 66 0f 1f 44 00 00 e8 83 43 d1 ff 85 c0 75 90 0f 1f 80 00 00 > RIP [] wait_for_common+0x131/0x190 > RSP > ---[ end trace a2c62d53604aab23 ]--- > (elapsed 0.04 seconds) done. > Freezing remaining freezable tasks ... <7>hub 1-0:1.0: debounce: port > 1: total 100ms stable 100ms status 0x100 > (elapsed 0.10 seconds) done. > PM: Entering mem sleep > > The second one (From 68564a46976017496c2227660930d81240f82355) > creates the same fault. > > Thus obviously Rafael is probably right and some series of patches > are necessary though I'd prefer to get a nice clean patch against the > current git which I should try to apply as both Ingo's patches > generated some reject (solvable by hand). You can pull the current set of patches/fixes in this area via: git pull git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus does that do the trick? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/