Return-path: Received: from mail-ew0-f219.google.com ([209.85.219.219]:50750 "EHLO mail-ew0-f219.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751596AbZLKJKv convert rfc822-to-8bit (ORCPT ); Fri, 11 Dec 2009 04:10:51 -0500 MIME-Version: 1.0 In-Reply-To: References: <20091210184931.257A.A69D9226@jp.fujitsu.com> <4B217219.6040109@crca.org.au> Date: Fri, 11 Dec 2009 17:10:56 +0800 Message-ID: Subject: Re: mmotm-2009-12-08-17-45 resume slowly From: Dave Young To: Nigel Cunningham Cc: KOSAKI Motohiro , Andrew Morton , Linux Kernel Mailing List , netdev , linux-wireless , "David S. Miller" , Zhu Yi Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, Dec 11, 2009 at 9:47 AM, Dave Young wrote: > On Fri, Dec 11, 2009 at 6:11 AM, Nigel Cunningham > wrote: >> Dave, could you be more specific? >> >> Is the delay Ksaki has picked out related to your report... > > I can not reproduce the wireless delay today, maybe related to > wireless environment? > >> >> KOSAKI Motohiro wrote: >>> (cc to netdev) >>> >>> Hi net-folks >>> >>>>> [  561.323866] mtrr: type mismatch for e0000000,10000000 old: >>>>> write-back new: write-combining >>>>> [ 2688.500033] No probe response from AP 00:02:2d:08:51:2b after >>>>> 500ms, disconnecting. >>>>> [ 2689.580376] wlan0: direct probe to AP 00:02:2d:08:51:2b (try 1) >>> >>> What's mean "No probe response"? Why its point waste 2000sec? Rereading the dmesg I post, I think maybe this delay is not relevant because it is after "PM: Finishing wakeup." The brightness is so low after resume finished that I thought it as resume delay. >> >> [...] >> >>>>> [  225.731462] ACPI: Preparing to enter system sleep state S3 >>>>> [  225.754167] Disabling non-boot CPUs ... >>>>> [  225.809478] CPU 1 is now offline >>>>> [  225.809481] lockdep: fixing up alternatives. >>>>> [  225.809487] SMP alternatives: switching to UP code >>>>> [  225.816500] Extended CMOS year: 2000 >>>>> [  225.816500] Back to C! >>>>> [  225.816500] Extended CMOS year: 2000 >>>>> [  225.816720] Enabling non-boot CPUs ... >>>>> [  225.818422] lockdep: fixing up alternatives. >>>>> [  225.818425] SMP alternatives: switching to SMP code >>>>> [  225.822188] Booting processor 1 APIC 0x1 ip 0x6000 >>>>> [  225.818021] Initializing CPU#1 >>>>> [  225.818021] CPU: Physical Processor ID: 0 >>>>> [  225.818021] CPU: Processor Core ID: 1 >>>>> [  225.913392] CPU1: Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz stepping 0d >>>>> [  225.937046] microcode: CPU1 sig=0x6fd, pf=0x80, revision=0xa3 >>>>> [  225.937053] platform microcode: firmware: requesting intel-ucode/06-0f-0d >>>>> [  225.937179] firmware microcode: parent microcode should not be sleeping >>>>> [  285.940840] CPU1 is up >> >> ... or the 60 second delay before the CPU1 is up message? > > Yes, this delay occurs every time Then what caused this one, any idea? > >> >> Regards, >> >> Nigel >> > > > > -- > Regards > dave > -- Regards dave