linux-kernel - Re: mmotm-2009-12-08-17-45 resume slowly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a8e1da0912101747l7e0e9fcbh8a7007e95e7c8509@mail.gmail.com>
Date:	Fri, 11 Dec 2009 09:47:54 +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>
Subject: Re: mmotm-2009-12-08-17-45 resume slowly

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?
>
> [...]
>
>>>> [  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

>
> Regards,
>
> Nigel
>



-- 
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/