On Sat, 16 May 2009 21:20:45 +0200 (CEST) "Rafael J. Wysocki" <[email protected]> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.29. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319
> Subject : Page allocation failures with b43 and p54usb
> Submitter : Larry Finger <[email protected]>
> Date : 2009-04-29 21:01 (18 days old)
> References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> Handled-By : Johannes Berg <[email protected]>
>
>
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?
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.
Hi Andrew,
On Sat, 16 May 2009 21:20:45 +0200 (CEST) "Rafael J. Wysocki"
<[email protected]> wrote:
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.29. ?Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry ? ? : http://bugzilla.kernel.org/show_bug.cgi?id=13319
>> Subject ? ? ? ? ? ? ? : Page allocation failures with b43 and p54usb
>> Submitter ? ? : Larry Finger <[email protected]>
>> Date ? ? ? ? ?: 2009-04-29 21:01 (18 days old)
>> References ? ?: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>> Handled-By ? ?: Johannes Berg <[email protected]>
On Sun, May 17, 2009 at 2:36 AM, Andrew Morton
<[email protected]> 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?
>
> 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 wonder if this is related:
http://bugzilla.kernel.org/show_bug.cgi?id=13069
Both point to post 2.6.29... Hmm.
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