From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from fmailhost01.isp.att.net ([204.127.217.101]:35871 "EHLO fmailhost01.isp.att.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751951AbZEQXQq (ORCPT ); Sun, 17 May 2009 19:16:46 -0400 Message-ID: <4A109AC5.7040008@lwfinger.net> Date: Sun, 17 May 2009 18:16:21 -0500 From: Larry Finger MIME-Version: 1.0 To: Andrew Morton CC: "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Johannes Berg , linux-wireless@vger.kernel.org Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb References: <_AjETDMbIoL.A.DcH.RYzDKB@chimera> <385Pu-agh7M.A.SU.iYzDKB@chimera> <20090516163610.8a012268.akpm@linux-foundation.org> In-Reply-To: <20090516163610.8a012268.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: Andrew Morton wrote: > > Well.. order-1 GFP_ATOMIC allocations are unreliable. The networking > code should hanlde the situation and recover. I assume that is > happening in this case? Yes, the driver has recovered in all cases so far. > Perhaps we did something in that code after 2.6.29 which increased the > frequency of the order-1 allocation attempts? Maybe earlier kernels > used order-0 all the time? Those are much more reliable. I think something happened to change the allocation as I never saw these O(1) failures before with these particular drivers. I put in a few test printk's and the buffers were 700-800 bytes long, and I would not expect them to require more than an O(0) allocation. I pushed 2.6.30-rc6 hard for ~12 hours without any recurrence of the problem. Given the relative infrequency of the error, this certainly does not indicate a fix in recent code. I will be trying to force it again. Larry