Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753332AbXKVKqG (ORCPT ); Thu, 22 Nov 2007 05:46:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751506AbXKVKpz (ORCPT ); Thu, 22 Nov 2007 05:45:55 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]:1459 "EHLO nf-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750920AbXKVKpy (ORCPT ); Thu, 22 Nov 2007 05:45:54 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; b=BfTNBN7gI4gdsFZEz24ZJ7obDFYR7cHnGVkx03wNKCzq3et3U3MMO0aHIm72/iRRq+tEMYhcSd10xvdUMNsVv69hzizPpnumyWii1VLESuhAcytsNIdmVZ6/Bmwo/r4eEGOXBrwuVNQbTkm/JjAv5AdQ51g0iS++6LlI8H8vLjo= Message-ID: <47455DEE.4050107@gmail.com> Date: Thu, 22 Nov 2007 11:46:06 +0100 From: Jiri Slaby User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: davej@codemonkey.org.uk CC: cpufreq@lists.linux.org.uk, Linux kernel mailing list , Greg KH Subject: cpufreq deadlock (?sysfs related?) X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5890 Lines: 146 Hi, some people hit this bug, I'm able to reproduce it too, but I'm out of ideas what could have cause it. Here are some traces of D processes: tee D ffff8100041e3c28 0 15798 13503 ffff8100041e3bc8 0000000000000086 0000000000000000 ffffffff804a007b ffff8100041e3be8 ffff8100029d8000 ffff810001fc9560 ffffffff8828e094 ffff810008af1ba0 ffff8100029d8000 ffff810001fc9560 ffff81002ae74e40 Call Trace: [] thread_return+0x0/0x5a5 [] :cpufreq_stats:cpufreq_stats_update+0x54/0x70 /* _spin_unlock */ [] wait_for_completion+0xa1/0xf0 [] default_wake_function+0x0/0x10 [] sysfs_addrm_finish+0x1ef/0x270 /* wait_for_completion */ [] sysfs_hash_and_remove+0xa6/0xc0 [] :cpufreq_userspace:cpufreq_governor_userspace+0xac/0x220 [] __cpufreq_governor+0x32/0x110 [] __cpufreq_set_policy+0x113/0x180 [] store_scaling_governor+0xf2/0x200 [] handle_update+0x0/0x10 here started the scheduled work ^^^ [] __alloc_pages+0x73/0x320 /* get_page_from_freelist */ [] store+0x7b/0x90 /* fattr->store(), holding write sem */ [] sysfs_write_file+0xcf/0x150 [] vfs_write+0xc8/0x170 [] sys_write+0x53/0x90 [] system_call+0x7e/0x83 tee D 0000000000000000 0 15800 22179 ffff8100058b7e28 0000000000000086 0000000000000000 001bdcd0000f32a0 0000000000000000 ffff810005f8ce40 ffff810001fd6e40 0000000000000001 0000000101281d48 000000008057bec0 0000000000000003 000280d000000000 Call Trace: [] __down_write_nested+0x79/0xc0 [] lock_policy_rwsem_write+0x41/0x80 [] store+0x5c/0x90 [] sysfs_write_file+0xcf/0x150 [] vfs_write+0xc8/0x170 [] sys_write+0x53/0x90 [] system_call+0x7e/0x83 cat D 0000000000000000 0 15801 13587 ffff810008f69e38 0000000000000082 0000000000000000 ffffffff8026a119 ffffffff80624fa0 ffff810005f8d560 ffffffff805703a0 ffffffff8057bec0 0000000101282286 0000000000000000 0000000000000003 000000010697e4a0 Call Trace: [] get_page_from_freelist+0x339/0x470 [] __down_read+0x79/0xb2 /* schedule */ [] lock_policy_rwsem_read+0x41/0x80 [] show+0x4d/0x80 [] sysfs_read_file+0x9d/0x150 [] vfs_read+0xc5/0x160 [] sys_read+0x53/0x90 [] system_call+0x7e/0x83 I reproduced it by executing these 3 scripts: #!/bin/bash while true do echo userspace | tee /sys/devices/system/cpu/*/cpufreq/scaling_governor cat /sys/devices/system/cpu/*/cpufreq/scaling_governor sleep 2 echo performance | tee /sys/devices/system/cpu/*/cpufreq/scaling_governor cat /sys/devices/system/cpu/*/cpufreq/scaling_governor sleep 4 echo ondemand | tee /sys/devices/system/cpu/*/cpufreq/scaling_governor cat /sys/devices/system/cpu/*/cpufreq/scaling_governor sleep 10 done #!/bin/bash while true do echo userspace | tee /sys/devices/system/cpu/*/cpufreq/scaling_governor cat /sys/devices/system/cpu/*/cpufreq/scaling_governor for (( a = 0; a < 10000; a++ )); do echo aaa >/dev/null; done echo performance | tee /sys/devices/system/cpu/*/cpufreq/scaling_governor cat /sys/devices/system/cpu/*/cpufreq/scaling_governor for (( a = 0; a < 11500; a++ )); do echo aaa >/dev/null; done echo ondemand | tee /sys/devices/system/cpu/*/cpufreq/scaling_governor cat /sys/devices/system/cpu/*/cpufreq/scaling_governor sleep 1 done #!/bin/bash while true do cat /sys/devices/system/cpu/*/cpufreq/* sleep 10 done This was on 2.6.23, however it is known to be also in older kernels. I suspect same race between wait_for_completion and complete() -- it wakes only one process, but not the other in sysfs/dir.c (would complete_all help?)? Any ideas? Here are events workers (seems OK): events/1 S 0000000000000000 0 13126 2 ffff81003fe71ec0 0000000000000046 0000000000000000 0000000000000202 ffff810001e120c0 ffff81003d821560 ffff810001fd6e40 00000000ffffffff 00000001012df7e1 0000000080248f2a 0000000000000003 ffff810001e120c8 Call Trace: [] worker_thread+0x0/0x130 [] worker_thread+0x105/0x130 [] autoremove_wake_function+0x0/0x30 [] worker_thread+0x0/0x130 [] worker_thread+0x0/0x130 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 events/0 S 0000000000000000 0 7 2 ffff81003ff0bec0 0000000000000046 0000000000000000 0000000000000202 ffff810001e0a0c0 ffff810001fd7560 ffffffff805703a0 00000000ffffffff 00000001012df7c6 0000000080248f2a 0000000000000003 ffff810001e0a0c8 Call Trace: [] worker_thread+0x0/0x130 [] worker_thread+0x105/0x130 [] autoremove_wake_function+0x0/0x30 [] worker_thread+0x0/0x130 [] worker_thread+0x0/0x130 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 I'm now trying to reproduce this with LOCKDEP on, but it's not easy to get to that state. thanks, -- http://www.fi.muni.cz/~xslaby/ Jiri Slaby faculty of informatics, masaryk university, brno, cz - 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/