[Bug #13319] Page allocation failures with b43 and p54usb

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Andrew Morton]

On Sat, 16 May 2009 21:20:45 +0200 (CEST) "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> 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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date		: 2009-04-29 21:01 (18 days old)
> References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> 
> 

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.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi Andrew,

On Sat, 16 May 2009 21:20:45 +0200 (CEST) "Rafael J. Wysocki"
<rjw-KKrjLPT3xs0@public.gmane.org> 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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>> Date          : 2009-04-29 21:01 (18 days old)
>> References    : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>> Handled-By    : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

On Sun, May 17, 2009 at 2:36 AM, Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Rafael J. Wysocki 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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date		: 2009-04-29 21:01 (18 days old)
> References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

I have been unable to repeat the problem with recent kernels - I am now running
2.6.30-rc6. This regression should probably be dropped even though it may show
up when 2.6.30 is released.

Larry

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (40 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Rafael J. Wysocki 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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date		: 2009-04-29 21:01 (40 days old)
> References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

This bug is extremely difficult to pin down. I cannot reproduce it at
will. The system has to be up for a long time, which is difficult with
testing the late RC's of 2.6.30 and the code in wireless-testing so
that new bugs don't end up in 2.6.31-RCX. That said, it still was in
2.6.30-RC6 and I'm not aware of any changes since that would fix it.

My operating kernel is patched with additional diagnostics to help me
understand why a kmalloc request for a buffer of 1390 bytes suddenly
ends up as an O(1) request. Unfortunately, I don't have any answers.

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi Larry,

On Sun, Jun 7, 2009 at 4:10 PM, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:
> Rafael J. Wysocki 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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>> Date          : 2009-04-29 21:01 (40 days old)
>> References    : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>> Handled-By    : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>
> This bug is extremely difficult to pin down. I cannot reproduce it at
> will. The system has to be up for a long time, which is difficult with
> testing the late RC's of 2.6.30 and the code in wireless-testing so
> that new bugs don't end up in 2.6.31-RCX. That said, it still was in
> 2.6.30-RC6 and I'm not aware of any changes since that would fix it.
>
> My operating kernel is patched with additional diagnostics to help me
> understand why a kmalloc request for a buffer of 1390 bytes suddenly
> ends up as an O(1) request. Unfortunately, I don't have any answers.

Looking at the out-of-memory trace, there's still memory available but
the pskb_expand_head() allocation is GFP_ATOMIC so there's not much
the page allocator can do here. The amount of memory consumed by
inactive_file is pretty high so maybe the problem is related to the
recent mm/vmscan.c changes. Lets copy some more mm developers and see
if they can help out.

                        Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Rik van Riel]

Pekka Enberg wrote:
> Hi Larry,
> 
> On Sun, Jun 7, 2009 at 4:10 PM, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:
>> Rafael J. Wysocki 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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>>> Date          : 2009-04-29 21:01 (40 days old)
>>> References    : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>>> Handled-By    : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>> This bug is extremely difficult to pin down. I cannot reproduce it at
>> will. The system has to be up for a long time, which is difficult with
>> testing the late RC's of 2.6.30 and the code in wireless-testing so
>> that new bugs don't end up in 2.6.31-RCX. That said, it still was in
>> 2.6.30-RC6 and I'm not aware of any changes since that would fix it.
>>
>> My operating kernel is patched with additional diagnostics to help me
>> understand why a kmalloc request for a buffer of 1390 bytes suddenly
>> ends up as an O(1) request. Unfortunately, I don't have any answers.
> 
> Looking at the out-of-memory trace, there's still memory available but
> the pskb_expand_head() allocation is GFP_ATOMIC so there's not much
> the page allocator can do here. The amount of memory consumed by
> inactive_file is pretty high so maybe the problem is related to the
> recent mm/vmscan.c changes. Lets copy some more mm developers and see
> if they can help out.

That is a very strange trace.  The Mem-Info indicates
that the system has more than enough memory free, and
also enough memory in higher-order free blocks.

This would indicate a bug somewhere in the page
allocator - this memory should have been given to this
allocation request.

-- 
All rights reversed.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Pekka Enberg wrote:
>>
>> Hi Larry,
>>
>> On Sun, Jun 7, 2009 at 4:10 PM, Larry Finger <Larry.Finger@lwfinger.net>
>> wrote:
>>>
>>> Rafael J. Wysocki 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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>>>> Date          : 2009-04-29 21:01 (40 days old)
>>>> References    : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>>>> Handled-By    : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>>>
>>> This bug is extremely difficult to pin down. I cannot reproduce it at
>>> will. The system has to be up for a long time, which is difficult with
>>> testing the late RC's of 2.6.30 and the code in wireless-testing so
>>> that new bugs don't end up in 2.6.31-RCX. That said, it still was in
>>> 2.6.30-RC6 and I'm not aware of any changes since that would fix it.
>>>
>>> My operating kernel is patched with additional diagnostics to help me
>>> understand why a kmalloc request for a buffer of 1390 bytes suddenly
>>> ends up as an O(1) request. Unfortunately, I don't have any answers.
>>
>> Looking at the out-of-memory trace, there's still memory available but
>> the pskb_expand_head() allocation is GFP_ATOMIC so there's not much
>> the page allocator can do here. The amount of memory consumed by
>> inactive_file is pretty high so maybe the problem is related to the
>> recent mm/vmscan.c changes. Lets copy some more mm developers and see
>> if they can help out.
>
> That is a very strange trace.  The Mem-Info indicates
> that the system has more than enough memory free, and
> also enough memory in higher-order free blocks.
>
> This would indicate a bug somewhere in the page
> allocator - this memory should have been given to this
> allocation request.

Aha, I always have difficulties deciphering the traces. But lets
invite Mel to the party then!

                        Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Pekka Enberg wrote:
> On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> That is a very strange trace.  The Mem-Info indicates
>> that the system has more than enough memory free, and
>> also enough memory in higher-order free blocks.
>>
>> This would indicate a bug somewhere in the page
>> allocator - this memory should have been given to this
>> allocation request.
> 
> Aha, I always have difficulties deciphering the traces. But lets
> invite Mel to the party then!

I'm happy to see some action on this problem. As usual, I'm happy to
test patches and/or provide diagnostic output.

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[KAMEZAWA Hiroyuki]

On Sun, 07 Jun 2009 11:35:27 -0500
Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:

> Pekka Enberg wrote:
> > On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >> That is a very strange trace.  The Mem-Info indicates
> >> that the system has more than enough memory free, and
> >> also enough memory in higher-order free blocks.
> >>
> >> This would indicate a bug somewhere in the page
> >> allocator - this memory should have been given to this
> >> allocation request.
> > 
> > Aha, I always have difficulties deciphering the traces. But lets
> > invite Mel to the party then!
> 
> I'm happy to see some action on this problem. As usual, I'm happy to
> test patches and/or provide diagnostic output.
> 
One question. 

Did your system fragmented in same way as to this
(see DMA32, 10052 of order-0 pages) in older kernel ? I think you can check
fragmentation status via /proc/buddyinfo.
=
kernel: Node 0 DMA: 3*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2100kB
kernel: Node 0 DMA32: 10062*4kB 1*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 40976kB
==

Thanks,
-Kame

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Mel Gorman]

On Sun, Jun 07, 2009 at 05:32:52PM +0300, Pekka Enberg wrote:
> On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > Pekka Enberg wrote:
> >>
> >> Hi Larry,
> >>
> >> On Sun, Jun 7, 2009 at 4:10 PM, Larry Finger <Larry.Finger@lwfinger.net>
> >> wrote:
> >>>
> >>> Rafael J. Wysocki 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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> >>>> Date          : 2009-04-29 21:01 (40 days old)
> >>>> References    : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> >>>> Handled-By    : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> >>>
> >>> This bug is extremely difficult to pin down. I cannot reproduce it at
> >>> will. The system has to be up for a long time, which is difficult with
> >>> testing the late RC's of 2.6.30 and the code in wireless-testing so
> >>> that new bugs don't end up in 2.6.31-RCX. That said, it still was in
> >>> 2.6.30-RC6 and I'm not aware of any changes since that would fix it.
> >>>
> >>> My operating kernel is patched with additional diagnostics to help me
> >>> understand why a kmalloc request for a buffer of 1390 bytes suddenly
> >>> ends up as an O(1) request. Unfortunately, I don't have any answers.
> >>
> >> Looking at the out-of-memory trace, there's still memory available but
> >> the pskb_expand_head() allocation is GFP_ATOMIC so there's not much
> >> the page allocator can do here. The amount of memory consumed by
> >> inactive_file is pretty high so maybe the problem is related to the
> >> recent mm/vmscan.c changes. Lets copy some more mm developers and see
> >> if they can help out.
> >
> > That is a very strange trace.  The Mem-Info indicates
> > that the system has more than enough memory free, and
> > also enough memory in higher-order free blocks.
> >
> > This would indicate a bug somewhere in the page
> > allocator - this memory should have been given to this
> > allocation request.
> 
> Aha, I always have difficulties deciphering the traces. But lets
> invite Mel to the party then!
> 

Nothing like a party on Monday morning to get the week started!

What we appear to have is

o Allocation failure is high-order, high-priority, compound and atomic.
o swap is mostly unused, but we cannot enter direct reclaim.
o ZONE_DMA32 can be used
o The allocation path is in the slub allocator
o Are way above the order-0 watermarks so kswapd is probably not awake
o The minimum watermark for an order-0 page was about 647 pages in ZONE_DMA32
o The minimum watermark for an order-1 page was about 323 pages in ZONE_DMA32
o There are 10244 pages free at the time of the failure
o With the order-0 pages taken out for watermark calculation, there are
  182 free pages which is below the watermark of 323 pages for an
  order-1 allocation

While there is enough free memory overall, the zone watermark calculation
takes into account the order of the request. As this is an order-1 allocation,
the free order-0 pages are taken out of consideration and so the allocation
fails.

We've encountered this before and the conclusion was that the current
adjustments for watermark calculations of high-order allocations is right,
or at least there is no better alternative. In other words, the page
allocator in this instance is behaving as expected. Do we want to
revisit that discussion as to whether the watermark calculations for
high-order allocation should change? I think we'll reach the same
conclusion or at least decide that allowing the order-1 atomic
allocation to succeed here would just postpone the problem.

So the question is why are we doing a high-order atomic allocation in
this path? According to an earlier discussion on this problemn

> 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.

So, SLUB is deciding to use order-1 pages for the slab allocation.
Ordinarily, it'll get away with that because order-1 pages will be
allocated from a path that can direct reclaim. However, if a slab is
being used for atomic allocations, there is a chance that it's the
atomic request that allocates a new page for the slab.

Larry, can you post the contents of /proc/slabinfo so we can see
what size pages are being used for the kmalloc() buckets please?

Larry, you say the buffer is 700-800 bytes. Can you confirm that 800 bytes
is roughly the request size being made by ieee80211_skb_resize()?

Pekka, assuming the request size is 800 bytes, and SLUB is using order-1
pages for allocations of that size, what happened order-1 allocations
falling back to order-0 allocations as necessary. That logic exists,
right? If so, could it be broken?

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Mon, Jun 8, 2009 at 1:17 PM, Mel Gorman<mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote:
> Pekka, assuming the request size is 800 bytes, and SLUB is using order-1
> pages for allocations of that size, what happened order-1 allocations
> falling back to order-0 allocations as necessary. That logic exists,
> right? If so, could it be broken?

That logic is in allocate_slab() and if the higher order allocation
fails, we fall-back to struct kmem_cache ->min order. That in turn is
set up in calculate_sizes() to get_order(size) so it seems pretty
unlikely to me the allocation is 800 bytes. Of course, I could be
missing something here and there's a bug in oo_make() or oo_order().
Hmm.

                        Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Mel Gorman]

On Mon, Jun 08, 2009 at 01:52:05PM +0300, Pekka Enberg wrote:
> On Mon, Jun 8, 2009 at 1:17 PM, Mel Gorman<mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote:
> > Pekka, assuming the request size is 800 bytes, and SLUB is using order-1
> > pages for allocations of that size, what happened order-1 allocations
> > falling back to order-0 allocations as necessary. That logic exists,
> > right? If so, could it be broken?
> 
> That logic is in allocate_slab() and if the higher order allocation
> fails, we fall-back to struct kmem_cache ->min order. That in turn is
> set up in calculate_sizes() to get_order(size) so it seems pretty
> unlikely to me the allocation is 800 bytes. Of course, I could be
> missing something here and there's a bug in oo_make() or oo_order().
> Hmm.

Is there any chance you could hatchet together a patch
slab-allocation-failure that reports on slab allocation failures similar
to what the page allocator does? Minimally, it should tell us what
the size of the allocation was but any other information such as the
same of the slab, the size of pages it normally uses are, etc. would
also be useful.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Rik van Riel]

Mel Gorman wrote:

> We've encountered this before and the conclusion was that the current
> adjustments for watermark calculations of high-order allocations is right,
> or at least there is no better alternative. In other words, the page
> allocator in this instance is behaving as expected. Do we want to
> revisit that discussion as to whether the watermark calculations for
> high-order allocation should change? I think we'll reach the same
> conclusion or at least decide that allowing the order-1 atomic
> allocation to succeed here would just postpone the problem.

It would not just postpone the problem, it would also
bring the system closer to a state where kswapd does
something about the order-1 free areas.

This might postpone the problem indefinately.

Currently the system fails early, without kswapd
kicking in and freeing new order-1 areas.

-- 
All rights reversed.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Mel Gorman wrote:
>
> Larry, can you post the contents of /proc/slabinfo so we can see
> what size pages are being used for the kmalloc() buckets please?

The system is not generating the failures at the moment, but here is
the current state:

finger@larrylap:~/wireless-testing> cat /proc/slabinfo
slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab>
<pagesperslab> : tunables <limit> <batchcount> <sharedfactor> :
slabdata <active_slabs> <num_slabs> <sharedavail>
nfs_direct_cache       0      0    288   14    1 : tunables    0    0
   0 : slabdata      0      0      0
nfs_write_data        42     42    768   21    4 : tunables    0    0
   0 : slabdata      2      2      0
nfs_read_data         42     42    768   21    4 : tunables    0    0
   0 : slabdata      2      2      0
nfs_inode_cache       20     20   1568   20    8 : tunables    0    0
   0 : slabdata      1      1      0
nfs_page               0      0    192   21    1 : tunables    0    0
   0 : slabdata      0      0      0
rpc_buffers           30     30   2176   15    8 : tunables    0    0
   0 : slabdata      2      2      0
rpc_tasks             42     42    384   21    2 : tunables    0    0
   0 : slabdata      2      2      0
rpc_inode_cache       23     23   1408   23    8 : tunables    0    0
   0 : slabdata      1      1      0
fuse_request         351    352    720   22    4 : tunables    0    0
   0 : slabdata     16     16      0
fuse_inode           325    325   1216   13    4 : tunables    0    0
   0 : slabdata     25     25      0
ext4_inode_cache   17180  17180   1568   20    8 : tunables    0    0
   0 : slabdata    859    859      0
ext4_xattr             0      0    160   25    1 : tunables    0    0
   0 : slabdata      0      0      0
ext4_free_block_extents      0      0    128   32    1 : tunables    0
   0    0 : slabdata      0      0      0
ext4_alloc_context      0      0    216   18    1 : tunables    0    0
   0 : slabdata      0      0      0
ext4_prealloc_space      0      0    216   18    1 : tunables    0
0    0 : slabdata      0      0      0
jbd2_journal_handle     68     68    120   34    1 : tunables    0
0    0 : slabdata      2      2      0
jbd2_journal_head   3734   3784    184   22    1 : tunables    0    0
   0 : slabdata    172    172      0
jbd2_revoke_table     46     46     88   46    1 : tunables    0    0
   0 : slabdata      1      1      0
jbd2_revoke_record      0      0    128   32    1 : tunables    0    0
   0 : slabdata      0      0      0
kcopyd_job             0      0    528   15    2 : tunables    0    0
   0 : slabdata      0      0      0
dm_rq_clone_bio_info      0      0     88   46    1 : tunables    0
 0    0 : slabdata      0      0      0
dm_rq_target_io        0      0    480   17    2 : tunables    0    0
   0 : slabdata      0      0      0
dm_target_io           0      0     96   42    1 : tunables    0    0
   0 : slabdata      0      0      0
dm_io                  0      0    104   39    1 : tunables    0    0
   0 : slabdata      0      0      0
uhci_urb_priv          0      0    128   32    1 : tunables    0    0
   0 : slabdata      0      0      0
ext3_inode_cache   69341  69345   1408   23    8 : tunables    0    0
   0 : slabdata   3015   3015      0
ext3_xattr           325    325    160   25    1 : tunables    0    0
   0 : slabdata     13     13      0
journal_handle        68     68    120   34    1 : tunables    0    0
   0 : slabdata      2      2      0
journal_head        2473   4642    184   22    1 : tunables    0    0
   0 : slabdata    211    211      0
revoke_table          46     46     88   46    1 : tunables    0    0
   0 : slabdata      1      1      0
revoke_record         64     64    128   32    1 : tunables    0    0
   0 : slabdata      2      2      0
scsi_sense_cache      46     63    192   21    1 : tunables    0    0
   0 : slabdata      3      3      0
scsi_cmd_cache        28     36    320   12    1 : tunables    0    0
   0 : slabdata      3      3      0
sgpool-128            16     21   4224    7    8 : tunables    0    0
   0 : slabdata      3      3      0
sgpool-64             30     30   2176   15    8 : tunables    0    0
   0 : slabdata      2      2      0
sgpool-32             28     28   1152   14    4 : tunables    0    0
   0 : slabdata      2      2      0
sgpool-16             24     24    640   12    2 : tunables    0    0
   0 : slabdata      2      2      0
sgpool-8              44     63    384   21    2 : tunables    0    0
   0 : slabdata      3      3      0
scsi_data_buffer       0      0     96   42    1 : tunables    0    0
   0 : slabdata      0      0      0
flow_cache             0      0    168   24    1 : tunables    0    0
   0 : slabdata      0      0      0
cfq_io_context        93    102    240   17    1 : tunables    0    0
   0 : slabdata      6      6      0
cfq_queue             97    102    240   17    1 : tunables    0    0
   0 : slabdata      6      6      0
mqueue_inode_cache     23     23   1408   23    8 : tunables    0    0
   0 : slabdata      1      1      0
isofs_inode_cache      0      0   1088   15    4 : tunables    0    0
   0 : slabdata      0      0      0
kioctx                 0      0    640   12    2 : tunables    0    0
   0 : slabdata      0      0      0
kiocb                  0      0    320   12    1 : tunables    0    0
   0 : slabdata      0      0      0
inotify_event_cache     72     72    112   36    1 : tunables    0
0    0 : slabdata      2      2      0
inotify_watch_cache    224    224    144   28    1 : tunables    0
0    0 : slabdata      8      8      0
fasync_cache          42     42     96   42    1 : tunables    0    0
   0 : slabdata      1      1      0
shmem_inode_cache   1485   1488   1344   12    4 : tunables    0    0
   0 : slabdata    124    124      0
nsproxy                0      0    120   34    1 : tunables    0    0
   0 : slabdata      0      0      0
posix_timers_cache     26     26    304   13    1 : tunables    0    0
   0 : slabdata      2      2      0
uid_cache             24     24    320   12    1 : tunables    0    0
   0 : slabdata      2      2      0
UNIX                 354    360   1344   12    4 : tunables    0    0
   0 : slabdata     30     30      0
ip_mrt_cache           0      0    192   21    1 : tunables    0    0
   0 : slabdata      0      0      0
UDP-Lite               0      0   1216   13    4 : tunables    0    0
   0 : slabdata      0      0      0
tcp_bind_bucket       64     64    128   32    1 : tunables    0    0
   0 : slabdata      2      2      0
inet_peer_cache       21     21    192   21    1 : tunables    0    0
   0 : slabdata      1      1      0
secpath_cache          0      0    128   32    1 : tunables    0    0
   0 : slabdata      0      0      0
xfrm_dst_cache         0      0    448   18    2 : tunables    0    0
   0 : slabdata      0      0      0
ip_fib_alias           0      0    104   39    1 : tunables    0    0
   0 : slabdata      0      0      0
ip_fib_hash           56     56    144   28    1 : tunables    0    0
   0 : slabdata      2      2      0
ip_dst_cache          36     36    448   18    2 : tunables    0    0
   0 : slabdata      2      2      0
arp_cache             36     36    448   18    2 : tunables    0    0
   0 : slabdata      2      2      0
RAW                   14     14   1152   14    4 : tunables    0    0
   0 : slabdata      1      1      0
UDP                   26     26   1216   13    4 : tunables    0    0
   0 : slabdata      2      2      0
tw_sock_TCP           32     32    256   16    1 : tunables    0    0
   0 : slabdata      2      2      0
request_sock_TCP      21     21    192   21    1 : tunables    0    0
   0 : slabdata      1      1      0
TCP                   34     45   2176   15    8 : tunables    0    0
   0 : slabdata      3      3      0
eventpoll_pwq        110    112    144   28    1 : tunables    0    0
   0 : slabdata      4      4      0
eventpoll_epi         94     96    256   16    1 : tunables    0    0
   0 : slabdata      6      6      0
blkdev_queue          22     22   2736   11    8 : tunables    0    0
   0 : slabdata      2      2      0
blkdev_requests       40     54    440   18    2 : tunables    0    0
   0 : slabdata      3      3      0
blkdev_ioc           101    105    192   21    1 : tunables    0    0
   0 : slabdata      5      5      0
bio-0                 32     32    256   16    1 : tunables    0    0
   0 : slabdata      2      2      0
biovec-256             7      7   4224    7    8 : tunables    0    0
   0 : slabdata      1      1      0
biovec-128            30     30   2176   15    8 : tunables    0    0
   0 : slabdata      2      2      0
biovec-64             28     28   1152   14    4 : tunables    0    0
   0 : slabdata      2      2      0
biovec-16             42     42    384   21    2 : tunables    0    0
   0 : slabdata      2      2      0
sock_inode_cache     397    406   1152   14    4 : tunables    0    0
   0 : slabdata     29     29      0
skbuff_fclone_cache     32     32    512   16    2 : tunables    0
0    0 : slabdata      2      2      0
skbuff_head_cache    593    600    320   12    1 : tunables    0    0
   0 : slabdata     50     50      0
file_lock_cache       39     42    288   14    1 : tunables    0    0
   0 : slabdata      3      3      0
Acpi-Operand        1301   1316    144   28    1 : tunables    0    0
   0 : slabdata     47     47      0
Acpi-ParseExt         56     56    144   28    1 : tunables    0    0
   0 : slabdata      2      2      0
Acpi-Parse            68     68    120   34    1 : tunables    0    0
   0 : slabdata      2      2      0
Acpi-State            52     52    152   26    1 : tunables    0    0
   0 : slabdata      2      2      0
Acpi-Namespace       897    897    104   39    1 : tunables    0    0
   0 : slabdata     23     23      0
task_delay_info      247    255    232   17    1 : tunables    0    0
   0 : slabdata     15     15      0
taskstats             40     40    400   20    2 : tunables    0    0
   0 : slabdata      2      2      0
proc_inode_cache    1709   1725   1088   15    4 : tunables    0    0
   0 : slabdata    115    115      0
sigqueue              34     34    232   17    1 : tunables    0    0
   0 : slabdata      2      2      0
radix_tree_node    22109  22126    624   13    2 : tunables    0    0
   0 : slabdata   1702   1702      0
bdev_cache            42     42   1536   21    8 : tunables    0    0
   0 : slabdata      2      2      0
sysfs_dir_cache    12246  12246    152   26    1 : tunables    0    0
   0 : slabdata    471    471      0
mnt_cache             47     48    320   12    1 : tunables    0    0
   0 : slabdata      4      4      0
filp                2971   3150    384   21    2 : tunables    0    0
   0 : slabdata    150    150      0
inode_cache         3185   3195   1040   15    4 : tunables    0    0
   0 : slabdata    213    213      0
dentry            274295 274300    312   13    1 : tunables    0    0
   0 : slabdata  21100  21100      0
names_cache           14     14   4224    7    8 : tunables    0    0
   0 : slabdata      2      2      0
key_jar                0      0    320   12    1 : tunables    0    0
   0 : slabdata      0      0      0
buffer_head       120232 120244    176   23    1 : tunables    0    0
   0 : slabdata   5228   5228      0
vm_area_struct     10385  10768    248   16    1 : tunables    0    0
   0 : slabdata    673    673      0
mm_struct            111    140   1152   14    4 : tunables    0    0
   0 : slabdata     10     10      0
fs_cache             125    147    192   21    1 : tunables    0    0
   0 : slabdata      7      7      0
files_cache          122    144    896   18    4 : tunables    0    0
   0 : slabdata      8      8      0
signal_cache         164    192   1024   16    4 : tunables    0    0
   0 : slabdata     12     12      0
sighand_cache        161    182   2240   14    8 : tunables    0    0
   0 : slabdata     13     13      0
task_xstate           66     72    640   12    2 : tunables    0    0
   0 : slabdata      6      6      0
task_struct          241    256   3872    8    8 : tunables    0    0
   0 : slabdata     32     32      0
cred_jar             366    560    256   16    1 : tunables    0    0
   0 : slabdata     35     35      0
anon_vma            2206   2310    136   30    1 : tunables    0    0
   0 : slabdata     77     77      0
pid                  257    273    192   21    1 : tunables    0    0
   0 : slabdata     13     13      0
shared_policy_node      0      0    120   34    1 : tunables    0    0
   0 : slabdata      0      0      0
numa_policy           42     42     96   42    1 : tunables    0    0
   0 : slabdata      1      1      0
idr_layer_cache      403    403    616   13    2 : tunables    0    0
   0 : slabdata     31     31      0
kmalloc-8192          28     30   8264    3    8 : tunables    0    0
   0 : slabdata     10     10      0
kmalloc-4096         661    665   4168    7    8 : tunables    0    0
   0 : slabdata     95     95      0
kmalloc-2048         335    360   2120   15    8 : tunables    0    0
   0 : slabdata     24     24      0
kmalloc-1024         479    609   1096   29    8 : tunables    0    0
   0 : slabdata     21     21      0
kmalloc-512          783    784    584   14    2 : tunables    0    0
   0 : slabdata     56     56      0
kmalloc-256          535    552    328   12    1 : tunables    0    0
   0 : slabdata     46     46      0
kmalloc-128          309    360    200   20    1 : tunables    0    0
   0 : slabdata     18     18      0
kmalloc-64          2430   2520    136   30    1 : tunables    0    0
   0 : slabdata     84     84      0
kmalloc-32           656    663    104   39    1 : tunables    0    0
   0 : slabdata     17     17      0
kmalloc-16          2250   2254     88   46    1 : tunables    0    0
   0 : slabdata     49     49      0
kmalloc-8           3619   3621     80   51    1 : tunables    0    0
   0 : slabdata     71     71      0
kmalloc-192         1449   1455    264   15    1 : tunables    0    0
   0 : slabdata     97     97      0
kmalloc-96           726    816    168   24    1 : tunables    0    0
   0 : slabdata     34     34      0
kmem_cache_node        0      0    176   23    1 : tunables    0    0
   0 : slabdata      0      0      0

>
> Larry, you say the buffer is 700-800 bytes. Can you confirm that 800
bytes
> is roughly the request size being made by ieee80211_skb_resize()?

For some of the failures, the size was in the 700-800 range, but the
ones I found in my logs called pskb_expand_head() with skb->data_len
of 1962. For those calls, head_need and tail_need were both 0.

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Mel Gorman]

On Mon, Jun 08, 2009 at 09:20:23AM -0400, Rik van Riel wrote:
> Mel Gorman wrote:
>
>> We've encountered this before and the conclusion was that the current
>> adjustments for watermark calculations of high-order allocations is right,
>> or at least there is no better alternative. In other words, the page
>> allocator in this instance is behaving as expected. Do we want to
>> revisit that discussion as to whether the watermark calculations for
>> high-order allocation should change? I think we'll reach the same
>> conclusion or at least decide that allowing the order-1 atomic
>> allocation to succeed here would just postpone the problem.
>
> It would not just postpone the problem, it would also
> bring the system closer to a state where kswapd does
> something about the order-1 free areas.
>
> This might postpone the problem indefinately.
>

How do you figure it does not just postpone the problem? If there are a batch
of order-1 allocations that come in like this, it will eventually deplete
the higher-order pages and then fail because kswapd is not getting woken up.

Minimally, if we were to ignore the watermarks, there would need to be logic
that says

	"If a high-order allocation would fail due to high-order watermarks
	not being met, but the watermarks are ok from an order-0 perspective
	and the high-order page is available, then grant the allocation but
	wake up kswapd as if the order-1 allocation had failed to get the
	high-order watermarks back in shape"

> Currently the system fails early, without kswapd
> kicking in and freeing new order-1 areas.
>

If the allocation was granted, then kswapd will still not kick in.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka J Enberg]

Hi Mel,

On Mon, 8 Jun 2009, Mel Gorman wrote:
> Is there any chance you could hatchet together a patch
> slab-allocation-failure that reports on slab allocation failures similar
> to what the page allocator does? Minimally, it should tell us what
> the size of the allocation was but any other information such as the
> same of the slab, the size of pages it normally uses are, etc. would
> also be useful.

Would something like this be sufficient? Figuring out the actual _size_ 
passed to kmalloc() is pretty difficult as then we would need to do the 
NULL test in fastpath code or pass the argument deeper in the call-chain.

			Pekka

diff --git a/mm/slub.c b/mm/slub.c
index 65ffda5..b5acf18 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1565,6 +1565,8 @@ new_slab:
 		c->page = new;
 		goto load_freelist;
 	}
+	printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n",
+		s->name, s->size, node, gfpflags);
 	return NULL;
 debug:
 	if (!alloc_debug_processing(s, c->page, object, addr))

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Mel Gorman]

On Mon, Jun 08, 2009 at 04:58:10PM +0300, Pekka J Enberg wrote:
> Hi Mel,
> 
> On Mon, 8 Jun 2009, Mel Gorman wrote:
> > Is there any chance you could hatchet together a patch
> > slab-allocation-failure that reports on slab allocation failures similar
> > to what the page allocator does? Minimally, it should tell us what
> > the size of the allocation was but any other information such as the
> > same of the slab, the size of pages it normally uses are, etc. would
> > also be useful.
> 
> Would something like this be sufficient? Figuring out the actual _size_ 
> passed to kmalloc() is pretty difficult as then we would need to do the 
> NULL test in fastpath code or pass the argument deeper in the call-chain.
> 

It's much better than nothing. In the event of an allocation failure, we'll
know which kmalloc bucket it's coming out of so we'll have a limited range
of possible buffer sizes.

I have some suggestions on what we're outputting though.

> 			Pekka
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 65ffda5..b5acf18 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1565,6 +1565,8 @@ new_slab:
>  		c->page = new;
>  		goto load_freelist;
>  	}
> +	printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n",
> +		s->name, s->size, node, gfpflags);

size could be almost anything here for a casual reader. You are
outputting the size of the object plus its metadata so the name should
reflect that. I think it would be better to output objsize= and the
object size without the metadata overhead. What do you think?

In addition, include how many objects there are per-slab and include what
the order is being passed to the page allocator when allocating new slabs.
Would that be enough to determine if fallback-to-smaller orders occured?

>  	return NULL;
>  debug:
>  	if (!alloc_debug_processing(s, c->page, object, addr))
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Mon, 8 Jun 2009, Mel Gorman wrote:

> In addition, include how many objects there are per-slab and include what
> the order is being passed to the page allocator when allocating new slabs.
> Would that be enough to determine if fallback-to-smaller orders occured?

There is a per slab counter ORDER_FALLBACK that is increased for
allocations that required fallback.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

KAMEZAWA Hiroyuki wrote:
> On Sun, 07 Jun 2009 11:35:27 -0500
> Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:
> 
>> Pekka Enberg wrote:
>>> On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>> That is a very strange trace.  The Mem-Info indicates
>>>> that the system has more than enough memory free, and
>>>> also enough memory in higher-order free blocks.
>>>>
>>>> This would indicate a bug somewhere in the page
>>>> allocator - this memory should have been given to this
>>>> allocation request.
>>> Aha, I always have difficulties deciphering the traces. But lets
>>> invite Mel to the party then!
>> I'm happy to see some action on this problem. As usual, I'm happy to
>> test patches and/or provide diagnostic output.
>>
> One question. 
> 
> Did your system fragmented in same way as to this
> (see DMA32, 10052 of order-0 pages) in older kernel ? I think you can check
> fragmentation status via /proc/buddyinfo.
> =
> kernel: Node 0 DMA: 3*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
> 1*1024kB 0*2048kB 0*4096kB = 2100kB
> kernel: Node 0 DMA32: 10062*4kB 1*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB
> 1*512kB 0*1024kB 0*2048kB 0*4096kB = 40976kB
> ==

The current system has not been up very long and does not show the
fragmentation:

finger@larrylap:~/wireless-testing> cat /proc/buddyinfo
Node 0, zone      DMA      4      5      4      2      4      1      2
     0      1      0      0
Node 0, zone    DMA32    261     78     46     55     61     54     37
    17     14     12    262

After I did a git pull and a kernel build with the sources on an
NFS-mounted volume, the fragmentation increased:

Node 0, zone      DMA      4      5      4      2      4      1      2
     0      1      0      0
Node 0, zone    DMA32   2213   1924   1292    705    285     81     25
     8      5      4    141

After a git pull and a kernel build on a second NFS-mounted tree:

Node 0, zone      DMA      4      5      4      2      4      1      2
     0      1      0      0
Node 0, zone    DMA32   3127   3058   1989    756    401    142     56
    14      5      3     12

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi Mel,

On Mon, 2009-06-08 at 15:12 +0100, Mel Gorman wrote:
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 65ffda5..b5acf18 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1565,6 +1565,8 @@ new_slab:
> >  		c->page = new;
> >  		goto load_freelist;
> >  	}
> > +	printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n",
> > +		s->name, s->size, node, gfpflags);
> 
> size could be almost anything here for a casual reader. You are
> outputting the size of the object plus its metadata so the name should
> reflect that. I think it would be better to output objsize= and the
> object size without the metadata overhead. What do you think?
> 
> In addition, include how many objects there are per-slab and include what
> the order is being passed to the page allocator when allocating new slabs.
> Would that be enough to determine if fallback-to-smaller orders occured?

So how about something like this then?

			Pekka

diff --git a/mm/slub.c b/mm/slub.c
index 65ffda5..a03dbe8 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1484,6 +1484,58 @@ static inline int node_match(struct kmem_cache_cpu *c, int node)
 	return 1;
 }
 
+static int count_free(struct page *page)
+{
+	return page->objects - page->inuse;
+}
+
+static unsigned long count_partial(struct kmem_cache_node *n,
+					int (*get_count)(struct page *))
+{
+	unsigned long flags;
+	unsigned long x = 0;
+	struct page *page;
+
+	spin_lock_irqsave(&n->list_lock, flags);
+	list_for_each_entry(page, &n->partial, lru)
+		x += get_count(page);
+	spin_unlock_irqrestore(&n->list_lock, flags);
+	return x;
+}
+
+static noinline void
+slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
+{
+	int node;
+
+	printk(KERN_WARNING
+		"SLUB: Unable to allocate memory on node %d (gfp=%x)\n",
+		nid, gfpflags);
+	printk(KERN_WARNING "  cache: %s, object size: %d, buffer size: %d, "
+		"default order: %d, min order: %d\n", s->name, s->objsize,
+		s->size, oo_order(s->oo), oo_order(s->min));
+
+	for_each_online_node(node) {
+		struct kmem_cache_node *n = get_node(s, node);
+		unsigned long nr_partials;
+		unsigned long nr_slabs;
+		unsigned long nr_objs;
+		unsigned long nr_free;
+
+		if (!n)
+			continue;
+
+		nr_partials = n->nr_partial;
+		nr_slabs = atomic_long_read(&n->nr_slabs);
+		nr_objs = atomic_long_read(&n->total_objects);
+		nr_free = count_partial(n, count_free);
+
+		printk(KERN_WARNING
+			"  node %d: partials: %ld, slabs: %ld, objs: %ld, free: %ld\n",
+			node, nr_partials, nr_slabs, nr_objs, nr_free);
+	}
+}
+
 /*
  * Slow path. The lockless freelist is empty or we need to perform
  * debugging duties.
@@ -1565,6 +1617,7 @@ new_slab:
 		c->page = new;
 		goto load_freelist;
 	}
+	slab_out_of_memory(s, gfpflags, node);
 	return NULL;
 debug:
 	if (!alloc_debug_processing(s, c->page, object, addr))
@@ -3318,20 +3371,6 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags,
 }
 
 #ifdef CONFIG_SLUB_DEBUG
-static unsigned long count_partial(struct kmem_cache_node *n,
-					int (*get_count)(struct page *))
-{
-	unsigned long flags;
-	unsigned long x = 0;
-	struct page *page;
-
-	spin_lock_irqsave(&n->list_lock, flags);
-	list_for_each_entry(page, &n->partial, lru)
-		x += get_count(page);
-	spin_unlock_irqrestore(&n->list_lock, flags);
-	return x;
-}
-
 static int count_inuse(struct page *page)
 {
 	return page->inuse;
@@ -3342,11 +3381,6 @@ static int count_total(struct page *page)
 	return page->objects;
 }
 
-static int count_free(struct page *page)
-{
-	return page->objects - page->inuse;
-}
-
 static int validate_slab(struct kmem_cache *s, struct page *page,
 						unsigned long *map)
 {

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Mon, Jun 8, 2009 at 5:12 PM, Mel Gorman<mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote:
> In addition, include how many objects there are per-slab and include what
> the order is being passed to the page allocator when allocating new slabs.
> Would that be enough to determine if fallback-to-smaller orders occured?

Well, if the slab_out_of_memory() is called, we already know the
higher order allocation failed _and_ the fallback allocation failed.
So yes, it would be enough.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Tue, 9 Jun 2009, Pekka Enberg wrote:

> Hi Mel,
> 
> On Mon, 2009-06-08 at 15:12 +0100, Mel Gorman wrote:
> > > diff --git a/mm/slub.c b/mm/slub.c
> > > index 65ffda5..b5acf18 100644
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -1565,6 +1565,8 @@ new_slab:
> > >  		c->page = new;
> > >  		goto load_freelist;
> > >  	}
> > > +	printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n",
> > > +		s->name, s->size, node, gfpflags);
> > 
> > size could be almost anything here for a casual reader. You are
> > outputting the size of the object plus its metadata so the name should
> > reflect that. I think it would be better to output objsize= and the
> > object size without the metadata overhead. What do you think?
> > 
> > In addition, include how many objects there are per-slab and include what
> > the order is being passed to the page allocator when allocating new slabs.
> > Would that be enough to determine if fallback-to-smaller orders occured?
> 
> So how about something like this then?
> 

Larry reported this stack trace:

kernel: git: page allocation failure. order:1, mode:0x4020
kernel: Pid: 3707, comm: git Not tainted 2.6.30-rc1-wl #115
kernel: Call Trace:
kernel:  [<ffffffff80292f84>] __alloc_pages_internal+0x43d/0x45d
kernel:  [<ffffffff802b2383>] alloc_pages_current+0xbe/0xc6
kernel:  [<ffffffff802b66a4>] new_slab+0xcf/0x28b

That's in the order fallback for new slab allocations; so this cache must 
have oo_order(s->min) of 1.

To diagnose whether its object size dictates a >0 slab order, you could 
enable CONFIG_SLUB_STATS (it's disabled in his .config) and check which 
/sys/kernel/slab/cache/order_fallback increased.  Once you have identified 
the cache, you can get this information via 
/sys/kernel/slab/cache/{objsize,order,size}.  I think this is what 
Christoph was getting at.

You could even boot with `slub_nomerge' to determine whether cache merging 
was the issue where the cache under consideration was unnecessarily merged 
with one that requires larger higher order minimums.

I don't quite understand how its necessary to print the partial lists for 
each node, they should be exhausted if we're allocating a new slab if the 
node doesn't matter (and can't in Larry's case, he only has one).

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi David,

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> Larry reported this stack trace:
> 
> kernel: git: page allocation failure. order:1, mode:0x4020
> kernel: Pid: 3707, comm: git Not tainted 2.6.30-rc1-wl #115
> kernel: Call Trace:
> kernel:  [<ffffffff80292f84>] __alloc_pages_internal+0x43d/0x45d
> kernel:  [<ffffffff802b2383>] alloc_pages_current+0xbe/0xc6
> kernel:  [<ffffffff802b66a4>] new_slab+0xcf/0x28b
> 
> That's in the order fallback for new slab allocations; so this cache must 
> have oo_order(s->min) of 1.

Yes, agreed which is why I said it's unlikely that the allocated size is
800 bytes or so.

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> To diagnose whether its object size dictates a >0 slab order, you could 
> enable CONFIG_SLUB_STATS (it's disabled in his .config) and check which 
> /sys/kernel/slab/cache/order_fallback increased.  Once you have identified 
> the cache, you can get this information via 
> /sys/kernel/slab/cache/{objsize,order,size}.  I think this is what 
> Christoph was getting at.
> 
> You could even boot with `slub_nomerge' to determine whether cache merging 
> was the issue where the cache under consideration was unnecessarily merged 
> with one that requires larger higher order minimums.

Sure. Applying my diagnostic patch will probably shed some light on the
subject too.

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> I don't quite understand how its necessary to print the partial lists for 
> each node, they should be exhausted if we're allocating a new slab if the 
> node doesn't matter (and can't in Larry's case, he only has one).

It doesn't hurt either, does it? Yes, we expect the partial lists to be
exhausted but it's better to print that out just in case we have a bug
some day somewhere and that condition is not true. This is very
infrequent slow patch code here anyway.

			Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Tue, 9 Jun 2009, Pekka Enberg wrote:

> > To diagnose whether its object size dictates a >0 slab order, you could 
> > enable CONFIG_SLUB_STATS (it's disabled in his .config) and check which 
> > /sys/kernel/slab/cache/order_fallback increased.  Once you have identified 
> > the cache, you can get this information via 
> > /sys/kernel/slab/cache/{objsize,order,size}.  I think this is what 
> > Christoph was getting at.
> > 
> > You could even boot with `slub_nomerge' to determine whether cache merging 
> > was the issue where the cache under consideration was unnecessarily merged 
> > with one that requires larger higher order minimums.
> 
> Sure. Applying my diagnostic patch will probably shed some light on the
> subject too.
> 

I wasn't sure whether you were proposing the patch as an addition to slub 
or just to help with this issue.  I agree it would help in a hopefully 
ratelimited manner for general slab allocation failures and would have 
avoided some of the confusion for this issue from lack of diagnostics.

> > I don't quite understand how its necessary to print the partial lists for 
> > each node, they should be exhausted if we're allocating a new slab if the 
> > node doesn't matter (and can't in Larry's case, he only has one).
> 
> It doesn't hurt either, does it? Yes, we expect the partial lists to be
> exhausted but it's better to print that out just in case we have a bug
> some day somewhere and that condition is not true. This is very
> infrequent slow patch code here anyway.
> 

It will lead to false postiives since you can get a free to a full slab 
which moves it back to an allowed node's partial list before count_free() 
is printed.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi David,

On Tue, 2009-06-09 at 01:14 -0700, David Rientjes wrote:
> I wasn't sure whether you were proposing the patch as an addition to slub 
> or just to help with this issue.  I agree it would help in a hopefully 
> ratelimited manner for general slab allocation failures and would have 
> avoided some of the confusion for this issue from lack of diagnostics.

I am proposing it as a generic addition to SLUB.

On Tue, 2009-06-09 at 01:14 -0700, David Rientjes wrote:
> > It doesn't hurt either, does it? Yes, we expect the partial lists to be
> > exhausted but it's better to print that out just in case we have a bug
> > some day somewhere and that condition is not true. This is very
> > infrequent slow patch code here anyway.
> 
> It will lead to false postiives since you can get a free to a full slab 
> which moves it back to an allowed node's partial list before count_free() 
> is printed.

Fair enough, lets drop it then!

			Pekka

diff --git a/mm/slub.c b/mm/slub.c
index 65ffda5..2bbacfc 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1484,6 +1484,56 @@ static inline int node_match(struct kmem_cache_cpu *c, int node)
 	return 1;
 }
 
+static int count_free(struct page *page)
+{
+	return page->objects - page->inuse;
+}
+
+static unsigned long count_partial(struct kmem_cache_node *n,
+					int (*get_count)(struct page *))
+{
+	unsigned long flags;
+	unsigned long x = 0;
+	struct page *page;
+
+	spin_lock_irqsave(&n->list_lock, flags);
+	list_for_each_entry(page, &n->partial, lru)
+		x += get_count(page);
+	spin_unlock_irqrestore(&n->list_lock, flags);
+	return x;
+}
+
+static noinline void
+slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
+{
+	int node;
+
+	printk(KERN_WARNING
+		"SLUB: Unable to allocate memory on node %d (gfp=%x)\n",
+		nid, gfpflags);
+	printk(KERN_WARNING "  cache: %s, object size: %d, buffer size: %d, "
+		"default order: %d, min order: %d\n", s->name, s->objsize,
+		s->size, oo_order(s->oo), oo_order(s->min));
+
+	for_each_online_node(node) {
+		struct kmem_cache_node *n = get_node(s, node);
+		unsigned long nr_slabs;
+		unsigned long nr_objs;
+		unsigned long nr_free;
+
+		if (!n)
+			continue;
+
+		nr_slabs = atomic_long_read(&n->nr_slabs);
+		nr_objs = atomic_long_read(&n->total_objects);
+		nr_free = count_partial(n, count_free);
+
+		printk(KERN_WARNING
+			"  node %d: slabs: %ld, objs: %ld, free: %ld\n",
+			node, nr_slabs, nr_objs, nr_free);
+	}
+}
+
 /*
  * Slow path. The lockless freelist is empty or we need to perform
  * debugging duties.
@@ -1565,6 +1615,7 @@ new_slab:
 		c->page = new;
 		goto load_freelist;
 	}
+	slab_out_of_memory(s, gfpflags, node);
 	return NULL;
 debug:
 	if (!alloc_debug_processing(s, c->page, object, addr))
@@ -3318,20 +3369,6 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags,
 }
 
 #ifdef CONFIG_SLUB_DEBUG
-static unsigned long count_partial(struct kmem_cache_node *n,
-					int (*get_count)(struct page *))
-{
-	unsigned long flags;
-	unsigned long x = 0;
-	struct page *page;
-
-	spin_lock_irqsave(&n->list_lock, flags);
-	list_for_each_entry(page, &n->partial, lru)
-		x += get_count(page);
-	spin_unlock_irqrestore(&n->list_lock, flags);
-	return x;
-}
-
 static int count_inuse(struct page *page)
 {
 	return page->inuse;
@@ -3342,11 +3379,6 @@ static int count_total(struct page *page)
 	return page->objects;
 }
 
-static int count_free(struct page *page)
-{
-	return page->objects - page->inuse;
-}
-
 static int validate_slab(struct kmem_cache *s, struct page *page,
 						unsigned long *map)
 {

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Pekka Enberg wrote:
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 65ffda5..2bbacfc 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1484,6 +1484,56 @@ static inline int node_match(struct kmem_cache_cpu *c, int node)
>  	return 1;
>  }
>  
> +static int count_free(struct page *page)
> +{
> +	return page->objects - page->inuse;
> +}
> +
> +static unsigned long count_partial(struct kmem_cache_node *n,
> +					int (*get_count)(struct page *))
> +{
> +	unsigned long flags;
> +	unsigned long x = 0;
> +	struct page *page;
> +
> +	spin_lock_irqsave(&n->list_lock, flags);
> +	list_for_each_entry(page, &n->partial, lru)
> +		x += get_count(page);
> +	spin_unlock_irqrestore(&n->list_lock, flags);
> +	return x;
> +}
> +
> +static noinline void
> +slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
> +{
> +	int node;
> +
> +	printk(KERN_WARNING
> +		"SLUB: Unable to allocate memory on node %d (gfp=%x)\n",
> +		nid, gfpflags);
> +	printk(KERN_WARNING "  cache: %s, object size: %d, buffer size: %d, "
> +		"default order: %d, min order: %d\n", s->name, s->objsize,
> +		s->size, oo_order(s->oo), oo_order(s->min));
> +
> +	for_each_online_node(node) {
> +		struct kmem_cache_node *n = get_node(s, node);
> +		unsigned long nr_slabs;
> +		unsigned long nr_objs;
> +		unsigned long nr_free;
> +
> +		if (!n)
> +			continue;
> +
> +		nr_slabs = atomic_long_read(&n->nr_slabs);
> +		nr_objs = atomic_long_read(&n->total_objects);
> +		nr_free = count_partial(n, count_free);
> +
> +		printk(KERN_WARNING
> +			"  node %d: slabs: %ld, objs: %ld, free: %ld\n",
> +			node, nr_slabs, nr_objs, nr_free);
> +	}
> +}
> +
>  /*
>   * Slow path. The lockless freelist is empty or we need to perform
>   * debugging duties.
> @@ -1565,6 +1615,7 @@ new_slab:
>  		c->page = new;
>  		goto load_freelist;
>  	}
> +	slab_out_of_memory(s, gfpflags, node);
>  	return NULL;
>  debug:
>  	if (!alloc_debug_processing(s, c->page, object, addr))
> @@ -3318,20 +3369,6 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags,
>  }
>  
>  #ifdef CONFIG_SLUB_DEBUG
> -static unsigned long count_partial(struct kmem_cache_node *n,
> -					int (*get_count)(struct page *))
> -{
> -	unsigned long flags;
> -	unsigned long x = 0;
> -	struct page *page;
> -
> -	spin_lock_irqsave(&n->list_lock, flags);
> -	list_for_each_entry(page, &n->partial, lru)
> -		x += get_count(page);
> -	spin_unlock_irqrestore(&n->list_lock, flags);
> -	return x;
> -}
> -
>  static int count_inuse(struct page *page)
>  {
>  	return page->inuse;
> @@ -3342,11 +3379,6 @@ static int count_total(struct page *page)
>  	return page->objects;
>  }
>  
> -static int count_free(struct page *page)
> -{
> -	return page->objects - page->inuse;
> -}
> -
>  static int validate_slab(struct kmem_cache *s, struct page *page,
>  						unsigned long *map)
>  {

With the above patch installed, I pushed my system hard enough to get
the O(1) allocation failures. This time they were triggered with a
'make -j8' on the kernel. No, I don't have that many CPUs, but I
figured that the extra make jobs might stress memory. My kernel is
2.6.30-rc8 from the wireless-testing tree. Everything matches Linus's
tree except drivers/net/wireless/, which contains what is essentially
2.6.31 code.

The dmesg output starting with the first allocation failure is:

cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211]
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffffa0291957>] ieee80211_subif_start_xmit+0x54b/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422332kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382252 pages shared
441407 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
phy0: failed to reallocate TX buffer
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422332kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382252 pages shared
441407 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422332kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382252 pages shared
441407 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422332kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382252 pages shared
441407 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422332kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382252 pages shared
441407 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422332kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382252 pages shared
441407 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422332kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382252 pages shared
441407 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422332kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382238 pages shared
441414 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355620 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422480kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382238 pages shared
441414 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b4038>] ? add_partial+0x1a/0x69
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  15
CPU    1: hi:  186, btch:  31 usd:  65
Active_anon:128724 active_file:123018 inactive_anon:47276
 inactive_file:355620 unevictable:8 dirty:18 writeback:0 unstable:0
 free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
active_anon:514896kB inactive_anon:189104kB active_file:492072kB
inactive_file:1422480kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
479694 total pagecache pages
969 pages in swap cache
Swap cache stats: add 4523, delete 3554, find 2913/3063
Free swap  = 2091884kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
382238 pages shared
441414 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
__ratelimit: 23 callbacks suppressed
rpciod/0: page allocation failure. order:1, mode:0x4020
Pid: 3085, comm: rpciod/0 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291815>] ieee80211_subif_start_xmit+0x409/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff8023fc6b>] ? local_bh_enable+0xc9/0xcf
 [<ffffffff80422e9d>] tcp_push_one+0x2f/0x31
 [<ffffffff80417439>] tcp_sendmsg+0x7a1/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff803e0f6e>] ? sock_sendmsg+0xdf/0xf8
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffff803e39b3>] sock_no_sendpage+0x9b/0xaa
 [<ffffffff804176de>] tcp_sendpage+0x48/0x5ec
 [<ffffffffa054c525>] xs_sendpages+0x12c/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bf9c3>] ? nfs3_xdr_writeargs+0x0/0x87 [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054faa1>] rpc_async_schedule+0x10/0x12 [sunrpc]
 [<ffffffff8024af33>] worker_thread+0x1fa/0x30a
 [<ffffffff8024aedc>] ? worker_thread+0x1a3/0x30a
 [<ffffffffa054fa91>] ? rpc_async_schedule+0x0/0x12 [sunrpc]
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff8024ad39>] ? worker_thread+0x0/0x30a
 [<ffffffff8024ad39>] ? worker_thread+0x0/0x30a
 [<ffffffff8024ec21>] kthread+0x56/0x83
 [<ffffffff8020cb7a>] child_rip+0xa/0x20
 [<ffffffff8020c57c>] ? restore_args+0x0/0x30
 [<ffffffff8024ebcb>] ? kthread+0x0/0x83
 [<ffffffff8020cb70>] ? child_rip+0x0/0x20
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd: 154
CPU    1: hi:  186, btch:  31 usd: 173
Active_anon:147694 active_file:116688 inactive_anon:47252
 inactive_file:344419 unevictable:8 dirty:5 writeback:0 unstable:0
 free:2692 slab:76878 mapped:19321 pagetables:4204 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:8664kB min:6904kB low:8628kB high:10356kB
active_anon:590776kB inactive_anon:189008kB active_file:466752kB
inactive_file:1377660kB unevictable:32kB present:2997292kB
pages_scanned:70 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 1898*4kB 12*8kB 8*16kB 1*32kB 0*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 8744kB
462221 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4555, delete 3589, find 2917/3067
Free swap  = 2091764kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
373616 pages shared
454599 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
cc1: page allocation failure. order:1, mode:0x4020
Pid: 8867, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211]
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffffa0291957>] ieee80211_subif_start_xmit+0x54b/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff803e33a8>] ? release_sock+0xcd/0xd6
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff80422e9d>] tcp_push_one+0x2f/0x31
 [<ffffffff80417439>] tcp_sendmsg+0x7a1/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff803e0f6e>] ? sock_sendmsg+0xdf/0xf8
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffff803e39b3>] sock_no_sendpage+0x9b/0xaa
 [<ffffffff804176de>] tcp_sendpage+0x48/0x5ec
 [<ffffffffa054c525>] xs_sendpages+0x12c/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bf9c3>] ? nfs3_xdr_writeargs+0x0/0x87 [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
kswapd0: page allocation failure. order:1, mode:0x4020
Pid: 229, comm: kswapd0 Not tainted 2.6.30-rc8-wl #164
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa05bb774>] nfs_write_rpcsetup+0x215/0x237 [nfs]
Call Trace:
 [<ffffffffa05bd257>] nfs_flush_one+0xa2/0xd9 [nfs]
 [<ffffffffa05b82d9>] nfs_pageio_doio+0x32/0x5b [nfs]
 [<ffffffffa05b83ec>] nfs_pageio_complete+0x9/0xb [nfs]
 [<ffffffffa05bbeae>] nfs_writepages+0x101/0x13a [nfs]
 [<ffffffffa05bd1b5>] ? nfs_flush_one+0x0/0xd9 [nfs]
 [<ffffffffa05bd043>] nfs_write_mapping+0x63/0x9e [nfs]
 [<ffffffffa05bd0a7>] nfs_wb_all+0x12/0x14 [nfs]
 [<ffffffffa05b0145>] nfs_file_flush+0x8a/0xb1 [nfs]
 [<ffffffff802bb18d>] filp_close+0x40/0x63
 [<ffffffff802bb255>] sys_close+0xa5/0xe4
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
 <IRQ> Node 0  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  85
Active_anon:151538 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606152kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB  [<ffffffff802b6362>] new_slab+0xcf/0x28b
5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB 1*1024kB 0*2048kB
0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB  [<ffffffff802b4d1f>] ?
unfreeze_slab+0x4c/0xbd
3*16kB 0*32kB 1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB
0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa01aaee5>] ? ssb_pci_read32+0x46/0x54 [ssb]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff8023f988>] irq_exit+0x4e/0x88
 [<ffffffff8020de2d>] do_IRQ+0xac/0xc3
 [<ffffffff8020c4d3>] ret_from_intr+0x0/0xf
 <EOI>  [<ffffffff8046013e>] ? _spin_unlock_irq+0x2d/0x30
 [<ffffffff80296a35>] ? __remove_mapping+0xac/0xc6
 [<ffffffff802971b3>] ? shrink_page_list+0x558/0x69f
 [<ffffffff80296262>] ? isolate_pages_global+0x179/0x219
 [<ffffffff8046013c>] ? _spin_unlock_irq+0x2b/0x30
 [<ffffffff8025ce77>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffff80297937>] ? shrink_list+0x2a1/0x5b6
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80297ed7>] ? shrink_zone+0x28b/0x335
 [<ffffffff8033a0d4>] ? __up_read+0x92/0x9a
 [<ffffffff802980c3>] ? shrink_slab+0x142/0x154
 [<ffffffff80298837>] ? kswapd+0x4b1/0x692
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff802960e9>] ? isolate_pages_global+0x0/0x219
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff8024ec21>] ? kthread+0x56/0x83
 [<ffffffff8020cb7a>] ? child_rip+0xa/0x20
 [<ffffffff8020c57c>] ? restore_args+0x0/0x30
 [<ffffffff8024ebcb>] ? kthread+0x0/0x83
 [<ffffffff8020cb70>] ? child_rip+0x0/0x20
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  85
Active_anon:151538 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606152kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
769872 pages RAM
769872 pages RAM
21377 pages reserved
371529 pages shared
456955 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
21377 pages reserved
  node 0: slabs: 96, objs: 672, free: 0
371529 pages shared
456955 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
phy0: failed to reallocate TX buffer
kswapd0: page allocation failure. order:1, mode:0x4020
Pid: 229, comm: kswapd0 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff8025ce5d>] ? trace_hardirqs_on_caller+0xf1/0x12f
 [<ffffffffa01aaee5>] ? ssb_pci_read32+0x46/0x54 [ssb]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff80243f1f>] ? run_timer_softirq+0x259/0x268
 [<ffffffff80243dfc>] ? run_timer_softirq+0x136/0x268
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff8023f988>] irq_exit+0x4e/0x88
 [<ffffffff8020de2d>] do_IRQ+0xac/0xc3
 [<ffffffff8020c4d3>] ret_from_intr+0x0/0xf
 <EOI>  [<ffffffff8046013e>] ? _spin_unlock_irq+0x2d/0x30
 [<ffffffff80296a35>] ? __remove_mapping+0xac/0xc6
 [<ffffffff802971b3>] ? shrink_page_list+0x558/0x69f
 [<ffffffff80296262>] ? isolate_pages_global+0x179/0x219
 [<ffffffff8046013c>] ? _spin_unlock_irq+0x2b/0x30
 [<ffffffff8025ce77>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffff80297937>] ? shrink_list+0x2a1/0x5b6
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80297ed7>] ? shrink_zone+0x28b/0x335
 [<ffffffff8033a0d4>] ? __up_read+0x92/0x9a
 [<ffffffff802980c3>] ? shrink_slab+0x142/0x154
 [<ffffffff80298837>] ? kswapd+0x4b1/0x692
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff802960e9>] ? isolate_pages_global+0x0/0x219
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff8024ec21>] ? kthread+0x56/0x83
 [<ffffffff8020cb7a>] ? child_rip+0xa/0x20
 [<ffffffff8020c57c>] ? restore_args+0x0/0x30
 [<ffffffff8024ebcb>] ? kthread+0x0/0x83
 [<ffffffff8020cb70>] ? child_rip+0x0/0x20
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  84
Active_anon:151538 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606152kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
cc1: page allocation failure. order:1, mode:0x4020
Pid: 8867, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211]
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffffa0291957>] ieee80211_subif_start_xmit+0x54b/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff80422e9d>] tcp_push_one+0x2f/0x31
 [<ffffffff80417439>] tcp_sendmsg+0x7a1/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff803e0f6e>] ? sock_sendmsg+0xdf/0xf8
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffff803e39b3>] sock_no_sendpage+0x9b/0xaa
 [<ffffffff804176de>] tcp_sendpage+0x48/0x5ec
 [<ffffffffa054c525>] xs_sendpages+0x12c/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bf9c3>] ? nfs3_xdr_writeargs+0x0/0x87 [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa05bb774>] nfs_write_rpcsetup+0x215/0x237 [nfs]
 [<ffffffffa05bd257>] nfs_flush_one+0xa2/0xd9 [nfs]
 [<ffffffffa05b82d9>] nfs_pageio_doio+0x32/0x5b [nfs]
 [<ffffffffa05b83ec>] nfs_pageio_complete+0x9/0xb [nfs]
 [<ffffffffa05bbeae>] nfs_writepages+0x101/0x13a [nfs]
 [<ffffffffa05bd1b5>] ? nfs_flush_one+0x0/0xd9 [nfs]
 [<ffffffffa05bd043>] nfs_write_mapping+0x63/0x9e [nfs]
 [<ffffffffa05bd0a7>] nfs_wb_all+0x12/0x14 [nfs]
 [<ffffffffa05b0145>] nfs_file_flush+0x8a/0xb1 [nfs]
 [<ffffffff802bb18d>] filp_close+0x40/0x63
 [<ffffffff802bb255>] sys_close+0xa5/0xe4
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  51
Active_anon:151575 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606300kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
371534 pages shared
456983 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
kswapd0: page allocation failure. order:1, mode:0x4020
Pid: 229, comm: kswapd0 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa01aaee5>] ? ssb_pci_read32+0x46/0x54 [ssb]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff80243f1f>] ? run_timer_softirq+0x259/0x268
 [<ffffffff80243dfc>] ? run_timer_softirq+0x136/0x268
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff8023f988>] irq_exit+0x4e/0x88
 [<ffffffff8020de2d>] do_IRQ+0xac/0xc3
 [<ffffffff8020c4d3>] ret_from_intr+0x0/0xf
 <EOI>  [<ffffffff8046013e>] ? _spin_unlock_irq+0x2d/0x30
 [<ffffffff80296a35>] ? __remove_mapping+0xac/0xc6
 [<ffffffff802971b3>] ? shrink_page_list+0x558/0x69f
 [<ffffffff80296262>] ? isolate_pages_global+0x179/0x219
 [<ffffffff8046013c>] ? _spin_unlock_irq+0x2b/0x30
 [<ffffffff8025ce77>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffff80297937>] ? shrink_list+0x2a1/0x5b6
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80297ed7>] ? shrink_zone+0x28b/0x335
 [<ffffffff8033a0d4>] ? __up_read+0x92/0x9a
 [<ffffffff802980c3>] ? shrink_slab+0x142/0x154
 [<ffffffff80298837>] ? kswapd+0x4b1/0x692
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff802960e9>] ? isolate_pages_global+0x0/0x219
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff8024ec21>] ? kthread+0x56/0x83
 [<ffffffff8020cb7a>] ? child_rip+0xa/0x20
 [<ffffffff8020c57c>] ? restore_args+0x0/0x30
 [<ffffffff8024ebcb>] ? kthread+0x0/0x83
 [<ffffffff8020cb70>] ? child_rip+0x0/0x20
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  51
Active_anon:151575 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606300kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
371535 pages shared
456983 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
cc1: page allocation failure. order:1, mode:0x4020
Pid: 8867, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291815>] ieee80211_subif_start_xmit+0x409/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b40a2>] ? get_partial_node+0x1b/0x8a
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff803e33a8>] ? release_sock+0xcd/0xd6
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e3497>] ? lock_sock_nested+0xe6/0xf5
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff803e11f7>] ? kernel_sendmsg+0x34/0x49
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c583>] xs_sendpages+0x18a/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bf9c3>] ? nfs3_xdr_writeargs+0x0/0x87 [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa05bb774>] nfs_write_rpcsetup+0x215/0x237 [nfs]
 [<ffffffffa05bd257>] nfs_flush_one+0xa2/0xd9 [nfs]
 [<ffffffffa05b82d9>] nfs_pageio_doio+0x32/0x5b [nfs]
 [<ffffffffa05b83ec>] nfs_pageio_complete+0x9/0xb [nfs]
 [<ffffffffa05bbeae>] nfs_writepages+0x101/0x13a [nfs]
 [<ffffffffa05bd1b5>] ? nfs_flush_one+0x0/0xd9 [nfs]
 [<ffffffffa05bd043>] nfs_write_mapping+0x63/0x9e [nfs]
 [<ffffffffa05bd0a7>] nfs_wb_all+0x12/0x14 [nfs]
 [<ffffffffa05b0145>] nfs_file_flush+0x8a/0xb1 [nfs]
 [<ffffffff802bb18d>] filp_close+0x40/0x63
 [<ffffffff802bb255>] sys_close+0xa5/0xe4
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  51
Active_anon:151575 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606300kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
371535 pages shared
456983 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
kswapd0: page allocation failure. order:1, mode:0x4020
Pid: 229, comm: kswapd0 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa01aaee5>] ? ssb_pci_read32+0x46/0x54 [ssb]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff80243f1f>] ? run_timer_softirq+0x259/0x268
 [<ffffffff80243dfc>] ? run_timer_softirq+0x136/0x268
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff8023f988>] irq_exit+0x4e/0x88
 [<ffffffff8020de2d>] do_IRQ+0xac/0xc3
 [<ffffffff8020c4d3>] ret_from_intr+0x0/0xf
 <EOI>  [<ffffffff8046013e>] ? _spin_unlock_irq+0x2d/0x30
 [<ffffffff80296a35>] ? __remove_mapping+0xac/0xc6
 [<ffffffff802971b3>] ? shrink_page_list+0x558/0x69f
 [<ffffffff80296262>] ? isolate_pages_global+0x179/0x219
 [<ffffffff8046013c>] ? _spin_unlock_irq+0x2b/0x30
 [<ffffffff8025ce77>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffff80297937>] ? shrink_list+0x2a1/0x5b6
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80297ed7>] ? shrink_zone+0x28b/0x335
 [<ffffffff8033a0d4>] ? __up_read+0x92/0x9a
 [<ffffffff802980c3>] ? shrink_slab+0x142/0x154
 [<ffffffff80298837>] ? kswapd+0x4b1/0x692
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff802960e9>] ? isolate_pages_global+0x0/0x219
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff8024ec21>] ? kthread+0x56/0x83
 [<ffffffff8020cb7a>] ? child_rip+0xa/0x20
 [<ffffffff8020c57c>] ? restore_args+0x0/0x30
 [<ffffffff8024ebcb>] ? kthread+0x0/0x83
 [<ffffffff8020cb70>] ? child_rip+0x0/0x20
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  51
Active_anon:151575 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606300kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
371535 pages shared
456983 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
cc1: page allocation failure. order:1, mode:0x4020
Pid: 8867, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291815>] ieee80211_subif_start_xmit+0x409/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803ed179>] net_tx_action+0xd9/0x156
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 <EOI>  [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff803efc0e>] ? dev_queue_xmit+0x352/0x384
 [<ffffffff8023fc57>] local_bh_enable+0xb5/0xcf
 [<ffffffff803efc0e>] dev_queue_xmit+0x352/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff802b40a2>] ? get_partial_node+0x1b/0x8a
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff803e33a8>] ? release_sock+0xcd/0xd6
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e3497>] ? lock_sock_nested+0xe6/0xf5
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff803e11f7>] ? kernel_sendmsg+0x34/0x49
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c583>] xs_sendpages+0x18a/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bf9c3>] ? nfs3_xdr_writeargs+0x0/0x87 [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa05bb774>] nfs_write_rpcsetup+0x215/0x237 [nfs]
 [<ffffffffa05bd257>] nfs_flush_one+0xa2/0xd9 [nfs]
 [<ffffffffa05b82d9>] nfs_pageio_doio+0x32/0x5b [nfs]
 [<ffffffffa05b83ec>] nfs_pageio_complete+0x9/0xb [nfs]
 [<ffffffffa05bbeae>] nfs_writepages+0x101/0x13a [nfs]
 [<ffffffffa05bd1b5>] ? nfs_flush_one+0x0/0xd9 [nfs]
 [<ffffffffa05bd043>] nfs_write_mapping+0x63/0x9e [nfs]
 [<ffffffffa05bd0a7>] nfs_wb_all+0x12/0x14 [nfs]
 [<ffffffffa05b0145>] nfs_file_flush+0x8a/0xb1 [nfs]
 [<ffffffff802bb18d>] filp_close+0x40/0x63
 [<ffffffff802bb255>] sys_close+0xa5/0xe4
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  51
Active_anon:151575 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606300kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
371535 pages shared
456983 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
kswapd0: page allocation failure. order:1, mode:0x4020
Pid: 229, comm: kswapd0 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 <IRQ>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff802b78f5>] __kmalloc_node_track_caller+0xbd/0x144
 [<ffffffffa02d131d>] ? setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffff803e872d>] __alloc_skb+0x6f/0x143
 [<ffffffffa02d131d>] setup_rx_descbuffer+0x4b/0x2d7 [b43]
 [<ffffffffa01aaee5>] ? ssb_pci_read32+0x46/0x54 [ssb]
 [<ffffffffa02d192e>] b43_dma_rx+0x319/0x4ff [b43]
 [<ffffffffa02c55d3>] b43_interrupt_tasklet+0x699/0x7fe [b43]
 [<ffffffff80243f1f>] ? run_timer_softirq+0x259/0x268
 [<ffffffff80243dfc>] ? run_timer_softirq+0x136/0x268
 [<ffffffff8023f684>] ? tasklet_action+0x44/0xdb
 [<ffffffff8023f6c0>] tasklet_action+0x80/0xdb
 [<ffffffff8023fdc7>] __do_softirq+0xb1/0x186
 [<ffffffff8020cc7c>] call_softirq+0x1c/0x28
 [<ffffffff8020e54d>] do_softirq+0x39/0x8a
 [<ffffffff8023f988>] irq_exit+0x4e/0x88
 [<ffffffff8020de2d>] do_IRQ+0xac/0xc3
 [<ffffffff8020c4d3>] ret_from_intr+0x0/0xf
 <EOI>  [<ffffffff8046013e>] ? _spin_unlock_irq+0x2d/0x30
 [<ffffffff80296a35>] ? __remove_mapping+0xac/0xc6
 [<ffffffff802971b3>] ? shrink_page_list+0x558/0x69f
 [<ffffffff80296262>] ? isolate_pages_global+0x179/0x219
 [<ffffffff8046013c>] ? _spin_unlock_irq+0x2b/0x30
 [<ffffffff8025ce77>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffff80297937>] ? shrink_list+0x2a1/0x5b6
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80297ed7>] ? shrink_zone+0x28b/0x335
 [<ffffffff8033a0d4>] ? __up_read+0x92/0x9a
 [<ffffffff802980c3>] ? shrink_slab+0x142/0x154
 [<ffffffff80298837>] ? kswapd+0x4b1/0x692
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff802960e9>] ? isolate_pages_global+0x0/0x219
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff80298386>] ? kswapd+0x0/0x692
 [<ffffffff8024ec21>] ? kthread+0x56/0x83
 [<ffffffff8020cb7a>] ? child_rip+0xa/0x20
 [<ffffffff8020c57c>] ? restore_args+0x0/0x30
 [<ffffffff8024ebcb>] ? kthread+0x0/0x83
 [<ffffffff8020cb70>] ? child_rip+0x0/0x20
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  89
CPU    1: hi:  186, btch:  31 usd:  51
Active_anon:151575 active_file:114269 inactive_anon:47211
 inactive_file:340887 unevictable:8 dirty:36 writeback:0 unstable:2
 free:5246 slab:76536 mapped:19364 pagetables:4251 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:18880kB min:6904kB low:8628kB high:10356kB
active_anon:606300kB inactive_anon:188844kB active_file:457076kB
inactive_file:1363548kB unevictable:32kB present:2997292kB
pages_scanned:69 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 4459*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 18852kB
456290 total pagecache pages
966 pages in swap cache
Swap cache stats: add 4587, delete 3621, find 2934/3084
Free swap  = 2091636kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
371535 pages shared
456983 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
protocol 0008 is buggy, dev eth1
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
769872 pages RAM
21377 pages reserved
371535 pages shared
456983 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 96, objs: 672, free: 0
b43-phy0 debug: DMA RX: setup_rx_descbuffer() failed
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
phy0: failed to reallocate TX buffer
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
phy0: failed to reallocate TX buffer
__ratelimit: 73 callbacks suppressed
cc1: page allocation failure. order:1, mode:0x4020
Pid: 9042, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291815>] ieee80211_subif_start_xmit+0x409/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff802b40a2>] ? get_partial_node+0x1b/0x8a
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  13
CPU    1: hi:  186, btch:  31 usd: 173
Active_anon:163559 active_file:111927 inactive_anon:47119
 inactive_file:334673 unevictable:8 dirty:23 writeback:0 unstable:0
 free:2704 slab:75670 mapped:19336 pagetables:4281 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:8712kB min:6904kB low:8628kB high:10356kB
active_anon:654236kB inactive_anon:188476kB active_file:447708kB
inactive_file:1338692kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 1910*4kB 6*8kB 6*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 8744kB
447641 total pagecache pages
962 pages in swap cache
Swap cache stats: add 4651, delete 3689, find 2934/3084
Free swap  = 2091380kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
365043 pages shared
466540 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 97, objs: 679, free: 0
phy0: failed to reallocate TX buffer
cc1: page allocation failure. order:1, mode:0x4020
Pid: 10081, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211]
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffffa0291957>] ieee80211_subif_start_xmit+0x54b/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
 [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
 [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
 [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
 [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
 [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
 [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
 [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
 [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
 [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
 [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
 [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
 [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
 [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
 [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
 [<ffffffff802c6d1d>] path_walk+0x69/0xd4
 [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
 [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
 [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
 [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
 [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
 [<ffffffff802bb393>] sys_open+0x1b/0x1d
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  60
CPU    1: hi:  186, btch:  31 usd: 132
Active_anon:162603 active_file:111766 inactive_anon:47119
 inactive_file:332454 unevictable:8 dirty:11 writeback:0 unstable:0
 free:6493 slab:75317 mapped:19281 pagetables:4242 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:23868kB min:6904kB low:8628kB high:10356kB
active_anon:650412kB inactive_anon:188476kB active_file:447064kB
inactive_file:1329816kB unevictable:32kB present:2997292kB
pages_scanned:154 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 5688*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 23768kB
445272 total pagecache pages
946 pages in swap cache
Swap cache stats: add 4659, delete 3713, find 2934/3084
Free swap  = 2091348kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
357698 pages shared
466721 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 0
phy0: failed to reallocate TX buffer
cc1: page allocation failure. order:1, mode:0x4020
Pid: 10064, comm: cc1 Not tainted 2.6.30-rc8-wl #164
Call Trace:
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
 [<ffffffff802b7e60>] __kmalloc+0x119/0x194
 [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
 [<ffffffff80460180>] ? _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
 [<ffffffffa0291815>] ieee80211_subif_start_xmit+0x409/0x56b [mac80211]
 [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
 [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
 [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
 [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
 [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
 [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
 [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
 [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
 [<ffffffff803e33a8>] ? release_sock+0xcd/0xd6
 [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
 [<ffffffff8040f093>] ip_local_out+0x20/0x24
 [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
 [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
 [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
 [<ffffffff80422e9d>] tcp_push_one+0x2f/0x31
 [<ffffffff80417439>] tcp_sendmsg+0x7a1/0x9fe
 [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
 [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff803e0f6e>] ? sock_sendmsg+0xdf/0xf8
 [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
 [<ffffffff803e39b3>] sock_no_sendpage+0x9b/0xaa
 [<ffffffff804176de>] tcp_sendpage+0x48/0x5ec
 [<ffffffffa054c525>] xs_sendpages+0x12c/0x1af [sunrpc]
 [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
 [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
 [<ffffffffa05bf9c3>] ? nfs3_xdr_writeargs+0x0/0x87 [nfs]
 [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
 [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
 [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
 [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
 [<ffffffffa05bb774>] nfs_write_rpcsetup+0x215/0x237 [nfs]
 [<ffffffffa05bd257>] nfs_flush_one+0xa2/0xd9 [nfs]
 [<ffffffffa05b82d9>] nfs_pageio_doio+0x32/0x5b [nfs]
 [<ffffffffa05b83ec>] nfs_pageio_complete+0x9/0xb [nfs]
 [<ffffffffa05bbeae>] nfs_writepages+0x101/0x13a [nfs]
 [<ffffffffa05bd1b5>] ? nfs_flush_one+0x0/0xd9 [nfs]
 [<ffffffffa05bd043>] nfs_write_mapping+0x63/0x9e [nfs]
 [<ffffffffa05bd0a7>] nfs_wb_all+0x12/0x14 [nfs]
 [<ffffffffa05b0145>] nfs_file_flush+0x8a/0xb1 [nfs]
 [<ffffffff802bb18d>] filp_close+0x40/0x63
 [<ffffffff802bb255>] sys_close+0xa5/0xe4
 [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  42
CPU    1: hi:  186, btch:  31 usd: 207
Active_anon:165674 active_file:111453 inactive_anon:47087
 inactive_file:331621 unevictable:8 dirty:11 writeback:0 unstable:0
 free:4632 slab:75221 mapped:19318 pagetables:4242 bounce:0
Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15220kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2927 2927 2927
Node 0 DMA32 free:16424kB min:6904kB low:8628kB high:10356kB
active_anon:662696kB inactive_anon:188348kB active_file:445812kB
inactive_file:1326484kB unevictable:32kB present:2997292kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 2104kB
Node 0 DMA32: 3831*4kB 1*8kB 3*16kB 0*32kB 1*64kB 1*128kB 1*256kB
1*512kB 0*1024kB 0*2048kB 0*4096kB = 16340kB
444199 total pagecache pages
962 pages in swap cache
Swap cache stats: add 4683, delete 3721, find 2934/3084
Free swap  = 2091252kB
Total swap = 2104444kB
769872 pages RAM
21377 pages reserved
358924 pages shared
469842 pages non-shared
SLUB: Unable to allocate memory on node -1 (gfp=20)
  cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
order: 3, min order: 1
  node 0: slabs: 95, objs: 665, free: 2
phy0: failed to reallocate TX buffer

If you need the rest of the dmesg output, or anything else, please let
me know.

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Wed, 2009-06-10 at 09:41 -0500, Larry Finger wrote:
> With the above patch installed, I pushed my system hard enough to get
> the O(1) allocation failures. This time they were triggered with a
> 'make -j8' on the kernel. No, I don't have that many CPUs, but I
> figured that the extra make jobs might stress memory. My kernel is
> 2.6.30-rc8 from the wireless-testing tree. Everything matches Linus's
> tree except drivers/net/wireless/, which contains what is essentially
> 2.6.31 code.
> 
> The dmesg output starting with the first allocation failure is:
> 
> cc1: page allocation failure. order:1, mode:0x4020
> Pid: 6577, comm: cc1 Not tainted 2.6.30-rc8-wl #164
> Call Trace:
>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
>  [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
>  [<ffffffff802b6362>] new_slab+0xcf/0x28b
>  [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
>  [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
>  [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
>  [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
>  [<ffffffff802b7e60>] __kmalloc+0x119/0x194
>  [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
>  [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
>  [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211]
>  [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
>  [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
>  [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
>  [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
>  [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
>  [<ffffffffa0291957>] ieee80211_subif_start_xmit+0x54b/0x56b [mac80211]
>  [<ffffffffa029162b>] ? ieee80211_subif_start_xmit+0x21f/0x56b [mac80211]
>  [<ffffffff8025cea8>] ? trace_hardirqs_on+0xd/0xf
>  [<ffffffff803e7790>] ? __kfree_skb+0x82/0x86
>  [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
>  [<ffffffff803ef55c>] ? dev_hard_start_xmit+0x5b/0x2a8
>  [<ffffffff804005ee>] __qdisc_run+0xed/0x1fe
>  [<ffffffff803efb08>] dev_queue_xmit+0x24c/0x384
>  [<ffffffff803efa2f>] ? dev_queue_xmit+0x173/0x384
>  [<ffffffff8040fec9>] ip_finish_output+0x217/0x25c
>  [<ffffffff802b4038>] ? add_partial+0x1a/0x69
>  [<ffffffff8040ffaa>] ip_output+0x9c/0xa1
>  [<ffffffff8040f093>] ip_local_out+0x20/0x24
>  [<ffffffff8040f900>] ip_queue_xmit+0x2e0/0x337
>  [<ffffffff8042087e>] tcp_transmit_skb+0x5f7/0x63a
>  [<ffffffff802b790b>] ? __kmalloc_node_track_caller+0xd3/0x144
>  [<ffffffff80422d89>] tcp_write_xmit+0x83f/0x924
>  [<ffffffff803e872d>] ? __alloc_skb+0x6f/0x143
>  [<ffffffff80422ec9>] __tcp_push_pending_frames+0x2a/0x81
>  [<ffffffff80417590>] tcp_sendmsg+0x8f8/0x9fe
>  [<ffffffff803e0f6e>] sock_sendmsg+0xdf/0xf8
>  [<ffffffff8024efec>] ? autoremove_wake_function+0x0/0x38
>  [<ffffffff8023695c>] ? finish_task_switch+0x3b/0xdc
>  [<ffffffff803e11f7>] kernel_sendmsg+0x34/0x49
>  [<ffffffffa054c3f0>] xs_send_kvec+0x7a/0x83 [sunrpc]
>  [<ffffffffa054c486>] xs_sendpages+0x8d/0x1af [sunrpc]
>  [<ffffffffa054c6b1>] xs_tcp_send_request+0x52/0x149 [sunrpc]
>  [<ffffffffa054b470>] xprt_transmit+0x178/0x234 [sunrpc]
>  [<ffffffffa05bfc11>] ? nfs3_xdr_fhandle+0x0/0x2e [nfs]
>  [<ffffffffa0548d02>] call_transmit+0x20e/0x250 [sunrpc]
>  [<ffffffffa054f8a7>] __rpc_execute+0x86/0x244 [sunrpc]
>  [<ffffffffa054fa8d>] rpc_execute+0x28/0x2c [sunrpc]
>  [<ffffffffa054963c>] rpc_run_task+0x56/0x5e [sunrpc]
>  [<ffffffffa054972f>] rpc_call_sync+0x3f/0x5d [sunrpc]
>  [<ffffffffa05bdcd0>] nfs3_rpc_wrapper+0x22/0x5c [nfs]
>  [<ffffffffa05be40c>] nfs3_proc_getattr+0x5b/0x81 [nfs]
>  [<ffffffffa05b1e22>] __nfs_revalidate_inode+0xbd/0x1c9 [nfs]
>  [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
>  [<ffffffffa05d0529>] ? nfs_have_delegation+0x79/0x82 [nfs]
>  [<ffffffffa05d04b0>] ? nfs_have_delegation+0x0/0x82 [nfs]
>  [<ffffffffa05acb60>] nfs_lookup_revalidate+0x265/0x49c [nfs]
>  [<ffffffff802ccfa9>] ? __d_lookup+0xba/0x16a
>  [<ffffffff802cd047>] ? __d_lookup+0x158/0x16a
>  [<ffffffff802cceef>] ? __d_lookup+0x0/0x16a
>  [<ffffffffa0550992>] ? rpcauth_lookupcred+0x77/0x9f [sunrpc]
>  [<ffffffff802c49c6>] do_lookup+0x166/0x1bb
>  [<ffffffff802c66b7>] __link_path_walk+0x8f8/0xd58
>  [<ffffffff802c6d1d>] path_walk+0x69/0xd4
>  [<ffffffff802c6fb6>] do_path_lookup+0x187/0x1df
>  [<ffffffff802bdf80>] ? get_empty_filp+0xe9/0x14e
>  [<ffffffff802c7c4b>] do_filp_open+0x105/0x909
>  [<ffffffff802d0bb6>] ? alloc_fd+0x11d/0x12e
>  [<ffffffff802bb2ea>] do_sys_open+0x56/0xd6
>  [<ffffffff802bb393>] sys_open+0x1b/0x1d
>  [<ffffffff8020baab>] system_call_fastpath+0x16/0x1b
> Mem-Info:
> Node 0 DMA per-cpu:
> CPU    0: hi:    0, btch:   1 usd:   0
> CPU    1: hi:    0, btch:   1 usd:   0
> Node 0 DMA32 per-cpu:
> CPU    0: hi:  186, btch:  31 usd:  15
> CPU    1: hi:  186, btch:  31 usd:  65
> Active_anon:128724 active_file:123018 inactive_anon:47276
>  inactive_file:355583 unevictable:8 dirty:18 writeback:0 unstable:0
>  free:3621 slab:77881 mapped:18629 pagetables:4056 bounce:0
> Node 0 DMA free:2104kB min:32kB low:40kB high:48kB active_anon:0kB
> inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
> present:15220kB pages_scanned:0 all_unreclaimable? yes
> lowmem_reserve[]: 0 2927 2927 2927
> Node 0 DMA32 free:12380kB min:6904kB low:8628kB high:10356kB
> active_anon:514896kB inactive_anon:189104kB active_file:492072kB
> inactive_file:1422332kB unevictable:32kB present:2997292kB
> pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0 0
> Node 0 DMA: 4*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB
> 1*1024kB 0*2048kB 0*4096kB = 2104kB
> Node 0 DMA32: 2821*4kB 1*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB
> 1*512kB 0*1024kB 0*2048kB 0*4096kB = 12332kB
> 479694 total pagecache pages
> 969 pages in swap cache
> Swap cache stats: add 4523, delete 3554, find 2913/3063
> Free swap  = 2091884kB
> Total swap = 2104444kB
> 769872 pages RAM
> 21377 pages reserved
> 382252 pages shared
> 441407 pages non-shared
> SLUB: Unable to allocate memory on node -1 (gfp=20)
>   cache: kmalloc-4096, object size: 4096, buffer size: 4168, default
> order: 3, min order: 1
>   node 0: slabs: 95, objs: 665, free: 0
> phy0: failed to reallocate TX buffer

Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have
CONFIG_SLUB_DEBUG enabled? If yes, something like to following should
help. Christoph, are you okay with this patch?

			Pekka

diff --git a/mm/slub.c b/mm/slub.c
index 65ffda5..2c93c30 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2334,6 +2334,8 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
 
 }
 
+#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
+
 static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
 		const char *name, size_t size,
 		size_t align, unsigned long flags,
@@ -2346,6 +2348,9 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
 	s->align = align;
 	s->flags = kmem_cache_flags(size, flags, name, ctor);
 
+	if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE)
+		flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER);
+
 	if (!calculate_sizes(s, -1))
 		goto error;
 

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Wed, 2009-06-10 at 18:44 +0300, Pekka Enberg wrote:

> Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have
> CONFIG_SLUB_DEBUG enabled? If yes, something like to following should
> help. Christoph, are you okay with this patch?
> 
> 			Pekka
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 65ffda5..2c93c30 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2334,6 +2334,8 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
>  
>  }
>  
> +#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
> +
>  static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
>  		const char *name, size_t size,
>  		size_t align, unsigned long flags,
> @@ -2346,6 +2348,9 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
>  	s->align = align;
>  	s->flags = kmem_cache_flags(size, flags, name, ctor);
>  
> +	if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE)
> +		flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER);
> +
>  	if (!calculate_sizes(s, -1))
>  		goto error;
>  
> 
Argh, that patch has a typo. Please try this one instead.

			Pekka

diff --git a/mm/slub.c b/mm/slub.c
index 65ffda5..cb0473c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2334,6 +2334,8 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
 
 }
 
+#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
+
 static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
 		const char *name, size_t size,
 		size_t align, unsigned long flags,
@@ -2346,6 +2348,9 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
 	s->align = align;
 	s->flags = kmem_cache_flags(size, flags, name, ctor);
 
+	if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE)
+		s->flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER);
+
 	if (!calculate_sizes(s, -1))
 		goto error;
 

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Wed, 2009-06-10 at 18:49 +0300, Pekka Enberg wrote:
> On Wed, 2009-06-10 at 18:44 +0300, Pekka Enberg wrote:
> 
> > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have
> > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should
> > help. Christoph, are you okay with this patch?


> +	if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE)

&& size <= PAGE_SIZE

? Or is this a path that only happens for small allocations?

> +		s->flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER);
> +
>  	if (!calculate_sizes(s, -1))
>  		goto error;

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Mel Gorman]

On Tue, Jun 09, 2009 at 10:06:41AM +0300, Pekka Enberg wrote:
> Hi Mel,
> 
> On Mon, 2009-06-08 at 15:12 +0100, Mel Gorman wrote:
> > > diff --git a/mm/slub.c b/mm/slub.c
> > > index 65ffda5..b5acf18 100644
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -1565,6 +1565,8 @@ new_slab:
> > >  		c->page = new;
> > >  		goto load_freelist;
> > >  	}
> > > +	printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n",
> > > +		s->name, s->size, node, gfpflags);
> > 
> > size could be almost anything here for a casual reader. You are
> > outputting the size of the object plus its metadata so the name should
> > reflect that. I think it would be better to output objsize= and the
> > object size without the metadata overhead. What do you think?
> > 
> > In addition, include how many objects there are per-slab and include what
> > the order is being passed to the page allocator when allocating new slabs.
> > Would that be enough to determine if fallback-to-smaller orders occured?
> 
> So how about something like this then?
> 
> 			Pekka
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 65ffda5..a03dbe8 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1484,6 +1484,58 @@ static inline int node_match(struct kmem_cache_cpu *c, int node)
>  	return 1;
>  }
>  
> +static int count_free(struct page *page)
> +{
> +	return page->objects - page->inuse;
> +}
> +
> +static unsigned long count_partial(struct kmem_cache_node *n,
> +					int (*get_count)(struct page *))
> +{
> +	unsigned long flags;
> +	unsigned long x = 0;
> +	struct page *page;
> +
> +	spin_lock_irqsave(&n->list_lock, flags);
> +	list_for_each_entry(page, &n->partial, lru)
> +		x += get_count(page);
> +	spin_unlock_irqrestore(&n->list_lock, flags);
> +	return x;
> +}
> +
> +static noinline void
> +slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
> +{
> +	int node;
> +
> +	printk(KERN_WARNING
> +		"SLUB: Unable to allocate memory on node %d (gfp=%x)\n",
> +		nid, gfpflags);
> +	printk(KERN_WARNING "  cache: %s, object size: %d, buffer size: %d, "
> +		"default order: %d, min order: %d\n", s->name, s->objsize,
> +		s->size, oo_order(s->oo), oo_order(s->min));
> +

Much nicer. There is a clear division between the object size and the
size including the metadata. There is also now a good idea of what sort
of request it was, we know what cache it was so we can guess the size
passed to kmalloc() with reasonable accuracy.

> +	for_each_online_node(node) {
> +		struct kmem_cache_node *n = get_node(s, node);
> +		unsigned long nr_partials;
> +		unsigned long nr_slabs;
> +		unsigned long nr_objs;
> +		unsigned long nr_free;
> +
> +		if (!n)
> +			continue;
> +
> +		nr_partials = n->nr_partial;
> +		nr_slabs = atomic_long_read(&n->nr_slabs);
> +		nr_objs = atomic_long_read(&n->total_objects);
> +		nr_free = count_partial(n, count_free);
> +
> +		printk(KERN_WARNING
> +			"  node %d: partials: %ld, slabs: %ld, objs: %ld, free: %ld\n",
> +			node, nr_partials, nr_slabs, nr_objs, nr_free);
> +	}
> +}

That looks like it would generate easier-to-debug-with messages and to
not-expert-at-slub eye, it looks correct. Slap a changelog on it with an
example message and go with it.  It should make page allocation failures
messages that go through SLUB a lot easier to figure out.

Thanks

> +
>  /*
>   * Slow path. The lockless freelist is empty or we need to perform
>   * debugging duties.
> @@ -1565,6 +1617,7 @@ new_slab:
>  		c->page = new;
>  		goto load_freelist;
>  	}
> +	slab_out_of_memory(s, gfpflags, node);
>  	return NULL;
>  debug:
>  	if (!alloc_debug_processing(s, c->page, object, addr))
> @@ -3318,20 +3371,6 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags,
>  }
>  
>  #ifdef CONFIG_SLUB_DEBUG
> -static unsigned long count_partial(struct kmem_cache_node *n,
> -					int (*get_count)(struct page *))
> -{
> -	unsigned long flags;
> -	unsigned long x = 0;
> -	struct page *page;
> -
> -	spin_lock_irqsave(&n->list_lock, flags);
> -	list_for_each_entry(page, &n->partial, lru)
> -		x += get_count(page);
> -	spin_unlock_irqrestore(&n->list_lock, flags);
> -	return x;
> -}
> -
>  static int count_inuse(struct page *page)
>  {
>  	return page->inuse;
> @@ -3342,11 +3381,6 @@ static int count_total(struct page *page)
>  	return page->objects;
>  }
>  
> -static int count_free(struct page *page)
> -{
> -	return page->objects - page->inuse;
> -}
> -
>  static int validate_slab(struct kmem_cache *s, struct page *page,
>  						unsigned long *map)
>  {
> 
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Wed, 2009-06-10 at 17:52 +0200, Johannes Berg wrote:
> On Wed, 2009-06-10 at 18:49 +0300, Pekka Enberg wrote:
> > On Wed, 2009-06-10 at 18:44 +0300, Pekka Enberg wrote:
> > 
> > > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have
> > > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should
> > > help. Christoph, are you okay with this patch?
> 
> 
> > +	if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE)
> 
> && size <= PAGE_SIZE
> 
> ? Or is this a path that only happens for small allocations?

Anything that's beyond PAGE_SIZE * 2 is passed straight to the page
allocator and the intent of this patch is to disable debugging for all
big caches like SLAB does.

			Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Pekka Enberg wrote:

> Argh, that patch has a typo. Please try this one instead.
> 
> 			Pekka

I installed this patch on top of the other one and have started
testing. It usually takes almost a day for it to occur.

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Wed, 2009-06-10 at 18:49 +0300, Pekka Enberg wrote:
> > On Wed, 2009-06-10 at 18:44 +0300, Pekka Enberg wrote:
> > 
> > > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have
> > > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should
> > > help. Christoph, are you okay with this patch?

On Wed, 2009-06-10 at 17:52 +0200, Johannes Berg wrote:
> > +	if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE)
> 
> && size <= PAGE_SIZE
> 
> ? Or is this a path that only happens for small allocations?
> 
> > +		s->flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER);
> > +
> >  	if (!calculate_sizes(s, -1))
> >  		goto error;

Although something like this would probably be even nicer.

			Pekka

diff --git a/mm/slub.c b/mm/slub.c
index 65ffda5..a4206ef 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2334,6 +2334,16 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
 
 }
 
+#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
+
+static bool must_disable_debug(size_t size)
+{
+	/*
+	 * Disable debugging if it increases the minimum page order.
+	 */
+	return get_order(size + MAX_DEBUG_SIZE) > get_order(size);
+}
+
 static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
 		const char *name, size_t size,
 		size_t align, unsigned long flags,
@@ -2346,6 +2356,9 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
 	s->align = align;
 	s->flags = kmem_cache_flags(size, flags, name, ctor);
 
+	if (must_disable_debug(size))
+		s->flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER);
+
 	if (!calculate_sizes(s, -1))
 		goto error;
 

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Wed, Jun 10, 2009 at 6:56 PM, Mel Gorman<mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote:
> That looks like it would generate easier-to-debug-with messages and to
> not-expert-at-slub eye, it looks correct. Slap a changelog on it with an
> example message and go with it.  It should make page allocation failures
> messages that go through SLUB a lot easier to figure out.

Thanks Mel! The patch is here and will be part of next slab pull
request to Linus:

http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=4bc6e7858da5ea4ecc3e47538f7fabed331cc21b

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Wed, 10 Jun 2009, Pekka Enberg wrote:

> Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have
> CONFIG_SLUB_DEBUG enabled? If yes, something like to following should
> help. Christoph, are you okay with this patch?

He likely has CONFIG_SLUB_DEBUG_ON set which enables debugging and thus
needs more than the payload for metadata.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Wed, 10 Jun 2009, Pekka Enberg wrote:
> > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have
> > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should
> > help. Christoph, are you okay with this patch?

On Thu, 2009-06-11 at 10:41 -0400, Christoph Lameter wrote:
> He likely has CONFIG_SLUB_DEBUG_ON set which enables debugging and thus
> needs more than the payload for metadata.

Yup. I suspect a lot of people who are doing _testing_ enable that. If
you're unhappy with my patch (the get_order one which shouldn't affect
that many caches anyway), any suggestions how to fix this up? It seems
that the wireless stack at least does quite a few kmalloc(4096)
allocations.

We can probably switch back to page allocator pass-through in the near
future (when Mel's patches are in) but we need a fix for -stable.

			Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Thu, 2009-06-11 at 18:09 +0300, Pekka Enberg wrote:
> On Wed, 10 Jun 2009, Pekka Enberg wrote:
> > > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have
> > > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should
> > > help. Christoph, are you okay with this patch?
> 
> On Thu, 2009-06-11 at 10:41 -0400, Christoph Lameter wrote:
> > He likely has CONFIG_SLUB_DEBUG_ON set which enables debugging and thus
> > needs more than the payload for metadata.
> 
> Yup. I suspect a lot of people who are doing _testing_ enable that. If
> you're unhappy with my patch (the get_order one which shouldn't affect
> that many caches anyway), any suggestions how to fix this up? It seems
> that the wireless stack at least does quite a few kmalloc(4096)
> allocations.

I think networking rounds up allocations, but it's not wireless per se.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (61 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date		: 2009-04-29 21:01 (61 days old)
> References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> 		  http://lkml.org/lkml/2009/6/7/136
> Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

The cause of these failures has been determined. The wireless
subsystem frequently requests buffers of size 4096, but when SLUB
debugging is enabled and the debug info is added, the request becomes
of order 1 and memory becomes fragmented.

A controversial "fix" in which SLUB debugging was disabled for
allocations where adding such debugging info would increase the order
was discussed and tried. With a quick look at the commit list for
Linus's tree, I don't see that such a patch is available, but I will
be corrected if I missed it.

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

On Monday 29 June 2009, Larry Finger wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> > Date		: 2009-04-29 21:01 (61 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> > 		  http://lkml.org/lkml/2009/6/7/136
> > Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> 
> The cause of these failures has been determined. The wireless
> subsystem frequently requests buffers of size 4096, but when SLUB
> debugging is enabled and the debug info is added, the request becomes
> of order 1 and memory becomes fragmented.
> 
> A controversial "fix" in which SLUB debugging was disabled for
> allocations where adding such debugging info would increase the order
> was discussed and tried. With a quick look at the commit list for
> Linus's tree, I don't see that such a patch is available, but I will
> be corrected if I missed it.

Thanks for the update.

Hmm, isn't it suboptimal to use a slab allocator for allocations taking up an
entire page?  That's the case on some architectures and seems to be the root
cause of the issue at hand.

Best,
Rafael

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Mon, 29 Jun 2009, Larry Finger wrote:

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13319
> > Subject		: Page allocation failures with b43 and p54usb
> > Submitter	: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> > Date		: 2009-04-29 21:01 (61 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> > 		  http://lkml.org/lkml/2009/6/7/136
> > Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> 
> The cause of these failures has been determined. The wireless
> subsystem frequently requests buffers of size 4096, but when SLUB
> debugging is enabled and the debug info is added, the request becomes
> of order 1 and memory becomes fragmented.
> 
> A controversial "fix" in which SLUB debugging was disabled for
> allocations where adding such debugging info would increase the order
> was discussed and tried. With a quick look at the commit list for
> Linus's tree, I don't see that such a patch is available, but I will
> be corrected if I missed it.
> 

I'd disagree with disabling slub debugging by default for caches where 
oo_order(s->min) increases as the result of using it.  This particular 
page allocation failure is happening for, presumably, kmalloc-4096, and 
the system has 4K pages.  Disabling debugging for that cache (and any of 
its aliases) implicitly will lead to errors going undiagnosed as a result.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

David Rientjes wrote:
> On Mon, 29 Jun 2009, Larry Finger wrote:
> 
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13319
>>> Subject		: Page allocation failures with b43 and p54usb
>>> Submitter	: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>>> Date		: 2009-04-29 21:01 (61 days old)
>>> References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>>> 		  http://lkml.org/lkml/2009/6/7/136
>>> Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>> The cause of these failures has been determined. The wireless
>> subsystem frequently requests buffers of size 4096, but when SLUB
>> debugging is enabled and the debug info is added, the request becomes
>> of order 1 and memory becomes fragmented.
>>
>> A controversial "fix" in which SLUB debugging was disabled for
>> allocations where adding such debugging info would increase the order
>> was discussed and tried. With a quick look at the commit list for
>> Linus's tree, I don't see that such a patch is available, but I will
>> be corrected if I missed it.
>>
> 
> I'd disagree with disabling slub debugging by default for caches where 
> oo_order(s->min) increases as the result of using it.  This particular 
> page allocation failure is happening for, presumably, kmalloc-4096, and 
> the system has 4K pages.  Disabling debugging for that cache (and any of 
> its aliases) implicitly will lead to errors going undiagnosed as a result.

If the current behavior is not changed, I will be forced to disable
SLUB debugging, which will explicitly lead to errors that are
undiagnosed. It seems better to me to debug when you can, but turn off
debugging in cases like this.

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Mon, 29 Jun 2009, Larry Finger wrote:

> > I'd disagree with disabling slub debugging by default for caches where 
> > oo_order(s->min) increases as the result of using it.  This particular 
> > page allocation failure is happening for, presumably, kmalloc-4096, and 
> > the system has 4K pages.  Disabling debugging for that cache (and any of 
> > its aliases) implicitly will lead to errors going undiagnosed as a result.
> 
> If the current behavior is not changed, I will be forced to disable
> SLUB debugging, which will explicitly lead to errors that are
> undiagnosed.

You're buying debugging support at the cost of increased memory 
consumption when you enable CONFIG_SLUB_DEBUG_ON and that's causing the 
page allocation failures because of fragmentation.  To reduce the minimum 
order required for caches such as kmalloc-4096, you'd have to disable 
debugging for that particular cache.  It's my opinion that such a 
configuration should not be the default, however.

You could argue adding `slub_debug=-,kmalloc-4096' support from the 
command line, but CONFIG_SLUB_DEBUG_ON should not change its well-defined 
purpose of enabling debugging on all slab caches.  Otherwise the rest of 
us would be forced to add `slub_debug=,kmalloc-4096' for consistent 
behavior with older kernels.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi David,

On Tue, Jun 30, 2009 at 2:47 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, 29 Jun 2009, Larry Finger wrote:
>
>> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13319
>> > Subject             : Page allocation failures with b43 and p54usb
>> > Submitter   : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>> > Date                : 2009-04-29 21:01 (61 days old)
>> > References  : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>> >               http://lkml.org/lkml/2009/6/7/136
>> > Handled-By  : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>>
>> The cause of these failures has been determined. The wireless
>> subsystem frequently requests buffers of size 4096, but when SLUB
>> debugging is enabled and the debug info is added, the request becomes
>> of order 1 and memory becomes fragmented.
>>
>> A controversial "fix" in which SLUB debugging was disabled for
>> allocations where adding such debugging info would increase the order
>> was discussed and tried. With a quick look at the commit list for
>> Linus's tree, I don't see that such a patch is available, but I will
>> be corrected if I missed it.
>>
>
> I'd disagree with disabling slub debugging by default for caches where
> oo_order(s->min) increases as the result of using it.  This particular
> page allocation failure is happening for, presumably, kmalloc-4096, and
> the system has 4K pages.  Disabling debugging for that cache (and any of
> its aliases) implicitly will lead to errors going undiagnosed as a result.

Well, I obviously don't agree here because kmalloc-4096 debugging
causes problems in the real world. Furthermore, SLUB never supported
debugging for objects that big historically because of page allocator
passthrough. And with Mel Gorman's page allocator optimizations, we
might be going back to that.

So we should fix SLUB debugging as outlined by Mel Gorman and
Christoph Lameter. I simply haven't had the time to do it. Patches are
welcome!

                              Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2316 bytes --]

On Tue, 30 Jun 2009, Pekka Enberg wrote:

> > I'd disagree with disabling slub debugging by default for caches where
> > oo_order(s->min) increases as the result of using it.  This particular
> > page allocation failure is happening for, presumably, kmalloc-4096, and
> > the system has 4K pages.  Disabling debugging for that cache (and any of
> > its aliases) implicitly will lead to errors going undiagnosed as a result.
> 
> Well, I obviously don't agree here because kmalloc-4096 debugging
> causes problems in the real world.

I don't think CONFIG_SLUB_DEBUG_ON is generally the configuration used in 
the real world.

The option has a clear and well-defined purpose and that is to enable 
debugging on all slab caches.  If you modify its definition, users will 
generally ignore the warning about debugging being disabled when "the 
minimum possible order at which slab may be allocated is higher than 
without."  And unless they check the kernel log for such a warning to boot 
with `slab_debug=,kmalloc-4096', we lose testing coverage because we 
cannot enable redzoning or tracing after boot.

> Furthermore, SLUB never supported
> debugging for objects that big historically because of page allocator
> passthrough. And with Mel Gorman's page allocator optimizations, we
> might be going back to that.
> 

Even when page allocation is fast enough, it would still be helpful to 
configure slub to not do passthrough purely for the lightweight debugging 
opportunities.

> So we should fix SLUB debugging as outlined by Mel Gorman and
> Christoph Lameter. I simply haven't had the time to do it. Patches are
> welcome!
> 

You're referring to `slub_debug=A'?  I think CONFIG_SLUB_DEBUG_ON should 
continue to enable debugging on all slab caches and in instances where it 
causes page allocation failures such in Larry's case because 
oo_order(s->min) with debugging on is greater than oo_order(s->min) with 
debugging off, you can emit a friendly warning in your recently added 
slab_out_of_memory() about using `slab_debug=-,<cache>'.

We have a disagreement about which is the default behavior, but I would 
opt on the side of adding exemptions to a debug configuration option as 
opposed to requiring additional command line parameters to be fully 
enabled.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi David,

On Tue, 30 Jun 2009, Pekka Enberg wrote:
>> > I'd disagree with disabling slub debugging by default for caches where
>> > oo_order(s->min) increases as the result of using it.  This particular
>> > page allocation failure is happening for, presumably, kmalloc-4096, and
>> > the system has 4K pages.  Disabling debugging for that cache (and any of
>> > its aliases) implicitly will lead to errors going undiagnosed as a result.
>>
>> Well, I obviously don't agree here because kmalloc-4096 debugging
>> causes problems in the real world.

On Tue, Jun 30, 2009 at 10:47 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> I don't think CONFIG_SLUB_DEBUG_ON is generally the configuration used in
> the real world.

It is, hence the epic bug report that's eaten too many man hours
already! Look, we encourage _testers_ to turn all as much as debugging
options as possible so we catch bugs early. That why the only sane
defaults are the ones that don't cause other problems!

I don't know why you want to argue this. It's simply not an option to
say "stupid user, fix your config" in core code like the slab
allocator. Enabling CONFIG_SLUB_DEBUG_ON is a very reasonable thing to
do when you are a tester looking for bugs.

On Tue, 30 Jun 2009, Pekka Enberg wrote:
>> So we should fix SLUB debugging as outlined by Mel Gorman and
>> Christoph Lameter. I simply haven't had the time to do it. Patches are
>> welcome!

On Tue, Jun 30, 2009 at 10:47 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> You're referring to `slub_debug=A'?  I think CONFIG_SLUB_DEBUG_ON should
> continue to enable debugging on all slab caches and in instances where it
> causes page allocation failures such in Larry's case because
> oo_order(s->min) with debugging on is greater than oo_order(s->min) with
> debugging off, you can emit a friendly warning in your recently added
> slab_out_of_memory() about using `slab_debug=-,<cache>'.
>
> We have a disagreement about which is the default behavior, but I would
> opt on the side of adding exemptions to a debug configuration option as
> opposed to requiring additional command line parameters to be fully
> enabled.

Yup, I was referring to slub_debug=A and no, I don't agree with you
that it should be on by default. Only people who know what they're
doing should enable the option and a random tester by definition
doesn't (no offence to Mr. Random Tester).

                                                   Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Tue, 30 Jun 2009, Pekka Enberg wrote:

> Well, I obviously don't agree here because kmalloc-4096 debugging causes
> problems in the real world. Furthermore, SLUB never supported debugging
> for objects that big historically because of page allocator passthrough.
> And with Mel Gorman's page allocator optimizations, we might be going
> back to that.

SLUB for some period of time had passthrough. It did not start out like
that though.

kmalloc-4096 causes problems in the long run and so do other caches that
are of similar size. But it allows debugging to occur. Silently switching
it off is something I am not comfortable with.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Pekka Enberg wrote:
> 
> Yup, I was referring to slub_debug=A and no, I don't agree with you
> that it should be on by default. Only people who know what they're
> doing should enable the option and a random tester by definition
> doesn't (no offence to Mr. Random Tester).

None taken.

For me, the next step is clear. As I'm much more interested in finding
bugs in the wireless system than in the mechanics of SLUB allocation,
I need to disable CONFIG_SLUB_DEBUG_ON. BTW, I use SLAB on Linus's
mainline tree and SLUB on the wireless testing tree. I build and boot
the mainline kernels mostly to look for quick failures/regressions,
but run the w-t kernels looking for longer-term effects such as memory
fragmentation or slow memory leaks.

For Rafael's benefit, we do need to decide if this is a bug or merely
an unintended side effect. My sense is the latter and Bug #13319
should have a summary of this discussion added to the record, and then
the bug should be closed.

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Tue, 2009-06-30 at 10:32 -0400, Christoph Lameter wrote:
> kmalloc-4096 causes problems in the long run and so do other caches that
> are of similar size. But it allows debugging to occur. Silently switching
> it off is something I am not comfortable with.

I suggested adding a

  printk(KERN_INFO ": debugging disabled for %s. Use slub_debug=a to "
                    "enable it blah blah blah\n");

Does that work for you?

			Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Tue, 30 Jun 2009, Pekka Enberg wrote:

>   printk(KERN_INFO ": debugging disabled for %s. Use slub_debug=a to "
>                     "enable it blah blah blah\n");
>
> Does that work for you?

Its definitely better.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Tue, 30 Jun 2009, Christoph Lameter wrote:

> >   printk(KERN_INFO ": debugging disabled for %s. Use slub_debug=a to "
> >                     "enable it blah blah blah\n");
> >
> > Does that work for you?
> 
> Its definitely better.
> 

I don't see how that's different from enabling debugging on all caches 
like CONFIG_SLAB_DEBUG_ON currently does and then warning at the time of 
slab allocation failure that it may be the result of the debugging 
metadata so the user can subsequently prevent it.  In other words, if we 
use MAX_DEBUG_SIZE as Pekka originally implemented as
(3 * sizeof(void *) + 2 * sizeof(struct track)), do this:

diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -142,6 +142,11 @@
 				SLAB_POISON | SLAB_STORE_USER)
 
 /*
+ * The maximum amount of metadata added to a slab when debugging is enabled.
+ */
+#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
+
+/*
  * Set of flags that will prevent slab merging
  */
 #define SLUB_NEVER_MERGE (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \
@@ -1561,6 +1566,21 @@ slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
 		"default order: %d, min order: %d\n", s->name, s->objsize,
 		s->size, oo_order(s->oo), oo_order(s->min));
 
+	if (s->flags & (SLAB_POISON | SLAB_RED_ZONE | SLAB_STORE_USER)) {
+		int min_order;
+
+		/*
+		 * Debugging is enabled, which may increase oo_order(s->min), so
+		 * warn the user that allocation failures may be avoided if
+		 * debugging is enabled for this cache.
+		 */
+		min_order = get_order(s->size - MAX_DEBUG_SIZE);
+		if (min_order < oo_order(s->min))
+			printk(KERN_WARNING "  %s debugging increased min order "
+			       "from %d to %d, use slab_debug=-,%s to disable.",
+			       s->name, min_order, oo_order(s->min), s->name);
+	}
+
 	for_each_online_node(node) {
 		struct kmem_cache_node *n = get_node(s, node);
 		unsigned long nr_slabs;

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Tue, 30 Jun 2009, Pekka Enberg wrote:

> On Tue, Jun 30, 2009 at 10:47 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> > I don't think CONFIG_SLUB_DEBUG_ON is generally the configuration used in
> > the real world.
> 
> It is, hence the epic bug report that's eaten too many man hours
> already! Look, we encourage _testers_ to turn all as much as debugging
> options as possible so we catch bugs early. That why the only sane
> defaults are the ones that don't cause other problems!
> 

I feel that asking a user to add a command line parameter such as 
`slub_debug=A' in addition to CONFIG_SLUB_DEBUG_ON will likely lead to 
less testing coverage and bugs going unreported.  CONFIG_SLUB_DEBUG_ON is 
not something that a distro is going to enable or would be used in a 
production environment, it's something that's used to debug slub and/or 
slab allocations either during the development of new kernel code or when 
an underlying problem is realized.

> I don't know why you want to argue this. It's simply not an option to
> say "stupid user, fix your config" in core code like the slab
> allocator. Enabling CONFIG_SLUB_DEBUG_ON is a very reasonable thing to
> do when you are a tester looking for bugs.
> 

Quite the contrary, I agree completely with the above, and that's why I'm 
arguing for full debugging to be enabled when a well-defined configuration 
option is enabled.  I simply don't believe that such debugging should be 
coupled with a command line option to be fully activated for all caches.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Tue, 30 Jun 2009, David Rientjes wrote:

> I don't see how that's different from enabling debugging on all caches
> like CONFIG_SLAB_DEBUG_ON currently does and then warning at the time of
> slab allocation failure that it may be the result of the debugging
> metadata so the user can subsequently prevent it.  In other words, if we
> use MAX_DEBUG_SIZE as Pekka originally implemented as
> (3 * sizeof(void *) + 2 * sizeof(struct track)), do this:

I like it.

> diff --git a/mm/slub.c b/mm/slub.c
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -142,6 +142,11 @@
>  				SLAB_POISON | SLAB_STORE_USER)
>
>  /*
> + * The maximum amount of metadata added to a slab when debugging is enabled.
> + */
> +#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
> +
> +/*
>   * Set of flags that will prevent slab merging
>   */
>  #define SLUB_NEVER_MERGE (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \
> @@ -1561,6 +1566,21 @@ slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
>  		"default order: %d, min order: %d\n", s->name, s->objsize,
>  		s->size, oo_order(s->oo), oo_order(s->min));
>
> +	if (s->flags & (SLAB_POISON | SLAB_RED_ZONE | SLAB_STORE_USER)) {
> +		int min_order;
> +
> +		/*
> +		 * Debugging is enabled, which may increase oo_order(s->min), so
> +		 * warn the user that allocation failures may be avoided if
> +		 * debugging is enabled for this cache.
> +		 */
> +		min_order = get_order(s->size - MAX_DEBUG_SIZE);
> +		if (min_order < oo_order(s->min))
> +			printk(KERN_WARNING "  %s debugging increased min order "
> +			       "from %d to %d, use slab_debug=-,%s to disable.",
> +			       s->name, min_order, oo_order(s->min), s->name);

It may be easier to check the order of the initial size vs. the order of
the size with all metadata

if (get_order(s->size) > get_order(s->objsize)

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Tue, 30 Jun 2009, Christoph Lameter wrote:

> > diff --git a/mm/slub.c b/mm/slub.c
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -142,6 +142,11 @@
> >  				SLAB_POISON | SLAB_STORE_USER)
> >
> >  /*
> > + * The maximum amount of metadata added to a slab when debugging is enabled.
> > + */
> > +#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
> > +
> > +/*
> >   * Set of flags that will prevent slab merging
> >   */
> >  #define SLUB_NEVER_MERGE (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \
> > @@ -1561,6 +1566,21 @@ slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
> >  		"default order: %d, min order: %d\n", s->name, s->objsize,
> >  		s->size, oo_order(s->oo), oo_order(s->min));
> >
> > +	if (s->flags & (SLAB_POISON | SLAB_RED_ZONE | SLAB_STORE_USER)) {
> > +		int min_order;
> > +
> > +		/*
> > +		 * Debugging is enabled, which may increase oo_order(s->min), so
> > +		 * warn the user that allocation failures may be avoided if
> > +		 * debugging is enabled for this cache.
> > +		 */
> > +		min_order = get_order(s->size - MAX_DEBUG_SIZE);
> > +		if (min_order < oo_order(s->min))
> > +			printk(KERN_WARNING "  %s debugging increased min order "
> > +			       "from %d to %d, use slab_debug=-,%s to disable.",
> > +			       s->name, min_order, oo_order(s->min), s->name);
> 
> It may be easier to check the order of the initial size vs. the order of
> the size with all metadata
> 
> if (get_order(s->size) > get_order(s->objsize)
> 

Ah, right.  Then we could simply eliminate the check on s->flags to begin 
with.

This patch is supposing that `slab_debug=-,<cache>' actually disables all 
debugging for <cache> which would need to be implemented first, but I 
think this is a better alternative than requiring slab_debug=A for full 
debugging after enabling CONFIG_SLUB_DEBUG_ON.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Tue, 30 Jun 2009, David Rientjes wrote:

> This patch is supposing that `slab_debug=-,<cache>' actually disables all
> debugging for <cache> which would need to be implemented first, but I
> think this is a better alternative than requiring slab_debug=A for full
> debugging after enabling CONFIG_SLUB_DEBUG_ON.

We could add an option that disables debugging for troublesome page
size slabs


slab_debug=p

or so

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Tue, 30 Jun 2009, Christoph Lameter wrote:

> We could add an option that disables debugging for troublesome page
> size slabs
> 
> 
> slab_debug=p
> 
> or so
> 

I definitely like that more than slab_debug=A, where we're requiring an 
added parameter for full debugging to be activated.

I'm curious whether there would ever be any use for disabling debugging on 
specific caches for reasons other than higher minimum orders for metadata, 
though, given that we already support things like slub_debug=FZ,cache, 
which should only enable free debugging and redzoning even with 
CONFIG_SLUB_DEBUG_ON enabled for cache.

I think the solution to this is really based on good software engineering 
and test practices, though, so hopefully there'll be a consensus on which 
direction to take before any time is spent in implementing and pushing it.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Tue, 30 Jun 2009, David Rientjes wrote:

> I'm curious whether there would ever be any use for disabling debugging on
> specific caches for reasons other than higher minimum orders for metadata,
> though, given that we already support things like slub_debug=FZ,cache,
> which should only enable free debugging and redzoning even with
> CONFIG_SLUB_DEBUG_ON enabled for cache.

One of the reasons for disabling debugging is to speed up the kernel. Race
conditions may vanish due to the additional latency added by the debugging
code. Ideally you know which slab cache has the race and you only would
enable it on that one.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi David,

On Wed, Jul 1, 2009 at 12:52 AM, David Rientjes<rientjes@google.com> wrote:
> I think the solution to this is really based on good software engineering
> and test practices, though, so hopefully there'll be a consensus on which
> direction to take before any time is spent in implementing and pushing it.

Lets go with the slab_out_of_memory() patch you outlined in a previous
post and implement the slub_debug=p thing Christoph suggested. I think
it's the best compromise at this point. When you guys finally see the
light, we can always change it to a reasonable default. ;)

So can you send a patch, please?

                        Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Wed, 1 Jul 2009, Pekka Enberg wrote:

> Lets go with the slab_out_of_memory() patch you outlined in a previous
> post and implement the slub_debug=p thing Christoph suggested. I think
> it's the best compromise at this point. When you guys finally see the
> light, we can always change it to a reasonable default. ;)
> 
> So can you send a patch, please?
> 

Sure, let me know if you think this is -rc material; otherwise, the bug 
will have to be deferred until 2.6.32 with the temporary workaround of 
disabling CONFIG_SLUB_DEBUG_ON.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi David,

On Wed, 1 Jul 2009, Pekka Enberg wrote:
>> Lets go with the slab_out_of_memory() patch you outlined in a previous
>> post and implement the slub_debug=p thing Christoph suggested. I think
>> it's the best compromise at this point. When you guys finally see the
>> light, we can always change it to a reasonable default. ;)
>>
>> So can you send a patch, please?

On Thu, Jul 2, 2009 at 8:18 PM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> Sure, let me know if you think this is -rc material; otherwise, the bug
> will have to be deferred until 2.6.32 with the temporary workaround of
> disabling CONFIG_SLUB_DEBUG_ON.

We're at -rc2 so yes, I do think we should fix 2.6.31.

2.6.31-rc2: Reported regressions 2.6.29 -> 2.6.30

[Rafael J. Wysocki]

This message contains a list of some regressions introduced between 2.6.29 and
2.6.30, for which there are no fixes in the mainline I know of.  If any of them
have been fixed already, please let me know.

If you know of any other unresolved regressions introduced between 2.6.29
and 2.6.30, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-07-07      138       50          46
  2009-06-29      133       46          43
  2009-06-07      110       35          31
  2009-05-31      100       32          27
  2009-05-24       92       34          27
  2009-05-16       81       36          33
  2009-04-25       55       36          26
  2009-04-17       37       35          28


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13694
Subject		: i915 phantom TV
Submitter	: Maciek Józiewicz <mjoziew@gmail.com>
Date		: 2009-07-02 12:26 (5 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13682
Subject		: The webcam stopped working when upgrading from 2.6.29 to 2.6.30
Submitter	: Nathanael Schaeffer <nathanael.schaeffer@gmail.com>
Date		: 2009-06-30 13:34 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13681
Subject		: A number of usb Devices causes Oops messages and kernel panics.
Submitter	: Alexander Kaltsas <alexkaltsas@gmail.com>
Date		: 2009-06-30 13:06 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13669
Subject		: Kernel bug with dock driver
Submitter	: Joerg Platte <jplatte@naasa.net>
Date		: 2009-06-14 21:00 (23 days old)
References	: http://lkml.org/lkml/2009/6/14/216
Handled-By	: Henrique de Moraes Holschuh <hmh@hmh.eng.br>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13668
Subject		: Can't boot 2.6.30 powerpc kernel under qemu.
Submitter	: Rob Landley <rob@landley.net>
Date		: 2009-06-27 18:08 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/159


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13660
Subject		: Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
Submitter	: Joao Correia <joaomiguelcorreia@gmail.com>
Date		: 2009-06-27 16:07 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/95


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13651
Subject		: Anyone know what happened with PC speaker in 2.6.30?
Submitter	: Michael Tokarev <mjt@tls.msk.ru>
Date		: 2009-06-15 14:41 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=124507695427817&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
Subject		: nfsd: page allocation failure
Submitter	: Justin Piszcz <jpiszcz@lucidpixels.com>
Date		: 2009-06-22 12:08 (15 days old)
References	: http://lkml.org/lkml/2009/6/22/309


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13647
Subject		: fb/mmap lockdep report.
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2009-06-21 13:33 (16 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189
References	: http://lkml.org/lkml/2009/6/21/90
		  http://lkml.org/lkml/2009/6/21/122


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13646
Subject		: warn_on tty_io.c, broken bluetooth
Submitter	: Pavel Machek <pavel@ucw.cz>
Date		: 2009-06-19 17:05 (18 days old)
References	: http://lkml.org/lkml/2009/6/19/187


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13644
Subject		: hibernation/swsusp lockup due to acpi-cpufreq
Submitter	: Johannes Stezenbach <js@sig21.net>
Date		: 2009-06-16 01:27 (21 days old)
References	: http://lkml.org/lkml/2009/6/15/630
		  http://lkml.org/lkml/2009/6/29/504
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13638
Subject		: rt2870 driver is broken for (some) cards
Submitter	: jakob gruber <jakob.gruber@kabelnet.at>
Date		: 2009-06-27 17:33 (10 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13634
Subject		: [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date		: 2009-06-27 07:02 (10 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
Subject		: usb: wrong autosuspend initialization
Submitter	:  <list@phuk.ath.cx>
Date		: 2009-06-25 18:18 (12 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13621
Subject		: xfs hangs with assertion failed
Submitter	: Johannes Engel <jcnengel@googlemail.com>
Date		: 2009-06-25 10:07 (12 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13620
Subject		: acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date		: 2009-06-25 08:31 (12 days old)
References	: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13583
Subject		: pdflush uses 5% CPU on otherwise idle system
Submitter	: Paul Martin <pm@debian.org>
Date		: 2009-06-19 13:33 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13581
Subject		: ath9k doesn't work with newer kernels
Submitter	: Matteo <rootkit85@yahoo.it>
Date		: 2009-06-19 12:04 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13564
Subject		: random general protection fault at boot time caused by khubd.
Submitter	: Pauli <suokkos@gmail.com>
Date		: 2009-06-18 12:44 (19 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13558
Subject		: Tracelog during resume
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date		: 2009-06-17 11:32 (20 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13554
Subject		: linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
Submitter	: Jos van Wolput <wolput@onsneteindhoven.nl>
Date		: 2009-06-17 06:28 (20 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13518
Subject		: slab grows with NFS write activity.
Submitter	: Andrew Randrianasulu <randrik@mail.ru>
Date		: 2009-06-12 09:51 (25 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13514
Subject		: acer_wmi causes stack corruption
Submitter	: Rus <harbour@sfinx.od.ua>
Date		: 2009-06-12 08:13 (25 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13512
Subject		: D43 on 2.6.30 doesn't suspend anymore
Submitter	: Daniel Smolik <marvin@mydatex.cz>
Date		: 2009-06-11 20:12 (26 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13502
Subject		: GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
Submitter	:  <sveina@gmail.com>
Date		: 2009-06-10 20:04 (27 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13472
Subject		: Oops with minicom and USB serial
Submitter	: Peter Chubb <peterc@gelato.unsw.edu.au>
Date		: 2009-06-05 1:37 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=124416901026700&w=4
Handled-By	: Alan Stern <stern@rowland.harvard.edu>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13471
Subject		: Loading parport_pc kills the keyboard if ACPI is enabled
Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
Date		: 2009-06-04 9:12 (33 days old)
References	: http://marc.info/?l=linux-kernel&m=124410667532558&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13424
Subject		: possible deadlock when doing governor switching
Submitter	: Shaohua Li <shaohua.li@intel.com>
Date		: 2009-05-31 16:36 (37 days old)
References	: http://www.spinics.net/lists/cpufreq/msg00711.html
		  http://lkml.org/lkml/2009/6/28/405
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13408
Subject		: Performance regression in 2.6.30-rc7
Submitter	: Diego Calleja <diegocg@gmail.com>
Date		: 2009-05-30 18:51 (38 days old)
References	: http://lkml.org/lkml/2009/5/30/146


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13407
Subject		: adb trackpad disappears after suspend to ram
Submitter	: Jan Scholz <scholz@fias.uni-frankfurt.de>
Date		: 2009-05-28 7:59 (40 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
References	: http://marc.info/?l=linux-kernel&m=124349762314976&w=4
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13401
Subject		: pktcdvd writing is really slow with CFQ scheduler (bisected)
Submitter	: Laurent Riffard <laurent.riffard@free.fr>
Date		: 2009-05-28 18:43 (40 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject		: reiserfs blocked for more than 120secs
Submitter	: Harald Dunkel <harald.dunkel@t-online.de>
Date		: 2009-05-23 8:52 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=124306880410811&w=4
		  http://lkml.org/lkml/2009/5/29/389


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject		: fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2009-05-23 5:08 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=124305538130702&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13362
Subject		: rt2x00: slow wifi with correct basic rate bitmap
Submitter	: Alejandro Riveira <ariveira@gmail.com>
Date		: 2009-05-22 13:32 (46 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject		: 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
Submitter	:  <unggnu@googlemail.com>
Date		: 2009-05-20 14:09 (48 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742
Handled-By	: Yinghai Lu <yinghai@kernel.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject		: Random Oops at boot at loading ip6tables rules
Submitter	:  <patrick@ostenberg.de>
Date		: 2009-05-19 09:08 (49 days old)
Handled-By	: Rusty Russell <rusty@rustcorp.com.au>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (50 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject		: b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter	: Francis Moreau <francis.moro@gmail.com>
Date		: 2009-05-03 16:22 (65 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject		: Page allocation failures with b43 and p54usb
Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
Date		: 2009-04-29 21:01 (69 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
Handled-By	: Johannes Berg <johannes@sipsolutions.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject		: AGP doesn't work anymore on nforce2
Submitter	: Karsten Mehrhoff <kawime@gmx.de>
Date		: 2009-04-30 8:51 (68 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By	: Shaohua Li <shaohua.li@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject		: hibernate slow on _second_ run
Submitter	: Johannes Berg <johannes@sipsolutions.net>
Date		: 2009-05-14 09:34 (54 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13277
Subject		: 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40
Submitter	: Daniel Vetter <daniel@ffwll.ch>
Date		: 2009-05-11 10:08 (57 days old)
Handled-By	: Len Brown <len.brown@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject		: Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4
Submitter	: David Hill <hilld@binarystorm.net>
Date		: 2009-05-01 16:57 (67 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13179
Subject		: CD-R: wodim intermittent failures
Submitter	: Andy Isaacson <adi@hexapodia.org>
Date		: 2009-04-21 1:52 (77 days old)
References	: http://marc.info/?l=linux-kernel&m=124027879214231&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13119
Subject		: Trouble with make-install from a NFS mount
Submitter	: Gregory Haskins <ghaskins@novell.com>
Date		: 2009-04-14 21:32 (84 days old)
References	: http://marc.info/?l=linux-kernel&m=123974482327044&w=4
Handled-By	: H. Peter Anvin <hpa@zytor.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject		: High latency on /sys/class/thermal
Submitter	: Tiago Simões Batista <tiagosbatista@gmail.com>
Date		: 2009-04-11 14:56 (87 days old)
References	: http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By	: Zhang Rui <rui.zhang@intel.com>
		  Alexey Starikovskiy <astarikovskiy@suse.de>


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13663
Subject		: suspend to ram regression (IDE related)
Submitter	: Etienne Basset <etienne.basset@numericable.fr>
Date		: 2009-06-26 17:40 (11 days old)
References	: http://lkml.org/lkml/2009/6/26/242
		  http://lkml.org/lkml/2009/6/29/126
Handled-By	: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Patch		: http://patchwork.kernel.org/patch/32719/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13649
Subject		: Bad page state in process with various applications
Submitter	: Maxim Levitsky <maximlevitsky@gmail.com>
Date		: 2009-06-20 15:27 (17 days old)
References	: http://marc.info/?l=linux-mm&m=124551168828090&w=4
Handled-By	: Mel Gorman <mel@csn.ul.ie>
Patch		: http://patchwork.kernel.org/patch/33130/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13475
Subject		: suspend/hibernate lockdep warning
Submitter	: Dave Young <hidave.darkstar@gmail.com>
Date		: 2009-06-02 10:00 (35 days old)
References	: http://marc.info/?l=linux-kernel&m=124393723321241&w=4
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Patch		: http://patchwork.kernel.org/patch/28660/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
Subject		: Warning 'Invalid throttling state, reset' gets displayed when it should not be
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2009-05-26 15:24 (42 days old)
Handled-By	: Frans Pop <elendil@planet.nl>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
		  http://bugzilla.kernel.org/attachment.cgi?id=21672


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.29 and 2.6.30, unresolved as well as resolved, at:

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

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have 
the opportunity to enter the BlackBerry Developer Challenge. See full prize 
details at: http://p.sf.net/sfu/blackberry
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug #13109] High latency on /sys/class/thermal

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject		: High latency on /sys/class/thermal
Submitter	: Tiago Simões Batista <tiagosbatista@gmail.com>
Date		: 2009-04-11 14:56 (87 days old)
References	: http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By	: Zhang Rui <rui.zhang@intel.com>
		  Alexey Starikovskiy <astarikovskiy@suse.de>

[Bug #13179] CD-R: wodim intermittent failures

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13179
Subject		: CD-R: wodim intermittent failures
Submitter	: Andy Isaacson <adi-3HqRAUrWAWyGglJvpFV4uA@public.gmane.org>
Date		: 2009-04-21 1:52 (77 days old)
References	: http://marc.info/?l=linux-kernel&m=124027879214231&w=4

[Bug #13277] 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13277
Subject		: 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40
Submitter	: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Date		: 2009-05-11 10:08 (57 days old)
Handled-By	: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

[Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject		: Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4
Submitter	: David Hill <hilld-HTiBYHdybX7UkGsOFmftXw@public.gmane.org>
Date		: 2009-05-01 16:57 (67 days old)

[Bug #13119] Trouble with make-install from a NFS mount

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13119
Subject		: Trouble with make-install from a NFS mount
Submitter	: Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
Date		: 2009-04-14 21:32 (84 days old)
References	: http://marc.info/?l=linux-kernel&m=123974482327044&w=4
Handled-By	: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>

[Bug #13318] AGP doesn't work anymore on nforce2

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject		: AGP doesn't work anymore on nforce2
Submitter	: Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org>
Date		: 2009-04-30 8:51 (68 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By	: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

[Bug #13306] hibernate slow on _second_ run

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject		: hibernate slow on _second_ run
Submitter	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date		: 2009-05-14 09:34 (54 days old)

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (69 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

[Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject		: b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter	: Francis Moreau <francis.moro@gmail.com>
Date		: 2009-05-03 16:22 (65 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
Date		: 2009-05-18 10:59 (50 days old)

[Bug #13362] rt2x00: slow wifi with correct basic rate bitmap

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13362
Subject		: rt2x00: slow wifi with correct basic rate bitmap
Submitter	: Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-22 13:32 (46 days old)

[Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject		: 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
Submitter	:  <unggnu-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date		: 2009-05-20 14:09 (48 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742
Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

[Bug #13341] Random Oops at boot at loading ip6tables rules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject		: Random Oops at boot at loading ip6tables rules
Submitter	:  <patrick-nxAOmsU53hB6lmGzAMPh1A@public.gmane.org>
Date		: 2009-05-19 09:08 (49 days old)
Handled-By	: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>

[Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
Subject		: Warning 'Invalid throttling state, reset' gets displayed when it should not be
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-05-26 15:24 (42 days old)
Handled-By	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
		  http://bugzilla.kernel.org/attachment.cgi?id=21672

[Bug #13374] reiserfs blocked for more than 120secs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject		: reiserfs blocked for more than 120secs
Submitter	: Harald Dunkel <harald.dunkel-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Date		: 2009-05-23 8:52 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=124306880410811&w=4
		  http://lkml.org/lkml/2009/5/29/389

[Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject		: fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-23 5:08 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=124305538130702&w=4

[Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13401
Subject		: pktcdvd writing is really slow with CFQ scheduler (bisected)
Submitter	: Laurent Riffard <laurent.riffard-GANU6spQydw@public.gmane.org>
Date		: 2009-05-28 18:43 (40 days old)

[Bug #13407] adb trackpad disappears after suspend to ram

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13407
Subject		: adb trackpad disappears after suspend to ram
Submitter	: Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
Date		: 2009-05-28 7:59 (40 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
References	: http://marc.info/?l=linux-kernel&m=124349762314976&w=4
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>

[Bug #13408] Performance regression in 2.6.30-rc7

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13408
Subject		: Performance regression in 2.6.30-rc7
Submitter	: Diego Calleja <diegocg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-30 18:51 (38 days old)
References	: http://lkml.org/lkml/2009/5/30/146

[Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13471
Subject		: Loading parport_pc kills the keyboard if ACPI is enabled
Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
Date		: 2009-06-04 9:12 (33 days old)
References	: http://marc.info/?l=linux-kernel&m=124410667532558&w=4


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug #13424] possible deadlock when doing governor switching

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13424
Subject		: possible deadlock when doing governor switching
Submitter	: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-31 16:36 (37 days old)
References	: http://www.spinics.net/lists/cpufreq/msg00711.html
		  http://lkml.org/lkml/2009/6/28/405
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>

[Bug #13475] suspend/hibernate lockdep warning

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13475
Subject		: suspend/hibernate lockdep warning
Submitter	: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-02 10:00 (35 days old)
References	: http://marc.info/?l=linux-kernel&m=124393723321241&w=4
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/28660/

[Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13502
Subject		: GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
Submitter	:  <sveina-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-10 20:04 (27 days old)

[Bug #13472] Oops with minicom and USB serial

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13472
Subject		: Oops with minicom and USB serial
Submitter	: Peter Chubb <peterc-M3ycANVxPotyL3EAZA59ERCuuivNXqWP@public.gmane.org>
Date		: 2009-06-05 1:37 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=124416901026700&w=4
Handled-By	: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>

[Bug #13518] slab grows with NFS write activity.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13518
Subject		: slab grows with NFS write activity.
Submitter	: Andrew Randrianasulu <randrik-JGs/UdohzUI@public.gmane.org>
Date		: 2009-06-12 09:51 (25 days old)

[Bug #13514] acer_wmi causes stack corruption

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13514
Subject		: acer_wmi causes stack corruption
Submitter	: Rus <harbour-K87ZgELTUEPsG83rWm+8vg@public.gmane.org>
Date		: 2009-06-12 08:13 (25 days old)

[Bug #13512] D43 on 2.6.30 doesn't suspend anymore

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13512
Subject		: D43 on 2.6.30 doesn't suspend anymore
Submitter	: Daniel Smolik <marvin-0pWKB23IDFjrBKCeMvbIDA@public.gmane.org>
Date		: 2009-06-11 20:12 (26 days old)

[Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13554
Subject		: linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
Submitter	: Jos van Wolput <wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org>
Date		: 2009-06-17 06:28 (20 days old)

[Bug #13558] Tracelog during resume

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13558
Subject		: Tracelog during resume
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org>
Date		: 2009-06-17 11:32 (20 days old)

[Bug #13564] random general protection fault at boot time caused by khubd.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13564
Subject		: random general protection fault at boot time caused by khubd.
Submitter	: Pauli <suokkos-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-18 12:44 (19 days old)

[Bug #13581] ath9k doesn't work with newer kernels

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13581
Subject		: ath9k doesn't work with newer kernels
Submitter	: Matteo <rootkit85-whZMOeQn8C0@public.gmane.org>
Date		: 2009-06-19 12:04 (18 days old)

[Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13620
Subject		: acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
Submitter	: Alan Jenkins <alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org>
Date		: 2009-06-25 08:31 (12 days old)
References	: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>

[Bug #13583] pdflush uses 5% CPU on otherwise idle system

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13583
Subject		: pdflush uses 5% CPU on otherwise idle system
Submitter	: Paul Martin <pm-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Date		: 2009-06-19 13:33 (18 days old)

[Bug #13624] usb: wrong autosuspend initialization

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
Subject		: usb: wrong autosuspend initialization
Submitter	:  <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org>
Date		: 2009-06-25 18:18 (12 days old)

[Bug #13621] xfs hangs with assertion failed

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13621
Subject		: xfs hangs with assertion failed
Submitter	: Johannes Engel <jcnengel-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date		: 2009-06-25 10:07 (12 days old)

[Bug #13638] rt2870 driver is broken for (some) cards

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13638
Subject		: rt2870 driver is broken for (some) cards
Submitter	: jakob gruber <jakob.gruber-1wqg/2C4znHk7+2FdBfRIA@public.gmane.org>
Date		: 2009-06-27 17:33 (10 days old)

[Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13634
Subject		: [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org>
Date		: 2009-06-27 07:02 (10 days old)

[Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13644
Subject		: hibernation/swsusp lockup due to acpi-cpufreq
Submitter	: Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
Date		: 2009-06-16 01:27 (21 days old)
References	: http://lkml.org/lkml/2009/6/15/630
		  http://lkml.org/lkml/2009/6/29/504
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>

[Bug #13646] warn_on tty_io.c, broken bluetooth

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13646
Subject		: warn_on tty_io.c, broken bluetooth
Submitter	: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date		: 2009-06-19 17:05 (18 days old)
References	: http://lkml.org/lkml/2009/6/19/187

[Bug #13647] fb/mmap lockdep report.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13647
Subject		: fb/mmap lockdep report.
Submitter	: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date		: 2009-06-21 13:33 (16 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189
References	: http://lkml.org/lkml/2009/6/21/90
		  http://lkml.org/lkml/2009/6/21/122

[Bug #13648] nfsd: page allocation failure

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
Subject		: nfsd: page allocation failure
Submitter	: Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
Date		: 2009-06-22 12:08 (15 days old)
References	: http://lkml.org/lkml/2009/6/22/309

[Bug #13649] Bad page state in process with various applications

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13649
Subject		: Bad page state in process with various applications
Submitter	: Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-20 15:27 (17 days old)
References	: http://marc.info/?l=linux-mm&m=124551168828090&w=4
Handled-By	: Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/33130/

[Bug #13651] Anyone know what happened with PC speaker in 2.6.30?

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13651
Subject		: Anyone know what happened with PC speaker in 2.6.30?
Submitter	: Michael Tokarev <mjt-XAri/EZa3C4vJsYlp49lxw@public.gmane.org>
Date		: 2009-06-15 14:41 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=124507695427817&w=4

[Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13660
Subject		: Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
Submitter	: Joao Correia <joaomiguelcorreia-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-27 16:07 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/95

[Bug #13663] suspend to ram regression (IDE related)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13663
Subject		: suspend to ram regression (IDE related)
Submitter	: Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
Date		: 2009-06-26 17:40 (11 days old)
References	: http://lkml.org/lkml/2009/6/26/242
		  http://lkml.org/lkml/2009/6/29/126
Handled-By	: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/32719/

[Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13668
Subject		: Can't boot 2.6.30 powerpc kernel under qemu.
Submitter	: Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
Date		: 2009-06-27 18:08 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/159

[Bug #13669] Kernel bug with dock driver

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13669
Subject		: Kernel bug with dock driver
Submitter	: Joerg Platte <jplatte-v18Uk5sXZWJeoWH0uzbU5w@public.gmane.org>
Date		: 2009-06-14 21:00 (23 days old)
References	: http://lkml.org/lkml/2009/6/14/216
Handled-By	: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>

[Bug #13681] A number of usb Devices causes Oops messages and kernel panics.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13681
Subject		: A number of usb Devices causes Oops messages and kernel panics.
Submitter	: Alexander Kaltsas <alexkaltsas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-30 13:06 (7 days old)

[Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13682
Subject		: The webcam stopped working when upgrading from 2.6.29 to 2.6.30
Submitter	: Nathanael Schaeffer <nathanael.schaeffer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-30 13:34 (7 days old)

[Bug #13694] i915 phantom TV

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13694
Subject		: i915 phantom TV
Submitter	: Maciek Józiewicz <mjoziew-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-02 12:26 (5 days old)

Re: [Bug #13306] hibernate slow on _second_ run

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On Tue, 2009-07-07 at 02:00 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
> Subject		: hibernate slow on _second_ run
> Submitter	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> Date		: 2009-05-14 09:34 (54 days old)

Still exists in 31-rc2.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13624] usb: wrong autosuspend initialization

[list]

I think this should be considered a regression, at least until 
laptop_mode has been fixed to deal with it. I've reported it to their 
mailing list, but it seems somebody has to come up with a patch (I won't 
be able to look into it before mid-August).

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
> Subject		: usb: wrong autosuspend initialization
> Submitter	:  <list@phuk.ath.cx>
> Date		: 2009-06-25 18:18 (12 days old)
> 
> 

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date		: 2009-04-29 21:01 (69 days old)
> References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> 		  http://lkml.org/lkml/2009/6/7/136
> Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

I have not seen the fix yet, but one is being prepared. I think the
bug can be closed.

Larry

Re: [Bug #13318] AGP doesn't work anymore on nforce2

[Shaohua Li]

On Tue, Jul 07, 2009 at 08:00:36AM +0800, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
> Subject		: AGP doesn't work anymore on nforce2
> Submitter	: Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org>
> Date		: 2009-04-30 8:51 (68 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
> References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
> Handled-By	: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Can anybody else help look at this issue? I really have no idea why this could
happens.

Thanks,
Shaohua

Re: [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu.

[Rob Landley]

On Monday 06 July 2009 19:01:05 Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13668
> Subject		: Can't boot 2.6.30 powerpc kernel under qemu.
> Submitter	: Rob Landley <rob@landley.net>
> Date		: 2009-06-27 18:08 (10 days old)
> References	: http://lkml.org/lkml/2009/6/27/159

Resolved, it just required a configuration change.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

Re: [Bug #13648] nfsd: page allocation failure

[David Rientjes]

On Tue, 7 Jul 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
> Subject		: nfsd: page allocation failure
> Submitter	: Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
> Date		: 2009-06-22 12:08 (15 days old)
> References	: http://lkml.org/lkml/2009/6/22/309
> 

Here's the last page allocation failure in the bug report:

[415964.311165] nfsd: page allocation failure. order:0, mode:0x20
[415964.311168] Pid: 2680, comm: nfsd Not tainted 2.6.30 #2
[415964.311170] Call Trace:
[415964.311171]  <IRQ>  [<ffffffff802849ed>] ? __alloc_pages_internal+0x3dd/0x4e0
[415964.311179]  [<ffffffff802a6c77>] ? cache_alloc_refill+0x2d7/0x570
[415964.311182]  [<ffffffff802a707d>] ? kmem_cache_alloc+0x8d/0xa0
[415964.311185]  [<ffffffff805a6109>] ? __alloc_skb+0x49/0x160
[415964.311188]  [<ffffffff805ea846>] ? tcp_send_ack+0x26/0x120
[415964.311191]  [<ffffffff805e867d>] ? tcp_rcv_established+0x7bd/0x940
[415964.311193]  [<ffffffff805efb1d>] ? tcp_v4_do_rcv+0xdd/0x210
[415964.311195]  [<ffffffff805f02d6>] ? tcp_v4_rcv+0x686/0x750
...
[415964.311319] Active_anon:154810 active_file:131162 inactive_anon:33447
[415964.311320]  inactive_file:690987 unevictable:0 dirty:112116 writeback:0 unstable:0
[415964.311321]  free:8662 slab:965366 mapped:9316 pagetables:4618 bounce:0
[415964.311325] DMA free:9692kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:8668kB pages_scanned:0 all_unreclaimable? yes
[415964.311328] lowmem_reserve[]: 0 3246 7980 7980
[415964.311333] DMA32 free:21312kB min:6656kB low:8320kB high:9984kB active_anon:118464kB inactive_anon:23908kB active_file:174708kB inactive_file:1206812kB unevictable:0kB present:3324312kB pages_scanned:0 all_unreclaimable? no
[415964.311336] lowmem_reserve[]: 0 0 4734 4734
[415964.311341] Normal free:3644kB min:9708kB low:12132kB high:14560kB active_anon:500776kB inactive_anon:109880kB active_file:349940kB inactive_file:1557136kB unevictable:0kB present:4848000kB pages_scanned:0 all_unreclaimable? no
[415964.311344] lowmem_reserve[]: 0 0 0 0
...

There's simply no memory available in ZONE_NORMAL to satisfy the atomic 
allocation; you've been able to allocate beyond the 9708K minimum 
watermark because it's GFP_ATOMIC (and then only to 3641K because of 
ALLOC_HIGH and ALLOC_HARDER).

112116 pages, or 438M of memory, is dirty.

[415964.311369] 827035 total pagecache pages
[415964.311371] 4728 pages in swap cache
[415964.311373] Swap cache stats: add 12746, delete 8018, find 16878/17480
[415964.311374] Free swap  = 16756356kB
[415964.311375] Total swap = 16787768kB
[415964.312141] 2277376 pages RAM
[415964.312141] 252254 pages reserved
[415964.312141] 546309 pages shared
[415964.312141] 1520221 pages non-shared

And since you have an 8G machine, that value is only about half of the 
default dirty_background_ratio setting of 10 to start pdflush from writing 
it out.

What is suspect is almost half of your system's memory is consumed by 
slab.  Have you been able to collect slabtop -o when these failures happen 
to determine whether this is a duplicate of 
http://bugzilla.kernel.org/show_bug.cgi?id=13518 ?

Re: [Bug #13647] fb/mmap lockdep report.

[Jarek Poplawski]

On Tue, Jul 07, 2009 at 02:00:51AM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13647
> Subject		: fb/mmap lockdep report.
> Submitter	: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date		: 2009-06-21 13:33 (16 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189
> References	: http://lkml.org/lkml/2009/6/21/90
> 		  http://lkml.org/lkml/2009/6/21/122

This lockdep report isn't triggered by 2.6.31-rc2 anymore.

Thanks,
Jarek P.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Mon, 6 Jul 2009, Larry Finger wrote:

> I have not seen the fix yet, but one is being prepared. I think the
> bug can be closed.
> 

http://patchwork.kernel.org/patch/34385 should fix your issue (try with 
CONFIG_SLUB_DEBUG_ON still enabled and slub_debug=O on the command line).

Pekka indicated he wanted this fixed in 2.6.31, so he'll probably push it 
to Linus before the 2.6.31-rc3.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi,

On Mon, 6 Jul 2009, Larry Finger wrote:
>> I have not seen the fix yet, but one is being prepared. I think the
>> bug can be closed.

On Tue, Jul 7, 2009 at 9:29 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> http://patchwork.kernel.org/patch/34385 should fix your issue (try with
> CONFIG_SLUB_DEBUG_ON still enabled and slub_debug=O on the command line).
>
> Pekka indicated he wanted this fixed in 2.6.31, so he'll probably push it
> to Linus before the 2.6.31-rc3.

Yup, if it's not too much trouble Larry, I'd appreciate if you gave it
a spin before I apply the sucker. Note to regression trackers, I don't
think this should go to -stable because it depends on other patches in
mainline and there's an obvious workaround for the problem (disable
CONFIG_SLUB_DEBUG_ON). Furthermore, it's very unlikely people will hit
this on production configurations anyway.

                        Pekka

Re: [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30

[Oliver Neukum]

Am Dienstag, 7. Juli 2009 02:01:07 schrieb Rafael J. Wysocki:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13682
> Subject		: The webcam stopped working when upgrading from 2.6.29 to 2.6.30
> Submitter	: Nathanael Schaeffer <nathanael.schaeffer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-06-30 13:34 (7 days old)

This is caused by selecting a format (no longer / not) supported. Please make
an strace of the failing programm so we know what it requests.

	Regards
		Oliver

Re: [Bug #13648] nfsd: page allocation failure

[Justin Piszcz]

On Mon, 6 Jul 2009, David Rientjes wrote:

> On Tue, 7 Jul 2009, Rafael J. Wysocki wrote:
>
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.29 and 2.6.30.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
>> Subject		: nfsd: page allocation failure
>> Submitter	: Justin Piszcz <jpiszcz@lucidpixels.com>
>> Date		: 2009-06-22 12:08 (15 days old)
>> References	: http://lkml.org/lkml/2009/6/22/309
>>
>
> Here's the last page allocation failure in the bug report:
>
> [415964.311165] nfsd: page allocation failure. order:0, mode:0x20
> [415964.311168] Pid: 2680, comm: nfsd Not tainted 2.6.30 #2
> [415964.311170] Call Trace:
> [415964.311171]  <IRQ>  [<ffffffff802849ed>] ? __alloc_pages_internal+0x3dd/0x4e0
> [415964.311179]  [<ffffffff802a6c77>] ? cache_alloc_refill+0x2d7/0x570
> [415964.311182]  [<ffffffff802a707d>] ? kmem_cache_alloc+0x8d/0xa0
> [415964.311185]  [<ffffffff805a6109>] ? __alloc_skb+0x49/0x160
> [415964.311188]  [<ffffffff805ea846>] ? tcp_send_ack+0x26/0x120
> [415964.311191]  [<ffffffff805e867d>] ? tcp_rcv_established+0x7bd/0x940
> [415964.311193]  [<ffffffff805efb1d>] ? tcp_v4_do_rcv+0xdd/0x210
> [415964.311195]  [<ffffffff805f02d6>] ? tcp_v4_rcv+0x686/0x750
> ...
> [415964.311319] Active_anon:154810 active_file:131162 inactive_anon:33447
> [415964.311320]  inactive_file:690987 unevictable:0 dirty:112116 writeback:0 unstable:0
> [415964.311321]  free:8662 slab:965366 mapped:9316 pagetables:4618 bounce:0
> [415964.311325] DMA free:9692kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:8668kB pages_scanned:0 all_unreclaimable? yes
> [415964.311328] lowmem_reserve[]: 0 3246 7980 7980
> [415964.311333] DMA32 free:21312kB min:6656kB low:8320kB high:9984kB active_anon:118464kB inactive_anon:23908kB active_file:174708kB inactive_file:1206812kB unevictable:0kB present:3324312kB pages_scanned:0 all_unreclaimable? no
> [415964.311336] lowmem_reserve[]: 0 0 4734 4734
> [415964.311341] Normal free:3644kB min:9708kB low:12132kB high:14560kB active_anon:500776kB inactive_anon:109880kB active_file:349940kB inactive_file:1557136kB unevictable:0kB present:4848000kB pages_scanned:0 all_unreclaimable? no
> [415964.311344] lowmem_reserve[]: 0 0 0 0
> ...
>
> There's simply no memory available in ZONE_NORMAL to satisfy the atomic
> allocation; you've been able to allocate beyond the 9708K minimum
> watermark because it's GFP_ATOMIC (and then only to 3641K because of
> ALLOC_HIGH and ALLOC_HARDER).
>
> 112116 pages, or 438M of memory, is dirty.
>
> [415964.311369] 827035 total pagecache pages
> [415964.311371] 4728 pages in swap cache
> [415964.311373] Swap cache stats: add 12746, delete 8018, find 16878/17480
> [415964.311374] Free swap  = 16756356kB
> [415964.311375] Total swap = 16787768kB
> [415964.312141] 2277376 pages RAM
> [415964.312141] 252254 pages reserved
> [415964.312141] 546309 pages shared
> [415964.312141] 1520221 pages non-shared
>
> And since you have an 8G machine, that value is only about half of the
> default dirty_background_ratio setting of 10 to start pdflush from writing
> it out.
>
> What is suspect is almost half of your system's memory is consumed by
> slab.  Have you been able to collect slabtop -o when these failures happen
> to determine whether this is a duplicate of
> http://bugzilla.kernel.org/show_bug.cgi?id=13518 ?
>

As of yet, the problem has not recurred, when it does, will pull slabtop 
-o output.

Justin.

Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap

[Alejandro Riveira Fernández]

El Tue,  7 Jul 2009 02:00:38 +0200 (CEST)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> escribió:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 

 It should be still listed 2.6.30.1 does not fix it. still not tried
2.6.31-rc* though.

> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13362
> Subject		: rt2x00: slow wifi with correct basic rate bitmap
> Submitter	: Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-05-22 13:32 (46 days old)
> 
> 

Re: [Bug #13306] hibernate slow on _second_ run

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Johannes Berg wrote:
> On Tue, 2009-07-07 at 02:00 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
> > Subject		: hibernate slow on _second_ run
> > Submitter	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> > Date		: 2009-05-14 09:34 (54 days old)
> 
> Still exists in 31-rc2.

Thanks for the update.

Last time I remember you managed to collect some ftrace output from the failing
case, but they didn't reveal anything directly.

We know, however, that is [suspend|resume]_device_irqs() in
driver/base/power/main.c are disabled, the issue doesn't show up.

Is that correct?

Rafael

Re: [Bug #13318] AGP doesn't work anymore on nforce2

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Shaohua Li wrote:
> On Tue, Jul 07, 2009 at 08:00:36AM +0800, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
> > Subject		: AGP doesn't work anymore on nforce2
> > Submitter	: Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org>
> > Date		: 2009-04-30 8:51 (68 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
> > References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
> > Handled-By	: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Can anybody else help look at this issue? I really have no idea why this could
> happens.

Quirky hardware?

Rafael

Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Alejandro Riveira Fernández wrote:
> El Tue,  7 Jul 2009 02:00:38 +0200 (CEST)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> escribió:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> 
>  It should be still listed 2.6.30.1 does not fix it. still not tried
> 2.6.31-rc* though.

Thanks for the update.

Best,
Rafael

Re: [Bug #13647] fb/mmap lockdep report.

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Jarek Poplawski wrote:
> On Tue, Jul 07, 2009 at 02:00:51AM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13647
> > Subject		: fb/mmap lockdep report.
> > Submitter	: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Date		: 2009-06-21 13:33 (16 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189
> > References	: http://lkml.org/lkml/2009/6/21/90
> > 		  http://lkml.org/lkml/2009/6/21/122
> 
> This lockdep report isn't triggered by 2.6.31-rc2 anymore.

Thanks, I've closed the bug.

Best,
Rafael

Re: [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu.

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Rob Landley wrote:
> On Monday 06 July 2009 19:01:05 Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13668
> > Subject		: Can't boot 2.6.30 powerpc kernel under qemu.
> > Submitter	: Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
> > Date		: 2009-06-27 18:08 (10 days old)
> > References	: http://lkml.org/lkml/2009/6/27/159
> 
> Resolved, it just required a configuration change.

Thanks, closed.

Best,
Rafael

Re: [Bug #13306] hibernate slow on _second_ run

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On Tue, 2009-07-07 at 12:58 +0200, Rafael J. Wysocki wrote:

> Thanks for the update.
> 
> Last time I remember you managed to collect some ftrace output from the failing
> case, but they didn't reveal anything directly.
> 
> We know, however, that is [suspend|resume]_device_irqs() in
> driver/base/power/main.c are disabled, the issue doesn't show up.
> 
> Is that correct?

I'm not sure -- did we verify that somehow? I was running with some
trial patch from you for a long time but it had no apparent effect.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13318] AGP doesn't work anymore on nforce2

[Bartlomiej Zolnierkiewicz]

On Tuesday 07 July 2009 13:00:11 Rafael J. Wysocki wrote:
> On Tuesday 07 July 2009, Shaohua Li wrote:
> > On Tue, Jul 07, 2009 at 08:00:36AM +0800, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.29 and 2.6.30.
> > > 
> > > The following bug entry is on the current list of known regressions
> > > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > > be listed and let me know (either way).
> > > 
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
> > > Subject		: AGP doesn't work anymore on nforce2
> > > Submitter	: Karsten Mehrhoff <kawime@gmx.de>
> > > Date		: 2009-04-30 8:51 (68 days old)
> > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
> > > References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
> > > Handled-By	: Shaohua Li <shaohua.li@intel.com>
> > Can anybody else help look at this issue? I really have no idea why this could
> > happens.
> 
> Quirky hardware?

Could be a weird interaction between CONFIG_X86_USE_3DNOW and AGP
or "simply" some timing issue.  Either way it means a lot of "fun". ;)

The latter theory can be verified by adding some {u,m}delay() to
agp_generic_alloc_page{s}() and the former one with:

---
 arch/x86/Kconfig.cpu |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/arch/x86/Kconfig.cpu
===================================================================
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -363,7 +363,7 @@ config X86_USE_PPRO_CHECKSUM
 
 config X86_USE_3DNOW
 	def_bool y
-	depends on (MCYRIXIII || MK7 || MGEODE_LX) && !UML
+	depends on (MCYRIXIII || MGEODE_LX) && !UML
 
 config X86_OOSTORE
 	def_bool y

Re: [Bug #13663] suspend to ram regression (IDE related)

[Etienne Basset]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13663
> Subject		: suspend to ram regression (IDE related)
> Submitter	: Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> Date		: 2009-06-26 17:40 (11 days old)
> References	: http://lkml.org/lkml/2009/6/26/242
> 		  http://lkml.org/lkml/2009/6/29/126
> Handled-By	: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/32719/
> 
> 
> 
hello,

current git is OK, patch is not yet in 2.6.30-stable

regards
Etienne

Re: [Bug #13651] Anyone know what happened with PC speaker in 2.6.30?

[Frans Pop]

On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13651
> Subject	: Anyone know what happened with PC speaker in 2.6.30?
> Submitter	: Michael Tokarev <mjt@tls.msk.ru>
> Date		: 2009-06-15 14:41 (22 days old)
> References	: http://marc.info/?l=linux-kernel&m=124507695427817&w=4

Given the last comments from Michael I think this should be closed as "not 
a bug". The observed behavior is intended.
See: http://lkml.org/lkml/2009/6/29/232.

Cheers,
FJP

Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be

[Frans Pop]

On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
> Subject	: Warning 'Invalid throttling state, reset' gets displayed when
>		  it should not be 
> Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> 
> Date		: 2009-05-26 15:24 (42 days old)
> Handled-By	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
> Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
> 		  http://bugzilla.kernel.org/attachment.cgi?id=21672

I still have not received any reaction from the ACPI maintainers to the 
bug or the proposed patches.

Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Frans Pop wrote:
> On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
> > Subject	: Warning 'Invalid throttling state, reset' gets displayed when
> >		  it should not be 
> > Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> 
> > Date		: 2009-05-26 15:24 (42 days old)
> > Handled-By	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
> > Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
> > 		  http://bugzilla.kernel.org/attachment.cgi?id=21672
> 
> I still have not received any reaction from the ACPI maintainers to the 
> bug or the proposed patches.

Sorry for that.

Len, what do you think of the patches listed above?

Rafael

Re: [Bug #13651] Anyone know what happened with PC speaker in 2.6.30?

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Frans Pop wrote:
> On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13651
> > Subject	: Anyone know what happened with PC speaker in 2.6.30?
> > Submitter	: Michael Tokarev <mjt-XAri/EZa3C4vJsYlp49lxw@public.gmane.org>
> > Date		: 2009-06-15 14:41 (22 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124507695427817&w=4
> 
> Given the last comments from Michael I think this should be closed as "not 
> a bug". The observed behavior is intended.
> See: http://lkml.org/lkml/2009/6/29/232.

Well, I guess the regression here is the apparent lack of documentation, but
now that the problem has been discussed, I guess this is not a problem any
more.

Best,
Rafael

Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be

[Zhang Rui]

On Wed, 2009-07-08 at 04:11 +0800, Rafael J. Wysocki wrote:
> On Tuesday 07 July 2009, Frans Pop wrote:
> > On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> > > The following bug entry is on the current list of known regressions
> > > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > > be listed and let me know (either way).
> > >
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
> > > Subject	: Warning 'Invalid throttling state, reset' gets displayed when
> > >		  it should not be 
> > > Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> 
> > > Date		: 2009-05-26 15:24 (42 days old)
> > > Handled-By	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
> > > Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
> > > 		  http://bugzilla.kernel.org/attachment.cgi?id=21672
> > 
both
Acked-by: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

thanks,
rui

> > I still have not received any reaction from the ACPI maintainers to the 
> > bug or the proposed patches.
> 
> Sorry for that.
> 
> Len, what do you think of the patches listed above?
> 
> Rafael

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Pekka Enberg wrote:
> 
> Yup, if it's not too much trouble Larry, I'd appreciate if you gave it
> a spin before I apply the sucker. Note to regression trackers, I don't
> think this should go to -stable because it depends on other patches in
> mainline and there's an obvious workaround for the problem (disable
> CONFIG_SLUB_DEBUG_ON). Furthermore, it's very unlikely people will hit
> this on production configurations anyway.

Pekka,

I have been running the patch for ~24 hours with slub_debug=0 as a
boot option. So far, no problems. My workload has not involved as many
network operations as some times, but my memory has not fragmented.
The output of 'cat /proc/buddyinfo' is as follows:

Node 0, zone      DMA      8      5      5      4      5      5      5
     4      3      0      1
Node 0, zone    DMA32   1804   1585   3007     36      0      0      0
     0      1      0      0

As might be expected, the high-order fragments are gone, but the O(1)
pieces have not been depleted.

Larry

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Hi,

I'm not sure if I experience the same bug on my apple iBook G4 (ppc
7447A, altivec supported PowerBook6,5) or just something very similar.

With v2.6.30-rc1 I noticed, that suspending to ram does not work if my
wireless card is 'up'. The wireless card is an apple airport extreme
card, this is its lspci output:

0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

I tested suspend like this:

# unload the wireless module
modprobe -r b43
echo mem > /sys/power/state

# wake up works fine

#loading b43
modprobe b43
echo mem > /sys/power/state

# wake up still works fine

ifconfig wlan0 up
echo mem > /sys/power/state

# the box does not wake up, I guess it's not really sleeping, because
# the sleep led is not on

I bisected this and got:

5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit
commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
Author: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date:   Sun May 17 11:40:42 2009 +0200
   
    mac80211: cancel/restart all timers across suspend/resume


Best regards,
    Jan Scholz

"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
> Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
> Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
> Date		: 2009-05-18 10:59 (50 days old)
>

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Hi,

I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
(I wanted to test this on v2.6.31-rc2 as well, but there I had other
suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)

For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
with the test procedure described below, but it works fine when I revert
commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
 "mac80211: cancel/restart all timers across suspend/resume"

Best regards,
   Jan

Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org> writes:

> Hi,
>
> I'm not sure if I experience the same bug on my apple iBook G4 (ppc
> 7447A, altivec supported PowerBook6,5) or just something very similar.
>
> With v2.6.30-rc1 I noticed, that suspending to ram does not work if my
> wireless card is 'up'. The wireless card is an apple airport extreme
> card, this is its lspci output:
>
> 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
>
> I tested suspend like this:
>
> # unload the wireless module
> modprobe -r b43
> echo mem > /sys/power/state
>
> # wake up works fine
>
> #loading b43
> modprobe b43
> echo mem > /sys/power/state
>
> # wake up still works fine
>
> ifconfig wlan0 up
> echo mem > /sys/power/state
>
> # the box does not wake up, I guess it's not really sleeping, because
> # the sleep led is not on
>
> I bisected this and got:
>
> 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit
> commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> Author: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> Date:   Sun May 17 11:40:42 2009 +0200
>    
>     mac80211: cancel/restart all timers across suspend/resume
>
>
> Best regards,
>     Jan Scholz
>
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
>
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.29 and 2.6.30.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
>> Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
>> Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
>> Date		: 2009-05-18 10:59 (50 days old)
>>

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

On Thursday 09 July 2009, Jan Scholz wrote:
> Hi,
> 
> I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> 
> For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> with the test procedure described below, but it works fine when I revert
> commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
>  "mac80211: cancel/restart all timers across suspend/resume"

Thanks for the update.

Johannes, do you have any idea what can go wrong here?

Rafael

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
> On Thursday 09 July 2009, Jan Scholz wrote:
> > Hi,
> > 
> > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> > 
> > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> > with the test procedure described below, but it works fine when I revert
> > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> >  "mac80211: cancel/restart all timers across suspend/resume"
> 
> Thanks for the update.
> 
> Johannes, do you have any idea what can go wrong here?

Not really, no. __ieee80211_suspend isn't holding any locks that the
cancel_work_sync() calls could require or so afaict...

Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
will correct me if I'm wrong) that should work on your platform, and put
a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
see where in there it's hanging?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

On Thursday 09 July 2009, Johannes Berg wrote:
> On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
> > On Thursday 09 July 2009, Jan Scholz wrote:
> > > Hi,
> > > 
> > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> > > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> > > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> > > 
> > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> > > with the test procedure described below, but it works fine when I revert
> > > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> > >  "mac80211: cancel/restart all timers across suspend/resume"
> > 
> > Thanks for the update.
> > 
> > Johannes, do you have any idea what can go wrong here?
> 
> Not really, no. __ieee80211_suspend isn't holding any locks that the
> cancel_work_sync() calls could require or so afaict...
> 
> Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> will correct me if I'm wrong)

That's just 'no_console_suspend'.

Best,
Rafael

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:
> On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
>> On Thursday 09 July 2009, Jan Scholz wrote:
>> > Hi,
>> > 
>> > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
>> > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
>> > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
>> > 
>> > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
>> > with the test procedure described below, but it works fine when I revert
>> > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
>> >  "mac80211: cancel/restart all timers across suspend/resume"
>> 
>> Thanks for the update.
>> 
>> Johannes, do you have any idea what can go wrong here?
>
> Not really, no. __ieee80211_suspend isn't holding any locks that the
> cancel_work_sync() calls could require or so afaict...
>
> Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> will correct me if I'm wrong) that should work on your platform, and put
> a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> see where in there it's hanging?

Did that, seems like it hangs in
  drv_remove_interface(local, &conf);

Jan

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:

> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> > will correct me if I'm wrong) that should work on your platform, and put
> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> > see where in there it's hanging?
> 
> Did that, seems like it hangs in
>   drv_remove_interface(local, &conf);

Ok, thanks! I was going to suggest doing the same in
b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
the problem is just that we have an ordering problem and call drv_stop
before drv_remove_interface. I'll try to come up with a fix soon --
might not be able to today though, in the meantime I guess you can just
move the drv_stop call to the end of the function and tell me if that
works -- that would be racy but should be ok most of the time.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:

> On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:
>
>> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
>> > will correct me if I'm wrong) that should work on your platform, and put
>> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
>> > see where in there it's hanging?
>> 
>> Did that, seems like it hangs in
>>   drv_remove_interface(local, &conf);
>
> Ok, thanks! I was going to suggest doing the same in
> b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
> the problem is just that we have an ordering problem and call drv_stop
> before drv_remove_interface. I'll try to come up with a fix soon --
> might not be able to today though, in the meantime I guess you can just
> move the drv_stop call to the end of the function and tell me if that
> works -- that would be racy but should be ok most of the time.

I moved drv_stop to the end of the function (see patch below) and now
suspend works fine.

Jan

diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index 7a549f9..0ac15fb 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
 	/* flush again, in case driver queued work */
 	flush_workqueue(local->hw.workqueue);
 
-	/* stop hardware - this must stop RX */
-	if (local->open_count) {
-		ieee80211_led_radio(local, false);
-		drv_stop(local);
-	}
-
 	/* remove STAs */
 	spin_lock_irqsave(&local->sta_lock, flags);
 	list_for_each_entry(sta, &local->sta_list, list) {
@@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
 		drv_remove_interface(local, &conf);
 	}
 
+	/* stop hardware - this must stop RX */
+	if (local->open_count) {
+		ieee80211_led_radio(local, false);
+		drv_stop(local);
+	}
+
 	local->suspended = true;
 	local->quiescing = false;

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

On Sat, 2009-07-11 at 19:20 +0200, Jan Scholz wrote:
> Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:
> 
> > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:
> >
> >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> >> > will correct me if I'm wrong) that should work on your platform, and put
> >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> >> > see where in there it's hanging?
> >> 
> >> Did that, seems like it hangs in
> >>   drv_remove_interface(local, &conf);
> >
> > Ok, thanks! I was going to suggest doing the same in
> > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
> > the problem is just that we have an ordering problem and call drv_stop
> > before drv_remove_interface. I'll try to come up with a fix soon --
> > might not be able to today though, in the meantime I guess you can just
> > move the drv_stop call to the end of the function and tell me if that
> > works -- that would be racy but should be ok most of the time.
> 
> I moved drv_stop to the end of the function (see patch below) and now
> suspend works fine.

Thanks, that's what I suspected -- I'll take a closer look into what is
required to make it race-free against RX.

johannes

> Jan
> 
> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
> index 7a549f9..0ac15fb 100644
> --- a/net/mac80211/pm.c
> +++ b/net/mac80211/pm.c
> @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>  	/* flush again, in case driver queued work */
>  	flush_workqueue(local->hw.workqueue);
>  
> -	/* stop hardware - this must stop RX */
> -	if (local->open_count) {
> -		ieee80211_led_radio(local, false);
> -		drv_stop(local);
> -	}
> -
>  	/* remove STAs */
>  	spin_lock_irqsave(&local->sta_lock, flags);
>  	list_for_each_entry(sta, &local->sta_list, list) {
> @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>  		drv_remove_interface(local, &conf);
>  	}
>  
> +	/* stop hardware - this must stop RX */
> +	if (local->open_count) {
> +		ieee80211_led_radio(local, false);
> +		drv_stop(local);
> +	}
> +
>  	local->suspended = true;
>  	local->quiescing = false;
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13648] nfsd: page allocation failure

[David Rientjes]

On Tue, 7 Jul 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
> Subject		: nfsd: page allocation failure
> Submitter	: Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
> Date		: 2009-06-22 12:08 (15 days old)
> References	: http://lkml.org/lkml/2009/6/22/309
> 

Stephan von Krawczynski has this problem with e1000e (but not e1000 or 
tg3) at least as far back as 2.6.28, so this doesn't appear to be a 
regression introduced in 2.6.30.

Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window

[Andrew Morton]

On Tue,  7 Jul 2009 02:00:46 +0200 (CEST)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13554
> Subject		: linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
> Submitter	: Jos van Wolput <wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org>
> Date		: 2009-06-17 06:28 (20 days old)

Nico reported a black-screen regression too.  Subject:

	2.6.31-r2: Xorg: Black screen


  Compared to the other normal brightness problems, with 2.6.31-r2
  xorg starts, but there is no image displayed (neither on internal nor
  external monitor).

  Switching back to console does not change the status, though
  hitting ctrlaltdel reboots the system (i.e.  still up and running
  fine).

  It works with 2.6.30-rc7 (besides sometimes the brightness is
  broken there).


This looks like it might be a post-2.6.30 regression, in which case it
might have a separate cause.


We're having a lot of problems in this area.

2.6.31-rc4: Reported regressions 2.6.29 -> 2.6.30

[Rafael J. Wysocki]

This message contains a list of some regressions introduced between 2.6.29 and
2.6.30, for which there are no fixes in the mainline I know of.  If any of them
have been fixed already, please let me know.

If you know of any other unresolved regressions introduced between 2.6.29
and 2.6.30, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-07-27      143       48          45
  2009-07-07      138       50          46
  2009-06-29      133       46          43
  2009-06-07      110       35          31
  2009-05-31      100       32          27
  2009-05-24       92       34          27
  2009-05-16       81       36          33
  2009-04-25       55       36          26
  2009-04-17       37       35          28


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13797
Subject		: iBook G4 doesn't suspend since 2ed8d2b3a8
Submitter	: Jörg Sommer <joerg@alea.gnuu.de>
Date		: 2009-07-18 20:18 (9 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13795
Subject		: abnormal boot and no suspend due to 'async' (fastboot)
Submitter	: Rafal Kaczynski <fscnoboot@wp.pl>
Date		: 2009-07-18 17:19 (9 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13780
Subject		: NULL pointer dereference loading powernowk8
Submitter	: Kurt Roeckx <kurt@roeckx.be>
Date		: 2009-07-15 18:00 (12 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13751
Subject		: oops on HP/Compaq 6910p lid closure
Submitter	: Bjorn Helgaas <bjorn.helgaas@hp.com>
Date		: 2009-07-09 15:17 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13739
Subject		: 2.6.30 leaking keys on console switch
Submitter	: Andi Kleen <andi@firstfloor.org>
Date		: 2009-07-07 8:44 (20 days old)
References	: http://marc.info/?l=linux-kernel&m=124695628924382&w=4
Handled-By	: Jiri Kosina <jkosina@suse.cz>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13694
Subject		: i915 phantom TV
Submitter	: Maciek Józiewicz <mjoziew@gmail.com>
Date		: 2009-07-02 12:26 (25 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13682
Subject		: The webcam stopped working when upgrading from 2.6.29 to 2.6.30
Submitter	: Nathanael Schaeffer <nathanael.schaeffer@gmail.com>
Date		: 2009-06-30 13:34 (27 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13681
Subject		: A number of usb Devices causes Oops messages and kernel panics.
Submitter	: Alexander Kaltsas <alexkaltsas@gmail.com>
Date		: 2009-06-30 13:06 (27 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13669
Subject		: Kernel bug with dock driver
Submitter	: Joerg Platte <jplatte@naasa.net>
Date		: 2009-06-14 21:00 (43 days old)
References	: http://lkml.org/lkml/2009/6/14/216
Handled-By	: Henrique de Moraes Holschuh <hmh@hmh.eng.br>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13660
Subject		: Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
Submitter	: Joao Correia <joaomiguelcorreia@gmail.com>
Date		: 2009-06-27 16:07 (30 days old)
References	: http://lkml.org/lkml/2009/6/27/95


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
Subject		: nfsd: page allocation failure
Submitter	: Justin Piszcz <jpiszcz@lucidpixels.com>
Date		: 2009-06-22 12:08 (35 days old)
References	: http://lkml.org/lkml/2009/6/22/309
		  http://marc.info/?l=linux-kernel&m=124748600712853&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13646
Subject		: warn_on tty_io.c, broken bluetooth
Submitter	: Pavel Machek <pavel@ucw.cz>
Date		: 2009-06-19 17:05 (38 days old)
References	: http://lkml.org/lkml/2009/6/19/187


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13644
Subject		: hibernation/swsusp lockup due to acpi-cpufreq
Submitter	: Johannes Stezenbach <js@sig21.net>
Date		: 2009-06-16 01:27 (41 days old)
References	: http://lkml.org/lkml/2009/6/15/630
		  http://lkml.org/lkml/2009/6/29/504
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13638
Subject		: rt2870 driver is broken for (some) cards
Submitter	: jakob gruber <jakob.gruber@kabelnet.at>
Date		: 2009-06-27 17:33 (30 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13634
Subject		: [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date		: 2009-06-27 07:02 (30 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
Subject		: usb: wrong autosuspend initialization
Submitter	:  <list@phuk.ath.cx>
Date		: 2009-06-25 18:18 (32 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13621
Subject		: xfs hangs with assertion failed
Submitter	: Johannes Engel <jcnengel@googlemail.com>
Date		: 2009-06-25 10:07 (32 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13620
Subject		: acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date		: 2009-06-25 08:31 (32 days old)
References	: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13583
Subject		: pdflush uses 5% CPU on otherwise idle system
Submitter	: Paul Martin <pm@debian.org>
Date		: 2009-06-19 13:33 (38 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13581
Subject		: ath9k doesn't work with newer kernels
Submitter	: Matteo <rootkit85@yahoo.it>
Date		: 2009-06-19 12:04 (38 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13564
Subject		: random general protection fault at boot time caused by khubd.
Submitter	: Pauli <suokkos@gmail.com>
Date		: 2009-06-18 12:44 (39 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13558
Subject		: Tracelog during resume
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date		: 2009-06-17 11:32 (40 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13554
Subject		: linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
Submitter	: Jos van Wolput <wolput@onsneteindhoven.nl>
Date		: 2009-06-17 06:28 (40 days old)
References	: http://marc.info/?l=linux-kernel&m=124686965407853&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13518
Subject		: slab grows with NFS write activity.
Submitter	: Andrew Randrianasulu <randrik@mail.ru>
Date		: 2009-06-12 09:51 (45 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13514
Subject		: acer_wmi causes stack corruption
Submitter	: Rus <harbour@sfinx.od.ua>
Date		: 2009-06-12 08:13 (45 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13512
Subject		: D43 on 2.6.30 doesn't suspend anymore
Submitter	: Daniel Smolik <marvin@mydatex.cz>
Date		: 2009-06-11 20:12 (46 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13502
Subject		: GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
Submitter	:  <sveina@gmail.com>
Date		: 2009-06-10 20:04 (47 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13472
Subject		: Oops with minicom and USB serial
Submitter	: Peter Chubb <peterc@gelato.unsw.edu.au>
Date		: 2009-06-05 1:37 (52 days old)
References	: http://marc.info/?l=linux-kernel&m=124416901026700&w=4
Handled-By	: Alan Stern <stern@rowland.harvard.edu>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13471
Subject		: Loading parport_pc kills the keyboard if ACPI is enabled
Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
Date		: 2009-06-04 9:12 (53 days old)
References	: http://marc.info/?l=linux-kernel&m=124410667532558&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13424
Subject		: possible deadlock when doing governor switching
Submitter	: Shaohua Li <shaohua.li@intel.com>
Date		: 2009-05-31 16:36 (57 days old)
References	: http://www.spinics.net/lists/cpufreq/msg00711.html
		  http://lkml.org/lkml/2009/6/28/405
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13408
Subject		: Performance regression in 2.6.30-rc7
Submitter	: Diego Calleja <diegocg@gmail.com>
Date		: 2009-05-30 18:51 (58 days old)
References	: http://lkml.org/lkml/2009/5/30/146


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13407
Subject		: adb trackpad disappears after suspend to ram
Submitter	: Jan Scholz <scholz@fias.uni-frankfurt.de>
Date		: 2009-05-28 7:59 (60 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
References	: http://marc.info/?l=linux-kernel&m=124349762314976&w=4
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13401
Subject		: pktcdvd writing is really slow with CFQ scheduler (bisected)
Submitter	: Laurent Riffard <laurent.riffard@free.fr>
Date		: 2009-05-28 18:43 (60 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject		: reiserfs blocked for more than 120secs
Submitter	: Harald Dunkel <harald.dunkel@t-online.de>
Date		: 2009-05-23 8:52 (65 days old)
References	: http://marc.info/?l=linux-kernel&m=124306880410811&w=4
		  http://lkml.org/lkml/2009/5/29/389


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject		: fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2009-05-23 5:08 (65 days old)
References	: http://marc.info/?l=linux-kernel&m=124305538130702&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13362
Subject		: rt2x00: slow wifi with correct basic rate bitmap
Submitter	: Alejandro Riveira <ariveira@gmail.com>
Date		: 2009-05-22 13:32 (66 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject		: 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
Submitter	:  <unggnu@googlemail.com>
Date		: 2009-05-20 14:09 (68 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742
Handled-By	: Yinghai Lu <yinghai@kernel.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject		: Random Oops at boot at loading ip6tables rules
Submitter	:  <patrick@ostenberg.de>
Date		: 2009-05-19 09:08 (69 days old)
Handled-By	: Rusty Russell <rusty@rustcorp.com.au>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (70 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject		: b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter	: Francis Moreau <francis.moro@gmail.com>
Date		: 2009-05-03 16:22 (85 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject		: Page allocation failures with b43 and p54usb
Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
Date		: 2009-04-29 21:01 (89 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
Handled-By	: Johannes Berg <johannes@sipsolutions.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject		: AGP doesn't work anymore on nforce2
Submitter	: Karsten Mehrhoff <kawime@gmx.de>
Date		: 2009-04-30 8:51 (88 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By	: Shaohua Li <shaohua.li@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject		: hibernate slow on _second_ run
Submitter	: Johannes Berg <johannes@sipsolutions.net>
Date		: 2009-05-14 09:34 (74 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject		: Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4
Submitter	: David Hill <hilld@binarystorm.net>
Date		: 2009-05-01 16:57 (87 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject		: High latency on /sys/class/thermal
Submitter	: Tiago Simões Batista <tiagosbatista@gmail.com>
Date		: 2009-04-11 14:56 (107 days old)
References	: http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By	: Zhang Rui <rui.zhang@intel.com>
		  Alexey Starikovskiy <astarikovskiy@suse.de>


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13649
Subject		: Bad page state in process with various applications
Submitter	: Maxim Levitsky <maximlevitsky@gmail.com>
Date		: 2009-06-20 15:27 (37 days old)
References	: http://marc.info/?l=linux-mm&m=124551168828090&w=4
Handled-By	: Mel Gorman <mel@csn.ul.ie>
Patch		: http://patchwork.kernel.org/patch/33130/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13475
Subject		: suspend/hibernate lockdep warning
Submitter	: Dave Young <hidave.darkstar@gmail.com>
Date		: 2009-06-02 10:00 (55 days old)
References	: http://marc.info/?l=linux-kernel&m=124393723321241&w=4
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Patch		: http://patchwork.kernel.org/patch/28660/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
Subject		: Warning 'Invalid throttling state, reset' gets displayed when it should not be
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2009-05-26 15:24 (62 days old)
Handled-By	: Frans Pop <elendil@planet.nl>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
		  http://bugzilla.kernel.org/attachment.cgi?id=21672


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.29 and 2.6.30, unresolved as well as resolved, at:

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

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael


------------------------------------------------------------------------------
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug #13109] High latency on /sys/class/thermal

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject		: High latency on /sys/class/thermal
Submitter	: Tiago Simões Batista <tiagosbatista-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-11 14:56 (107 days old)
References	: http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By	: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
		  Alexey Starikovskiy <astarikovskiy-l3A5Bk7waGM@public.gmane.org>

[Bug #13306] hibernate slow on _second_ run

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject		: hibernate slow on _second_ run
Submitter	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date		: 2009-05-14 09:34 (74 days old)

[Bug #13318] AGP doesn't work anymore on nforce2

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject		: AGP doesn't work anymore on nforce2
Submitter	: Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org>
Date		: 2009-04-30 8:51 (88 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By	: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

[Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject		: Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4
Submitter	: David Hill <hilld@binarystorm.net>
Date		: 2009-05-01 16:57 (87 days old)

[Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject		: b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter	: Francis Moreau <francis.moro@gmail.com>
Date		: 2009-05-03 16:22 (85 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
Date		: 2009-05-18 10:59 (70 days old)

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger@lwfinger.net>
Date		: 2009-04-29 21:01 (89 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
Handled-By	: Johannes Berg <johannes@sipsolutions.net>

[Bug #13341] Random Oops at boot at loading ip6tables rules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject		: Random Oops at boot at loading ip6tables rules
Submitter	:  <patrick-nxAOmsU53hB6lmGzAMPh1A@public.gmane.org>
Date		: 2009-05-19 09:08 (69 days old)
Handled-By	: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>

[Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject		: 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
Submitter	:  <unggnu-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date		: 2009-05-20 14:09 (68 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742
Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

[Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
Subject		: Warning 'Invalid throttling state, reset' gets displayed when it should not be
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-05-26 15:24 (62 days old)
Handled-By	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
		  http://bugzilla.kernel.org/attachment.cgi?id=21672

[Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13401
Subject		: pktcdvd writing is really slow with CFQ scheduler (bisected)
Submitter	: Laurent Riffard <laurent.riffard-GANU6spQydw@public.gmane.org>
Date		: 2009-05-28 18:43 (60 days old)

[Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject		: fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-23 5:08 (65 days old)
References	: http://marc.info/?l=linux-kernel&m=124305538130702&w=4

[Bug #13374] reiserfs blocked for more than 120secs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject		: reiserfs blocked for more than 120secs
Submitter	: Harald Dunkel <harald.dunkel@t-online.de>
Date		: 2009-05-23 8:52 (65 days old)
References	: http://marc.info/?l=linux-kernel&m=124306880410811&w=4
		  http://lkml.org/lkml/2009/5/29/389

[Bug #13362] rt2x00: slow wifi with correct basic rate bitmap

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13362
Subject		: rt2x00: slow wifi with correct basic rate bitmap
Submitter	: Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-22 13:32 (66 days old)

[Bug #13407] adb trackpad disappears after suspend to ram

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13407
Subject		: adb trackpad disappears after suspend to ram
Submitter	: Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
Date		: 2009-05-28 7:59 (60 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
References	: http://marc.info/?l=linux-kernel&m=124349762314976&w=4
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>

[Bug #13424] possible deadlock when doing governor switching

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13424
Subject		: possible deadlock when doing governor switching
Submitter	: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-31 16:36 (57 days old)
References	: http://www.spinics.net/lists/cpufreq/msg00711.html
		  http://lkml.org/lkml/2009/6/28/405
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>

[Bug #13408] Performance regression in 2.6.30-rc7

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13408
Subject		: Performance regression in 2.6.30-rc7
Submitter	: Diego Calleja <diegocg@gmail.com>
Date		: 2009-05-30 18:51 (58 days old)
References	: http://lkml.org/lkml/2009/5/30/146

[Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13471
Subject		: Loading parport_pc kills the keyboard if ACPI is enabled
Submitter	: Ozan Çağlayan <ozan-caicS1wCkhO6A22drWdTBw@public.gmane.org>
Date		: 2009-06-04 9:12 (53 days old)
References	: http://marc.info/?l=linux-kernel&m=124410667532558&w=4

[Bug #13475] suspend/hibernate lockdep warning

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13475
Subject		: suspend/hibernate lockdep warning
Submitter	: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-02 10:00 (55 days old)
References	: http://marc.info/?l=linux-kernel&m=124393723321241&w=4
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/28660/

[Bug #13514] acer_wmi causes stack corruption

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13514
Subject		: acer_wmi causes stack corruption
Submitter	: Rus <harbour-K87ZgELTUEPsG83rWm+8vg@public.gmane.org>
Date		: 2009-06-12 08:13 (45 days old)

[Bug #13518] slab grows with NFS write activity.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13518
Subject		: slab grows with NFS write activity.
Submitter	: Andrew Randrianasulu <randrik-JGs/UdohzUI@public.gmane.org>
Date		: 2009-06-12 09:51 (45 days old)

[Bug #13472] Oops with minicom and USB serial

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13472
Subject		: Oops with minicom and USB serial
Submitter	: Peter Chubb <peterc@gelato.unsw.edu.au>
Date		: 2009-06-05 1:37 (52 days old)
References	: http://marc.info/?l=linux-kernel&m=124416901026700&w=4
Handled-By	: Alan Stern <stern@rowland.harvard.edu>

[Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13554
Subject		: linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
Submitter	: Jos van Wolput <wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org>
Date		: 2009-06-17 06:28 (40 days old)
References	: http://marc.info/?l=linux-kernel&m=124686965407853&w=4

[Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13502
Subject		: GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
Submitter	:  <sveina-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-10 20:04 (47 days old)

[Bug #13512] D43 on 2.6.30 doesn't suspend anymore

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13512
Subject		: D43 on 2.6.30 doesn't suspend anymore
Submitter	: Daniel Smolik <marvin-0pWKB23IDFjrBKCeMvbIDA@public.gmane.org>
Date		: 2009-06-11 20:12 (46 days old)

[Bug #13564] random general protection fault at boot time caused by khubd.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13564
Subject		: random general protection fault at boot time caused by khubd.
Submitter	: Pauli <suokkos@gmail.com>
Date		: 2009-06-18 12:44 (39 days old)

[Bug #13558] Tracelog during resume

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13558
Subject		: Tracelog during resume
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org>
Date		: 2009-06-17 11:32 (40 days old)

[Bug #13581] ath9k doesn't work with newer kernels

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13581
Subject		: ath9k doesn't work with newer kernels
Submitter	: Matteo <rootkit85@yahoo.it>
Date		: 2009-06-19 12:04 (38 days old)

[Bug #13583] pdflush uses 5% CPU on otherwise idle system

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13583
Subject		: pdflush uses 5% CPU on otherwise idle system
Submitter	: Paul Martin <pm@debian.org>
Date		: 2009-06-19 13:33 (38 days old)

[Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13620
Subject		: acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date		: 2009-06-25 08:31 (32 days old)
References	: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>

[Bug #13621] xfs hangs with assertion failed

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13621
Subject		: xfs hangs with assertion failed
Submitter	: Johannes Engel <jcnengel@googlemail.com>
Date		: 2009-06-25 10:07 (32 days old)

[Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13634
Subject		: [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org>
Date		: 2009-06-27 07:02 (30 days old)

[Bug #13638] rt2870 driver is broken for (some) cards

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13638
Subject		: rt2870 driver is broken for (some) cards
Submitter	: jakob gruber <jakob.gruber@kabelnet.at>
Date		: 2009-06-27 17:33 (30 days old)

[Bug #13624] usb: wrong autosuspend initialization

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
Subject		: usb: wrong autosuspend initialization
Submitter	:  <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org>
Date		: 2009-06-25 18:18 (32 days old)

[Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13644
Subject		: hibernation/swsusp lockup due to acpi-cpufreq
Submitter	: Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
Date		: 2009-06-16 01:27 (41 days old)
References	: http://lkml.org/lkml/2009/6/15/630
		  http://lkml.org/lkml/2009/6/29/504
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>

[Bug #13646] warn_on tty_io.c, broken bluetooth

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13646
Subject		: warn_on tty_io.c, broken bluetooth
Submitter	: Pavel Machek <pavel@ucw.cz>
Date		: 2009-06-19 17:05 (38 days old)
References	: http://lkml.org/lkml/2009/6/19/187

[Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13660
Subject		: Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
Submitter	: Joao Correia <joaomiguelcorreia@gmail.com>
Date		: 2009-06-27 16:07 (30 days old)
References	: http://lkml.org/lkml/2009/6/27/95

[Bug #13649] Bad page state in process with various applications

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13649
Subject		: Bad page state in process with various applications
Submitter	: Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-20 15:27 (37 days old)
References	: http://marc.info/?l=linux-mm&m=124551168828090&w=4
Handled-By	: Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/33130/

[Bug #13648] nfsd: page allocation failure

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
Subject		: nfsd: page allocation failure
Submitter	: Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
Date		: 2009-06-22 12:08 (35 days old)
References	: http://lkml.org/lkml/2009/6/22/309
		  http://marc.info/?l=linux-kernel&m=124748600712853&w=4

[Bug #13669] Kernel bug with dock driver

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13669
Subject		: Kernel bug with dock driver
Submitter	: Joerg Platte <jplatte@naasa.net>
Date		: 2009-06-14 21:00 (43 days old)
References	: http://lkml.org/lkml/2009/6/14/216
Handled-By	: Henrique de Moraes Holschuh <hmh@hmh.eng.br>

[Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13682
Subject		: The webcam stopped working when upgrading from 2.6.29 to 2.6.30
Submitter	: Nathanael Schaeffer <nathanael.schaeffer@gmail.com>
Date		: 2009-06-30 13:34 (27 days old)

[Bug #13681] A number of usb Devices causes Oops messages and kernel panics.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13681
Subject		: A number of usb Devices causes Oops messages and kernel panics.
Submitter	: Alexander Kaltsas <alexkaltsas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-30 13:06 (27 days old)

[Bug #13694] i915 phantom TV

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13694
Subject		: i915 phantom TV
Submitter	: Maciek Józiewicz <mjoziew@gmail.com>
Date		: 2009-07-02 12:26 (25 days old)

[Bug #13751] oops on HP/Compaq 6910p lid closure

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13751
Subject		: oops on HP/Compaq 6910p lid closure
Submitter	: Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
Date		: 2009-07-09 15:17 (18 days old)

[Bug #13780] NULL pointer dereference loading powernowk8

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13780
Subject		: NULL pointer dereference loading powernowk8
Submitter	: Kurt Roeckx <kurt@roeckx.be>
Date		: 2009-07-15 18:00 (12 days old)

[Bug #13795] abnormal boot and no suspend due to 'async' (fastboot)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13795
Subject		: abnormal boot and no suspend due to 'async' (fastboot)
Submitter	: Rafal Kaczynski <fscnoboot@wp.pl>
Date		: 2009-07-18 17:19 (9 days old)

[Bug #13739] 2.6.30 leaking keys on console switch

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13739
Subject		: 2.6.30 leaking keys on console switch
Submitter	: Andi Kleen <andi@firstfloor.org>
Date		: 2009-07-07 8:44 (20 days old)
References	: http://marc.info/?l=linux-kernel&m=124695628924382&w=4
Handled-By	: Jiri Kosina <jkosina@suse.cz>

[Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13797
Subject		: iBook G4 doesn't suspend since 2ed8d2b3a8
Submitter	: Jörg Sommer <joerg@alea.gnuu.de>
Date		: 2009-07-18 20:18 (9 days old)

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Larry Finger]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date		: 2009-04-29 21:01 (89 days old)
> References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> 		  http://lkml.org/lkml/2009/6/7/136
> Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60
entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg
<penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org> and dated Wed Jun 10 18:50:32 2009 +0300.

The fault occurred because when CONFIG_SLUB_DEBUG was set, many of the
memory allocations for wireless buffers were increased from O(0) to
O(1) causing memory fragmentation, and eventually there were no
remaining O(1) fragments. This problem is unlikely to affect most
users as none of the distos turn on the above debug option.

This bug should be marked "closed with patch".

Larry

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Sun, 26 Jul 2009, Larry Finger wrote:

> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> > Date		: 2009-04-29 21:01 (89 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> > 		  http://lkml.org/lkml/2009/6/7/136
> > Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> 
> This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60
> entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg
> <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org> and dated Wed Jun 10 18:50:32 2009 +0300.
> 

Hmm, I'm remembering differently.  I thought the root problem here has 
only been fixed in Pekka's slab-2.6.git tree with "slub: add option to 
disable higher order debugging slabs" and isn't currently in Linus' tree.

> The fault occurred because when CONFIG_SLUB_DEBUG was set, many of the
> memory allocations for wireless buffers were increased from O(0) to
> O(1) causing memory fragmentation, and eventually there were no
> remaining O(1) fragments. This problem is unlikely to affect most
> users as none of the distos turn on the above debug option.
> 

It only happens when CONFIG_SLUB_DEBUG_ON is enabled for caches with 
sizes that increase as the result of the added metadata.

Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be

[Frans Pop]

On Sunday 26 July 2009, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
> Subject	: Warning 'Invalid throttling state, reset' gets displayed
>		  when it should not be
> Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
> 		  http://bugzilla.kernel.org/attachment.cgi?id=21672

Rui has acked the patches [1], but AFAIK Len has not yet picked them up.

[1] http://lkml.org/lkml/2009/7/7/474

Re: [Bug #13475] suspend/hibernate lockdep warning

[Dave Young]

On Mon, Jul 27, 2009 at 4:45 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).

It has been fixed, at least I did not see it in recent rc4 kernel.

>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13475
> Subject         : suspend/hibernate lockdep warning
> Submitter       : Dave Young <hidave.darkstar-Re5JQEeQqe8@public.gmane.orgm>
> Date            : 2009-06-02 10:00 (55 days old)
> References      : http://marc.info/?l=linux-kernel&m=124393723321241&w=4
> Handled-By      : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch           : http://patchwork.kernel.org/patch/28660/
>
>
>



-- 
Regards
dave

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

On Mon, Jul 27, 2009 at 3:24 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> On Sun, 26 Jul 2009, Larry Finger wrote:
>
>> Rafael J. Wysocki wrote:
>> > This message has been generated automatically as a part of a report
>> > of regressions introduced between 2.6.29 and 2.6.30.
>> >
>> > The following bug entry is on the current list of known regressions
>> > introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>> > Date                : 2009-04-29 21:01 (89 days old)
>> > References  : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>> >               http://lkml.org/lkml/2009/6/7/136
>> > Handled-By  : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>>
>> This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60
>> entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg
>> <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org> and dated Wed Jun 10 18:50:32 2009 +0300.
>>
>
> Hmm, I'm remembering differently.  I thought the root problem here has
> only been fixed in Pekka's slab-2.6.git tree with "slub: add option to
> disable higher order debugging slabs" and isn't currently in Linus' tree.

Yup, the fix is in slab.git and queued for 2.6.32. There was some
complaints from Christoph from the patch that need to be addressed
still.

                                        Pekka

Re: [Bug #13306] hibernate slow on _second_ run

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

On Sun, 2009-07-26 at 22:45 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).

The problem persists in 31-rc3.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13649] Bad page state in process with various applications

[Johannes Weiner]

On Sun, Jul 26, 2009 at 10:45:33PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13649
> Subject		: Bad page state in process with various applications
> Submitter	: Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-06-20 15:27 (37 days old)
> References	: http://marc.info/?l=linux-mm&m=124551168828090&w=4
> Handled-By	: Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/33130/

Fixed in mainline: c277331d5fbaae5772ed19862feefa91f4e477d3

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1169 bytes --]

On Mon, 27 Jul 2009, Pekka Enberg wrote:

> > Hmm, I'm remembering differently.  I thought the root problem here has
> > only been fixed in Pekka's slab-2.6.git tree with "slub: add option to
> > disable higher order debugging slabs" and isn't currently in Linus' tree.
> 
> Yup, the fix is in slab.git and queued for 2.6.32. There was some
> complaints from Christoph from the patch that need to be addressed
> still.
> 

From what I recall, he asked that calculate_sizes() be called twice, first 
to determine if get_order(s->size) increased as the result of the metadata 
and, if so, a second time with the flags disabled.

slab_debug=O only disables debugging options that increase the min order 
of slab as defined in DEBUG_FLAGS; it doesn't selectively disable some of 
them when get_order(s->size) grows.  So it's quite sane, like my patch 
does, to disable all DEBUG_FLAGS when

	get_order(s->objsize) + DEBUG_SIZE_FLAGS > get_order(s->objsize)

without calling calculate_sizes() twice.

We need DEBUG_FLAGS to determine which flags to mask off to reduce the 
minimum order, so I don't see DEBUG_FLAGS_SIZE as troublesome.

Christoph?

Re: [Bug #13648] nfsd: page allocation failure

[Stephan von Krawczynski]

On Sun, 26 Jul 2009 22:45:33 +0200 (CEST)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
> Subject		: nfsd: page allocation failure
> Submitter	: Justin Piszcz <jpiszcz@lucidpixels.com>
> Date		: 2009-06-22 12:08 (35 days old)
> References	: http://lkml.org/lkml/2009/6/22/309
> 		  http://marc.info/?l=linux-kernel&m=124748600712853&w=4
> 

This is no regression between 2.6.29 and 2.6.30.
In fact we could reproduce the problem with kernel versions:

2.6.27.26 < X <= 2.6.30.3

(Meaning 2.6.27.26 is the last one _not_ showing the problem).

-- 
Regards,
Stephan

Re: [Bug #13472] Oops with minicom and USB serial

[Alan Stern]

On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13472
> Subject		: Oops with minicom and USB serial
> Submitter	: Peter Chubb <peterc-M3ycANVxPotyL3EAZA59ERCuuivNXqWP@public.gmane.org>
> Date		: 2009-06-05 1:37 (52 days old)
> References	: http://marc.info/?l=linux-kernel&m=124416901026700&w=4
> Handled-By	: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>

This bug has been fixed in 2.6.30.stable by commit
b6cd9d132aa5e2ef0abdd1d5171e45dad9aafc29.

Alan Stern

Re: [Bug #13624] usb: wrong autosuspend initialization

[Alan Stern]

On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
> Subject		: usb: wrong autosuspend initialization
> Submitter	:  <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org>
> Date		: 2009-06-25 18:18 (32 days old)

There's some question as to whether this should be considered a kernel 
bug.  The kernel isn't doing anything wrong; the problem is that 
various userspace programs enable autosuspend for devices that can't 
support it properly.

Alan Stern

Re: [Bug #13624] usb: wrong autosuspend initialization

[list-2tUql6aCh3Vfq8cQ1yknNg]

Alan Stern wrote:
> On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:
> 
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.29 and 2.6.30.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
>> Subject		: usb: wrong autosuspend initialization
>> Submitter	:  <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org>
>> Date		: 2009-06-25 18:18 (32 days old)
> 
> There's some question as to whether this should be considered a kernel 
> bug.  The kernel isn't doing anything wrong; the problem is that 
> various userspace programs enable autosuspend for devices that can't 
> support it properly.
> 
> Alan Stern
> 

I'm currently working on a patch for laptop_mode. The maintainer tells 
me there's work going on in the kernel to blacklist USB devices that 
don't implement autosuspend correctly (like mice turning their light 
off, etc...). Is that true?

Re: [Bug #13624] usb: wrong autosuspend initialization

[Alan Stern]

On Mon, 27 Jul 2009 list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org wrote:

> Alan Stern wrote:
> > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:
> > 
> >> This message has been generated automatically as a part of a report
> >> of regressions introduced between 2.6.29 and 2.6.30.
> >>
> >> The following bug entry is on the current list of known regressions
> >> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> >> be listed and let me know (either way).
> >>
> >>
> >> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
> >> Subject		: usb: wrong autosuspend initialization
> >> Submitter	:  <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org>
> >> Date		: 2009-06-25 18:18 (32 days old)
> > 
> > There's some question as to whether this should be considered a kernel 
> > bug.  The kernel isn't doing anything wrong; the problem is that 
> > various userspace programs enable autosuspend for devices that can't 
> > support it properly.
> > 
> > Alan Stern
> > 
> 
> I'm currently working on a patch for laptop_mode. The maintainer tells 
> me there's work going on in the kernel to blacklist USB devices that 
> don't implement autosuspend correctly (like mice turning their light 
> off, etc...). Is that true?

No, it isn't.  The kernel has no way to tell whether mice behave that
way or not.

The only suspend-related blacklisting in the kernel is concerned with
broken devices that can't be resumed after they have been suspended.  
The kernel has to reset these devices instead of resuming them.

Alan Stern

Re: [Bug #13424] possible deadlock when doing governor switching

[Mathieu Desnoyers]

It should be fixed now by recents commits to the cpufreq tree, which got
into mainline:

42a06f2166f2f6f7bf04f32b4e823eacdceafdc9
b253d2b2d28ead6fed012feb54694b3d0562839a
b14893a62c73af0eca414cfed505b8c09efc613c
7d26e2d5e2da37e92c6c7644b26b294dedd8c982
37c90e8887efd218dc4af949b7f498ca2da4af9f
5a75c82828e7c088ca6e7b4827911dc29cc8e774
ee88415caf736b89500f16e0a545614541a45005
3f4a782b5ce2698b1870b5a7b573cd721d4fce33
5e1596f75395e7a402e1059c518e633d2732dcf8

Mathieu


* Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13424
> Subject		: possible deadlock when doing governor switching
> Submitter	: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date		: 2009-05-31 16:36 (57 days old)
> References	: http://www.spinics.net/lists/cpufreq/msg00711.html
> 		  http://lkml.org/lkml/2009/6/28/405
> Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> 
> 
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [Bug #13475] suspend/hibernate lockdep warning

[Mathieu Desnoyers]

It should be fixed now by recents commits to the cpufreq tree, which got  
into mainline: 

42a06f2166f2f6f7bf04f32b4e823eacdceafdc9
b253d2b2d28ead6fed012feb54694b3d0562839a
b14893a62c73af0eca414cfed505b8c09efc613c
7d26e2d5e2da37e92c6c7644b26b294dedd8c982
37c90e8887efd218dc4af949b7f498ca2da4af9f
5a75c82828e7c088ca6e7b4827911dc29cc8e774
ee88415caf736b89500f16e0a545614541a45005
3f4a782b5ce2698b1870b5a7b573cd721d4fce33
5e1596f75395e7a402e1059c518e633d2732dcf8

Mathieu


* Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13475
> Subject		: suspend/hibernate lockdep warning
> Submitter	: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-06-02 10:00 (55 days old)
> References	: http://marc.info/?l=linux-kernel&m=124393723321241&w=4
> Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/28660/
> 
> 
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Mon, 27 Jul 2009, David Rientjes wrote:

> We need DEBUG_FLAGS to determine which flags to mask off to reduce the
> minimum order, so I don't see DEBUG_FLAGS_SIZE as troublesome.
>
> Christoph?

Post a patch? Otherwise just go ahead.

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Mon, 27 Jul 2009, Christoph Lameter wrote:

> On Mon, 27 Jul 2009, David Rientjes wrote:
> 
> > We need DEBUG_FLAGS to determine which flags to mask off to reduce the
> > minimum order, so I don't see DEBUG_FLAGS_SIZE as troublesome.
> >
> > Christoph?
> 
> Post a patch? Otherwise just go ahead.
> 
> 

My patch is already in Pekka's slab-2.6.git tree at 
http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commit;h=fa5ec8a1f66f3c2a3af723abcf8085509c9ee682

You had proposed http://marc.info/?l=linux-kernel&m=124725166205814, which 
moves the mask to kmem_cache_open() and calls calculate_sizes() twice.  
That eliminates DEBUG_FLAGS_SIZE, but I don't see that define as being 
troublesome since we must define DEBUG_FLAGS to specify what options add 
metdata anyway.

Re: [Bug 13306] hibernate slow on _second_ run

[Rafael J. Wysocki]

On Monday 27 July 2009, Johannes Berg wrote:
> On Sun, 2009-07-26 at 22:45 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> 
> The problem persists in 31-rc3.

Thanks for the update.

Unfortunately, I have no idea about what's wrong here.

Generally, there are three possible areas the problem may be related to:
(1) interrupts,
(2) CPU hotplug,
(3) ordering of the platform callbacks,

but I can't say much more than that.

Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be

[Rafael J. Wysocki]

On Monday 27 July 2009, Frans Pop wrote:
> On Sunday 26 July 2009, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13389
> > Subject	: Warning 'Invalid throttling state, reset' gets displayed
> >		  when it should not be
> > Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21671
> > 		  http://bugzilla.kernel.org/attachment.cgi?id=21672
> 
> Rui has acked the patches [1], but AFAIK Len has not yet picked them up.
> 
> [1] http://lkml.org/lkml/2009/7/7/474

No, Len hasn't picked them up, but he's not been responsive recently in
general.

Best,
Rafael

Re: [Bug #13424] possible deadlock when doing governor switching

[Rafael J. Wysocki]

On Monday 27 July 2009, Mathieu Desnoyers wrote:
> It should be fixed now by recents commits to the cpufreq tree, which got
> into mainline:
> 
> 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9
> b253d2b2d28ead6fed012feb54694b3d0562839a
> b14893a62c73af0eca414cfed505b8c09efc613c
> 7d26e2d5e2da37e92c6c7644b26b294dedd8c982
> 37c90e8887efd218dc4af949b7f498ca2da4af9f
> 5a75c82828e7c088ca6e7b4827911dc29cc8e774
> ee88415caf736b89500f16e0a545614541a45005
> 3f4a782b5ce2698b1870b5a7b573cd721d4fce33
> 5e1596f75395e7a402e1059c518e633d2732dcf8

Thanks, closed.

Rafael

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Christoph Lameter]

On Mon, 27 Jul 2009, David Rientjes wrote:

> My patch is already in Pekka's slab-2.6.git tree at
> http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commit;h=fa5ec8a1f66f3c2a3af723abcf8085509c9ee682
>
> You had proposed http://marc.info/?l=linux-kernel&m=124725166205814, which
> moves the mask to kmem_cache_open() and calls calculate_sizes() twice.
> That eliminates DEBUG_FLAGS_SIZE, but I don't see that define as being
> troublesome since we must define DEBUG_FLAGS to specify what options add
> metdata anyway.

My prosal was to use the size and objsize parameters. You would only have
to call calculate_sizes() twice when the comparison of the order of size
and objsize would be different.

Doing so would simplify additing future flags. If you do your own
calculations (like in the patch) then you have to replicate the size
calculation from calculate_sizes() somehow. Is the duplicate calculation
really accurate regarding alignment and other special casing?

Re: [Bug #13472] Oops with minicom and USB serial

[Rafael J. Wysocki]

On Monday 27 July 2009, Alan Stern wrote:
> On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13472
> > Subject		: Oops with minicom and USB serial
> > Submitter	: Peter Chubb <peterc@gelato.unsw.edu.au>
> > Date		: 2009-06-05 1:37 (52 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124416901026700&w=4
> > Handled-By	: Alan Stern <stern@rowland.harvard.edu>
> 
> This bug has been fixed in 2.6.30.stable by commit
> b6cd9d132aa5e2ef0abdd1d5171e45dad9aafc29.

Thanks, closed.

Rafael

Re: [Bug #13475] suspend/hibernate lockdep warning

[Rafael J. Wysocki]

On Monday 27 July 2009, Mathieu Desnoyers wrote:
> It should be fixed now by recents commits to the cpufreq tree, which got  
> into mainline: 
> 
> 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9
> b253d2b2d28ead6fed012feb54694b3d0562839a
> b14893a62c73af0eca414cfed505b8c09efc613c
> 7d26e2d5e2da37e92c6c7644b26b294dedd8c982
> 37c90e8887efd218dc4af949b7f498ca2da4af9f
> 5a75c82828e7c088ca6e7b4827911dc29cc8e774
> ee88415caf736b89500f16e0a545614541a45005
> 3f4a782b5ce2698b1870b5a7b573cd721d4fce33
> 5e1596f75395e7a402e1059c518e633d2732dcf8

Thanks, closed.

Rafael

Re: [Bug #13624] usb: wrong autosuspend initialization

[Rafael J. Wysocki]

On Monday 27 July 2009, Alan Stern wrote:
> On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
> > Subject		: usb: wrong autosuspend initialization
> > Submitter	:  <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org>
> > Date		: 2009-06-25 18:18 (32 days old)
> 
> There's some question as to whether this should be considered a kernel 
> bug.  The kernel isn't doing anything wrong; the problem is that 
> various userspace programs enable autosuspend for devices that can't 
> support it properly.

OK, I'll drop it from the list of recent regressions.

Thanks,
Rafael

Re: [Bug #13648] nfsd: page allocation failure

[Rafael J. Wysocki]

On Monday 27 July 2009, Stephan von Krawczynski wrote:
> On Sun, 26 Jul 2009 22:45:33 +0200 (CEST)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13648
> > Subject		: nfsd: page allocation failure
> > Submitter	: Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
> > Date		: 2009-06-22 12:08 (35 days old)
> > References	: http://lkml.org/lkml/2009/6/22/309
> > 		  http://marc.info/?l=linux-kernel&m=124748600712853&w=4
> > 
> 
> This is no regression between 2.6.29 and 2.6.30.
> In fact we could reproduce the problem with kernel versions:
> 
> 2.6.27.26 < X <= 2.6.30.3
> 
> (Meaning 2.6.27.26 is the last one _not_ showing the problem).

Thanks, moved to the list of regressions from 2.6.27.

Best,
Rafael

Re: [Bug #13649] Bad page state in process with various applications

[Rafael J. Wysocki]

On Monday 27 July 2009, Johannes Weiner wrote:
> On Sun, Jul 26, 2009 at 10:45:33PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13649
> > Subject		: Bad page state in process with various applications
> > Submitter	: Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-06-20 15:27 (37 days old)
> > References	: http://marc.info/?l=linux-mm&m=124551168828090&w=4
> > Handled-By	: Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
> > Patch		: http://patchwork.kernel.org/patch/33130/
> 
> Fixed in mainline: c277331d5fbaae5772ed19862feefa91f4e477d3

Thanks, closed.

Rafael

Re: [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8

[Jörg Sommer]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Hi Rafael,

Rafael J. Wysocki hat am Sun 26. Jul, 22:45 (+0200) geschrieben:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).

Yes, the bug still exists. I can't put my iBook asleep using 2.6.30-rc4.

Regards, Jörg.
-- 
Da würde ich auch lieber den Panzerführerschein machen als den MCSE.
Bringt mehr, dürfte das gleiche kosten und macht sicher mehr Spaß.
                                   Jens Dittmar in de.comp.security

[-- Attachment #2: Digital signature http://en.wikipedia.org/wiki/OpenPGP --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[David Rientjes]

On Mon, 27 Jul 2009, Christoph Lameter wrote:

> My prosal was to use the size and objsize parameters. You would only have
> to call calculate_sizes() twice when the comparison of the order of size
> and objsize would be different.
> 
> Doing so would simplify additing future flags. If you do your own
> calculations (like in the patch) then you have to replicate the size
> calculation from calculate_sizes() somehow. Is the duplicate calculation
> really accurate regarding alignment and other special casing?
> 

Ok, fair enough.  It seems like a matter of taste in implementation but 
your proposal is also more extendable than mine, and I'm definitely not 
going to argue your taste vs. mine when it comes to slub :)

I'll write an incremental patch on top of Pekka's for-next branch to 
implement your idea.

[patch] slub: use size and objsize orders to disable debug flags

[David Rientjes]

This patch moves the masking of debugging flags which increase a cache's
min order due to metadata when `slub_debug=O' is used from
kmem_cache_flags() to kmem_cache_open().

Instead of defining the maximum metadata size increase in a preprocessor
macro, this approach uses the cache's ->size and ->objsize members to
determine if the min order increased due to debugging options.  If so,
the flags specified in the more appropriately named DEBUG_METADATA_FLAGS
are masked off.

This approach was suggested by Christoph Lameter
<cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>.

Cc: Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
 mm/slub.c |   40 +++++++++++++++++++---------------------
 1 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -142,11 +142,11 @@
 				SLAB_POISON | SLAB_STORE_USER)
 
 /*
- * Debugging flags that require metadata to be stored in the slab, up to
- * DEBUG_SIZE in size.
+ * Debugging flags that require metadata to be stored in the slab.  These get
+ * disabled when slub_debug=O is used and a cache's min order increases with
+ * metadata.
  */
-#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
-#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
+#define DEBUG_METADATA_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
 
 /*
  * Set of flags that will prevent slab merging
@@ -1040,27 +1040,13 @@ static unsigned long kmem_cache_flags(unsigned long objsize,
 	unsigned long flags, const char *name,
 	void (*ctor)(void *))
 {
-	int debug_flags = slub_debug;
-
 	/*
 	 * Enable debugging if selected on the kernel commandline.
 	 */
-	if (debug_flags) {
-		if (slub_debug_slabs &&
-		    strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs)))
-			goto out;
-
-		/*
-		 * Disable debugging that increases slab size if the minimum
-		 * slab order would have increased as a result.
-		 */
-		if (disable_higher_order_debug &&
-		    get_order(objsize + DEBUG_SIZE) > get_order(objsize))
-			debug_flags &= ~DEBUG_SIZE_FLAGS;
+	if (slub_debug && (!slub_debug_slabs ||
+		!strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs))))
+		flags |= slub_debug;
 
-		flags |= debug_flags;
-	}
-out:
 	return flags;
 }
 #else
@@ -2488,6 +2474,18 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
 
 	if (!calculate_sizes(s, -1))
 		goto error;
+	if (disable_higher_order_debug) {
+		/*
+		 * Disable debugging flags that store metadata if the min slab
+		 * order increased.
+		 */
+		if (get_order(s->size) > get_order(s->objsize)) {
+			s->flags &= ~DEBUG_METADATA_FLAGS;
+			s->offset = 0;
+			if (!calculate_sizes(s, -1))
+				goto error;
+		}
+	}
 
 	/*
 	 * The larger the object size is, the more pages we want on the partial

Re: [patch] slub: use size and objsize orders to disable debug flags

[Pekka Enberg]

David Rientjes wrote:
> This patch moves the masking of debugging flags which increase a cache's
> min order due to metadata when `slub_debug=O' is used from
> kmem_cache_flags() to kmem_cache_open().
> 
> Instead of defining the maximum metadata size increase in a preprocessor
> macro, this approach uses the cache's ->size and ->objsize members to
> determine if the min order increased due to debugging options.  If so,
> the flags specified in the more appropriately named DEBUG_METADATA_FLAGS
> are masked off.
> 
> This approach was suggested by Christoph Lameter
> <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>.
> 
> Cc: Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> Signed-off-by: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

Applied, thanks!

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Sat, 2009-07-11 at 19:20 +0200, Jan Scholz wrote:
>> Johannes Berg <johannes@sipsolutions.net> writes:
>> 
>> > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:
>> >
>> >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
>> >> > will correct me if I'm wrong) that should work on your platform, and put
>> >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
>> >> > see where in there it's hanging?
>> >> 
>> >> Did that, seems like it hangs in
>> >>   drv_remove_interface(local, &conf);
>> >
>> > Ok, thanks! I was going to suggest doing the same in
>> > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
>> > the problem is just that we have an ordering problem and call drv_stop
>> > before drv_remove_interface. I'll try to come up with a fix soon --
>> > might not be able to today though, in the meantime I guess you can just
>> > move the drv_stop call to the end of the function and tell me if that
>> > works -- that would be racy but should be ok most of the time.
>> 
>> I moved drv_stop to the end of the function (see patch below) and now
>> suspend works fine.
>
> Thanks, that's what I suspected -- I'll take a closer look into what is
> required to make it race-free against RX.
>

Hi,

The bug is still present in v2.6.31-rc4, it's still fixed by the patch
(see below) suggested as a test by Johannes.

Regards,
   Jan

>> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
>> index 7a549f9..0ac15fb 100644
>> --- a/net/mac80211/pm.c
>> +++ b/net/mac80211/pm.c
>> @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>>  	/* flush again, in case driver queued work */
>>  	flush_workqueue(local->hw.workqueue);
>>  
>> -	/* stop hardware - this must stop RX */
>> -	if (local->open_count) {
>> -		ieee80211_led_radio(local, false);
>> -		drv_stop(local);
>> -	}
>> -
>>  	/* remove STAs */
>>  	spin_lock_irqsave(&local->sta_lock, flags);
>>  	list_for_each_entry(sta, &local->sta_list, list) {
>> @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>>  		drv_remove_interface(local, &conf);
>>  	}
>>  
>> +	/* stop hardware - this must stop RX */
>> +	if (local->open_count) {
>> +		ieee80211_led_radio(local, false);
>> +		drv_stop(local);
>> +	}
>> +
>>  	local->suspended = true;
>>  	local->quiescing = false;
>> 

-- 
 Jan Scholz                                ____  ____    __    ___ 
                                          ( ___)(_  _)  /__\  / __)
 Frankfurt Institute for Advanced Studies  )__)  _)(_  /(__)\ \__ \
                                          (__)  (____)(__)(__)(___/
 Goethe Universitaet Frankfurt
 Ruth-Moufang-Str. 1                             Tel. 069-798-47534
 60438 Frankfurt am Main

Re: [Bug #13407] adb trackpad disappears after suspend to ram

[Jan Scholz]

Hi,

The bug is still present in v2.6.31-rc4, it is fixed by commenting out
{suspend,resume}_device_irqs() in drivers/base/power/main.c as suggested
by Rafael. Any success in reproducing it?

Regards,
   Jan

"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13407
> Subject		: adb trackpad disappears after suspend to ram
> Submitter	: Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
> Date		: 2009-05-28 7:59 (60 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
> References	: http://marc.info/?l=linux-kernel&m=124349762314976&w=4
> Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
>
>
>

-- 
 Jan Scholz                                ____  ____    __    ___ 
                                          ( ___)(_  _)  /__\  / __)
 Frankfurt Institute for Advanced Studies  )__)  _)(_  /(__)\ \__ \
                                          (__)  (____)(__)(__)(___/
 Goethe Universitaet Frankfurt
 Ruth-Moufang-Str. 1                             Tel. 069-798-47534
 60438 Frankfurt am Main

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On Tue, 2009-07-28 at 16:40 +0200, Jan Scholz wrote:

> The bug is still present in v2.6.31-rc4, it's still fixed by the patch
> (see below) suggested as a test by Johannes.

Sorry, this completely dropped off my radar, I'll take a look today.
Thanks for reminding me.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

On Tuesday 28 July 2009, Johannes Berg wrote:
> On Tue, 2009-07-28 at 16:40 +0200, Jan Scholz wrote:
> 
> > The bug is still present in v2.6.31-rc4, it's still fixed by the patch
> > (see below) suggested as a test by Johannes.
> 
> Sorry, this completely dropped off my radar, I'll take a look today.
> Thanks for reminding me.

Thanks for the patch Johannes!

Best,
Rafael

Re: [Bug #13681] A number of usb Devices causes Oops messages and kernel panics.

[Greg KH]

On Sun, Jul 26, 2009 at 10:45:34PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13681
> Subject		: A number of usb Devices causes Oops messages and kernel panics.
> Submitter	: Alexander Kaltsas <alexkaltsas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-06-30 13:06 (27 days old)

This can no longer be reproduced by the original reporter, so it should
be closed.

thanks,

greg k-h

Re: [Bug #13681] A number of usb Devices causes Oops messages and kernel panics.

[Rafael J. Wysocki]

On Wednesday 29 July 2009, Greg KH wrote:
> On Sun, Jul 26, 2009 at 10:45:34PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13681
> > Subject		: A number of usb Devices causes Oops messages and kernel panics.
> > Submitter	: Alexander Kaltsas <alexkaltsas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-06-30 13:06 (27 days old)
> 
> This can no longer be reproduced by the original reporter, so it should
> be closed.

Done.

Best,
Rafael

Re: [Bug #13648] nfsd: page allocation failure

[David Rientjes]

On Mon, 27 Jul 2009, Stephan von Krawczynski wrote:

> This is no regression between 2.6.29 and 2.6.30.
> In fact we could reproduce the problem with kernel versions:
> 
> 2.6.27.26 < X <= 2.6.30.3
> 
> (Meaning 2.6.27.26 is the last one _not_ showing the problem).
> 

And 2.6.28.10 is showing the exact same problem as initially reported, 
right?

I noticed your /var/log/messages is showing you're using slub as opposed 
to slab (which Justin was using, and causing order-0 allocations errors).  
SLUB uses order-1 allocations for this cache growth and it's failing 
because of memory fragmentation, not because you're truly oom.

The only thing that is immediately apparent that changed in this path over 
these kernel versions (there were significant changes to e1000e) is the 
CRC stripping.  If it's loaded as a module, perhaps you could try

	modprobe e1000e CrcStripping=0,0

(assuming you have two adapters).

I've cc'd some relevant e1000e driver people in the hopes they'll be able 
to diagnose this problem.  Memory fragmentation as the result of page 
group changes wouldn't affect order-0 allocations such as this on slab, so 
it's doubtful the VM regressed if you can reproduce the problem with 
CONFIG_SLAB.

Re: [Bug #13780] NULL pointer dereference loading powernowk8

[David Rientjes]

On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13780
> Subject		: NULL pointer dereference loading powernowk8
> Submitter	: Kurt Roeckx <kurt-burXGKnpAKGzQB+pC5nmwQ@public.gmane.org>
> Date		: 2009-07-15 18:00 (12 days old)
> 

powernowk8_cpu_init() has since been largely modified for cpumask changes 
commit 1ff6e97f1d993dff2f9b6f4a9173687370660232.  

Kurt, could you try 2.6.31-rc4?  If it still hits a bug, please post the 
dmesg and your .config.

Re: [Bug #13648] nfsd: page allocation failure

[Stephan von Krawczynski]

On Thu, 30 Jul 2009 14:30:42 -0700 (PDT)
David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:

> On Mon, 27 Jul 2009, Stephan von Krawczynski wrote:
> 
> > This is no regression between 2.6.29 and 2.6.30.
> > In fact we could reproduce the problem with kernel versions:
> > 
> > 2.6.27.26 < X <= 2.6.30.3
> > 
> > (Meaning 2.6.27.26 is the last one _not_ showing the problem).
> > 
> 
> And 2.6.28.10 is showing the exact same problem as initially reported, 
> right?

Yes, that is correct.
 
> I noticed your /var/log/messages is showing you're using slub as opposed 
> to slab (which Justin was using, and causing order-0 allocations errors).  
> SLUB uses order-1 allocations for this cache growth and it's failing 
> because of memory fragmentation, not because you're truly oom.

Originally I used slab, and as someone wanted me to test slub I tried. The
results looked pretty much the same to me.
 
> The only thing that is immediately apparent that changed in this path over 
> these kernel versions (there were significant changes to e1000e) is the 
> CRC stripping.  If it's loaded as a module, perhaps you could try
> 
> 	modprobe e1000e CrcStripping=0,0
> 
> (assuming you have two adapters).

I will try that.
 
> I've cc'd some relevant e1000e driver people in the hopes they'll be able 
> to diagnose this problem.  Memory fragmentation as the result of page 
> group changes wouldn't affect order-0 allocations such as this on slab, so 
> it's doubtful the VM regressed if you can reproduce the problem with 
> CONFIG_SLAB.

I can, as said before, the problem first showed up with slab.


-- 
Regards,
Stephan

Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled

[Alan Cox]

On Sun, 26 Jul 2009 22:45:29 +0200 (CEST)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).


Ozan - can you confirm it broke between 2.6.29 (ie you tested 2.6.29),
and 2.6.30-rc1. If so I have an idea what is going on

Alan

Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled

[Ozan Çağlayan]

Alan Cox wrote:
> On Sun, 26 Jul 2009 22:45:29 +0200 (CEST)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
>   
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.29 and 2.6.30.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
>> be listed and let me know (either way).
>>     
>
>
> Ozan - can you confirm it broke between 2.6.29 (ie you tested 2.6.29),
> and 2.6.30-rc1. If so I have an idea what is going on
>   

From my last comment on bugzilla.kernel.org:

"I tried with 2.6.30.1 but the problem still persists. I really don't have time
to bisect it, but I can help with any other debugging outputs. I also started
think that my board could somehow be faulty as no other people complains about
a similar issue.

Finally, it seems that the problem is available with 2.6.28, so the starting
point is still fuzzy to me. I remember that the keyboard was working OK with
2.6.29_rc7 but now it's not.

Maybe we should drop this report from the regression list."


Monday I'll have access to the computer. I'll build and try to find the last working version.
Meanwhile, I'd like to hear about your possible finding.

Thanks,

Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled

[Alan Cox]

O> Finally, it seems that the problem is available with 2.6.28, so the starting
> point is still fuzzy to me. I remember that the keyboard was working OK with
> 2.6.29_rc7 but now it's not.
> 
> Maybe we should drop this report from the regression list."
> 
> 
> Monday I'll have access to the computer. I'll build and try to find the last working version.
> Meanwhile, I'd like to hear about your possible finding.

There have been few changes to parport_pc but one thing recent changed
the probe for SuperIO chips via low addresses and that could be
interfering.

commit e2434dc1c19412639dd047a4d4eff8ed0e5d0d50
Author: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Date:   Mon Jun 22 16:51:49 2009 +0100

changed the behaviour slightly (hence asking about which release if it
was a recent breakage). Its also a code area with very few changes so if
you can find which one worked last, you should be able to transplant that
parport_pc into 2.6.current and see if its parport or acpi triggered
breakage.

Alan

Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap

[Alejandro Riveira Fernández]

El Sun, 26 Jul 2009 22:45:27 +0200 (CEST)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> escribió:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).

 Sorry for the delay i did not have the time to test 2.6.31-rc* until now.
Tried 2.6.31-rc5 the problem persist. The revert still fixes the issue; so
the bug should be still present.

> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13362
> Subject		: rt2x00: slow wifi with correct basic rate bitmap
> Submitter	: Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-05-22 13:32 (66 days old)
> 
> 

Thanks;
Alejandro

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (96 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
		  http://lkml.org/lkml/2009/7/26/213
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
		  David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/37655/

Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap

[Rafael J. Wysocki]

On Sunday 02 August 2009, Alejandro Riveira Fernández wrote:
> El Sun, 26 Jul 2009 22:45:27 +0200 (CEST)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> escribió:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> 
>  Sorry for the delay i did not have the time to test 2.6.31-rc* until now.
> Tried 2.6.31-rc5 the problem persist. The revert still fixes the issue; so
> the bug should be still present.
> 
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13362
> > Subject		: rt2x00: slow wifi with correct basic rate bitmap
> > Submitter	: Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-05-22 13:32 (66 days old)

Thanks for the update.

Rafael

Re: [patch] slub: use size and objsize orders to disable debug flags

[Christoph Lameter]

Acked-by: Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>

On Mon, 27 Jul 2009, David Rientjes wrote:
> @@ -2488,6 +2474,18 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags,
>
>  	if (!calculate_sizes(s, -1))
>  		goto error;
> +	if (disable_higher_order_debug) {
> +		/*
> +		 * Disable debugging flags that store metadata if the min slab
> +		 * order increased.
> +		 */
> +		if (get_order(s->size) > get_order(s->objsize)) {
> +			s->flags &= ~DEBUG_METADATA_FLAGS;

> +			s->offset = 0;

Hmmm... Move this line into calculate_sizes()?

Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled

[Ozan Çağlayan]

Alan Cox wrote On 31-07-2009 18:17:
> There have been few changes to parport_pc but one thing recent changed
> the probe for SuperIO chips via low addresses and that could be
> interfering.
>
> commit e2434dc1c19412639dd047a4d4eff8ed0e5d0d50
> Author: Jens Rottmann <JRottmann-pZAVvlj+WpoXz/+GnIZSFIQuADTiUCJX@public.gmane.org>
> Date:   Mon Jun 22 16:51:49 2009 +0100
>
> changed the behaviour slightly (hence asking about which release if it
> was a recent breakage). Its also a code area with very few changes so if
> you can find which one worked last, you should be able to transplant that
> parport_pc into 2.6.current and see if its parport or acpi triggered
> breakage.
>   

I've tested on 2.6.30.4 which has apparently this commit, no changes.

I've booted into Ubuntu 8.10 which has 2.6.28. The keyboard was working
correctly eventhough parport_pc was loaded. I removed and re-probed and
the keyboard is gone.

I've set BIOS settings to default, nope.

I'll try bisecting when I find the last-good/first-bad kernel version.

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger@lwfinger.net>
Date		: 2009-04-29 21:01 (103 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
		  http://lkml.org/lkml/2009/7/26/213
Handled-By	: Johannes Berg <johannes@sipsolutions.net>
		  David Rientjes <rientjes@google.com>
Patch		: http://patchwork.kernel.org/patch/37655/

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (113 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
		  http://lkml.org/lkml/2009/7/26/213
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
		  David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/37655/

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.

The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (119 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
		  http://lkml.org/lkml/2009/6/7/136
		  http://lkml.org/lkml/2009/7/26/213
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
		  David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/37655/

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg]

Hi Rafael,

On Wed, Aug 26, 2009 at 12:05 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date            : 2009-04-29 21:01 (119 days old)
> References      : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
>                  http://lkml.org/lkml/2009/6/7/136
>                  http://lkml.org/lkml/2009/7/26/213
> Handled-By      : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>                  David Rientjes <rientjes-hpIqsD4AKldhl2p70BpVqQ@public.gmane.orgm>
> Patch           : http://patchwork.kernel.org/patch/37655/

FYI, the fix (a new slub debugging option) is queued for 2.6.32 and we
don't have plans to backport it to -stable because it depends on SLUB
out-of-memory diagnostic patches and the problem doesn't affect
production configs.

                                Pekka

Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

On Wednesday 26 August 2009, Pekka Enberg wrote:
> Hi Rafael,
> 
> On Wed, Aug 26, 2009 at 12:05 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  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 <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> > Date            : 2009-04-29 21:01 (119 days old)
> > References      : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> >                  http://lkml.org/lkml/2009/6/7/136
> >                  http://lkml.org/lkml/2009/7/26/213
> > Handled-By      : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> >                  David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > Patch           : http://patchwork.kernel.org/patch/37655/
> 
> FYI, the fix (a new slub debugging option) is queued for 2.6.32 and we
> don't have plans to backport it to -stable because it depends on SLUB
> out-of-memory diagnostic patches and the problem doesn't affect
> production configs.

Thanks for the info, I've closed the bug as "will fix later".

Rafael