[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a8e1da0912110110m425d8544xdcdf1f5a9ed8ab17@mail.gmail.com>
Date: Fri, 11 Dec 2009 17:10:56 +0800
From: Dave Young <hidave.darkstar@...il.com>
To: Nigel Cunningham <ncunningham@...a.org.au>
Cc: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
linux-wireless <linux-wireless@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>, Zhu Yi <yi.zhu@...el.com>
Subject: Re: mmotm-2009-12-08-17-45 resume slowly
On Fri, Dec 11, 2009 at 9:47 AM, Dave Young <hidave.darkstar@...il.com> wrote:
> On Fri, Dec 11, 2009 at 6:11 AM, Nigel Cunningham
> <ncunningham@...a.org.au> 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
--
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