linux-kernel - Re: [Bugme-new] [Bug 15551] New: wifi doesn't work after resume from s2ram on ThinkPad T61

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] [day] [month] [year] [list]

Message-Id: <201003222204.47169.rjw@sisk.pl>
Date:	Mon, 22 Mar 2010 22:04:47 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	alex.vizor@...il.com
Subject: Re: [Bugme-new] [Bug 15551] New: wifi doesn't work after resume from s2ram on ThinkPad T61

On Monday 22 March 2010, Andrew Morton wrote:
> On Tue, 16 Mar 2010 22:03:53 GMT
> bugzilla-daemon@...zilla.kernel.org wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=15551
> 
> This'll be a post-2.6.33 regression.
> 
> >            Summary: wifi doesn't work after resume from s2ram on ThinkPad
> >                     T61
> >            Product: Networking
> >            Version: 2.5
> >     Kernel Version: 2.6.34-rc1
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: Wireless
> >         AssignedTo: networking_wireless@...nel-bugs.osdl.org
> >         ReportedBy: alex.vizor@...il.com
> >         Regression: Yes
> > 
> > 
> > Created an attachment (id=25561)
> >  --> (http://bugzilla.kernel.org/attachment.cgi?id=25561)
> > dmesg
> > 
> > Hi. I caught this after several resumes from s2ram, from s2disk it works ok.
> > 
> > I attached my dmesg. Please inform me if I can do the report more useful.
> > 
> 
> This:
> 
> : [22456.252166] s2ram: page allocation failure. order:4, mode:0x4010
> : [22456.252172] Pid: 23558, comm: s2ram Not tainted 2.6.34-rc1 #1
> : [22456.252175] Call Trace:
> : [22456.252187]  [<ffffffff810b8dc9>] __alloc_pages_nodemask+0x565/0x60c
> : [22456.252195]  [<ffffffff810de879>] alloc_pages_current+0x90/0x99
> : [22456.252201]  [<ffffffff810b7a9e>] __get_free_pages+0x9/0x46
> : [22456.252221]  [<ffffffffa03b4bdd>] iwl_tx_queue_init+0xf2/0x2a1 [iwlcore]
> : [22456.252227]  [<ffffffffa03b4f12>] iwl_txq_ctx_reset+0x186/0x20c [iwlcore]
> : [22456.252233]  [<ffffffffa03ae41c>] iwl_hw_nic_init+0x124/0x139 [iwlcore]
> 
> Rafael, this is fallout from 452aa6999e6703ffbddd7f6ea124d3968915f3e3
> ("mm/pm: force GFP_NOIO during suspend/hibernation and resume"). 
> Wireless was previously doing this stupidly-large allocation with
> GFP_KERNEL.  But I think the above change is what flipped it to
> __GFP_WAIT, which caused the page allocator to go into lame-and-sucky
> mode, so the allocation failed.

Well, technically the problem is in the driver.  It shouldn't do anything like
this during suspend/resume.  I'll try to figure out how to fix this at minimal cost.

> (btw, that was a bug - 452aa6999e6703ffbddd7f6ea124d3968915f3e3 should
> have cleared the __GFP_WAIT bit too).

Hmm, should it?  That would make all allocations GFP_ATOMIC and is this what
we really want?

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