On Fri, 2013-02-22 at 22:14 -0800, Marc MERLIN wrote: > On Wed, Feb 20, 2013 at 10:15:03AM +0100, Johannes Berg wrote: > > On Wed, 2013-02-20 at 10:12 +0100, Johannes Berg wrote: > > > On Tue, 2013-02-19 at 08:21 -0800, Eric Dumazet wrote: > > > > On Tue, 2013-02-19 at 11:03 +0100, Johannes Berg wrote: > > > > > On Mon, 2013-02-18 at 21:17 -0800, Eric Dumazet wrote: > > > > > > > > > > > > chrome: page allocation failure: order:1, mode:0x4020 > > > > > > > Pid: 8730, comm: chrome Tainted: G O 3.7.8-amd64-preempt-20121226-fixwd #1 > > > > > > > Call Trace: > > > > > > > <IRQ> [<ffffffff810d5f38>] warn_alloc_failed+0x117/0x12c > > > > > > > > > > > You could try to load iwlwifi with amsdu_size_8K set to 0 (disable) > > > > > > > > > > > > It should hopefully use order-0 pages > > > > > > > > > > It will, do that then, unfortunately it can't switch at runtime because > > > > > it advertised this support to the access point or clients. > > > > > > > > What are the drawbacks of setting amsdu_size_8K to 0 by default ? > > > > > > We're discussing this now, the only downside would be that we couldn't > > > receive 8k A-MSDUs. Thing is, practically nobody uses A-MSDU anyway, and > > > even when I suspect the difference between 4k and 8k won't be huge. > > > > OTOH, this affects the protocol, and when you really can't allocate any > > order-1 pages you pointed out yourself that many other things also won't > > work, so I'm not really sure it makes a big difference if we change the > > driver? > > That as an unscientific test, but when I did the NFS eats all my pages > test using ethernet, my system didn't hang like it did with iwlagn. > > So while the NFS code is definitely doing something wrong when it uses > its default huge buffers, the e1000e code deals with it without hanging > my system. > > So thanks for trying to improve the iwlagn code to avoid those system > lockups. We'll be submitting a patch to make single pages default. johannes -- 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
