2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30

[Rafael J. Wysocki]

On Monday 29 June 2009, Jos van Wolput 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=13554
> > Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
> > Submitter : Jos van Wolput <wolput@...>
> > Date : 2009-06-17 06:28 (12 days old)
> >
> >
> >
> >  
> Yes, it still should be listed, KMS doesn't work, at least on my system.

Thanks for the update, but I'm afraid we won't have enough information to
debug this issue.

Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[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@...>
> > 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@...>
>
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[David Rientjes]

On Mon, 29 Jun 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@...>
> Date : 2009-06-22 12:08 (7 days old)
> References : http://lkml.org/lkml/2009/6/22/309
>

I'd be interested to hear from Justin if reducing
/proc/sys/vm/dirty_background_ratio as I earlier suggested helps.  

ZONE_NORMAL isn't much larger than ZONE_DMA32 on this machine and both
lowmem zones have an abundance of free memory which suggests pdflush's
ratio isn't being met to commence background writeout while at the same
time ZONE_NORMAL is being depleted as the result of constant nfs
GFP_ATOMIC allocations that cannot try direct reclaim.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Johannes Stezenbach-2]

On Mon, Jun 29, 2009 at 02:31:01AM +0200, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644
> Subject : hibernation/swsusp lockup due to acpi-cpufreq
> Submitter : Johannes Stezenbach <js@...>
> Date : 2009-06-16 01:27 (13 days old)
> References : http://lkml.org/lkml/2009/6/15/630
> Handled-By : Rafael J. Wysocki <rjw@...>

I tested v2.6.31-rc1-228-g2bfdd79 and the bug is still there.
It actually got worse, the local_irq_save/restore workaround
in kernel/up-c (http://lkml.org/lkml/2009/6/16/333) doesn't fix it
anymore, it hangs at suspend before writing out the image.

With the up.c workaround (including a
WARN_ON_ONCE(irqs_disabled() && !oops_in_progress);)
applied and no_console_suspend I captured the attached
output using a crappy webcam.  (Without the workaround
there is a huge spew of warnings about irqs enabled
unexpectedly.)  I guess the interesting part is

  pm_op(): pci_pm_thaw returns -16
  PM: Device 0000:00:00.0 failed to thaw: error -16

(PCI info is in http://lkml.org/lkml/2009/6/15/630)


Johannes

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

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

[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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Pekka Enberg-3]

Hi David,

On Tue, Jun 30, 2009 at 2:47 AM, David Rientjes<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@...>
>> > 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@...>
>>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[David Rientjes]

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.

[Justin Piszcz]

On Mon, 29 Jun 2009, David Rientjes wrote:

> On Mon, 29 Jun 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@...>
>> Date : 2009-06-22 12:08 (7 days old)
>> References : http://lkml.org/lkml/2009/6/22/309
>>
>
> I'd be interested to hear from Justin if reducing
> /proc/sys/vm/dirty_background_ratio as I earlier suggested helps.
>
> ZONE_NORMAL isn't much larger than ZONE_DMA32 on this machine and both
> lowmem zones have an abundance of free memory which suggests pdflush's
> ratio isn't being met to commence background writeout while at the same
> time ZONE_NORMAL is being depleted as the result of constant nfs
> GFP_ATOMIC allocations that cannot try direct reclaim.
>

Hello,

http://patchwork.kernel.org/patch/30960/

"It's funny, though, that the problem that originally started this thread
was quickly diagnosed because of these messages.  As far as I know, my
suggestion to increase /proc/sys/vm/dirty_background_ratio to kick pdflush
earlier has prevented the slab allocation failures and not required
delayed acks for nfsd."

--

The current value is 10, what value do you suggest I try?

$ cat /proc/sys/vm/dirty_background_ratio
10

Justin.

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

[Pekka Enberg-3]

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@...> 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@...> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[David Rientjes]

On Tue, 30 Jun 2009, Justin Piszcz wrote:

> The current value is 10, what value do you suggest I try?
>
> $ cat /proc/sys/vm/dirty_background_ratio
> 10
>

Looking at your initial bug report, it doesn't look like a background
writeout issue:

[415964.022375] Active_anon:154810 active_file:131162 inactive_anon:33447
[415964.022375]  inactive_file:690987 unevictable:0 dirty:112116 writeback:0 unstable:0
[415964.022375]  free:8662 slab:965366 mapped:9316 pagetables:4618 bounce:0
[415964.022375] 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.022375] lowmem_reserve[]: 0 3246 7980 7980
[415964.022375] 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.022375] lowmem_reserve[]: 0 0 4734 4734
[415964.022375] 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.022375] lowmem_reserve[]: 0 0 0 0
...
[415964.022375] 2277376 pages RAM

Ignore the all_unreclaimable information, this is a GFP_ATOMIC allocation
so we can't reclaim.

You have an 8G machine and only 437K is dirty (which is why pdflush hasn't
kicked in yet).  You do have over 3.5G of slab allocated, however.

This appears related to http://bugzilla.kernel.org/show_bug.cgi?id=13518,
but that could be confirmed with slabtop.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Rafael J. Wysocki]

On Tuesday 30 June 2009, Johannes Stezenbach wrote:

> On Mon, Jun 29, 2009 at 02:31:01AM +0200, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644
> > Subject : hibernation/swsusp lockup due to acpi-cpufreq
> > Submitter : Johannes Stezenbach <js@...>
> > Date : 2009-06-16 01:27 (13 days old)
> > References : http://lkml.org/lkml/2009/6/15/630
> > Handled-By : Rafael J. Wysocki <rjw@...>
>
> I tested v2.6.31-rc1-228-g2bfdd79 and the bug is still there.
> It actually got worse, the local_irq_save/restore workaround
> in kernel/up-c (http://lkml.org/lkml/2009/6/16/333) doesn't fix it
> anymore, it hangs at suspend before writing out the image.
>
> With the up.c workaround (including a
> WARN_ON_ONCE(irqs_disabled() && !oops_in_progress);)
> applied and no_console_suspend I captured the attached
> output using a crappy webcam.  (Without the workaround
> there is a huge spew of warnings about irqs enabled
> unexpectedly.)  I guess the interesting part is
>
>   pm_op(): pci_pm_thaw returns -16
>   PM: Device 0000:00:00.0 failed to thaw: error -16

Hmm, it looks like we fail to thaw the host bridge.

> (PCI info is in http://lkml.org/lkml/2009/6/15/630)

Well, thanks for the update.  I'll do my best to fix the cpufreq suspend
before 2.6.31 final.

Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Christoph Lameter-7]

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.

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

[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

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

[Pekka Enberg-3]

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

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

[Christoph Lameter-7]

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.

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

[Alejandro Riveira Fernández-2]

El Mon, 29 Jun 2009 02:30:55 +0200 (CEST)
"Rafael J. Wysocki" <rjw@...> 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).

 There is no 2.6.30.1 to see if it has been fixed and i have not tested
2.6.31-rc1 (too early for me) so i think it should be still listed

>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
> Subject : rt2x00: slow wifi with correct basic rate bitmap
> Submitter : Alejandro Riveira <ariveira@...>
> Date : 2009-05-22 13:32 (38 days old)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[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;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[David Rientjes]

On Tue, 30 Jun 2009, Pekka Enberg wrote:

> On Tue, Jun 30, 2009 at 10:47 AM, David Rientjes<rientjes@...> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Christoph Lameter-7]

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)

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