From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: linux-next: Tree for September 4 Date: Fri, 5 Sep 2008 11:30:42 -0700 Message-ID: <20080905113042.0f6d5850.akpm@linux-foundation.org> References: <20080904193606.573f2cb3.sfr@canb.auug.org.au> <20080904214437.c53f02d9.akpm@linux-foundation.org> <200809051256.36257.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:44431 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754345AbYIESc1 (ORCPT ); Fri, 5 Sep 2008 14:32:27 -0400 In-Reply-To: <200809051256.36257.rjw@sisk.pl> Sender: linux-next-owner@vger.kernel.org List-ID: To: "Rafael J. Wysocki" Cc: Stephen Rothwell , linux-next@vger.kernel.org, LKML On Fri, 5 Sep 2008 12:56:35 +0200 "Rafael J. Wysocki" wrote: > On Friday, 5 of September 2008, Andrew Morton wrote: > > On Thu, 4 Sep 2008 19:36:06 +1000 Stephen Rothwell wrote: > > > > > I have created today's linux-next tree at > > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git > > > > The infamous Vaio hasn't finished catching up with you guys yet. > > Something in linux-next broke suspend-to-RAM. > > > > An `echo mem > /sys/power/state' causes "Freezing of tasks failed after > > 20.00 seconds (1 tasks refusing to freeze):" > > > > dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-suspend.txt > > config: http://userweb.kernel.org/~akpm/config-sony.txt > > > > This only happens after the X server has been started. > > > > Mainline is OK. > > According to your dmesg the process that refused to freeze was > > hald-addon-stor > > which got stuck in ... getnstimeofday (???) (can you check what > source code corresponds to getnstimeofday+0x37/0xbc pls?): > > hald-addon-st D 00000046 0 2322 2282 > f4de5b74 00000046 f4de5b54 00000046 f4de5b5c c0135f56 f6b96e44 f4deaf40 > f4deb0bc f5580948 f4de5bb0 f4de5b6c c013336e f6aa77c8 f6aa77c8 f6aa77a0 > f4de5bb0 f4de5b7c c0331f09 f4de5bd0 c01f4205 00000000 00000000 00000000 > Call Trace: > [] ? getnstimeofday+0x37/0xbc > [] ? ktime_get_ts+0x40/0x44 > [] io_schedule+0x39/0x6c > [] get_request_wait+0x80/0xcd > ... (gdb) x/60i getnstimeofday 0xc0135d63 : push %ebp 0xc0135d64 : mov %esp,%ebp 0xc0135d66 : push %edi 0xc0135d67 : push %esi 0xc0135d68 : push %ebx 0xc0135d69 : sub $0x8,%esp 0xc0135d6c : mov %eax,0xffffffec(%ebp) 0xc0135d6f : mov 0xc045a2c0,%eax 0xc0135d74 : mov %eax,0xfffffff0(%ebp) 0xc0135d77 : test $0x1,%al 0xc0135d79 : je 0xc0135d7f 0xc0135d7b : pause 0xc0135d7d : jmp 0xc0135d6f 0xc0135d7f : mov 0xffffffec(%ebp),%ecx 0xc0135d82 : mov 0xc05db920,%eax 0xc0135d87 : mov 0xc05db924,%edx 0xc0135d8d : mov %eax,(%ecx) 0xc0135d8f : mov %edx,0x4(%ecx) 0xc0135d92 : mov 0xc05db938,%eax 0xc0135d97 : call *0x10(%eax) 0xc0135d9a : mov 0xc05db938,%esi 0xc0135da0 : mov 0x1c(%esi),%ecx 0xc0135da3 : sub 0x48(%esi),%eax 0xc0135da6 : sbb 0x4c(%esi),%edx 0xc0135da9 : and 0x14(%esi),%eax 0xc0135dac : and 0x18(%esi),%edx 0xc0135daf : mov %edx,%edi 0xc0135db1 : imul %ecx,%edi 0xc0135db4 : mul %ecx 0xc0135db6 : mov 0x24(%esi),%ecx 0xc0135db9 : lea (%edi,%edx,1),%edx 0xc0135dbc : mov %eax,%ebx 0xc0135dbe : mov %edx,%esi 0xc0135dc0 : xor %edi,%edi 0xc0135dc2 : shrd %cl,%edx,%ebx 0xc0135dc5 : shr %cl,%esi 0xc0135dc7 : test $0x20,%cl 0xc0135dca : cmovne %esi,%ebx 0xc0135dcd : cmovne %edi,%esi 0xc0135dd0 : mov %ebx,%edx (gdb) l *0xc0135d9a 0xc0135d9a is in getnstimeofday (kernel/time/timekeeping.c:104). 99 100 /* read clocksource: */ 101 cycle_now = clocksource_read(clock); 102 103 /* calculate the delta since the last update_wall_time: */ 104 cycle_delta = (cycle_now - clock->cycle_last) & clock->mask; 105 106 /* convert to nanoseconds: */ 107 nsecs = cyc2ns(clock, cycle_delta); 108 Which implies that someone mucked up xtime_lock. But I don't think any of that is correct. The getnstimeofday is just stack gunk. hald is in D state and is asleep in get_request_wait().