* 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30
@ 2009-08-02 19:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
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-08-02 145 44 39
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=13898
Subject : Intel 3945ABG - problems on 2.6.30.X
Submitter : dienet <dienet@poczta.fm>
Date : 2009-07-31 15:17 (3 days old)
References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13886
Subject : Suspend to disk no longer works in 2.6.30.2 with an EIDE drive
Submitter : <akwatts@ymail.com>
Date : 2009-08-01 10:12 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13865
Subject : Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
Submitter : cedric <cedric@belbone.be>
Date : 2009-07-29 12:47 (5 days old)
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 (16 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 (16 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 (19 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 (27 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 (32 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 (34 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 (50 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 (37 days old)
References : http://lkml.org/lkml/2009/6/27/95
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 (45 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 (48 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 (37 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 (37 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 (39 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 (39 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 (45 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 (45 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 (46 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 (47 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 (47 days old)
References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4
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 (52 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 (53 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 (54 days old)
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 (65 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 (67 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 (67 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 (72 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 (72 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 (73 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 (75 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 (76 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
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 (92 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
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 (95 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 (81 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.6
Submitter : David Hill <hilld@binarystorm.net>
Date : 2009-05-01 16:57 (94 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-04-21 21:35 (104 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
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 (114 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=13897
Subject : PAT wc & vmap mapping count issue
Submitter : Jerome Glisse <glisse@freedesktop.org>
Date : 2009-07-30 13:11 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3869c4aa18835c8c61b44bd0f3ace36e9d3b5bd0
References : http://marc.info/?l=linux-kernel&m=124895237114605&w=4
Handled-By : Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Patch : http://patchwork.kernel.org/patch/38436/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13884
Subject : x86 CPA incorrect memtype reserving using set_pages_array_xx
Submitter : Thomas Hellstrom <thellstrom@vmware.com>
Date : 2009-07-31 13:39 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9ae2847591c857bed44bc094b908b412bfa1b244
Handled-By : Thomas Hellstrom <thellstrom@vmware.com>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=22552
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 (69 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
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 (77 days old)
Handled-By : Johannes Berg <johannes@sipsolutions.net>
Patch : http://patchwork.kernel.org/patch/37837/
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 (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@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30
@ 2009-08-02 19:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Natalie Protasevich, Linux ACPI, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List
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-08-02 145 44 39
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=13898
Subject : Intel 3945ABG - problems on 2.6.30.X
Submitter : dienet <dienet@poczta.fm>
Date : 2009-07-31 15:17 (3 days old)
References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13886
Subject : Suspend to disk no longer works in 2.6.30.2 with an EIDE drive
Submitter : <akwatts@ymail.com>
Date : 2009-08-01 10:12 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13865
Subject : Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
Submitter : cedric <cedric@belbone.be>
Date : 2009-07-29 12:47 (5 days old)
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 (16 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 (16 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 (19 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 (27 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 (32 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 (34 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 (50 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 (37 days old)
References : http://lkml.org/lkml/2009/6/27/95
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 (45 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 (48 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 (37 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 (37 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 (39 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 (39 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 (45 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 (45 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 (46 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 (47 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 (47 days old)
References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4
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 (52 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 (53 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 (54 days old)
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 (65 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 (67 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 (67 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 (72 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 (72 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 (73 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 (75 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 (76 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
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 (92 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
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 (95 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 (81 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.6
Submitter : David Hill <hilld@binarystorm.net>
Date : 2009-05-01 16:57 (94 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-04-21 21:35 (104 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
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 (114 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=13897
Subject : PAT wc & vmap mapping count issue
Submitter : Jerome Glisse <glisse@freedesktop.org>
Date : 2009-07-30 13:11 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3869c4aa18835c8c61b44bd0f3ace36e9d3b5bd0
References : http://marc.info/?l=linux-kernel&m=124895237114605&w=4
Handled-By : Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Patch : http://patchwork.kernel.org/patch/38436/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13884
Subject : x86 CPA incorrect memtype reserving using set_pages_array_xx
Submitter : Thomas Hellstrom <thellstrom@vmware.com>
Date : 2009-07-31 13:39 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9ae2847591c857bed44bc094b908b412bfa1b244
Handled-By : Thomas Hellstrom <thellstrom@vmware.com>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=22552
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 (69 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
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 (77 days old)
Handled-By : Johannes Berg <johannes@sipsolutions.net>
Patch : http://patchwork.kernel.org/patch/37837/
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 (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@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
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
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13109] High latency on /sys/class/thermal
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alexey Starikovskiy,
Tiago Simões Batista, Zhang Rui
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 (114 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13109] High latency on /sys/class/thermal
@ 2009-08-02 19:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alexey Starikovskiy,
Tiago Simões Batista, Zhang Rui
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 (114 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Niel Lambrechts
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=13180
Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-04-21 21:35 (104 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, David Hill
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.6
Submitter : David Hill <hilld@binarystorm.net>
Date : 2009-05-01 16:57 (94 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13306] hibernate slow on _second_ run
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Johannes Berg
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@sipsolutions.net>
Date : 2009-05-14 09:34 (81 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13318] AGP doesn't work anymore on nforce2
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Jerome Glisse,
Karsten Mehrhoff, Michel Dänzer, Shaohua Li
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 (95 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, David Hill
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.6
Submitter : David Hill <hilld-HTiBYHdybX7UkGsOFmftXw@public.gmane.org>
Date : 2009-05-01 16:57 (94 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Niel Lambrechts
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=13180
Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter : Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-21 21:35 (104 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13306] hibernate slow on _second_ run
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Johannes Berg
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 (81 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13318] AGP doesn't work anymore on nforce2
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Jerome Glisse,
Karsten Mehrhoff, Michel Dänzer, Shaohua Li
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 (95 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger
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 (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@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
2009-08-02 19:06 ` Rafael J. Wysocki
` (7 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Francis Moreau, netdev
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 (92 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13341] Random Oops at boot at loading ip6tables rules
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, patrick, Rusty Russell
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@ostenberg.de>
Date : 2009-05-19 09:08 (76 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Tomas Janousek
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@nomi.cz>
Date : 2009-05-18 10:59 (77 days old)
Handled-By : Johannes Berg <johannes@sipsolutions.net>
Patch : http://patchwork.kernel.org/patch/37837/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger
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/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13341] Random Oops at boot at loading ip6tables rules
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, patrick, Rusty Russell
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@ostenberg.de>
Date : 2009-05-19 09:08 (76 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Tomas Janousek
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 (77 days old)
Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/37837/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Miles Lane
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@gmail.com>
Date : 2009-05-23 5:08 (72 days old)
References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, unggnu, Yinghai Lu
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@googlemail.com>
Date : 2009-05-20 14:09 (75 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13374] reiserfs blocked for more than 120secs
2009-08-02 19:06 ` Rafael J. Wysocki
` (9 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-03 1:01 ` Frédéric Weisbecker
-1 siblings, 1 reply; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Harald Dunkel
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 (72 days old)
References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4
http://lkml.org/lkml/2009/5/29/389
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap
2009-08-02 19:06 ` Rafael J. Wysocki
` (10 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alejandro Riveira, Chris Wright,
Johannes Berg, John W. Linville
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@gmail.com>
Date : 2009-05-22 13:32 (73 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Miles Lane
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 (72 days old)
References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, unggnu, Yinghai Lu
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@googlemail.com>
Date : 2009-05-20 14:09 (75 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be
2009-08-02 19:06 ` Rafael J. Wysocki
` (13 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Frans Pop
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@planet.nl>
Date : 2009-05-26 15:24 (69 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected)
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jens Axboe, Laurent Riffard
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@free.fr>
Date : 2009-05-28 18:43 (67 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jens Axboe, Laurent Riffard
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 (67 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, sveina
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@gmail.com>
Date : 2009-06-10 20:04 (54 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13512] D43 on 2.6.30 doesn't suspend anymore
2009-08-02 19:06 ` Rafael J. Wysocki
` (15 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Daniel Smolik, 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@mydatex.cz>
Date : 2009-06-11 20:12 (53 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13407] adb trackpad disappears after suspend to ram
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Jan Scholz,
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@fias.uni-frankfurt.de>
Date : 2009-05-28 7:59 (67 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13408] Performance regression in 2.6.30-rc7
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Diego Calleja
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 (65 days old)
References : http://lkml.org/lkml/2009/5/30/146
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13408] Performance regression in 2.6.30-rc7
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Diego Calleja
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 (65 days old)
References : http://lkml.org/lkml/2009/5/30/146
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, sveina
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@gmail.com>
Date : 2009-06-10 20:04 (54 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13407] adb trackpad disappears after suspend to ram
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Jan Scholz,
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 (67 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jesse Barnes, Jos van Wolput
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@onsneteindhoven.nl>
Date : 2009-06-17 06:28 (47 days old)
References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13514] acer_wmi causes stack corruption
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Rus
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@sfinx.od.ua>
Date : 2009-06-12 08:13 (52 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13558] Tracelog during resume
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov
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@volny.cz>
Date : 2009-06-17 11:32 (47 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jesse Barnes, Jos van Wolput
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 (47 days old)
References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13514] acer_wmi causes stack corruption
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Rus
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 (52 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13558] Tracelog during resume
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov
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 (47 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13583] pdflush uses 5% CPU on otherwise idle system
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Paul Martin
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 (45 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13564] random general protection fault at boot time caused by khubd.
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pauli
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 (46 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13581] ath9k doesn't work with newer kernels
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Matteo
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 (45 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13564] random general protection fault at boot time caused by khubd.
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pauli
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 (46 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13583] pdflush uses 5% CPU on otherwise idle system
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Paul Martin
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 (45 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13581] ath9k doesn't work with newer kernels
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Matteo
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 (45 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
2009-08-02 19:06 ` Rafael J. Wysocki
` (26 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov
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@volny.cz>
Date : 2009-06-27 07:02 (37 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13621] xfs hangs with assertion failed
2009-08-02 19:06 ` Rafael J. Wysocki
` (28 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Johannes Engel
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 (39 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13638] rt2870 driver is broken for (some) cards
2009-08-02 19:06 ` Rafael J. Wysocki
` (25 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, jakob gruber
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 (37 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
2009-08-02 19:06 ` Rafael J. Wysocki
` (27 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Jenkins, Bob Moore
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 (39 days old)
References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13669] Kernel bug with dock driver
2009-08-02 19:06 ` Rafael J. Wysocki
` (32 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-03 23:55 ` Henrique de Moraes Holschuh
-1 siblings, 1 reply; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Henrique de Moraes Holschuh, Joerg Platte
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 (50 days old)
References : http://lkml.org/lkml/2009/6/14/216
Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
2009-08-02 19:06 ` Rafael J. Wysocki
` (30 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Joao Correia
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 (37 days old)
References : http://lkml.org/lkml/2009/6/27/95
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
2009-08-02 19:06 ` Rafael J. Wysocki
` (31 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-06 14:49 ` Johannes Stezenbach
-1 siblings, 1 reply; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Stezenbach, 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@sig21.net>
Date : 2009-06-16 01:27 (48 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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13646] warn_on tty_io.c, broken bluetooth
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pavel Machek
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 (45 days old)
References : http://lkml.org/lkml/2009/6/19/187
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13646] warn_on tty_io.c, broken bluetooth
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pavel Machek
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 (45 days old)
References : http://lkml.org/lkml/2009/6/19/187
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30
2009-08-02 19:06 ` Rafael J. Wysocki
` (34 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Nathanael Schaeffer
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 (34 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13780] NULL pointer dereference loading powernowk8
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Kurt Roeckx
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 (19 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13694] i915 phantom TV
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciek Józiewicz
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 (32 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13739] 2.6.30 leaking keys on console switch
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andi Kleen, Jiri Kosina
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 (27 days old)
References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4
Handled-By : Jiri Kosina <jkosina@suse.cz>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13780] NULL pointer dereference loading powernowk8
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Kurt Roeckx
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 (19 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13694] i915 phantom TV
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciek Józiewicz
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 (32 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13739] 2.6.30 leaking keys on console switch
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andi Kleen, Jiri Kosina
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-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>
Date : 2009-07-07 8:44 (27 days old)
References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4
Handled-By : Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jörg Sommer, 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 (16 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13795] abnormal boot and no suspend due to 'async' (fastboot)
2009-08-02 19:06 ` Rafael J. Wysocki
` (39 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Arjan van de Ven, Rafal Kaczynski
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 (16 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13865] Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
2009-08-02 19:06 ` Rafael J. Wysocki
` (38 preceding siblings ...)
(?)
@ 2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 22:53 ` Frans Pop
-1 siblings, 1 reply; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, cedric, Frans Pop, Matthew Garrett
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=13865
Subject : Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
Submitter : cedric <cedric@belbone.be>
Date : 2009-07-29 12:47 (5 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13884] x86 CPA incorrect memtype reserving using set_pages_array_xx
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Thomas Hellstrom, venkatesh.pallipadi
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=13884
Subject : x86 CPA incorrect memtype reserving using set_pages_array_xx
Submitter : Thomas Hellstrom <thellstrom@vmware.com>
Date : 2009-07-31 13:39 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9ae2847591c857bed44bc094b908b412bfa1b244
Handled-By : Thomas Hellstrom <thellstrom@vmware.com>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=22552
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jörg Sommer, 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-au2b9oQwubsjnolme5KbmQ@public.gmane.org>
Date : 2009-07-18 20:18 (16 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13884] x86 CPA incorrect memtype reserving using set_pages_array_xx
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Thomas Hellstrom,
venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w
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=13884
Subject : x86 CPA incorrect memtype reserving using set_pages_array_xx
Submitter : Thomas Hellstrom <thellstrom-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
Date : 2009-07-31 13:39 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9ae2847591c857bed44bc094b908b412bfa1b244
Handled-By : Thomas Hellstrom <thellstrom-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=22552
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13886] Suspend to disk no longer works in 2.6.30.2 with an EIDE drive
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, akwatts, Bartlomiej Zolnierkiewicz
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=13886
Subject : Suspend to disk no longer works in 2.6.30.2 with an EIDE drive
Submitter : <akwatts@ymail.com>
Date : 2009-08-01 10:12 (2 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13897] PAT wc & vmap mapping count issue
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Jerome Glisse, Pallipadi,
Venkatesh, Suresh Siddha, venkatesh.pallipadi,
Venkatesh Pallipadi
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=13897
Subject : PAT wc & vmap mapping count issue
Submitter : Jerome Glisse <glisse@freedesktop.org>
Date : 2009-07-30 13:11 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3869c4aa18835c8c61b44bd0f3ace36e9d3b5bd0
References : http://marc.info/?l=linux-kernel&m=124895237114605&w=4
Handled-By : Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Patch : http://patchwork.kernel.org/patch/38436/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13898] Intel 3945ABG - problems on 2.6.30.X
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, dienet
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=13898
Subject : Intel 3945ABG - problems on 2.6.30.X
Submitter : dienet <dienet@poczta.fm>
Date : 2009-07-31 15:17 (3 days old)
References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13897] PAT wc & vmap mapping count issue
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Jerome Glisse, Pallipadi,
Venkatesh, Suresh Siddha,
venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w, Venkatesh Pallipadi
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=13897
Subject : PAT wc & vmap mapping count issue
Submitter : Jerome Glisse <glisse-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org>
Date : 2009-07-30 13:11 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3869c4aa18835c8c61b44bd0f3ace36e9d3b5bd0
References : http://marc.info/?l=linux-kernel&m=124895237114605&w=4
Handled-By : Pallipadi, Venkatesh <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/38436/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13898] Intel 3945ABG - problems on 2.6.30.X
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, dienet
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=13898
Subject : Intel 3945ABG - problems on 2.6.30.X
Submitter : dienet <dienet-IjDXvh/HVVUAvxtiuMwx3w@public.gmane.org>
Date : 2009-07-31 15:17 (3 days old)
References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13886] Suspend to disk no longer works in 2.6.30.2 with an EIDE drive
@ 2009-08-02 19:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, akwatts, Bartlomiej Zolnierkiewicz
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=13886
Subject : Suspend to disk no longer works in 2.6.30.2 with an EIDE drive
Submitter : <akwatts@ymail.com>
Date : 2009-08-01 10:12 (2 days old)
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13865] Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
2009-08-02 19:09 ` [Bug #13865] Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted Rafael J. Wysocki
@ 2009-08-02 22:53 ` Frans Pop
0 siblings, 0 replies; 263+ messages in thread
From: Frans Pop @ 2009-08-02 22:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, cedric, Matthew Garrett
On Sunday 02 August 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=13865
> Subject : Can only resume with HP_WMI selected on compaq nc6000 when
> 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
> Submitter : cedric <cedric@belbone.be>
> Date : 2009-07-29 12:47 (5 days old)
Fix just made it into mainline: daed953721850381673687c59f3a0df553eb6626
Cheers,
FJP
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13865] Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
@ 2009-08-02 22:53 ` Frans Pop
0 siblings, 0 replies; 263+ messages in thread
From: Frans Pop @ 2009-08-02 22:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, cedric, Matthew Garrett
On Sunday 02 August 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=13865
> Subject : Can only resume with HP_WMI selected on compaq nc6000 when
> 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
> Submitter : cedric <cedric-x1Cn44Nr1HaZIoH1IeqzKA@public.gmane.org>
> Date : 2009-07-29 12:47 (5 days old)
Fix just made it into mainline: daed953721850381673687c59f3a0df553eb6626
Cheers,
FJP
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
2009-08-02 19:09 ` [Bug #13374] reiserfs blocked for more than 120secs Rafael J. Wysocki
@ 2009-08-03 1:01 ` Frédéric Weisbecker
0 siblings, 0 replies; 263+ messages in thread
From: Frédéric Weisbecker @ 2009-08-03 1:01 UTC (permalink / raw)
To: Harald Dunkel
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Jeff Mahoney
Harald,
Does it still happen with 2.6.31-rc5 ?
If so, do you have further informations that could help us reproducing it?
Thanks,
Frederic.
2009/8/2 Rafael J. Wysocki <rjw@sisk.pl>:
> 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 (72 days old)
> References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4
> http://lkml.org/lkml/2009/5/29/389
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-03 1:01 ` Frédéric Weisbecker
0 siblings, 0 replies; 263+ messages in thread
From: Frédéric Weisbecker @ 2009-08-03 1:01 UTC (permalink / raw)
To: Harald Dunkel
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Jeff Mahoney
Harald,
Does it still happen with 2.6.31-rc5 ?
If so, do you have further informations that could help us reproducing it?
Thanks,
Frederic.
2009/8/2 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> 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 (72 days old)
> References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4
> http://lkml.org/lkml/2009/5/29/389
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30
2009-08-02 19:06 ` Rafael J. Wysocki
@ 2009-08-03 15:16 ` Luis R. Rodriguez
-1 siblings, 0 replies; 263+ messages in thread
From: Luis R. Rodriguez @ 2009-08-03 15:16 UTC (permalink / raw)
To: Rafael J. Wysocki, rootkit85
Cc: Linux Kernel Mailing List, Andrew Morton, Linus Torvalds,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
Here are the wireless ones:
On Sun, Aug 2, 2009 at 12:06 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898
> Subject : Intel 3945ABG - problems on 2.6.30.X
> Submitter : dienet <dienet@poczta.fm>
> Date : 2009-07-31 15:17 (3 days old)
> References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
> 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 (37 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 (45 days old)
Issue looks more like a the user has rfkill enabled rather than a
driver issue. Waiting on user feedback since 2009-07-27.
> 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 (73 days old)
> 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 (77 days old)
> Handled-By : Johannes Berg <johannes@sipsolutions.net>
> Patch : http://patchwork.kernel.org/patch/37837/
> 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 (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@sipsolutions.net>
> David Rientjes <rientjes@google.com>
> Patch : http://patchwork.kernel.org/patch/37655/
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30
@ 2009-08-03 15:16 ` Luis R. Rodriguez
0 siblings, 0 replies; 263+ messages in thread
From: Luis R. Rodriguez @ 2009-08-03 15:16 UTC (permalink / raw)
To: Rafael J. Wysocki, rootkit85-whZMOeQn8C0
Cc: Linux Kernel Mailing List, Andrew Morton, Linus Torvalds,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
Here are the wireless ones:
On Sun, Aug 2, 2009 at 12:06 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898
> Subject : Intel 3945ABG - problems on 2.6.30.X
> Submitter : dienet <dienet-IjDXvh/HVVUAvxtiuMwx3w@public.gmane.org>
> Date : 2009-07-31 15:17 (3 days old)
> References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
> 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 (37 days old)
> 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 (45 days old)
Issue looks more like a the user has rfkill enabled rather than a
driver issue. Waiting on user feedback since 2009-07-27.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
> Subject : rt2x00: slow wifi with correct basic rate bitmap
> Submitter : Alejandro Riveira <ariveira-Re5JQEeQqe8@public.gmane.orgm>
> Date : 2009-05-22 13:32 (73 days old)
> 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 (77 days old)
> Handled-By : Johannes Berg <johannes@sipsolutions.net>
> Patch : http://patchwork.kernel.org/patch/37837/
> 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 (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@sipsolutions.net>
> David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Patch : http://patchwork.kernel.org/patch/37655/
--
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30
2009-08-02 19:06 ` Rafael J. Wysocki
` (45 preceding siblings ...)
(?)
@ 2009-08-03 15:16 ` Luis R. Rodriguez
-1 siblings, 0 replies; 263+ messages in thread
From: Luis R. Rodriguez @ 2009-08-03 15:16 UTC (permalink / raw)
To: Rafael J. Wysocki, rootkit85
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI,
Andrew Morton, Kernel Testers List, Linus Torvalds,
Linux PM List
Here are the wireless ones:
On Sun, Aug 2, 2009 at 12:06 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898
> Subject : Intel 3945ABG - problems on 2.6.30.X
> Submitter : dienet <dienet@poczta.fm>
> Date : 2009-07-31 15:17 (3 days old)
> References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
> 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 (37 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 (45 days old)
Issue looks more like a the user has rfkill enabled rather than a
driver issue. Waiting on user feedback since 2009-07-27.
> 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 (73 days old)
> 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 (77 days old)
> Handled-By : Johannes Berg <johannes@sipsolutions.net>
> Patch : http://patchwork.kernel.org/patch/37837/
> 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 (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@sipsolutions.net>
> David Rientjes <rientjes@google.com>
> Patch : http://patchwork.kernel.org/patch/37655/
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13865] Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
@ 2009-08-03 15:18 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-03 15:18 UTC (permalink / raw)
To: Frans Pop
Cc: Linux Kernel Mailing List, Kernel Testers List, cedric, Matthew Garrett
On Monday 03 August 2009, Frans Pop wrote:
> On Sunday 02 August 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=13865
> > Subject : Can only resume with HP_WMI selected on compaq nc6000 when
> > 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
> > Submitter : cedric <cedric@belbone.be>
> > Date : 2009-07-29 12:47 (5 days old)
>
> Fix just made it into mainline: daed953721850381673687c59f3a0df553eb6626
Thanks, closed.
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13865] Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
@ 2009-08-03 15:18 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-03 15:18 UTC (permalink / raw)
To: Frans Pop
Cc: Linux Kernel Mailing List, Kernel Testers List, cedric, Matthew Garrett
On Monday 03 August 2009, Frans Pop wrote:
> On Sunday 02 August 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=13865
> > Subject : Can only resume with HP_WMI selected on compaq nc6000 when
> > 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted
> > Submitter : cedric <cedric-x1Cn44Nr1HaZIoH1IeqzKA@public.gmane.org>
> > Date : 2009-07-29 12:47 (5 days old)
>
> Fix just made it into mainline: daed953721850381673687c59f3a0df553eb6626
Thanks, closed.
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-03 17:43 ` Harald Dunkel
0 siblings, 0 replies; 263+ messages in thread
From: Harald Dunkel @ 2009-08-03 17:43 UTC (permalink / raw)
To: Frédéric Weisbecker
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Jeff Mahoney
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
Frédéric Weisbecker wrote:
> Harald,
>
> Does it still happen with 2.6.31-rc5 ?
>
Using 2.6.30.x kernels (x>=0) I haven't seen this problem anymore.
If it is still in, then it seems to be very hard to reproduce.
As suggested I am moving to 2.6.31-rc5. I will mail immediately if
the problem comes back.
Regards
Harri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-03 17:43 ` Harald Dunkel
0 siblings, 0 replies; 263+ messages in thread
From: Harald Dunkel @ 2009-08-03 17:43 UTC (permalink / raw)
To: Frédéric Weisbecker
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Jeff Mahoney
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
Frédéric Weisbecker wrote:
> Harald,
>
> Does it still happen with 2.6.31-rc5 ?
>
Using 2.6.30.x kernels (x>=0) I haven't seen this problem anymore.
If it is still in, then it seems to be very hard to reproduce.
As suggested I am moving to 2.6.31-rc5. I will mail immediately if
the problem comes back.
Regards
Harri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-03 19:13 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-03 19:13 UTC (permalink / raw)
To: Harald Dunkel
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney
On Monday 03 August 2009, Harald Dunkel wrote:
> Frédéric Weisbecker wrote:
> > Harald,
> >
> > Does it still happen with 2.6.31-rc5 ?
> >
>
> Using 2.6.30.x kernels (x>=0) I haven't seen this problem anymore.
> If it is still in, then it seems to be very hard to reproduce.
>
> As suggested I am moving to 2.6.31-rc5. I will mail immediately if
> the problem comes back.
Please let us know either way.
Best,
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-03 19:13 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-03 19:13 UTC (permalink / raw)
To: Harald Dunkel
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney
On Monday 03 August 2009, Harald Dunkel wrote:
> Frédéric Weisbecker wrote:
> > Harald,
> >
> > Does it still happen with 2.6.31-rc5 ?
> >
>
> Using 2.6.30.x kernels (x>=0) I haven't seen this problem anymore.
> If it is still in, then it seems to be very hard to reproduce.
>
> As suggested I am moving to 2.6.31-rc5. I will mail immediately if
> the problem comes back.
Please let us know either way.
Best,
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13669] Kernel bug with dock driver
2009-08-02 19:09 ` [Bug #13669] Kernel bug with dock driver Rafael J. Wysocki
@ 2009-08-03 23:55 ` Henrique de Moraes Holschuh
0 siblings, 0 replies; 263+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-08-03 23:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Joerg Platte
On Sun, 02 Aug 2009, Rafael J. Wysocki wrote:
> 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 (50 days old)
> References : http://lkml.org/lkml/2009/6/14/216
> Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Already fixed in mainline, data in bug report.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13669] Kernel bug with dock driver
@ 2009-08-03 23:55 ` Henrique de Moraes Holschuh
0 siblings, 0 replies; 263+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-08-03 23:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Joerg Platte
On Sun, 02 Aug 2009, Rafael J. Wysocki wrote:
> 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 (50 days old)
> References : http://lkml.org/lkml/2009/6/14/216
> Handled-By : Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Already fixed in mainline, data in bug report.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13669] Kernel bug with dock driver
@ 2009-08-04 16:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-04 16:23 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Linux Kernel Mailing List, Kernel Testers List, Joerg Platte
On Tuesday 04 August 2009, Henrique de Moraes Holschuh wrote:
> On Sun, 02 Aug 2009, Rafael J. Wysocki wrote:
> > 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 (50 days old)
> > References : http://lkml.org/lkml/2009/6/14/216
> > Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>
> Already fixed in mainline, data in bug report.
Thanks, closed.
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13669] Kernel bug with dock driver
@ 2009-08-04 16:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-04 16:23 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Linux Kernel Mailing List, Kernel Testers List, Joerg Platte
On Tuesday 04 August 2009, Henrique de Moraes Holschuh wrote:
> On Sun, 02 Aug 2009, Rafael J. Wysocki wrote:
> > 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 (50 days old)
> > References : http://lkml.org/lkml/2009/6/14/216
> > Handled-By : Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
>
> Already fixed in mainline, data in bug report.
Thanks, closed.
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
2009-08-02 19:09 ` [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq Rafael J. Wysocki
@ 2009-08-06 14:49 ` Johannes Stezenbach
2009-08-06 15:12 ` Rafael J. Wysocki
0 siblings, 1 reply; 263+ messages in thread
From: Johannes Stezenbach @ 2009-08-06 14:49 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Sun, Aug 02, 2009 at 09:09:32PM +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=13644
> Subject : hibernation/swsusp lockup due to acpi-cpufreq
> Submitter : Johannes Stezenbach <js@sig21.net>
> Date : 2009-06-16 01:27 (48 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>
This issue is fixed in linux-2.6.31-rc5-246-g90bc1a6,
I'm guessing due to
commit 4bc5d34135039566b8d6efa2de7515b2be505da8
Author: Dave Jones <davej@redhat.com>
Date: Tue Aug 4 14:03:25 2009 -0400
[CPUFREQ] Make cpufreq suspend code conditional on powerpc.
Thanks,
Johannes
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
@ 2009-08-06 15:12 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-06 15:12 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Thursday 06 August 2009, Johannes Stezenbach wrote:
> On Sun, Aug 02, 2009 at 09:09:32PM +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=13644
> > Subject : hibernation/swsusp lockup due to acpi-cpufreq
> > Submitter : Johannes Stezenbach <js@sig21.net>
> > Date : 2009-06-16 01:27 (48 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>
>
> This issue is fixed in linux-2.6.31-rc5-246-g90bc1a6,
> I'm guessing due to
>
> commit 4bc5d34135039566b8d6efa2de7515b2be505da8
> Author: Dave Jones <davej@redhat.com>
> Date: Tue Aug 4 14:03:25 2009 -0400
>
> [CPUFREQ] Make cpufreq suspend code conditional on powerpc.
Thanks, bug closed.
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
@ 2009-08-06 15:12 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-06 15:12 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Thursday 06 August 2009, Johannes Stezenbach wrote:
> On Sun, Aug 02, 2009 at 09:09:32PM +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=13644
> > Subject : hibernation/swsusp lockup due to acpi-cpufreq
> > Submitter : Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
> > Date : 2009-06-16 01:27 (48 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>
>
> This issue is fixed in linux-2.6.31-rc5-246-g90bc1a6,
> I'm guessing due to
>
> commit 4bc5d34135039566b8d6efa2de7515b2be505da8
> Author: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Tue Aug 4 14:03:25 2009 -0400
>
> [CPUFREQ] Make cpufreq suspend code conditional on powerpc.
Thanks, bug closed.
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13739] 2.6.30 leaking keys on console switch
2009-08-02 19:09 ` Rafael J. Wysocki
@ 2009-08-07 23:22 ` Jiri Kosina
-1 siblings, 0 replies; 263+ messages in thread
From: Jiri Kosina @ 2009-08-07 23:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andi Kleen
On Sun, 2 Aug 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=13739
> Subject : 2.6.30 leaking keys on console switch
> Submitter : Andi Kleen <andi@firstfloor.org>
> Date : 2009-07-07 8:44 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4
> Handled-By : Jiri Kosina <jkosina@suse.cz>
Andi, did the bisection reveal anything?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13739] 2.6.30 leaking keys on console switch
@ 2009-08-07 23:22 ` Jiri Kosina
0 siblings, 0 replies; 263+ messages in thread
From: Jiri Kosina @ 2009-08-07 23:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andi Kleen
On Sun, 2 Aug 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=13739
> Subject : 2.6.30 leaking keys on console switch
> Submitter : Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>
> Date : 2009-07-07 8:44 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4
> Handled-By : Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
Andi, did the bisection reveal anything?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
2009-08-03 19:13 ` Rafael J. Wysocki
(?)
@ 2009-08-12 20:43 ` Harald Dunkel
2009-08-12 21:15 ` Rafael J. Wysocki
-1 siblings, 1 reply; 263+ messages in thread
From: Harald Dunkel @ 2009-08-12 20:43 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
Rafael J. Wysocki wrote:
>
> Please let us know either way.
>
I am running 2.6.31-rc5 for amd64 on 2 systems. By now I haven't
seen this problem on the new kernel yet, but since I saw it only
once for an older kernel I cannot say whether it is really gone.
Regards
Harri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-12 21:15 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-12 21:15 UTC (permalink / raw)
To: Harald Dunkel
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney
On Wednesday 12 August 2009, Harald Dunkel wrote:
> Rafael J. Wysocki wrote:
> >
> > Please let us know either way.
> >
>
> I am running 2.6.31-rc5 for amd64 on 2 systems. By now I haven't
> seen this problem on the new kernel yet, but since I saw it only
> once for an older kernel I cannot say whether it is really gone.
I closed the bug as not reproducible.
Please go to the Bugzilla and reopen the bug entry if you see it again.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-12 21:15 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-12 21:15 UTC (permalink / raw)
To: Harald Dunkel
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney
On Wednesday 12 August 2009, Harald Dunkel wrote:
> Rafael J. Wysocki wrote:
> >
> > Please let us know either way.
> >
>
> I am running 2.6.31-rc5 for amd64 on 2 systems. By now I haven't
> seen this problem on the new kernel yet, but since I saw it only
> once for an older kernel I cannot say whether it is really gone.
I closed the bug as not reproducible.
Please go to the Bugzilla and reopen the bug entry if you see it again.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-18 17:30 ` Harald Dunkel
0 siblings, 0 replies; 263+ messages in thread
From: Harald Dunkel @ 2009-08-18 17:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
Hi Rafael,
I haven't seen the 120secs timeout yet, but using 2.6.31-rc5 there _are_
some delays that I am not sure of. Sometimes it takes about 30 secs till
the XWindow server comes up, for example. (I use xinit on the command line
at login. / and /home are both reiserfs.) For 2.6.30.4 and older I haven't
seen this delay yet, AFAIR.
Most recent event: I tried to format a 4 GByte USB stick with reiserfs.
Here is the screen output:
# device=/dev/sdf
# parted $device mklabel gpt
Warning: The existing disk label on /dev/sdf will be destroyed and
all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
Information: You may need to update /etc/fstab.
# parted -- $device mkpart primary 0s -1s
Warning: You requested a partition from 0.00B to 4127MB.
The closest location we can manage is 17.4kB to 4127MB.
Is this still acceptable to you?
Yes/No? Yes
Information: You may need to update /etc/fstab.
# mkreiserfs -l usbstick /dev/sdf1
mkreiserfs 3.6.21 (2009 www.namesys.com)
:
:
UUID: 154d66cc-02ac-4979-9a39-163e3cf80623
LABEL: usbstick
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
ALL DATA WILL BE LOST ON '/dev/sdf1'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok
ReiserFS is successfully created on /dev/sdf1.
It took about 2 to 3 minutes till the "ok" in the "Syncing" line
was shown. /var/log/messages was silent. When I tried to reproduce
the delay it was gone, of course.
Since I would like to try 2.6.31-rc6 anyway, maybe you could post
some hints about what debugging options to set in the config file?
Many thanx
Harri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-18 17:30 ` Harald Dunkel
0 siblings, 0 replies; 263+ messages in thread
From: Harald Dunkel @ 2009-08-18 17:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
Hi Rafael,
I haven't seen the 120secs timeout yet, but using 2.6.31-rc5 there _are_
some delays that I am not sure of. Sometimes it takes about 30 secs till
the XWindow server comes up, for example. (I use xinit on the command line
at login. / and /home are both reiserfs.) For 2.6.30.4 and older I haven't
seen this delay yet, AFAIR.
Most recent event: I tried to format a 4 GByte USB stick with reiserfs.
Here is the screen output:
# device=/dev/sdf
# parted $device mklabel gpt
Warning: The existing disk label on /dev/sdf will be destroyed and
all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
Information: You may need to update /etc/fstab.
# parted -- $device mkpart primary 0s -1s
Warning: You requested a partition from 0.00B to 4127MB.
The closest location we can manage is 17.4kB to 4127MB.
Is this still acceptable to you?
Yes/No? Yes
Information: You may need to update /etc/fstab.
# mkreiserfs -l usbstick /dev/sdf1
mkreiserfs 3.6.21 (2009 www.namesys.com)
:
:
UUID: 154d66cc-02ac-4979-9a39-163e3cf80623
LABEL: usbstick
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
ALL DATA WILL BE LOST ON '/dev/sdf1'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok
ReiserFS is successfully created on /dev/sdf1.
It took about 2 to 3 minutes till the "ok" in the "Syncing" line
was shown. /var/log/messages was silent. When I tried to reproduce
the delay it was gone, of course.
Since I would like to try 2.6.31-rc6 anyway, maybe you could post
some hints about what debugging options to set in the config file?
Many thanx
Harri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-18 19:12 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-18 19:12 UTC (permalink / raw)
To: Harald Dunkel
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney, Tejun Heo
On Tuesday 18 August 2009, Harald Dunkel wrote:
> Hi Rafael,
>
> I haven't seen the 120secs timeout yet, but using 2.6.31-rc5 there _are_
> some delays that I am not sure of. Sometimes it takes about 30 secs till
> the XWindow server comes up, for example. (I use xinit on the command line
> at login. / and /home are both reiserfs.) For 2.6.30.4 and older I haven't
> seen this delay yet, AFAIR.
>
> Most recent event: I tried to format a 4 GByte USB stick with reiserfs.
> Here is the screen output:
>
> # device=/dev/sdf
> # parted $device mklabel gpt
> Warning: The existing disk label on /dev/sdf will be destroyed and
> all data on this disk will be lost. Do you want to continue?
> Yes/No? Yes
> Information: You may need to update /etc/fstab.
>
> # parted -- $device mkpart primary 0s -1s
> Warning: You requested a partition from 0.00B to 4127MB.
> The closest location we can manage is 17.4kB to 4127MB.
> Is this still acceptable to you?
> Yes/No? Yes
> Information: You may need to update /etc/fstab.
>
> # mkreiserfs -l usbstick /dev/sdf1
> mkreiserfs 3.6.21 (2009 www.namesys.com)
> :
> :
> UUID: 154d66cc-02ac-4979-9a39-163e3cf80623
> LABEL: usbstick
> ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
> ALL DATA WILL BE LOST ON '/dev/sdf1'!
> Continue (y/n):y
> Initializing journal - 0%....20%....40%....60%....80%....100%
> Syncing..ok
> ReiserFS is successfully created on /dev/sdf1.
>
> It took about 2 to 3 minutes till the "ok" in the "Syncing" line
> was shown. /var/log/messages was silent. When I tried to reproduce
> the delay it was gone, of course.
Thanks for the update.
> Since I would like to try 2.6.31-rc6 anyway, maybe you could post
> some hints about what debugging options to set in the config file?
Unfortunately, I don't have much experience with debugging issues of this kind.
Perhaps Tejun will have some hints (CC added)?
Best,
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-18 19:12 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-18 19:12 UTC (permalink / raw)
To: Harald Dunkel
Cc: Frédéric Weisbecker, Linux Kernel Mailing List,
Kernel Testers List, Jeff Mahoney, Tejun Heo
On Tuesday 18 August 2009, Harald Dunkel wrote:
> Hi Rafael,
>
> I haven't seen the 120secs timeout yet, but using 2.6.31-rc5 there _are_
> some delays that I am not sure of. Sometimes it takes about 30 secs till
> the XWindow server comes up, for example. (I use xinit on the command line
> at login. / and /home are both reiserfs.) For 2.6.30.4 and older I haven't
> seen this delay yet, AFAIR.
>
> Most recent event: I tried to format a 4 GByte USB stick with reiserfs.
> Here is the screen output:
>
> # device=/dev/sdf
> # parted $device mklabel gpt
> Warning: The existing disk label on /dev/sdf will be destroyed and
> all data on this disk will be lost. Do you want to continue?
> Yes/No? Yes
> Information: You may need to update /etc/fstab.
>
> # parted -- $device mkpart primary 0s -1s
> Warning: You requested a partition from 0.00B to 4127MB.
> The closest location we can manage is 17.4kB to 4127MB.
> Is this still acceptable to you?
> Yes/No? Yes
> Information: You may need to update /etc/fstab.
>
> # mkreiserfs -l usbstick /dev/sdf1
> mkreiserfs 3.6.21 (2009 www.namesys.com)
> :
> :
> UUID: 154d66cc-02ac-4979-9a39-163e3cf80623
> LABEL: usbstick
> ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
> ALL DATA WILL BE LOST ON '/dev/sdf1'!
> Continue (y/n):y
> Initializing journal - 0%....20%....40%....60%....80%....100%
> Syncing..ok
> ReiserFS is successfully created on /dev/sdf1.
>
> It took about 2 to 3 minutes till the "ok" in the "Syncing" line
> was shown. /var/log/messages was silent. When I tried to reproduce
> the delay it was gone, of course.
Thanks for the update.
> Since I would like to try 2.6.31-rc6 anyway, maybe you could post
> some hints about what debugging options to set in the config file?
Unfortunately, I don't have much experience with debugging issues of this kind.
Perhaps Tejun will have some hints (CC added)?
Best,
Rafael
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-19 1:54 ` Tejun Heo
0 siblings, 0 replies; 263+ messages in thread
From: Tejun Heo @ 2009-08-19 1:54 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Harald Dunkel, Frédéric Weisbecker,
Linux Kernel Mailing List, Kernel Testers List, Jeff Mahoney
Hello,
Rafael J. Wysocki wrote:
> Unfortunately, I don't have much experience with debugging issues of
> this kind. Perhaps Tejun will have some hints (CC added)?
Eh... I don't have much experience either and from the reported
information I can't tell much. The question would be what the thread
which is holding the lock was doing and whether it traces down to IO
layer. So, as Jeff said, we'll need sysrq-t output to tell what's
going on. The current trace only reveals the victim not the offender.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-08-19 1:54 ` Tejun Heo
0 siblings, 0 replies; 263+ messages in thread
From: Tejun Heo @ 2009-08-19 1:54 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Harald Dunkel, Frédéric Weisbecker,
Linux Kernel Mailing List, Kernel Testers List, Jeff Mahoney
Hello,
Rafael J. Wysocki wrote:
> Unfortunately, I don't have much experience with debugging issues of
> this kind. Perhaps Tejun will have some hints (CC added)?
Eh... I don't have much experience either and from the reported
information I can't tell much. The question would be what the thread
which is holding the lock was doing and whether it traces down to IO
layer. So, as Jeff said, we'll need sysrq-t output to tell what's
going on. The current trace only reveals the victim not the offender.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-08-26 20:53 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-26 20:53 UTC (permalink / raw)
To: Pekka Enberg
Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes,
Johannes Berg, Larry Finger
On Wednesday 26 August 2009, Pekka Enberg wrote:
> Hi Rafael,
>
> On Wed, Aug 26, 2009 at 12:05 AM, 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=13319
> > Subject : Page allocation failures with b43 and p54usb
> > Submitter : Larry Finger <Larry.Finger@lwfinger.net>
> > 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@sipsolutions.net>
> > David Rientjes <rientjes@google.com>
> > 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-08-26 20:53 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-26 20:53 UTC (permalink / raw)
To: Pekka Enberg
Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes,
Johannes Berg, Larry Finger
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-08-25 21:05 ` Rafael J. Wysocki
@ 2009-08-26 6:25 ` Pekka Enberg
-1 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-08-26 6:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes,
Johannes Berg, Larry Finger
Hi Rafael,
On Wed, Aug 26, 2009 at 12:05 AM, 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=13319
> Subject : Page allocation failures with b43 and p54usb
> Submitter : Larry Finger <Larry.Finger@lwfinger.net>
> 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@sipsolutions.net>
> David Rientjes <rientjes@google.com>
> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-08-26 6:25 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-08-26 6:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes,
Johannes Berg, Larry Finger
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-08-25 20:37 2.6.31-rc7-git2: " Rafael J. Wysocki
@ 2009-08-25 21:05 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-25 21:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger
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 (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@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-08-25 21:05 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-25 21:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger
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/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-08-19 20:36 2.6.31-rc6-git5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
@ 2009-08-19 20:40 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-19 20:40 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger
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 (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@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-08-19 20:40 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-19 20:40 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger
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/
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-08-09 21:07 2.6.31-rc5-git5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
@ 2009-08-09 21:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-08-09 21:10 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger
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/
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-07-27 21:43 ` Christoph Lameter
(?)
@ 2009-07-27 22:38 ` David Rientjes
-1 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-27 22:38 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 21:43 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-07-27 21:43 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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?
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 21:43 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-07-27 21:43 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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?
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 18:16 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-27 18:16 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 18:16 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-27 18:16 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 17:20 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-07-27 17:20 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 17:20 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-07-27 17:20 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 9:37 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-27 9:37 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1143 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?
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 9:37 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-27 9:37 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
[-- 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?
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 7:08 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-07-27 7:08 UTC (permalink / raw)
To: David Rientjes
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
On Mon, Jul 27, 2009 at 3:24 AM, David Rientjes<rientjes@google.com> 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@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>
>>
>> This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60
>> entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg
>> <penberg@cs.helsinki.fi> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 7:08 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-07-27 7:08 UTC (permalink / raw)
To: David Rientjes
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 0:24 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-27 0:24 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg
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@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>
>
> This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60
> entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg
> <penberg@cs.helsinki.fi> 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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 0:24 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-27 0:24 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-07-26 20:45 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
@ 2009-07-27 0:17 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-07-27 0:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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@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>
This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60
entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg
<penberg@cs.helsinki.fi> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-27 0:17 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-07-27 0:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-07-26 20:41 2.6.31-rc4: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
@ 2009-07-26 20:45 ` Rafael J. Wysocki
2009-07-27 0:17 ` Larry Finger
0 siblings, 1 reply; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-08 13:18 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-07-08 13:18 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-08 13:18 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-07-08 13:18 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-07 6:57 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-07-07 6:57 UTC (permalink / raw)
To: David Rientjes
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg
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@google.com> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-07 6:57 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-07-07 6:57 UTC (permalink / raw)
To: David Rientjes
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-07 6:29 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-07 6:29 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-07 6:29 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-07 6:29 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-07-07 0:00 ` Rafael J. Wysocki
@ 2009-07-07 1:05 ` Larry Finger
-1 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-07-07 1:05 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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@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>
I have not seen the fix yet, but one is being prepared. I think the
bug can be closed.
Larry
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-07 1:05 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-07-07 1:05 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-07-06 23:57 2.6.31-rc2: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
@ 2009-07-07 0:00 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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 (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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-07 0:00 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-03 7:23 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-07-03 7:23 UTC (permalink / raw)
To: David Rientjes
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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@google.com> 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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-03 7:23 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-07-03 7:23 UTC (permalink / raw)
To: David Rientjes
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-02 17:18 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-02 17:18 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-02 17:18 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-07-02 17:18 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-30 21:52 ` David Rientjes
(?)
(?)
@ 2009-07-01 5:53 ` Pekka Enberg
2009-07-02 17:18 ` David Rientjes
-1 siblings, 1 reply; 263+ messages in thread
From: Pekka Enberg @ 2009-07-01 5:53 UTC (permalink / raw)
To: David Rientjes
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 22:18 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 22:18 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 22:18 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 22:18 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:52 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 21:52 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:52 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 21:52 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:23 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 21:23 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:23 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 21:23 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:15 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 21:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:15 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 21:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:05 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 21:05 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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)
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:05 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 21:05 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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)
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 20:25 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 20:25 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
On Tue, 30 Jun 2009, Pekka Enberg wrote:
> On Tue, Jun 30, 2009 at 10:47 AM, David Rientjes<rientjes@google.com> 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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 20:25 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 20:25 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 20:04 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 20:04 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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;
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 20:04 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 20:04 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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;
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-30 15:01 ` Pekka Enberg
@ 2009-06-30 15:14 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 15:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 15:14 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 15:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-30 14:32 ` Christoph Lameter
(?)
@ 2009-06-30 15:01 ` Pekka Enberg
2009-06-30 15:14 ` Christoph Lameter
-1 siblings, 1 reply; 263+ messages in thread
From: Pekka Enberg @ 2009-06-30 15:01 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Rientjes, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-30 8:24 ` Pekka Enberg
(?)
@ 2009-06-30 14:38 ` Larry Finger
-1 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-30 14:38 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 14:32 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 14:32 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 14:32 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-30 14:32 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 8:24 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-30 8:24 UTC (permalink / raw)
To: David Rientjes
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
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@google.com> 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@google.com> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 8:24 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-30 8:24 UTC (permalink / raw)
To: David Rientjes
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 7:47 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 7:47 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2269 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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 7:47 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 7:47 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
[-- 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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 6:55 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-30 6:55 UTC (permalink / raw)
To: David Rientjes
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
Hi David,
On Tue, Jun 30, 2009 at 2:47 AM, David Rientjes<rientjes@google.com> 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@lwfinger.net>
>> > 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@sipsolutions.net>
>>
>> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 6:55 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-30 6:55 UTC (permalink / raw)
To: David Rientjes
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-30 2:06 ` Larry Finger
(?)
@ 2009-06-30 5:47 ` David Rientjes
-1 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-30 5:47 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg,
Christoph Lameter
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 2:06 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-30 2:06 UTC (permalink / raw)
To: David Rientjes
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg,
Christoph Lameter
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@lwfinger.net>
>>> 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@sipsolutions.net>
>> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 2:06 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-30 2:06 UTC (permalink / raw)
To: David Rientjes
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg,
Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 23:47 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-29 23:47 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg,
Christoph Lameter
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@lwfinger.net>
> > 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@sipsolutions.net>
>
> 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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 23:47 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-29 23:47 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Pekka Enberg,
Christoph Lameter
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 23:15 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 23:15 UTC (permalink / raw)
To: Larry Finger
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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@lwfinger.net>
> > 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@sipsolutions.net>
>
> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 23:15 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 23:15 UTC (permalink / raw)
To: Larry Finger
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-29 0:30 ` Rafael J. Wysocki
@ 2009-06-29 16:51 ` Larry Finger
-1 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-29 16:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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@lwfinger.net>
> 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@sipsolutions.net>
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 16:51 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-29 16:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-29 0:26 2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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 (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@sipsolutions.net>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-11 15:09 ` Pekka Enberg
@ 2009-06-11 18:41 ` Johannes Berg
-1 siblings, 0 replies; 263+ messages in thread
From: Johannes Berg @ 2009-06-11 18:41 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Larry Finger, David Rientjes, Mel Gorman,
Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, npiggin, yanmin.zhang
[-- 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 --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-11 18:41 ` Johannes Berg
0 siblings, 0 replies; 263+ messages in thread
From: Johannes Berg @ 2009-06-11 18:41 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Larry Finger, David Rientjes, Mel Gorman,
Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, npiggin-l3A5Bk7waGM,
yanmin.zhang-VuQAYsv1563Yd54FQh9/CA
[-- 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 --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-11 15:09 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-11 15:09 UTC (permalink / raw)
To: Christoph Lameter
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, npiggin, yanmin.zhang
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-11 15:09 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-11 15:09 UTC (permalink / raw)
To: Christoph Lameter
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, npiggin-l3A5Bk7waGM,
yanmin.zhang-VuQAYsv1563Yd54FQh9/CA
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-10 15:44 ` Pekka Enberg
@ 2009-06-11 14:41 ` Christoph Lameter
2009-06-11 14:41 ` Christoph Lameter
1 sibling, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-11 14:41 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, npiggin, yanmin.zhang,
Andrew Morton
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-11 14:41 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-11 14:41 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, npiggin-l3A5Bk7waGM,
yanmin.zhang-VuQAYsv1563Yd54FQh9/CA, Andrew Morton
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 18:03 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 18:03 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin
On Wed, Jun 10, 2009 at 6:56 PM, Mel Gorman<mel@csn.ul.ie> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 18:03 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 18:03 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin-l3A5Bk7waGM
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 16:16 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 16:16 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, Christoph Lameter, npiggin, yanmin.zhang
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;
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 16:16 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 16:16 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM,
yanmin.zhang-VuQAYsv1563Yd54FQh9/CA
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;
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-10 15:49 ` Pekka Enberg
@ 2009-06-10 16:10 ` Larry Finger
-1 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-10 16:10 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin, yanmin.zhang
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 16:10 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-10 16:10 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin-l3A5Bk7waGM,
yanmin.zhang-VuQAYsv1563Yd54FQh9/CA
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 16:06 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 16:06 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, Christoph Lameter, npiggin, yanmin.zhang
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 16:06 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 16:06 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM,
yanmin.zhang-VuQAYsv1563Yd54FQh9/CA
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-09 7:06 ` Pekka Enberg
@ 2009-06-10 15:56 ` Mel Gorman
-1 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-10 15:56 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 15:56 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-10 15:56 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin-l3A5Bk7waGM
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-10 15:49 ` Pekka Enberg
@ 2009-06-10 15:52 ` Johannes Berg
-1 siblings, 0 replies; 263+ messages in thread
From: Johannes Berg @ 2009-06-10 15:52 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, Christoph Lameter, npiggin, yanmin.zhang
[-- 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 --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 15:52 ` Johannes Berg
0 siblings, 0 replies; 263+ messages in thread
From: Johannes Berg @ 2009-06-10 15:52 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel,
Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM,
yanmin.zhang-VuQAYsv1563Yd54FQh9/CA
[-- 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 --]
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-10 15:44 ` Pekka Enberg
@ 2009-06-10 15:49 ` Pekka Enberg
2009-06-11 14:41 ` Christoph Lameter
1 sibling, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 15:49 UTC (permalink / raw)
To: Larry Finger
Cc: David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin, yanmin.zhang
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;
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-10 15:49 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 15:49 UTC (permalink / raw)
To: Larry Finger
Cc: David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin-l3A5Bk7waGM,
yanmin.zhang-VuQAYsv1563Yd54FQh9/CA
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;
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-10 14:41 ` Larry Finger
@ 2009-06-10 15:44 ` Pekka Enberg
2009-06-10 15:49 ` Pekka Enberg
2009-06-11 14:41 ` Christoph Lameter
0 siblings, 2 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-10 15:44 UTC (permalink / raw)
To: Larry Finger
Cc: David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin, yanmin.zhang, akpm
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;
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-09 8:28 ` Pekka Enberg
(?)
@ 2009-06-10 14:41 ` Larry Finger
2009-06-10 15:44 ` Pekka Enberg
-1 siblings, 1 reply; 263+ messages in thread
From: Larry Finger @ 2009-06-10 14:41 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-09 8:28 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-09 8:28 UTC (permalink / raw)
To: David Rientjes
Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin
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)
{
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-09 8:28 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-09 8:28 UTC (permalink / raw)
To: David Rientjes
Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin-l3A5Bk7waGM
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)
{
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-09 7:58 ` Pekka Enberg
@ 2009-06-09 8:14 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-09 8:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-09 8:14 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-09 8:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin-l3A5Bk7waGM
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-09 7:54 ` David Rientjes
(?)
@ 2009-06-09 7:58 ` Pekka Enberg
2009-06-09 8:14 ` David Rientjes
-1 siblings, 1 reply; 263+ messages in thread
From: Pekka Enberg @ 2009-06-09 7:58 UTC (permalink / raw)
To: David Rientjes
Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-09 7:06 ` Pekka Enberg
@ 2009-06-09 7:54 ` David Rientjes
-1 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-09 7:54 UTC (permalink / raw)
To: Pekka Enberg
Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin
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).
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-09 7:54 ` David Rientjes
0 siblings, 0 replies; 263+ messages in thread
From: David Rientjes @ 2009-06-09 7:54 UTC (permalink / raw)
To: Pekka Enberg
Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin-l3A5Bk7waGM
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).
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-09 7:50 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-09 7:50 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
On Mon, Jun 8, 2009 at 5:12 PM, Mel Gorman<mel@csn.ul.ie> 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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-09 7:50 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-09 7:50 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-09 7:06 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-09 7:06 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin
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)
{
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-09 7:06 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-09 7:06 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter, npiggin-l3A5Bk7waGM
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)
{
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 17:20 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-08 17:20 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Pekka Enberg, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, Mel Gorman
KAMEZAWA Hiroyuki wrote:
> On Sun, 07 Jun 2009 11:35:27 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> Pekka Enberg wrote:
>>> On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel@redhat.com> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 17:20 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-08 17:20 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Pekka Enberg, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, Mel Gorman
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 14:42 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-08 14:42 UTC (permalink / raw)
To: Mel Gorman
Cc: Pekka J Enberg, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 14:42 ` Christoph Lameter
0 siblings, 0 replies; 263+ messages in thread
From: Christoph Lameter @ 2009-06-08 14:42 UTC (permalink / raw)
To: Mel Gorman
Cc: Pekka J Enberg, Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 14:12 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-08 14:12 UTC (permalink / raw)
To: Pekka J Enberg
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 14:12 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-08 14:12 UTC (permalink / raw)
To: Pekka J Enberg
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 13:58 ` Pekka J Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka J Enberg @ 2009-06-08 13:58 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
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))
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 13:58 ` Pekka J Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka J Enberg @ 2009-06-08 13:58 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
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))
^ permalink raw reply related [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 13:35 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-08 13:35 UTC (permalink / raw)
To: Rik van Riel
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 13:35 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-08 13:35 UTC (permalink / raw)
To: Rik van Riel
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-08 10:17 ` Mel Gorman
` (2 preceding siblings ...)
(?)
@ 2009-06-08 13:34 ` Larry Finger
-1 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-08 13:34 UTC (permalink / raw)
To: Mel Gorman
Cc: Pekka Enberg, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 13:20 ` Rik van Riel
0 siblings, 0 replies; 263+ messages in thread
From: Rik van Riel @ 2009-06-08 13:20 UTC (permalink / raw)
To: Mel Gorman
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 13:20 ` Rik van Riel
0 siblings, 0 replies; 263+ messages in thread
From: Rik van Riel @ 2009-06-08 13:20 UTC (permalink / raw)
To: Mel Gorman
Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 11:03 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-08 11:03 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
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@csn.ul.ie> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 11:03 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-08 11:03 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 10:52 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-08 10:52 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
On Mon, Jun 8, 2009 at 1:17 PM, Mel Gorman<mel@csn.ul.ie> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 10:52 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-08 10:52 UTC (permalink / raw)
To: Mel Gorman
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki,
Christoph Lameter
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 10:17 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-08 10:17 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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@redhat.com> 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@lwfinger.net>
> >>>> 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@sipsolutions.net>
> >>>
> >>> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 10:17 ` Mel Gorman
0 siblings, 0 replies; 263+ messages in thread
From: Mel Gorman @ 2009-06-08 10:17 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 8:32 ` KAMEZAWA Hiroyuki
0 siblings, 0 replies; 263+ messages in thread
From: KAMEZAWA Hiroyuki @ 2009-06-08 8:32 UTC (permalink / raw)
To: Larry Finger
Cc: Pekka Enberg, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, Mel Gorman
On Sun, 07 Jun 2009 11:35:27 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Pekka Enberg wrote:
> > On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel@redhat.com> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-08 8:32 ` KAMEZAWA Hiroyuki
0 siblings, 0 replies; 263+ messages in thread
From: KAMEZAWA Hiroyuki @ 2009-06-08 8:32 UTC (permalink / raw)
To: Larry Finger
Cc: Pekka Enberg, Rik van Riel, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Andrew Morton, KOSAKI Motohiro, Mel Gorman
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 16:35 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-07 16:35 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, Mel Gorman
Pekka Enberg wrote:
> On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel@redhat.com> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 16:35 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-07 16:35 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, Mel Gorman
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 14:32 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-07 14:32 UTC (permalink / raw)
To: Rik van Riel
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, Mel Gorman
On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel@redhat.com> 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@lwfinger.net>
>>>> 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@sipsolutions.net>
>>>
>>> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 14:32 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-07 14:32 UTC (permalink / raw)
To: Rik van Riel
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, Mel Gorman
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 14:19 ` Rik van Riel
0 siblings, 0 replies; 263+ messages in thread
From: Rik van Riel @ 2009-06-07 14:19 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, hugh
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@lwfinger.net>
>>> 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@sipsolutions.net>
>> 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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 14:19 ` Rik van Riel
0 siblings, 0 replies; 263+ messages in thread
From: Rik van Riel @ 2009-06-07 14:19 UTC (permalink / raw)
To: Pekka Enberg
Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, hugh-DTz5qymZ9yRBDgjK7y7TUQ
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 13:40 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-07 13:40 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton, Rik van Riel,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, hugh
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@lwfinger.net>
>> 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@sipsolutions.net>
>
> 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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 13:40 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-06-07 13:40 UTC (permalink / raw)
To: Larry Finger
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Andrew Morton, Rik van Riel,
KOSAKI Motohiro, KAMEZAWA Hiroyuki, hugh-DTz5qymZ9yRBDgjK7y7TUQ
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-07 9:52 ` Rafael J. Wysocki
@ 2009-06-07 13:10 ` Larry Finger
-1 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-07 13:10 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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@lwfinger.net>
> 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@sipsolutions.net>
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 13:10 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-06-07 13:10 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-07 9:47 2.6.30-rc8-git4: Reported regressions from 2.6.29 Rafael J. Wysocki
@ 2009-06-07 9:52 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-06-07 9:52 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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@lwfinger.net>
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@sipsolutions.net>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-07 9:52 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-06-07 9:52 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-05-30 19:29 2.6.30-rc7-git4: Reported regressions from 2.6.29 Rafael J. Wysocki
@ 2009-05-30 19:37 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-05-30 19:37 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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@lwfinger.net>
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@sipsolutions.net>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-30 19:37 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-05-30 19:37 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-05-24 19:06 2.6.30-rc7: Reported regressions from 2.6.29 Rafael J. Wysocki
@ 2009-05-24 19:11 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-05-24 19:11 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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@lwfinger.net>
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@sipsolutions.net>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-24 19:11 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-05-24 19:11 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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>
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-05-16 19:20 ` Rafael J. Wysocki
@ 2009-05-21 13:21 ` Larry Finger
-1 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-05-21 13:21 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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@lwfinger.net>
> 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@sipsolutions.net>
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-21 13:21 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-05-21 13:21 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-18 6:31 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-05-18 6:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Larry Finger, linux-wireless,
adrian
Hi Andrew,
On Sat, 16 May 2009 21:20:45 +0200 (CEST) "Rafael J. Wysocki"
<rjw@sisk.pl> 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@lwfinger.net>
>> 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@sipsolutions.net>
On Sun, May 17, 2009 at 2:36 AM, Andrew Morton
<akpm@linux-foundation.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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-18 6:31 ` Pekka Enberg
0 siblings, 0 replies; 263+ messages in thread
From: Pekka Enberg @ 2009-05-18 6:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, Larry Finger,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
adrian-TSF8l6Tg6afpT6hvJLqO3U8SxdOydiOw
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-17 23:16 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-05-17 23:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg, linux-wireless
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-17 23:16 ` Larry Finger
0 siblings, 0 replies; 263+ messages in thread
From: Larry Finger @ 2009-05-17 23:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Johannes Berg,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
2009-05-16 19:20 ` Rafael J. Wysocki
@ 2009-05-16 23:36 ` Andrew Morton
-1 siblings, 0 replies; 263+ messages in thread
From: Andrew Morton @ 2009-05-16 23:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Larry Finger, linux-wireless
On Sat, 16 May 2009 21:20:45 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> 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@lwfinger.net>
> 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@sipsolutions.net>
>
>
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-16 23:36 ` Andrew Morton
0 siblings, 0 replies; 263+ messages in thread
From: Andrew Morton @ 2009-05-16 23:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
Larry Finger, linux-wireless-u79uwXL29TY76Z2rM5mHXA
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.
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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@lwfinger.net>
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@sipsolutions.net>
^ permalink raw reply [flat|nested] 263+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-05-16 19:20 ` Rafael J. Wysocki
0 siblings, 0 replies; 263+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Larry Finger
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>
^ permalink raw reply [flat|nested] 263+ messages in thread
end of thread, other threads:[~2009-08-26 20:53 UTC | newest]
Thread overview: 263+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-02 19:06 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
2009-08-02 19:06 ` Rafael J. Wysocki
2009-08-02 19:06 ` [Bug #13109] High latency on /sys/class/thermal Rafael J. Wysocki
2009-08-02 19:06 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13306] hibernate slow on _second_ run Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13318] AGP doesn't work anymore on nforce2 Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6 Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13341] Random Oops at boot at loading ip6tables rules Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13374] reiserfs blocked for more than 120secs Rafael J. Wysocki
2009-08-03 1:01 ` Frédéric Weisbecker
2009-08-03 1:01 ` Frédéric Weisbecker
2009-08-03 17:43 ` Harald Dunkel
2009-08-03 17:43 ` Harald Dunkel
2009-08-03 19:13 ` Rafael J. Wysocki
2009-08-03 19:13 ` Rafael J. Wysocki
2009-08-12 20:43 ` Harald Dunkel
2009-08-12 21:15 ` Rafael J. Wysocki
2009-08-12 21:15 ` Rafael J. Wysocki
2009-08-18 17:30 ` Harald Dunkel
2009-08-18 17:30 ` Harald Dunkel
2009-08-18 19:12 ` Rafael J. Wysocki
2009-08-18 19:12 ` Rafael J. Wysocki
2009-08-19 1:54 ` Tejun Heo
2009-08-19 1:54 ` Tejun Heo
2009-08-02 19:09 ` [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected) Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13512] D43 on 2.6.30 doesn't suspend anymore Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13408] Performance regression in 2.6.30-rc7 Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13407] adb trackpad disappears after suspend to ram Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13514] acer_wmi causes stack corruption Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13558] Tracelog during resume Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13581] ath9k doesn't work with newer kernels Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13583] pdflush uses 5% CPU on otherwise idle system Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13564] random general protection fault at boot time caused by khubd Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13638] rt2870 driver is broken for (some) cards Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13621] xfs hangs with assertion failed Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13646] warn_on tty_io.c, broken bluetooth Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq Rafael J. Wysocki
2009-08-06 14:49 ` Johannes Stezenbach
2009-08-06 15:12 ` Rafael J. Wysocki
2009-08-06 15:12 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13669] Kernel bug with dock driver Rafael J. Wysocki
2009-08-03 23:55 ` Henrique de Moraes Holschuh
2009-08-03 23:55 ` Henrique de Moraes Holschuh
2009-08-04 16:23 ` Rafael J. Wysocki
2009-08-04 16:23 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13739] 2.6.30 leaking keys on console switch Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-07 23:22 ` Jiri Kosina
2009-08-07 23:22 ` Jiri Kosina
2009-08-02 19:09 ` [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13780] NULL pointer dereference loading powernowk8 Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13694] i915 phantom TV Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13884] x86 CPA incorrect memtype reserving using set_pages_array_xx Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13865] Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted Rafael J. Wysocki
2009-08-02 22:53 ` Frans Pop
2009-08-02 22:53 ` Frans Pop
2009-08-03 15:18 ` Rafael J. Wysocki
2009-08-03 15:18 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13795] abnormal boot and no suspend due to 'async' (fastboot) Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8 Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13898] Intel 3945ABG - problems on 2.6.30.X Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13897] PAT wc & vmap mapping count issue Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13886] Suspend to disk no longer works in 2.6.30.2 with an EIDE drive Rafael J. Wysocki
2009-08-02 19:09 ` Rafael J. Wysocki
2009-08-03 15:16 ` 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30 Luis R. Rodriguez
2009-08-03 15:16 ` Luis R. Rodriguez
2009-08-03 15:16 ` Luis R. Rodriguez
-- strict thread matches above, loose matches on Subject: below --
2009-08-25 20:37 2.6.31-rc7-git2: " Rafael J. Wysocki
2009-08-25 21:05 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-08-25 21:05 ` Rafael J. Wysocki
2009-08-26 6:25 ` Pekka Enberg
2009-08-26 6:25 ` Pekka Enberg
2009-08-26 20:53 ` Rafael J. Wysocki
2009-08-26 20:53 ` Rafael J. Wysocki
2009-08-19 20:36 2.6.31-rc6-git5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
2009-08-19 20:40 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-08-19 20:40 ` Rafael J. Wysocki
2009-08-09 21:07 2.6.31-rc5-git5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
2009-08-09 21:10 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-07-26 20:41 2.6.31-rc4: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
2009-07-26 20:45 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-07-27 0:17 ` Larry Finger
2009-07-27 0:17 ` Larry Finger
2009-07-27 0:24 ` David Rientjes
2009-07-27 0:24 ` David Rientjes
2009-07-27 7:08 ` Pekka Enberg
2009-07-27 7:08 ` Pekka Enberg
2009-07-27 9:37 ` David Rientjes
2009-07-27 9:37 ` David Rientjes
2009-07-27 17:20 ` Christoph Lameter
2009-07-27 17:20 ` Christoph Lameter
2009-07-27 18:16 ` David Rientjes
2009-07-27 18:16 ` David Rientjes
2009-07-27 21:43 ` Christoph Lameter
2009-07-27 21:43 ` Christoph Lameter
2009-07-27 22:38 ` David Rientjes
2009-07-06 23:57 2.6.31-rc2: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
2009-07-07 0:00 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-07-07 0:00 ` Rafael J. Wysocki
2009-07-07 1:05 ` Larry Finger
2009-07-07 1:05 ` Larry Finger
2009-07-07 6:29 ` David Rientjes
2009-07-07 6:29 ` David Rientjes
2009-07-07 6:57 ` Pekka Enberg
2009-07-07 6:57 ` Pekka Enberg
2009-07-08 13:18 ` Larry Finger
2009-07-08 13:18 ` Larry Finger
2009-06-29 0:26 2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 16:51 ` Larry Finger
2009-06-29 16:51 ` Larry Finger
2009-06-29 23:15 ` Rafael J. Wysocki
2009-06-29 23:15 ` Rafael J. Wysocki
2009-06-29 23:47 ` David Rientjes
2009-06-29 23:47 ` David Rientjes
2009-06-30 2:06 ` Larry Finger
2009-06-30 2:06 ` Larry Finger
2009-06-30 5:47 ` David Rientjes
2009-06-30 6:55 ` Pekka Enberg
2009-06-30 6:55 ` Pekka Enberg
2009-06-30 7:47 ` David Rientjes
2009-06-30 7:47 ` David Rientjes
2009-06-30 8:24 ` Pekka Enberg
2009-06-30 8:24 ` Pekka Enberg
2009-06-30 14:38 ` Larry Finger
2009-06-30 20:25 ` David Rientjes
2009-06-30 20:25 ` David Rientjes
2009-06-30 14:32 ` Christoph Lameter
2009-06-30 14:32 ` Christoph Lameter
2009-06-30 15:01 ` Pekka Enberg
2009-06-30 15:14 ` Christoph Lameter
2009-06-30 15:14 ` Christoph Lameter
2009-06-30 20:04 ` David Rientjes
2009-06-30 20:04 ` David Rientjes
2009-06-30 21:05 ` Christoph Lameter
2009-06-30 21:05 ` Christoph Lameter
2009-06-30 21:15 ` David Rientjes
2009-06-30 21:15 ` David Rientjes
2009-06-30 21:23 ` Christoph Lameter
2009-06-30 21:23 ` Christoph Lameter
2009-06-30 21:52 ` David Rientjes
2009-06-30 21:52 ` David Rientjes
2009-06-30 22:18 ` Christoph Lameter
2009-06-30 22:18 ` Christoph Lameter
2009-07-01 5:53 ` Pekka Enberg
2009-07-02 17:18 ` David Rientjes
2009-07-02 17:18 ` David Rientjes
2009-07-03 7:23 ` Pekka Enberg
2009-07-03 7:23 ` Pekka Enberg
2009-06-07 9:47 2.6.30-rc8-git4: Reported regressions from 2.6.29 Rafael J. Wysocki
2009-06-07 9:52 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-06-07 9:52 ` Rafael J. Wysocki
2009-06-07 13:10 ` Larry Finger
2009-06-07 13:10 ` Larry Finger
2009-06-07 13:40 ` Pekka Enberg
2009-06-07 13:40 ` Pekka Enberg
2009-06-07 14:19 ` Rik van Riel
2009-06-07 14:19 ` Rik van Riel
2009-06-07 14:32 ` Pekka Enberg
2009-06-07 14:32 ` Pekka Enberg
2009-06-07 16:35 ` Larry Finger
2009-06-07 16:35 ` Larry Finger
2009-06-08 8:32 ` KAMEZAWA Hiroyuki
2009-06-08 8:32 ` KAMEZAWA Hiroyuki
2009-06-08 17:20 ` Larry Finger
2009-06-08 17:20 ` Larry Finger
2009-06-08 10:17 ` Mel Gorman
2009-06-08 10:17 ` Mel Gorman
2009-06-08 10:52 ` Pekka Enberg
2009-06-08 10:52 ` Pekka Enberg
2009-06-08 11:03 ` Mel Gorman
2009-06-08 11:03 ` Mel Gorman
2009-06-08 13:58 ` Pekka J Enberg
2009-06-08 13:58 ` Pekka J Enberg
2009-06-08 14:12 ` Mel Gorman
2009-06-08 14:12 ` Mel Gorman
2009-06-08 14:42 ` Christoph Lameter
2009-06-08 14:42 ` Christoph Lameter
2009-06-09 7:06 ` Pekka Enberg
2009-06-09 7:06 ` Pekka Enberg
2009-06-09 7:54 ` David Rientjes
2009-06-09 7:54 ` David Rientjes
2009-06-09 7:58 ` Pekka Enberg
2009-06-09 8:14 ` David Rientjes
2009-06-09 8:14 ` David Rientjes
2009-06-09 8:28 ` Pekka Enberg
2009-06-09 8:28 ` Pekka Enberg
2009-06-10 14:41 ` Larry Finger
2009-06-10 15:44 ` Pekka Enberg
2009-06-10 15:49 ` Pekka Enberg
2009-06-10 15:49 ` Pekka Enberg
2009-06-10 15:52 ` Johannes Berg
2009-06-10 15:52 ` Johannes Berg
2009-06-10 16:06 ` Pekka Enberg
2009-06-10 16:06 ` Pekka Enberg
2009-06-10 16:16 ` Pekka Enberg
2009-06-10 16:16 ` Pekka Enberg
2009-06-10 16:10 ` Larry Finger
2009-06-10 16:10 ` Larry Finger
2009-06-11 14:41 ` Christoph Lameter
2009-06-11 14:41 ` Christoph Lameter
2009-06-11 15:09 ` Pekka Enberg
2009-06-11 15:09 ` Pekka Enberg
2009-06-11 18:41 ` Johannes Berg
2009-06-11 18:41 ` Johannes Berg
2009-06-10 15:56 ` Mel Gorman
2009-06-10 15:56 ` Mel Gorman
2009-06-10 18:03 ` Pekka Enberg
2009-06-10 18:03 ` Pekka Enberg
2009-06-09 7:50 ` Pekka Enberg
2009-06-09 7:50 ` Pekka Enberg
2009-06-08 13:20 ` Rik van Riel
2009-06-08 13:20 ` Rik van Riel
2009-06-08 13:35 ` Mel Gorman
2009-06-08 13:35 ` Mel Gorman
2009-06-08 13:34 ` Larry Finger
2009-05-30 19:29 2.6.30-rc7-git4: Reported regressions from 2.6.29 Rafael J. Wysocki
2009-05-30 19:37 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-05-30 19:37 ` Rafael J. Wysocki
2009-05-24 19:06 2.6.30-rc7: Reported regressions from 2.6.29 Rafael J. Wysocki
2009-05-24 19:11 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-05-24 19:11 ` Rafael J. Wysocki
2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-05-16 19:20 ` Rafael J. Wysocki
2009-05-16 23:36 ` Andrew Morton
2009-05-16 23:36 ` Andrew Morton
2009-05-17 23:16 ` Larry Finger
2009-05-17 23:16 ` Larry Finger
2009-05-18 6:31 ` Pekka Enberg
2009-05-18 6:31 ` Pekka Enberg
2009-05-21 13:21 ` Larry Finger
2009-05-21 13:21 ` Larry Finger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.