On Mon, Jun 2, 2014 at 9:54 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Wed, May 28, 2014 at 5:09 AM, Emmanuel Grumbach <egrumbach@xxxxxxxxx> wrote: >>> >>> I doubt I can bisect -- the trigger was a new AP, not a new kernel. I >>> can't exactly cut the AP in half :) >> >> I see.. This is really weird though. Anyway. >> >>> >>> >>> Pre-suspend, i.e., working: >>> >>> [ 20.949900] enabled = 1, wowlan = 0 >>> [ 20.950177] enabled = 1, wowlan = 0 >>> [ 21.614016] enabled = 1, wowlan = 0 >>> [ 21.614658] enabled = 1, wowlan = 0 >>> [ 42.667586] enabled = 0, wowlan = 0 >>> [ 42.672514] enabled = 1, wowlan = 0 >>> [ 53.088165] fuse init (API version 7.23) >>> [ 53.102082] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts >>> [ 53.130945] SELinux: initialized (dev fusectl, type fusectl), uses >>> genfs_contexts >>> [ 85.627558] enabled = 0, wowlan = 0 >>> [ 85.631686] enabled = 1, wowlan = 0 >>> [ 134.649346] e1000e: em1 NIC Link is Down >>> [ 137.682277] wlan0: deauthenticating from 02:c6:26:cc:b4:c7 by local >>> choice (Reason: 3=DEAUTH_LEAVING) >>> [ 137.682780] enabled = 0, wowlan = 0 >>> [ 137.693889] enabled = 0, wowlan = 0 >>> >>> Post-suspend, i.e., not working: >>> >>> [ 144.406303] enabled = 1, wowlan = 0 >>> [ 144.406496] enabled = 1, wowlan = 0 >>> [ 145.026827] enabled = 1, wowlan = 0 >>> [ 145.028211] enabled = 1, wowlan = 0 >>> [ 165.688632] enabled = 0, wowlan = 0 >>> [ 165.689960] enabled = 0, wowlan = 0 >>> [ 165.693988] enabled = 1, wowlan = 0 >>> [ 165.694245] enabled = 1, wowlan = 0 >>> [ 208.641426] enabled = 0, wowlan = 0 >>> [ 208.641786] enabled = 0, wowlan = 0 >>> [ 208.647499] enabled = 1, wowlan = 0 >>> [ 208.647639] enabled = 1, wowlan = 0 >>> [ 271.435558] enabled = 0, wowlan = 0 >>> [ 271.435767] enabled = 0, wowlan = 0 >>> [ 271.440125] enabled = 1, wowlan = 0 >>> [ 271.440405] enabled = 1, wowlan = 0 >>> >>> With even more instrumentation added, I did get a glitch before >>> suspend/resume, but it came with more than two power setting updates. >>> Logs and patch attached, complete with call stacks. >>> >> >> I don't see any callstacks? >> Doesn't matter though. > > I think the callstacks were in the attachment. I could have messed up, though. > > Anyway, I don't buy the theory that this is caused by the firmware > going out to lunch. The queues files in debugfs show the rx queue > chugging along and all of the tx queues have read_ptr == write_ptr. > Wireshark shows incoming broadcast traffic, too. I'd guess that the > problem is more likely to be that the card is failing to wake up and > notice pending data in the TIM. OTOH, with iwlwifi.11n_disable=4 (no rx A-MPDU), I seem to be doing pretty well. I'll test a stock kernel configured like that for the next few days. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
