Skip to contentSkip to conversation

New: wifi doesn't work after resume from s2ram on ThinkPad T61

Bugme-new Andrew Morton 2 participants 2 messages Mar 22, 2010 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

#1 lore raw
Quoted 1 line · On Tue, 16 Mar 2010 22:03:53 GMT [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=15551

This'll be a post-2.6.33 regression.

Quoted 17 lines
           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: [email protected]
        ReportedBy: [email protected]
        Regression: Yes
Quoted 8 lines

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.

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

#2 lore raw
Quoted 45 lines · Andrew Morton
Quoted 1 line · On Tue, 16 Mar 2010 22:03:53 GMT [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=15551

This'll be a post-2.6.33 regression.

Quoted 17 lines
           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: [email protected]
        ReportedBy: [email protected]
        Regression: Yes
Quoted 8 lines

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]
Quoted 6 lines

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.

Quoted 2 lines

(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