linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.6.30-rc6: Reported regressions from 2.6.29
@ 2009-05-16 19:14 Rafael J. Wysocki
  2009-05-16 19:14 ` [Bug #13068] Lockdep warining in inotify_dev_queue_event Rafael J. Wysocki
                   ` (41 more replies)
  0 siblings, 42 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:14 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Adrian Bunk, 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 from 2.6.29, 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 from 2.6.29, 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-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=13329
Subject		: cifs_close: NULL pointer dereference
Submitter	: Luca Tettamanti <kronos.it@gmail.com>
Date		: 2009-05-16 16:28 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124249133701702&w=4


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 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13327
Subject		: Regression: 2.6.30-rc5 and rt2x00 / rt2500pci
Submitter	: Ken Lewis <kennylewis@gmail.com>
Date		: 2009-05-15 14:40 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124239988223614&w=4
Handled-By	: John W. Linville <linville@tuxdriver.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13326
Subject		: Null pointer dereference in rtc-cmos driver
Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
Date		: 2009-05-14 16:16 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124231783704696&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13325
Subject		: 2.6.30-rc kills my box hard - and lockdep chains
Submitter	: Jonathan Corbet <corbet@lwn.net>
Date		: 2009-05-14 15:49 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124231630701394&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13324
Subject		: panic when loading oprofile
Submitter	: Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date		: 2009-05-13 22:30 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=124225384311631&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13323
Subject		: 2.6.30-rc deadline scheduler performance regression for iozone over NFS
Submitter	: Jeff Moyer <jmoyer@redhat.com>
Date		: 2009-04-23 14:01 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049547915450&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13321
Subject		: kernel crash with NULL pointer when boot
Submitter	: Martin Bammer <mrb74@gmx.at>
Date		: 2009-05-16 12:37 (1 days old)
References	: http://lkml.org/lkml/2009/5/16/100


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>


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 (17 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 (3 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13298
Subject		: modprobe ipmi_si hangs under 2.6.30-rc5
Submitter	: Ferenc Wagner <wferi@niif.hu>
Date		: 2009-05-12 21:28 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=124216379407177&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
Subject		: kernel panic -  not syncing : fatel exception in interupt
Submitter	: rob <rob1@housetosell.net>
Date		: 2009-05-12 19:34 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13296
Subject		: Lockdep violation at cleanup_workqueue_thread during suspend
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2009-05-12 7:59 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=124211522525625&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject		: i915: drm: xorg leaks drm objects massively
Submitter	: Sergei Trofimovich <slyich@gmail.com>
Date		: 2009-05-10 19:56 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13293
Subject		: Kernel BUG under network load with gianfar
Submitter	: Michael Guntsche <mike@it-loops.com>
Date		: 2009-05-03 13:36 (14 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0fd56bb5be6455d0d42241e65aed057244665e5e
References	: http://marc.info/?l=linux-kernel&m=124135824600924&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13285
Subject		: INTELFB: Colors display incorrectly
Submitter	: Dean Menezes <samanddeanus@yahoo.com>
Date		: 2009-05-12 01:40 (5 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13250
Subject		: Side channel of Intel HDA chip doesn't work anymore, did work with 2.6.29
Submitter	: Andreas Juch <kernel-bt@juch.cc>
Date		: 2009-05-05 10:14 (12 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13245
Subject		: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2009-05-04 16:56 (13 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13188
Subject		: horizontal strips of the screen frozen
Submitter	: Justin Madru <jdm64@gawab.com>
Date		: 2009-04-24 20:59 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=280b713b5b0fd84cf2469098aee88acbb5de859c
References	: http://marc.info/?l=linux-kernel&m=124060685315937&w=4


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 (26 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=13179
Subject		: CD-R: wodim intermittent failures
Submitter	: Andy Isaacson <adi@hexapodia.org>
Date		: 2009-04-21 1:52 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124027879214231&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13177
Subject		: 2.6.30-rc2-git7 build problem
Submitter	: Martin Knoblauch <spamtrap@knobisoft.de>
Date		: 2009-04-21 13:39 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124032163602132&w=4
		  http://lkml.org/lkml/2009/4/27/56


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13171
Subject		: 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
Submitter	: Alex Bennee <kernel-hacker@bennee.com>
Date		: 2009-04-19 6:27 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=124022460014812&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13156
Subject		: keyboard backlight brightness up/down keys doesn't work
Submitter	: Thomas Meyer <thomas@m3y3r.de>
Date		: 2009-04-23 20:46 (24 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
Submitter	: fanderay <fanderay4@googlemail.com>
Date		: 2009-04-22 14:39 (25 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13126
Subject		: BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
Date		: 2009-04-15 12:43 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=123979949820538&w=4


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13118
Subject		: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
Submitter	: Jeff Chua <jeff.chua.linux@gmail.com>
Date		: 2009-04-10 16:05 (37 days old)
References	: http://lkml.org/lkml/2009/4/10/111
		  http://lkml.org/lkml/2009/4/25/83
Handled-By	: Eric Dumazet <dada1@cosmosbay.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13116
Subject		: Can't boot with nosmp
Submitter	: Stephen Hemminger <shemminger@vyatta.com>
Date		: 2009-04-15 4:18 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=123976917817920&w=4
Handled-By	: Dan Williams <dan.j.williams@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13107
Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
Submitter	: Kumar Gala <galak@kernel.crashing.org>
Date		: 2009-04-09 15:43 (38 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
		  http://lkml.org/lkml/2009/4/10/193
Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13069
Subject		: regression in 2.6.29-git3 on SH/Dreamcast
Submitter	: Adrian McMenamin <adrian@newgolddream.dyndns.info>
Date		: 2009-03-29 19:04 (49 days old)
References	: http://marc.info/?l=linux-kernel&m=123835353115372&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13068
Subject		: Lockdep warining in inotify_dev_queue_event
Submitter	: Sachin Sant <sachinp@in.ibm.com>
Date		: 2009-04-05 12:37 (42 days old)
References	: http://marc.info/?l=linux-kernel&m=123893439229272&w=4


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13125
Subject		: active uvcvideo breaks over suspend
Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date		: 2009-04-15 10:12 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=123979009508840&w=4
Handled-By	: Ming Lei <tom.leiming@gmail.com>
Patch		: http://lkml.org/lkml/2009/4/18/5


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13122
Subject		: reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)
Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
Date		: 2009-04-16 19:23 (31 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d984561b326cd0fe0d1183d11b9b4fa1d011d21d
References	: http://marc.info/?l=linux-kernel&m=123990989515105&w=4
Handled-By	: Jeff Mahoney <jeffm@suse.com>
Patch		: http://lkml.org/lkml/2009/5/10/91


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 (36 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>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21061
		  http://bugzilla.kernel.org/attachment.cgi?id=21282


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 from 2.6.29,
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] 171+ messages in thread

* [Bug #13068] Lockdep warining in inotify_dev_queue_event
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
@ 2009-05-16 19:14 ` Rafael J. Wysocki
  2009-05-17  6:35   ` Ingo Molnar
  2009-05-16 19:20 ` [Bug #13069] regression in 2.6.29-git3 on SH/Dreamcast Rafael J. Wysocki
                   ` (40 subsequent siblings)
  41 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:14 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Marcin Slusarz, Sachin Sant

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=13068
Subject		: Lockdep warining in inotify_dev_queue_event
Submitter	: Sachin Sant <sachinp@in.ibm.com>
Date		: 2009-04-05 12:37 (42 days old)
References	: http://marc.info/?l=linux-kernel&m=123893439229272&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13069] regression in 2.6.29-git3 on SH/Dreamcast
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
  2009-05-16 19:14 ` [Bug #13068] Lockdep warining in inotify_dev_queue_event Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13118] iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 Rafael J. Wysocki
                   ` (39 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Adrian McMenamin, Manuel Lauss

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=13069
Subject		: regression in 2.6.29-git3 on SH/Dreamcast
Submitter	: Adrian McMenamin <adrian@newgolddream.dyndns.info>
Date		: 2009-03-29 19:04 (49 days old)
References	: http://marc.info/?l=linux-kernel&m=123835353115372&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (4 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13109] High latency on /sys/class/thermal Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-17 19:13   ` Linus Torvalds
  2009-05-16 19:20 ` [Bug #13125] active uvcvideo breaks over suspend Rafael J. Wysocki
                   ` (35 subsequent siblings)
  41 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Andrew Morton, Kumar Gala, Linus Torvalds,
	Oleg Nesterov, Sukadev Bhattiprolu

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=13107
Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
Submitter	: Kumar Gala <galak@kernel.crashing.org>
Date		: 2009-04-09 15:43 (38 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
		  http://lkml.org/lkml/2009/4/10/193
Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13118] iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
  2009-05-16 19:14 ` [Bug #13068] Lockdep warining in inotify_dev_queue_event Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13069] regression in 2.6.29-git3 on SH/Dreamcast Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-17  6:06   ` Jeff Chua
  2009-05-16 19:20 ` [Bug #13116] Can't boot with nosmp Rafael J. Wysocki
                   ` (38 subsequent siblings)
  41 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Eric Dumazet, Jeff Chua, Patrick McHardy,
	Stephen Hemminger

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=13118
Subject		: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
Submitter	: Jeff Chua <jeff.chua.linux@gmail.com>
Date		: 2009-04-10 16:05 (37 days old)
References	: http://lkml.org/lkml/2009/4/10/111
		  http://lkml.org/lkml/2009/4/25/83
Handled-By	: Eric Dumazet <dada1@cosmosbay.com>



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13109] High latency on /sys/class/thermal
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (3 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13116] Can't boot with nosmp Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1 Rafael J. Wysocki
                   ` (36 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 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 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=13109
Subject		: High latency on /sys/class/thermal
Submitter	: Tiago Simões Batista <tiagosbatista@gmail.com>
Date		: 2009-04-11 14:56 (36 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>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21061
		  http://bugzilla.kernel.org/attachment.cgi?id=21282



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13116] Can't boot with nosmp
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (2 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13118] iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13109] High latency on /sys/class/thermal Rafael J. Wysocki
                   ` (37 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Dan Williams, Stephen Hemminger

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=13116
Subject		: Can't boot with nosmp
Submitter	: Stephen Hemminger <shemminger@vyatta.com>
Date		: 2009-04-15 4:18 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=123976917817920&w=4
Handled-By	: Dan Williams <dan.j.williams@intel.com>



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13119] Trouble with make-install from a NFS mount
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (6 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13125] active uvcvideo breaks over suspend Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13122] reiserfs_delete_xattrs: Couldn't delete all xattrs (-13) Rafael J. Wysocki
                   ` (33 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Gregory Haskins, H. Peter Anvin, Sam Ravnborg

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=13119
Subject		: Trouble with make-install from a NFS mount
Submitter	: Gregory Haskins <ghaskins@novell.com>
Date		: 2009-04-14 21:32 (33 days old)
References	: http://marc.info/?l=linux-kernel&m=123974482327044&w=4
Handled-By	: H. Peter Anvin <hpa@zytor.com>



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13122] reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (7 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13119] Trouble with make-install from a NFS mount Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-17 19:16   ` Linus Torvalds
  2009-05-16 19:20 ` [Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs Rafael J. Wysocki
                   ` (32 subsequent siblings)
  41 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Alexander Beregalov, Jeff Mahoney, Linus Torvalds

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=13122
Subject		: reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)
Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
Date		: 2009-04-16 19:23 (31 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d984561b326cd0fe0d1183d11b9b4fa1d011d21d
References	: http://marc.info/?l=linux-kernel&m=123990989515105&w=4
Handled-By	: Jeff Mahoney <jeffm@suse.com>
Patch		: http://lkml.org/lkml/2009/5/10/91



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13125] active uvcvideo breaks over suspend
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (5 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1 Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13119] Trouble with make-install from a NFS mount Rafael J. Wysocki
                   ` (34 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Alan Jenkins, Laurent Pinchart, Ming Lei

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=13125
Subject		: active uvcvideo breaks over suspend
Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date		: 2009-04-15 10:12 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=123979009508840&w=4
Handled-By	: Ming Lei <tom.leiming@gmail.com>
Patch		: http://lkml.org/lkml/2009/4/18/5



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13156] keyboard backlight brightness up/down keys doesn't work
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (10 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13177] 2.6.30-rc2-git7 build problem Rafael J. Wysocki
                   ` (29 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Dmitry Torokhov, Ingo Molnar, Thomas Meyer

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=13156
Subject		: keyboard backlight brightness up/down keys doesn't work
Submitter	: Thomas Meyer <thomas@m3y3r.de>
Date		: 2009-04-23 20:46 (24 days old)



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (9 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13156] keyboard backlight brightness up/down keys doesn't work Rafael J. Wysocki
                   ` (30 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, fanderay, Heiko Carstens, Len Brown,
	Lin Ming, Linus Torvalds, Mattia Dongili

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=13148
Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
Submitter	: fanderay <fanderay4@googlemail.com>
Date		: 2009-04-22 14:39 (25 days old)



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (8 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13122] reiserfs_delete_xattrs: Couldn't delete all xattrs (-13) Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present Rafael J. Wysocki
                   ` (31 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Alexander Beregalov, Philip Copeland

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=13126
Subject		: BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
Date		: 2009-04-15 12:43 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=123979949820538&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13171] 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (13 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13179] CD-R: wodim intermittent failures Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Rafael J. Wysocki
                   ` (26 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alex Bennee

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=13171
Subject		: 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
Submitter	: Alex Bennee <kernel-hacker@bennee.com>
Date		: 2009-04-19 6:27 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=124022460014812&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13179] CD-R: wodim intermittent failures
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (12 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13177] 2.6.30-rc2-git7 build problem Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 22:51   ` Robert Hancock
  2009-05-16 19:20 ` [Bug #13171] 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption Rafael J. Wysocki
                   ` (27 subsequent siblings)
  41 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Andy Isaacson, Joerg Schilling, Robert Hancock

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=13179
Subject		: CD-R: wodim intermittent failures
Submitter	: Andy Isaacson <adi@hexapodia.org>
Date		: 2009-04-21 1:52 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124027879214231&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (14 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13171] 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13188] horizontal strips of the screen frozen Rafael J. Wysocki
                   ` (25 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 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 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=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 (26 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] 171+ messages in thread

* [Bug #13177] 2.6.30-rc2-git7 build problem
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (11 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13156] keyboard backlight brightness up/down keys doesn't work Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-18 14:05   ` Martin Knoblauch
  2009-05-16 19:20 ` [Bug #13179] CD-R: wodim intermittent failures Rafael J. Wysocki
                   ` (28 subsequent siblings)
  41 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Martin Knoblauch

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=13177
Subject		: 2.6.30-rc2-git7 build problem
Submitter	: Martin Knoblauch <spamtrap@knobisoft.de>
Date		: 2009-04-21 13:39 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124032163602132&w=4
		  http://lkml.org/lkml/2009/4/27/56



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13245] possible circular locking dependency detected
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (16 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13188] horizontal strips of the screen frozen Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-17  3:22   ` Ming Lei
  2009-05-16 19:20 ` [Bug #13250] Side channel of Intel HDA chip doesn't work anymore, did work with 2.6.29 Rafael J. Wysocki
                   ` (23 subsequent siblings)
  41 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 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 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=13245
Subject		: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2009-05-04 16:56 (13 days old)



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13188] horizontal strips of the screen frozen
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (15 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-18 16:35   ` Justin Madru
  2009-05-16 19:20 ` [Bug #13245] possible circular locking dependency detected Rafael J. Wysocki
                   ` (24 subsequent siblings)
  41 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Eric Anholt, Justin Madru

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=13188
Subject		: horizontal strips of the screen frozen
Submitter	: Justin Madru <jdm64@gawab.com>
Date		: 2009-04-24 20:59 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=280b713b5b0fd84cf2469098aee88acbb5de859c
References	: http://marc.info/?l=linux-kernel&m=124060685315937&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13250] Side channel of Intel HDA chip doesn't work anymore, did work with 2.6.29
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (17 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13245] possible circular locking dependency detected Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13293] Kernel BUG under network load with gianfar Rafael J. Wysocki
                   ` (22 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andreas Juch

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=13250
Subject		: Side channel of Intel HDA chip doesn't work anymore, did work with 2.6.29
Submitter	: Andreas Juch <kernel-bt@juch.cc>
Date		: 2009-05-05 10:14 (12 days old)



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13285] INTELFB: Colors display incorrectly
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (19 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13293] Kernel BUG under network load with gianfar Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13296] Lockdep violation at cleanup_workqueue_thread during suspend Rafael J. Wysocki
                   ` (20 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Dean Menezes

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=13285
Subject		: INTELFB: Colors display incorrectly
Submitter	: Dean Menezes <samanddeanus@yahoo.com>
Date		: 2009-05-12 01:40 (5 days old)



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13293] Kernel BUG under network load with gianfar
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (18 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13250] Side channel of Intel HDA chip doesn't work anymore, did work with 2.6.29 Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13285] INTELFB: Colors display incorrectly Rafael J. Wysocki
                   ` (21 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Andy Fleming, David S. Miller, Michael Guntsche

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=13293
Subject		: Kernel BUG under network load with gianfar
Submitter	: Michael Guntsche <mike@it-loops.com>
Date		: 2009-05-03 13:36 (14 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0fd56bb5be6455d0d42241e65aed057244665e5e
References	: http://marc.info/?l=linux-kernel&m=124135824600924&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13294] i915: drm: xorg leaks drm objects massively
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (22 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13297] kernel panic - not syncing : fatel exception in interupt Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13306] hibernate slow on _second_ run Rafael J. Wysocki
                   ` (17 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Sergei Trofimovich

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=13294
Subject		: i915: drm: xorg leaks drm objects massively
Submitter	: Sergei Trofimovich <slyich@gmail.com>
Date		: 2009-05-10 19:56 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13297] kernel panic -  not syncing : fatel exception in interupt
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (21 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13296] Lockdep violation at cleanup_workqueue_thread during suspend Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13294] i915: drm: xorg leaks drm objects massively Rafael J. Wysocki
                   ` (18 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, rob

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=13297
Subject		: kernel panic -  not syncing : fatel exception in interupt
Submitter	: rob <rob1@housetosell.net>
Date		: 2009-05-12 19:34 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13296] Lockdep violation at cleanup_workqueue_thread during suspend
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (20 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13285] INTELFB: Colors display incorrectly Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13297] kernel panic - not syncing : fatel exception in interupt Rafael J. Wysocki
                   ` (19 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Rusty Russell, Zdenek Kabelac

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=13296
Subject		: Lockdep violation at cleanup_workqueue_thread during suspend
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2009-05-12 7:59 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=124211522525625&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13298] modprobe ipmi_si hangs under 2.6.30-rc5
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (24 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13306] hibernate slow on _second_ run Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
                   ` (15 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Corey Minyard, Ferenc Wagner

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=13298
Subject		: modprobe ipmi_si hangs under 2.6.30-rc5
Submitter	: Ferenc Wagner <wferi@niif.hu>
Date		: 2009-05-12 21:28 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=124216379407177&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13306] hibernate slow on _second_ run
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (23 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13294] i915: drm: xorg leaks drm objects massively Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13298] modprobe ipmi_si hangs under 2.6.30-rc5 Rafael J. Wysocki
                   ` (16 subsequent siblings)
  41 siblings, 0 replies; 171+ 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

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=13306
Subject		: hibernate slow on _second_ run
Submitter	: Johannes Berg <johannes@sipsolutions.net>
Date		: 2009-05-14 09:34 (3 days old)



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13318] AGP doesn't work anymore on nforce2
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (26 preceding siblings ...)
  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 19:20 ` [Bug #13323] 2.6.30-rc deadline scheduler performance regression for iozone over NFS Rafael J. Wysocki
                   ` (13 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 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 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=13318
Subject		: AGP doesn't work anymore on nforce2
Submitter	: Karsten Mehrhoff <kawime@gmx.de>
Date		: 2009-04-30 8:51 (17 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] 171+ 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
                   ` (25 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13298] modprobe ipmi_si hangs under 2.6.30-rc5 Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 23:36   ` Andrew Morton
  2009-05-21 13:21   ` Larry Finger
  2009-05-16 19:20 ` [Bug #13318] AGP doesn't work anymore on nforce2 Rafael J. Wysocki
                   ` (14 subsequent siblings)
  41 siblings, 2 replies; 171+ 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] 171+ messages in thread

* [Bug #13324] panic when loading oprofile
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (29 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13321] kernel crash with NULL pointer when boot Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13327] Regression: 2.6.30-rc5 and rt2x00 / rt2500pci Rafael J. Wysocki
                   ` (10 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Andi Kleen, Brandeburg, Jesse

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=13324
Subject		: panic when loading oprofile
Submitter	: Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date		: 2009-05-13 22:30 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=124225384311631&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13323] 2.6.30-rc deadline scheduler performance regression for iozone over NFS
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (27 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13318] AGP doesn't work anymore on nforce2 Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13321] kernel crash with NULL pointer when boot Rafael J. Wysocki
                   ` (12 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, J. Bruce Fields, Jeff Moyer, Jens Axboe,
	Jim Rees, Olga Kornievskaia, Trond Myklebust

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=13323
Subject		: 2.6.30-rc deadline scheduler performance regression for iozone over NFS
Submitter	: Jeff Moyer <jmoyer@redhat.com>
Date		: 2009-04-23 14:01 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049547915450&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13321] kernel crash with NULL pointer when boot
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (28 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13323] 2.6.30-rc deadline scheduler performance regression for iozone over NFS Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13324] panic when loading oprofile Rafael J. Wysocki
                   ` (11 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Martin Bammer

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=13321
Subject		: kernel crash with NULL pointer when boot
Submitter	: Martin Bammer <mrb74@gmx.at>
Date		: 2009-05-16 12:37 (1 days old)
References	: http://lkml.org/lkml/2009/5/16/100



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13326] Null pointer dereference in rtc-cmos driver
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (32 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13325] 2.6.30-rc kills my box hard - and lockdep chains Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13329] cifs_close: NULL pointer dereference Rafael J. Wysocki
                   ` (7 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ozan Çağlayan

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=13326
Subject		: Null pointer dereference in rtc-cmos driver
Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
Date		: 2009-05-14 16:16 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124231783704696&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13327] Regression: 2.6.30-rc5 and rt2x00 / rt2500pci
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (30 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13324] panic when loading oprofile Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13325] 2.6.30-rc kills my box hard - and lockdep chains Rafael J. Wysocki
                   ` (9 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, John W. Linville, Ken Lewis

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=13327
Subject		: Regression: 2.6.30-rc5 and rt2x00 / rt2500pci
Submitter	: Ken Lewis <kennylewis@gmail.com>
Date		: 2009-05-15 14:40 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124239988223614&w=4
Handled-By	: John W. Linville <linville@tuxdriver.com>



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13325] 2.6.30-rc kills my box hard - and lockdep chains
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (31 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13327] Regression: 2.6.30-rc5 and rt2x00 / rt2500pci Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13326] Null pointer dereference in rtc-cmos driver Rafael J. Wysocki
                   ` (8 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Kernel Testers List, Jonathan Corbet, Peter Zijlstra

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=13325
Subject		: 2.6.30-rc kills my box hard - and lockdep chains
Submitter	: Jonathan Corbet <corbet@lwn.net>
Date		: 2009-05-14 15:49 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124231630701394&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (34 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13329] cifs_close: NULL pointer dereference Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 23:44 ` 2.6.30-rc6: Reported regressions from 2.6.29 Linus Torvalds
                   ` (5 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 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 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=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 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* [Bug #13329] cifs_close: NULL pointer dereference
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (33 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13326] Null pointer dereference in rtc-cmos driver Rafael J. Wysocki
@ 2009-05-16 19:20 ` Rafael J. Wysocki
  2009-05-16 19:20 ` [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear Rafael J. Wysocki
                   ` (6 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Luca Tettamanti

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=13329
Subject		: cifs_close: NULL pointer dereference
Submitter	: Luca Tettamanti <kronos.it@gmail.com>
Date		: 2009-05-16 16:28 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124249133701702&w=4



^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13179] CD-R: wodim intermittent failures
  2009-05-16 19:20 ` [Bug #13179] CD-R: wodim intermittent failures Rafael J. Wysocki
@ 2009-05-16 22:51   ` Robert Hancock
  0 siblings, 0 replies; 171+ messages in thread
From: Robert Hancock @ 2009-05-16 22:51 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Kernel Testers List, Andy Isaacson,
	Joerg Schilling

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=13179
> Subject		: CD-R: wodim intermittent failures
> Submitter	: Andy Isaacson <adi@hexapodia.org>
> Date		: 2009-04-21 1:52 (26 days old)
> References	: http://marc.info/?l=linux-kernel&m=124027879214231&w=4

Last I heard the reporter was going to attempt to bisect the problem to 
see when the spurious udev events he was seeing started happening..

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-05-16 19:20 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
@ 2009-05-16 23:36   ` Andrew Morton
  2009-05-17 23:16     ` Larry Finger
  2009-05-18  6:31     ` Pekka Enberg
  2009-05-21 13:21   ` Larry Finger
  1 sibling, 2 replies; 171+ 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] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (35 preceding siblings ...)
  2009-05-16 19:20 ` [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear Rafael J. Wysocki
@ 2009-05-16 23:44 ` Linus Torvalds
  2009-05-17  0:01 ` Linus Torvalds
                   ` (4 subsequent siblings)
  41 siblings, 0 replies; 171+ messages in thread
From: Linus Torvalds @ 2009-05-16 23:44 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
	Natalie Protasevich, Shirish Pargaonkar, Steve French



On Sat, 16 May 2009, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13329
> Subject		: cifs_close: NULL pointer dereference
> Submitter	: Luca Tettamanti <kronos.it@gmail.com>
> Date		: 2009-05-16 16:28 (1 days old)
> References	: http://marc.info/?l=linux-kernel&m=124249133701702&w=4

The code in this one decodes to

   0:	89 ef                	mov    %ebp,%edi
   2:	45 31 e4             	xor    %r12d,%r12d
   5:	e8 f3 63 e7 df       	callq  0xffffffffdfe763fd
   a:	41 bd 0a 00 00 00    	mov    $0xa,%r13d
  10:	48 c7 c7 c4 6b 61 a0 	mov    $0xffffffffa0616bc4,%rdi
  17:	e8 b3 7f e7 df       	callq  0xffffffffdfe77fcf
  1c:	48 8b 53 10          	mov    0x10(%rbx),%rdx
  20:	48 8b 43 18          	mov    0x18(%rbx),%rax
  24:	48 c7 c7 c4 6b 61 a0 	mov    $0xffffffffa0616bc4,%rdi
  2b:*	48 89 42 08          	mov    %rax,0x8(%rdx)     <-- trapping instruction
  2f:	48 89 10             	mov    %rdx,(%rax)
  32:	48 c7 43 18 00 02 20 	movq   $0x200200,0x18(%rbx)
  39:	00 
  3a:	48 8b 13             	mov    (%rbx),%rdx

which seems to match (modulo normal compiler issues):

        movq    -56(%rbp), %rdi # %sfp,
        call    mutex_unlock    #
        movq    $GlobalSMBSeslock, %rdi #,
        call    _write_lock     #
        movq    16(%rbx), %rdx  # <variable>.flist.next, D.47095
        movq    24(%rbx), %rax  # <variable>.flist.prev, D.47094
        movq    %rax, 8(%rdx)   # D.47094, <variable>.prev
        movq    %rdx, (%rax)    # D.47095, <variable>.next
        movq    $2097664, 24(%rbx)      #, <variable>.flist.prev
        movq    (%rbx), %rdx    # <variable>.tlist.next, D.47099

which I think ends up being this code:

                mutex_unlock(&pSMBFile->lock_mutex);
        
                write_lock(&GlobalSMBSeslock);
                list_del(&pSMBFile->flist);   

ie 'pSMBFile->flist.next' looks to be zero. Either uninitialized or 
perhaps a use-after-free thing..

We have commit 90e4ee5d31 "[CIFS] Fix double list addition in cifs posix 
open code" that touches exactly that 'flist' thing, and removes the thing 
that adds it to the list because it's _claimed_ to be a "double add". It 
probably wasn't.

The bug reporter says:

> The machine is running kernel from git (1d80cac - almost rc6)

and that 1d80cac is _after_ 90e4ee5d31. So I do think 90e4ee5d31 is buggy.

		Linus

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (36 preceding siblings ...)
  2009-05-16 23:44 ` 2.6.30-rc6: Reported regressions from 2.6.29 Linus Torvalds
@ 2009-05-17  0:01 ` Linus Torvalds
  2009-05-17  0:15   ` Kay Sievers
  2009-05-17  0:32   ` Ozan Çağlayan
  2009-05-17  7:33 ` Ingo Molnar
                   ` (3 subsequent siblings)
  41 siblings, 2 replies; 171+ messages in thread
From: Linus Torvalds @ 2009-05-17  0:01 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
	Natalie Protasevich, Greg Kroah-Hartman, Kay Sievers



On Sat, 16 May 2009, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13326
> Subject		: Null pointer dereference in rtc-cmos driver
> Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
> Date		: 2009-05-14 16:16 (3 days old)
> References	: http://marc.info/?l=linux-kernel&m=124231783704696&w=4

Ok, I'm of two minds on this one.

The thing that triggers it is a module that is both a module _and_ 
compiled in (ie the same kernel compiled twice, and the stale module kept 
around). I can see how it happens, and we should react more gracefully to 
it, but at the same time I can't really bring myself to care deeply.

What is going on is that the cmos-rtc.c driver does this:

	#ifdef  CONFIG_PNP
	        pnp_register_driver(&cmos_pnp_driver);
	#endif

	        if (!cmos_rtc.dev)
	                retval = platform_driver_probe(&cmos_platform_driver,
                                               cmos_platform_probe);

	        if (retval == 0)
	                return 0;

	#ifdef  CONFIG_PNP
	        pnp_unregister_driver(&cmos_pnp_driver);
	#endif
	        return retval;

and what happens is that the pnp_register_driver fails when the module 
calls it (because the built-in driver already exists under the same name):

	[   10.428691] Error: Driver 'rtc_cmos' is already registered, aborting...

but the driver doesn't really care whether that succeeded or not, but then 
the platform_driver_probe fails (because the thing is already in use), so 
then it ends up unregistering something that never got registered in the 
first place.

I think this is strictly speaking a bug in driver_unregister(), which is 
too fragile. If you unregister a drivert that wasn't registered, we 
shouldn't oops. 

But we could certainly do it at the rtc-cmos.c level too, and just not 
unregister it if the registration failed. My gut feel is that we should 
aim for the core driver helpers to be less fragile, though - we'll always 
have driver bugs.

Greg?

			Linus

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  0:01 ` Linus Torvalds
@ 2009-05-17  0:15   ` Kay Sievers
  2009-05-17  1:01     ` Kay Sievers
  2009-05-17  0:32   ` Ozan Çağlayan
  1 sibling, 1 reply; 171+ messages in thread
From: Kay Sievers @ 2009-05-17  0:15 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Adrian Bunk,
	Andrew Morton, Natalie Protasevich, Greg Kroah-Hartman

On Sun, May 17, 2009 at 02:01, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

>        [   10.428691] Error: Driver 'rtc_cmos' is already registered, aborting...
>
> but the driver doesn't really care whether that succeeded or not, but then
> the platform_driver_probe fails (because the thing is already in use), so
> then it ends up unregistering something that never got registered in the
> first place.
>
> I think this is strictly speaking a bug in driver_unregister(), which is
> too fragile. If you unregister a drivert that wasn't registered, we
> shouldn't oops.
>
> But we could certainly do it at the rtc-cmos.c level too, and just not
> unregister it if the registration failed. My gut feel is that we should
> aim for the core driver helpers to be less fragile, though - we'll always
> have driver bugs.

In:
 driver_remove_file()
we try to access the private part:
 sysfs_remove_file(&drv->p->kobj, ...
and that is NULL, for an unregistered driver, I would expect.

I'm looking into it.

Kay

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  0:01 ` Linus Torvalds
  2009-05-17  0:15   ` Kay Sievers
@ 2009-05-17  0:32   ` Ozan Çağlayan
  2009-05-17  2:06     ` Linus Torvalds
  1 sibling, 1 reply; 171+ messages in thread
From: Ozan Çağlayan @ 2009-05-17  0:32 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Adrian Bunk,
	Andrew Morton, Natalie Protasevich, Greg Kroah-Hartman,
	Kay Sievers

Linus Torvalds wrote:
>
> Ok, I'm of two minds on this one.
>
> The thing that triggers it is a module that is both a module _and_ 
> compiled in (ie the same kernel compiled twice, and the stale module kept 
> around). I can see how it happens, and we should react more gracefully to 
> it, but at the same time I can't really bring myself to care deeply.
>   

The patch[0] from Andrew fixed the problem.

Thanks,
Ozan Caglayan

[0]: http://marc.info/?l=linux-kernel&m=124251428228049&w=2


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  0:15   ` Kay Sievers
@ 2009-05-17  1:01     ` Kay Sievers
  2009-05-17  2:13       ` Linus Torvalds
  2009-05-17  6:32       ` Ingo Molnar
  0 siblings, 2 replies; 171+ messages in thread
From: Kay Sievers @ 2009-05-17  1:01 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Adrian Bunk,
	Andrew Morton, Natalie Protasevich, Greg Kroah-Hartman

On Sun, 2009-05-17 at 02:15 +0200, Kay Sievers wrote:
> On Sun, May 17, 2009 at 02:01, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> 
> >        [   10.428691] Error: Driver 'rtc_cmos' is already registered, aborting...
> >
> > but the driver doesn't really care whether that succeeded or not, but then
> > the platform_driver_probe fails (because the thing is already in use), so
> > then it ends up unregistering something that never got registered in the
> > first place.
> >
> > I think this is strictly speaking a bug in driver_unregister(), which is
> > too fragile. If you unregister a drivert that wasn't registered, we
> > shouldn't oops.
> >
> > But we could certainly do it at the rtc-cmos.c level too, and just not
> > unregister it if the registration failed. My gut feel is that we should
> > aim for the core driver helpers to be less fragile, though - we'll always
> > have driver bugs.
> 
> In:
>  driver_remove_file()
> we try to access the private part:
>  sysfs_remove_file(&drv->p->kobj, ...
> and that is NULL, for an unregistered driver, I would expect.
> 
> I'm looking into it.

This makes the oops in the driver-core, caused by the rtc driver
unregister, go away. The original issue is also fixed in the rtc driver
itself.

Thanks,
Kay


From: Kay Sievers <kay.sievers@vrfy.org>
Subject: Driver Core: do not oops when driver_unregister() is called for unregistered drivers

Handle the case someone tries to unregister a non-registered driver
more gracefully.

  Error: Driver 'rtc_cmos' is already registered, aborting...
  BUG: unable to handle kernel NULL pointer dereference at 00000018
  [<c01e16ba>] sysfs_remove_file+0x1/0xf

Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---

 driver.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -257,6 +257,8 @@ EXPORT_SYMBOL_GPL(driver_register);
  */
 void driver_unregister(struct device_driver *drv)
 {
+	if (!drv || !drv->p)
+		return;
 	driver_remove_groups(drv, drv->groups);
 	bus_remove_driver(drv);
 }



^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  0:32   ` Ozan Çağlayan
@ 2009-05-17  2:06     ` Linus Torvalds
  0 siblings, 0 replies; 171+ messages in thread
From: Linus Torvalds @ 2009-05-17  2:06 UTC (permalink / raw)
  To: Ozan Çağlayan
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Adrian Bunk,
	Andrew Morton, Natalie Protasevich, Greg Kroah-Hartman,
	Kay Sievers



On Sun, 17 May 2009, Ozan Çağlayan wrote:
> 
> The patch[0] from Andrew fixed the problem.

Yeah, but that's the patch that I think isn't the long-term solution (ie 
other drievrs will do things like this too).

Also, I'm not 100% convinced it's even the right one for cmos-rtc, 
although I can't really judge. The thing is, even if the 
pnp_register_driver() call fails, I'm not at all sure that we shouldn't 
just continue. I suspect we might still want to do the 
platform_driver_probe regardless of any PnP issues.

I dunno. What I _do_ know is that I'd be happier of 

	pnp_register_driver(&driver);
	pnp_unregister_driver(&driver);

always worked without oopsing, regardless of whether the registration 
worked or not. Whether the rtc-cmos driver shold do that is then a 
secondary issue. 

The whole PnP thing has been broken several times, look for example at 
commit 72f22b1eb6ca5e4676a632a04d40d46cb61d4562. That one introduced the 
whole "do the platform driver regardless of any PnP driver issues", which 
makes me suspect we really shouldn't return early just because of some 
random pnp issue.

			Linus

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  1:01     ` Kay Sievers
@ 2009-05-17  2:13       ` Linus Torvalds
  2009-05-17 15:33         ` Greg KH
  2009-05-18  3:48         ` Greg KH
  2009-05-17  6:32       ` Ingo Molnar
  1 sibling, 2 replies; 171+ messages in thread
From: Linus Torvalds @ 2009-05-17  2:13 UTC (permalink / raw)
  To: Kay Sievers
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Adrian Bunk,
	Andrew Morton, Natalie Protasevich, Greg Kroah-Hartman



On Sun, 17 May 2009, Kay Sievers wrote:
> 
> This makes the oops in the driver-core, caused by the rtc driver
> unregister, go away. The original issue is also fixed in the rtc driver
> itself.

I don't think this is sufficient.

> --- a/drivers/base/driver.c
> +++ b/drivers/base/driver.c
> @@ -257,6 +257,8 @@ EXPORT_SYMBOL_GPL(driver_register);
>   */
>  void driver_unregister(struct device_driver *drv)
>  {
> +	if (!drv || !drv->p)
> +		return;
>  	driver_remove_groups(drv, drv->groups);
>  	bus_remove_driver(drv);
>  }

Ok, fine so far, but look at "driver_register()".

It will set drv->p, but then not unset it if it fails! (For a certain 
class of failures)

So for a certain failure pattern, drv->p will point to some stale value. 
Should we not clear drv->p in the "out_unregister" patch?

To confuse the thing more, there are actually "half-way failures" that 
_succeed_ in driver registration, but then return an error code. See that 
whole


	kobject_uevent(&priv->kobj, KOBJ_ADD);
	return error;

case in the "success" path driver_register(). We may return an error 
despite the fact that we actually attached the driver to bus, but 
"add_bind_files()" failed. A caller would be understandable very unhappy.

So I suspect we should do something like the appended (in addition to your 
patch). Comments?

			Linus
---

 drivers/base/bus.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index dc030f1..dcd499d 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -700,8 +700,9 @@ int bus_add_driver(struct device_driver *drv)
 	}
 
 	kobject_uevent(&priv->kobj, KOBJ_ADD);
-	return error;
+	return 0;
 out_unregister:
+	drv->p = NULL;
 	kobject_put(&priv->kobj);
 out_put_bus:
 	bus_put(bus);

^ permalink raw reply related	[flat|nested] 171+ messages in thread

* Re: [Bug #13245] possible circular locking dependency detected
  2009-05-16 19:20 ` [Bug #13245] possible circular locking dependency detected Rafael J. Wysocki
@ 2009-05-17  3:22   ` Ming Lei
  2009-05-17 10:26     ` Rafael J. Wysocki
  0 siblings, 1 reply; 171+ messages in thread
From: Ming Lei @ 2009-05-17  3:22 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Kernel Testers List, Miles Lane

I also can reproduce it on 2.6.30-rc5-next-20090515.

2009/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
> 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=13245
> Subject         : possible circular locking dependency detected
> Submitter       : Miles Lane <miles.lane@gmail.com>
> Date            : 2009-05-04 16:56 (13 days old)
>

-- 
Lei Ming

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13118] iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
  2009-05-16 19:20 ` [Bug #13118] iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 Rafael J. Wysocki
@ 2009-05-17  6:06   ` Jeff Chua
  2009-05-17 10:26     ` Rafael J. Wysocki
  0 siblings, 1 reply; 171+ messages in thread
From: Jeff Chua @ 2009-05-17  6:06 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Dumazet,
	Patrick McHardy, Stephen Hemminger

On Sun, May 17, 2009 at 3:20 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:

> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13118
> Subject         : iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
> Submitter       : Jeff Chua <jeff.chua.linux@gmail.com>
> Date            : 2009-04-10 16:05 (37 days old)
> References      : http://lkml.org/lkml/2009/4/10/111
>                  http://lkml.org/lkml/2009/4/25/83
> Handled-By      : Eric Dumazet <dada1@cosmosbay.com>

Fixed as of Apr 28.

commit 942e4a2bd680c606af0211e64eb216be2e19bf61
Author: Stephen Hemminger <shemminger@vyatta.com>
Date:   Tue Apr 28 22:36:33 2009 -0700

    netfilter: revised locking for x_tables


Thanks,
Jeff.

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  1:01     ` Kay Sievers
  2009-05-17  2:13       ` Linus Torvalds
@ 2009-05-17  6:32       ` Ingo Molnar
  1 sibling, 0 replies; 171+ messages in thread
From: Ingo Molnar @ 2009-05-17  6:32 UTC (permalink / raw)
  To: Kay Sievers
  Cc: Linus Torvalds, Rafael J. Wysocki, Linux Kernel Mailing List,
	Adrian Bunk, Andrew Morton, Natalie Protasevich,
	Greg Kroah-Hartman


* Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Sun, 2009-05-17 at 02:15 +0200, Kay Sievers wrote:
> > On Sun, May 17, 2009 at 02:01, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > 
> > >        [   10.428691] Error: Driver 'rtc_cmos' is already registered, aborting...
> > >
> > > but the driver doesn't really care whether that succeeded or not, but then
> > > the platform_driver_probe fails (because the thing is already in use), so
> > > then it ends up unregistering something that never got registered in the
> > > first place.
> > >
> > > I think this is strictly speaking a bug in driver_unregister(), which is
> > > too fragile. If you unregister a drivert that wasn't registered, we
> > > shouldn't oops.
> > >
> > > But we could certainly do it at the rtc-cmos.c level too, and just not
> > > unregister it if the registration failed. My gut feel is that we should
> > > aim for the core driver helpers to be less fragile, though - we'll always
> > > have driver bugs.
> > 
> > In:
> >  driver_remove_file()
> > we try to access the private part:
> >  sysfs_remove_file(&drv->p->kobj, ...
> > and that is NULL, for an unregistered driver, I would expect.
> > 
> > I'm looking into it.
> 
> This makes the oops in the driver-core, caused by the rtc driver
> unregister, go away. The original issue is also fixed in the rtc driver
> itself.
> 
> Thanks,
> Kay
> 
> 
> From: Kay Sievers <kay.sievers@vrfy.org>
> Subject: Driver Core: do not oops when driver_unregister() is called for unregistered drivers
> 
> Handle the case someone tries to unregister a non-registered driver
> more gracefully.
> 
>   Error: Driver 'rtc_cmos' is already registered, aborting...
>   BUG: unable to handle kernel NULL pointer dereference at 00000018
>   [<c01e16ba>] sysfs_remove_file+0x1/0xf
> 
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>

please also put in a proper Reported-by.

> ---
> 
>  driver.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> --- a/drivers/base/driver.c
> +++ b/drivers/base/driver.c
> @@ -257,6 +257,8 @@ EXPORT_SYMBOL_GPL(driver_register);
>   */
>  void driver_unregister(struct device_driver *drv)
>  {
> +	if (!drv || !drv->p)
> +		return;

I think it would be reasonable to also emit a:

	 WARN_ONCE(1, "unexpected driver unregister!\n");

here - as long as all such cases are a bug. As the imbalance (and a 
bug) is really at the rtc-cmos driver level too and we should not 
condone such pattern, silently.

( Not crashing in the driver core when we can avoid it is nice to 
  have too, of course. )

	Ingo

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13068] Lockdep warining in inotify_dev_queue_event
  2009-05-16 19:14 ` [Bug #13068] Lockdep warining in inotify_dev_queue_event Rafael J. Wysocki
@ 2009-05-17  6:35   ` Ingo Molnar
  2009-05-17  8:13     ` Sachin Sant
  0 siblings, 1 reply; 171+ messages in thread
From: Ingo Molnar @ 2009-05-17  6:35 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Kernel Testers List, Marcin Slusarz,
	Sachin Sant


* 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=13068
> Subject		: Lockdep warining in inotify_dev_queue_event

s/warining/warning

> Submitter	: Sachin Sant <sachinp@in.ibm.com>
> Date		: 2009-04-05 12:37 (42 days old)
> References	: http://marc.info/?l=linux-kernel&m=123893439229272&w=4

i think this might be fixed by:

381a80e: inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positive

already in -rc6.

	Ingo

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (37 preceding siblings ...)
  2009-05-17  0:01 ` Linus Torvalds
@ 2009-05-17  7:33 ` Ingo Molnar
  2009-05-17 10:34   ` Rafael J. Wysocki
                     ` (2 more replies)
  2009-05-17 17:55 ` Alex Bennee
                   ` (2 subsequent siblings)
  41 siblings, 3 replies; 171+ messages in thread
From: Ingo Molnar @ 2009-05-17  7:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Jonathan Corbet, Martin Bammer, Jeff Garzik,
	Oleg Nesterov, Kumar Gala, Andrew Morton
  Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
	Linus Torvalds, Natalie Protasevich, Kernel Testers List,
	Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
	Linux Wireless List, DRI


* Rafael J. Wysocki <rjw@sisk.pl> wrote:

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13325
> Subject		: 2.6.30-rc kills my box hard - and lockdep chains
> Submitter	: Jonathan Corbet <corbet@lwn.net>
> Date		: 2009-05-14 15:49 (3 days old)
> References	: http://marc.info/?l=linux-kernel&m=124231630701394&w=4

Jonathan, there's a side-issue reported there, us running out of 
lockdep space. Could you try this commit from -tip:

d80c19d: lockdep: increase MAX_LOCKDEP_ENTRIES and MAX_LOCKDEP_CHAINS

(which i'll get to Linus in the next ~24 hours.) Maybe that allows 
lockdep to report the reason for the deadlock.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13321
> Subject		: kernel crash with NULL pointer when boot
> Submitter	: Martin Bammer <mrb74@gmx.at>
> Date		: 2009-05-16 12:37 (1 days old)
> References	: http://lkml.org/lkml/2009/5/16/100

that crash is in reiserfs_for_each_xattr(), during sys_unlink()'s 
xattr teardown.

There's been a good deal of reiserfs changes in this cycle - some 
touch the xattr code as well. Some of them fairly late in the cycle, 
in the last two weeks:

 earth4:~/tip> gll v2.6.29..linus --since=two-weeks-ago fs/reiserfs/
 2a32ceb: Fix races around the access to ->s_options
 677c9b2: reiserfs: remove privroot hiding in lookup
 b82bb72: reiserfs: dont associate security.* with xattr files
 ab17c4f: reiserfs: fixup xattr_root caching
 edcc37a: Always lookup priv_root on reiserfs mount and keep it
 5a6059c: reiserfs: Expand i_mutex to enclose lookup_one_len

Martin, you could try a blind revert of say ... ab17c4f, which looks 
the most suspect and which is also a rather large commit.

Or/and you could try a bisect - perhaps accelerated via:

   git bisect start fs/reiserfs/

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> Subject		: kernel panic -  not syncing : fatel exception in interupt
> Submitter	: rob <rob1@housetosell.net>
> Date		: 2009-05-12 19:34 (5 days old)
> References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4

tainted crash, but probably legit. It does show some badness in an 
old-IDE legacy codepath:

[<c0371865>] error_code+0x65/0x6c
[<c0110155>] do_page_fault+0x0/0x1e0
[<c027dafc>] ide_complete_rq+0xf/0x3b
[<c02870a0>] cdrom_newpc_intr+0x64d/0x6cd
[<c0286a53>] cdrom_newpc_intr+0x0/0x6cd
[<c027dcc2>] ide_intr+0x109/0x161
[<c0132298>] handle_IRQ_event+0x54/0xc7
[<c013354a>] handle_level_irq+0x4f/0x85
[<c0103df7>] handle_irq+0x17/0x20
[<c0103da5>] do_IRQ+0x2b/0x66
[<c0102be9>] common_interupt+0x29/0x30
[<c0480000>] cmd40x_init+0x2ac/0x38d
[<c0106db3>] default_idle+0x25/0x38
[<c01019be>] cpu_idle+0x19/0x2d
[<c0468907>] start_kernel+0x23f/0x242

report subject line is too unspecific, it should be changed to 
something like:

  legacy IDE cmd40x related bootup crash

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13296
> Subject		: Lockdep violation at cleanup_workqueue_thread during suspend
> Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
> Date		: 2009-05-12 7:59 (5 days old)
> References	: http://marc.info/?l=linux-kernel&m=124211522525625&w=4

looks like wireless related - the dependency that connects the 
locks in a wrong way appears to be:

 -> #2 (cfg80211_mutex){+.+.+.}:
        [<ffffffff80271a64>] __lock_acquire+0xc64/0x10a0
        [<ffffffff80271f38>] lock_acquire+0x98/0x140
        [<ffffffff8054e78c>] __mutex_lock_common+0x4c/0x3b0
        [<ffffffff8054ebf6>] mutex_lock_nested+0x46/0x60
        [<ffffffffa007e66a>] reg_todo+0x19a/0x590 [cfg80211]
        [<ffffffff80258f18>] worker_thread+0x1e8/0x3a0
        [<ffffffff8025dc3a>] kthread+0x5a/0xa0
        [<ffffffff8020d23a>] child_rip+0xa/0x20

(havent checked deeper)

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13245
> Subject		: possible circular locking dependency detected
> Submitter	: Miles Lane <miles.lane@gmail.com>
> Date		: 2009-05-04 16:56 (13 days old)

same as #13296 above. (The one above should be merged into this one 
i guess)

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13126
> Subject		: BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
> Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
> Date		: 2009-04-15 12:43 (32 days old)
> References	: http://marc.info/?l=linux-kernel&m=123979949820538&w=4

should be resolved via the lockdep space extension fix.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13118
> Subject		: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
> Submitter	: Jeff Chua <jeff.chua.linux@gmail.com>
> Date		: 2009-04-10 16:05 (37 days old)
> References	: http://lkml.org/lkml/2009/4/10/111
> 		  http://lkml.org/lkml/2009/4/25/83
> Handled-By	: Eric Dumazet <dada1@cosmosbay.com>

solved by:

 commit 942e4a2bd680c606af0211e64eb216be2e19bf61
 Author: Stephen Hemminger <shemminger@vyatta.com>
 Date:   Tue Apr 28 22:36:33 2009 -0700

    netfilter: revised locking for x_tables

commit log does not credit reporters and testers and does not 
mention bugzilla id.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13116
> Subject		: Can't boot with nosmp
> Submitter	: Stephen Hemminger <shemminger@vyatta.com>
> Date		: 2009-04-15 4:18 (32 days old)
> References	: http://marc.info/?l=linux-kernel&m=123976917817920&w=4
> Handled-By	: Dan Williams <dan.j.williams@intel.com>

I think this might be fixed by:

 d6de2c8: async: Fix module loading async-work regression

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13107
> Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> Submitter	: Kumar Gala <galak@kernel.crashing.org>
> Date		: 2009-04-09 15:43 (38 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> 		  http://lkml.org/lkml/2009/4/10/193
> Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>

Oleg says in that thread that it's as-designed, and followup 
questions were not replied to (yet).

But ... a relevant seeming commit has been bisected to so this 
shouldnt be ignored that easily.

Andrew, you merged the commit that was bisected to:

  From b3bfa0cba867f23365b81658b47efd906830879b Mon Sep 17 00:00:00 2001
  From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
  Date: Thu, 2 Apr 2009 16:58:08 -0700
  Subject: [PATCH] signals: protect cinit from blocked fatal signals

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13068
> Subject		: Lockdep warining in inotify_dev_queue_event
> Submitter	: Sachin Sant <sachinp@in.ibm.com>
> Date		: 2009-04-05 12:37 (42 days old)
> References	: http://marc.info/?l=linux-kernel&m=123893439229272&w=4

should be fixed by:

381a80e: inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positive

	Ingo

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13068] Lockdep warining in inotify_dev_queue_event
  2009-05-17  6:35   ` Ingo Molnar
@ 2009-05-17  8:13     ` Sachin Sant
  2009-05-17 10:25       ` Rafael J. Wysocki
  0 siblings, 1 reply; 171+ messages in thread
From: Sachin Sant @ 2009-05-17  8:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
	Kernel Testers List, Marcin Slusarz

Ingo Molnar wrote:
> i think this might be fixed by:
>
> 381a80e: inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positive
>
> already in -rc6.
>   
Haven't seen this issue with rc6.

Thanks
-Sachin

-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13068] Lockdep warining in inotify_dev_queue_event
  2009-05-17  8:13     ` Sachin Sant
@ 2009-05-17 10:25       ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 10:25 UTC (permalink / raw)
  To: Sachin Sant
  Cc: Ingo Molnar, Linux Kernel Mailing List, Kernel Testers List,
	Marcin Slusarz

On Sunday 17 May 2009, Sachin Sant wrote:
> Ingo Molnar wrote:
> > i think this might be fixed by:
> >
> > 381a80e: inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positive
> >
> > already in -rc6.
> >   
> Haven't seen this issue with rc6.

Great, thanks.  Bug closed.

Best,
Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13118] iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
  2009-05-17  6:06   ` Jeff Chua
@ 2009-05-17 10:26     ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 10:26 UTC (permalink / raw)
  To: Jeff Chua
  Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Dumazet,
	Patrick McHardy, Stephen Hemminger

On Sunday 17 May 2009, Jeff Chua wrote:
> On Sun, May 17, 2009 at 3:20 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13118
> > Subject         : iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
> > Submitter       : Jeff Chua <jeff.chua.linux@gmail.com>
> > Date            : 2009-04-10 16:05 (37 days old)
> > References      : http://lkml.org/lkml/2009/4/10/111
> >                  http://lkml.org/lkml/2009/4/25/83
> > Handled-By      : Eric Dumazet <dada1@cosmosbay.com>
> 
> Fixed as of Apr 28.
> 
> commit 942e4a2bd680c606af0211e64eb216be2e19bf61
> Author: Stephen Hemminger <shemminger@vyatta.com>
> Date:   Tue Apr 28 22:36:33 2009 -0700
> 
>     netfilter: revised locking for x_tables

Thanks, closed.

Best,
Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13245] possible circular locking dependency detected
  2009-05-17  3:22   ` Ming Lei
@ 2009-05-17 10:26     ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 10:26 UTC (permalink / raw)
  To: Ming Lei; +Cc: Linux Kernel Mailing List, Kernel Testers List, Miles Lane

On Sunday 17 May 2009, Ming Lei wrote:
> I also can reproduce it on 2.6.30-rc5-next-20090515.
> 
> 2009/5/17 Rafael J. Wysocki <rjw@sisk.pl>:
> > 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=13245
> > Subject         : possible circular locking dependency detected
> > Submitter       : Miles Lane <miles.lane@gmail.com>
> > Date            : 2009-05-04 16:56 (13 days old)

Thanks for the update.

Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  7:33 ` Ingo Molnar
@ 2009-05-17 10:34   ` Rafael J. Wysocki
  2009-05-17 12:56     ` Stefan Richter
  2009-05-17 13:32   ` Frederic Weisbecker
  2009-05-18 14:57   ` Oleg Nesterov
  2 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 10:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Jonathan Corbet, Martin Bammer, Jeff Garzik, Oleg Nesterov,
	Kumar Gala, Andrew Morton, Linux Kernel Mailing List,
	Adrian Bunk, Linus Torvalds, Natalie Protasevich,
	Kernel Testers List, Network Development, Linux ACPI,
	Linux PM List, Linux SCSI List, Linux Wireless List, DRI,
	Jeff Mahoney, Stephen Hemminger

On Sunday 17 May 2009, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13325
> > Subject		: 2.6.30-rc kills my box hard - and lockdep chains
> > Submitter	: Jonathan Corbet <corbet@lwn.net>
> > Date		: 2009-05-14 15:49 (3 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124231630701394&w=4
> 
> Jonathan, there's a side-issue reported there, us running out of 
> lockdep space. Could you try this commit from -tip:
> 
> d80c19d: lockdep: increase MAX_LOCKDEP_ENTRIES and MAX_LOCKDEP_CHAINS
> 
> (which i'll get to Linus in the next ~24 hours.) Maybe that allows 
> lockdep to report the reason for the deadlock.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13321
> > Subject		: kernel crash with NULL pointer when boot
> > Submitter	: Martin Bammer <mrb74@gmx.at>
> > Date		: 2009-05-16 12:37 (1 days old)
> > References	: http://lkml.org/lkml/2009/5/16/100
> 
> that crash is in reiserfs_for_each_xattr(), during sys_unlink()'s 
> xattr teardown.
> 
> There's been a good deal of reiserfs changes in this cycle - some 
> touch the xattr code as well. Some of them fairly late in the cycle, 
> in the last two weeks:
> 
>  earth4:~/tip> gll v2.6.29..linus --since=two-weeks-ago fs/reiserfs/
>  2a32ceb: Fix races around the access to ->s_options
>  677c9b2: reiserfs: remove privroot hiding in lookup
>  b82bb72: reiserfs: dont associate security.* with xattr files
>  ab17c4f: reiserfs: fixup xattr_root caching
>  edcc37a: Always lookup priv_root on reiserfs mount and keep it
>  5a6059c: reiserfs: Expand i_mutex to enclose lookup_one_len
> 
> Martin, you could try a blind revert of say ... ab17c4f, which looks 
> the most suspect and which is also a rather large commit.
> 
> Or/and you could try a bisect - perhaps accelerated via:
> 
>    git bisect start fs/reiserfs/

I think there's a fix already for this in the works, but it hasn't been merged
yet.  It looks like Jeff has just posted some reiserfs fixes. :-)

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> > Subject		: kernel panic -  not syncing : fatel exception in interupt
> > Submitter	: rob <rob1@housetosell.net>
> > Date		: 2009-05-12 19:34 (5 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4
> 
> tainted crash, but probably legit. It does show some badness in an 
> old-IDE legacy codepath:
> 
> [<c0371865>] error_code+0x65/0x6c
> [<c0110155>] do_page_fault+0x0/0x1e0
> [<c027dafc>] ide_complete_rq+0xf/0x3b
> [<c02870a0>] cdrom_newpc_intr+0x64d/0x6cd
> [<c0286a53>] cdrom_newpc_intr+0x0/0x6cd
> [<c027dcc2>] ide_intr+0x109/0x161
> [<c0132298>] handle_IRQ_event+0x54/0xc7
> [<c013354a>] handle_level_irq+0x4f/0x85
> [<c0103df7>] handle_irq+0x17/0x20
> [<c0103da5>] do_IRQ+0x2b/0x66
> [<c0102be9>] common_interupt+0x29/0x30
> [<c0480000>] cmd40x_init+0x2ac/0x38d
> [<c0106db3>] default_idle+0x25/0x38
> [<c01019be>] cpu_idle+0x19/0x2d
> [<c0468907>] start_kernel+0x23f/0x242
> 
> report subject line is too unspecific, it should be changed to 
> something like:
> 
>   legacy IDE cmd40x related bootup crash
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13296
> > Subject		: Lockdep violation at cleanup_workqueue_thread during suspend
> > Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
> > Date		: 2009-05-12 7:59 (5 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124211522525625&w=4
> 
> looks like wireless related - the dependency that connects the 
> locks in a wrong way appears to be:
> 
>  -> #2 (cfg80211_mutex){+.+.+.}:
>         [<ffffffff80271a64>] __lock_acquire+0xc64/0x10a0
>         [<ffffffff80271f38>] lock_acquire+0x98/0x140
>         [<ffffffff8054e78c>] __mutex_lock_common+0x4c/0x3b0
>         [<ffffffff8054ebf6>] mutex_lock_nested+0x46/0x60
>         [<ffffffffa007e66a>] reg_todo+0x19a/0x590 [cfg80211]
>         [<ffffffff80258f18>] worker_thread+0x1e8/0x3a0
>         [<ffffffff8025dc3a>] kthread+0x5a/0xa0
>         [<ffffffff8020d23a>] child_rip+0xa/0x20
> 
> (havent checked deeper)
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13245
> > Subject		: possible circular locking dependency detected
> > Submitter	: Miles Lane <miles.lane@gmail.com>
> > Date		: 2009-05-04 16:56 (13 days old)
> 
> same as #13296 above. (The one above should be merged into this one 
> i guess)

Yes, I've merged the two.

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13126
> > Subject		: BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
> > Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
> > Date		: 2009-04-15 12:43 (32 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123979949820538&w=4
> 
> should be resolved via the lockdep space extension fix.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13118
> > Subject		: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
> > Submitter	: Jeff Chua <jeff.chua.linux@gmail.com>
> > Date		: 2009-04-10 16:05 (37 days old)
> > References	: http://lkml.org/lkml/2009/4/10/111
> > 		  http://lkml.org/lkml/2009/4/25/83
> > Handled-By	: Eric Dumazet <dada1@cosmosbay.com>
> 
> solved by:
> 
>  commit 942e4a2bd680c606af0211e64eb216be2e19bf61
>  Author: Stephen Hemminger <shemminger@vyatta.com>
>  Date:   Tue Apr 28 22:36:33 2009 -0700
> 
>     netfilter: revised locking for x_tables

Already closed.

> commit log does not credit reporters and testers and does not 
> mention bugzilla id.

Sigh.

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13116
> > Subject		: Can't boot with nosmp
> > Submitter	: Stephen Hemminger <shemminger@vyatta.com>
> > Date		: 2009-04-15 4:18 (32 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123976917817920&w=4
> > Handled-By	: Dan Williams <dan.j.williams@intel.com>
> 
> I think this might be fixed by:
> 
>  d6de2c8: async: Fix module loading async-work regression

That would be good to verify.  Stephen?

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13107
> > Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> > Submitter	: Kumar Gala <galak@kernel.crashing.org>
> > Date		: 2009-04-09 15:43 (38 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> > References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> > 		  http://lkml.org/lkml/2009/4/10/193
> > Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> 
> Oleg says in that thread that it's as-designed, and followup 
> questions were not replied to (yet).
> 
> But ... a relevant seeming commit has been bisected to so this 
> shouldnt be ignored that easily.
> 
> Andrew, you merged the commit that was bisected to:
> 
>   From b3bfa0cba867f23365b81658b47efd906830879b Mon Sep 17 00:00:00 2001
>   From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
>   Date: Thu, 2 Apr 2009 16:58:08 -0700
>   Subject: [PATCH] signals: protect cinit from blocked fatal signals
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13068
> > Subject		: Lockdep warining in inotify_dev_queue_event
> > Submitter	: Sachin Sant <sachinp@in.ibm.com>
> > Date		: 2009-04-05 12:37 (42 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123893439229272&w=4
> 
> should be fixed by:
> 
> 381a80e: inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positive

Closed.

Thanks a lot,
Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17 10:34   ` Rafael J. Wysocki
@ 2009-05-17 12:56     ` Stefan Richter
  2009-05-17 13:59       ` Jeff Mahoney
  0 siblings, 1 reply; 171+ messages in thread
From: Stefan Richter @ 2009-05-17 12:56 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Ingo Molnar, Martin Bammer, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk, Linus Torvalds,
	Natalie Protasevich, Kernel Testers List, Network Development,
	Jeff Mahoney

Rafael J. Wysocki wrote:
> On Sunday 17 May 2009, Ingo Molnar wrote:
>> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13321
>>> Subject		: kernel crash with NULL pointer when boot
>>> Submitter	: Martin Bammer <mrb74@gmx.at>
>>> Date		: 2009-05-16 12:37 (1 days old)
>>> References	: http://lkml.org/lkml/2009/5/16/100
>> that crash is in reiserfs_for_each_xattr(), during sys_unlink()'s 
>> xattr teardown.
>>
>> There's been a good deal of reiserfs changes in this cycle - some 
>> touch the xattr code as well. Some of them fairly late in the cycle,

(Also, the bug is reportedly a post -rc5 regression.)

>> in the last two weeks:
>>
>>  earth4:~/tip> gll v2.6.29..linus --since=two-weeks-ago fs/reiserfs/
>>  2a32ceb: Fix races around the access to ->s_options
>>  677c9b2: reiserfs: remove privroot hiding in lookup
>>  b82bb72: reiserfs: dont associate security.* with xattr files
>>  ab17c4f: reiserfs: fixup xattr_root caching
>>  edcc37a: Always lookup priv_root on reiserfs mount and keep it
>>  5a6059c: reiserfs: Expand i_mutex to enclose lookup_one_len
>>
>> Martin, you could try a blind revert of say ... ab17c4f, which looks 
>> the most suspect and which is also a rather large commit.
>>
>> Or/and you could try a bisect - perhaps accelerated via:
>>
>>    git bisect start fs/reiserfs/
> 
> I think there's a fix already for this in the works, but it hasn't been merged
> yet.  It looks like Jeff has just posted some reiserfs fixes. :-)

I'd say Martin should try Jeff's pending patches before a revert or 
before starting a bisection.  Either apply them from 
http://lkml.org/lkml/2009/5/17/6, or pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git for-next
or wait for them to appear in Linus' tree...

I for one didn't test the post v2.6.30-rc5 changes to reiserfs, but I 
did try them _together_ with the four pending patches on a system with 
reiserfs root filesystem and extended attributes disabled in the config. 
Everything is fine here after almost a week uptime.
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  7:33 ` Ingo Molnar
  2009-05-17 10:34   ` Rafael J. Wysocki
@ 2009-05-17 13:32   ` Frederic Weisbecker
  2009-05-17 16:19     ` Borislav Petkov
  2009-05-18 14:57   ` Oleg Nesterov
  2 siblings, 1 reply; 171+ messages in thread
From: Frederic Weisbecker @ 2009-05-17 13:32 UTC (permalink / raw)
  To: Ingo Molnar, Helge Deller, Borislav Petkov, Bartlomiej Zolnierkiewicz
  Cc: Rafael J. Wysocki, Andrew Morton, Linux Kernel Mailing List,
	Kernel Testers List, Kyle McMartin

On Sun, May 17, 2009 at 09:33:27AM +0200, Ingo Molnar wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> > Subject		: kernel panic -  not syncing : fatel exception in interupt
> > Submitter	: rob <rob1@housetosell.net>
> > Date		: 2009-05-12 19:34 (5 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4
> 
> tainted crash, but probably legit. It does show some badness in an 
> old-IDE legacy codepath:
> 
> [<c0371865>] error_code+0x65/0x6c
> [<c0110155>] do_page_fault+0x0/0x1e0
> [<c027dafc>] ide_complete_rq+0xf/0x3b
> [<c02870a0>] cdrom_newpc_intr+0x64d/0x6cd
> [<c0286a53>] cdrom_newpc_intr+0x0/0x6cd
> [<c027dcc2>] ide_intr+0x109/0x161
> [<c0132298>] handle_IRQ_event+0x54/0xc7
> [<c013354a>] handle_level_irq+0x4f/0x85
> [<c0103df7>] handle_irq+0x17/0x20
> [<c0103da5>] do_IRQ+0x2b/0x66
> [<c0102be9>] common_interupt+0x29/0x30
> [<c0480000>] cmd40x_init+0x2ac/0x38d
> [<c0106db3>] default_idle+0x25/0x38
> [<c01019be>] cpu_idle+0x19/0x2d
> [<c0468907>] start_kernel+0x23f/0x242
> 
> report subject line is too unspecific, it should be changed to 
> something like:
> 
>   legacy IDE cmd40x related bootup crash


It seems the crash has been rewritten by hand. I don't see
any cmd40x_init(), I guess it's about cmd640 chipset, then
cmd640x_init()

I don't see very recent changes in drivers/ide/cmd640.c
But there are some in drivers/ide/ide-io.c and drivers/ide/ide-cd.c
for this cycle.

Especially commit a1f9a89c90b4ac143c5b6054c2a157572b272cd2 which
fixed in -rc2:

 Kernel Fault: Code=26 regs=8ed34c40 (Addr=00000024)
     IASQ: 00000000 00000000 IAOQ: 1034b5ac 1034b5b0
     IIR: 4ab30048    ISR: 00000000  IOR: 00000024
     CPU:        0   CR30: 8ed34000 CR31: ffff55ff
     ORIG_R28: 00000000
     IAOQ[0]: ide_complete_rq+0x2c/0x70
     IAOQ[1]: ide_complete_rq+0x30/0x70
     RP(r2): cdrom_newpc_intr+0x178/0x46c
    Backtrace:
     [<1035c608>] cdrom_newpc_intr+0x178/0x46c
     [<1034c494>] ide_intr+0x1b0/0x214
     [<1016d284>] handle_IRQ_event+0x70/0x150
     [<1016d4b0>] __do_IRQ+0x14c/0x1cc
     [<102f7864>] superio_interrupt+0x88/0xbc
     [<1016d284>] handle_IRQ_event+0x70/0x150
     [<1016d4b0>] __do_IRQ+0x14c/0x1cc
     [<10112efc>] do_cpu_irq_mask+0x9c/0xd0
     [<10116068>] intr_return+0x0/0x4

Looks very similar. But the crash reported in this ticket is for -rc4, which means the
issue was still there after this fix or it's another one.
Adding some more Cc's.

Frederic.


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17 12:56     ` Stefan Richter
@ 2009-05-17 13:59       ` Jeff Mahoney
  0 siblings, 0 replies; 171+ messages in thread
From: Jeff Mahoney @ 2009-05-17 13:59 UTC (permalink / raw)
  To: Stefan Richter
  Cc: Rafael J. Wysocki, Ingo Molnar, Martin Bammer, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk, Linus Torvalds,
	Natalie Protasevich, Kernel Testers List, Network Development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Richter wrote:
> Rafael J. Wysocki wrote:
>> On Sunday 17 May 2009, Ingo Molnar wrote:
>>> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13321
>>>> Subject        : kernel crash with NULL pointer when boot
>>>> Submitter    : Martin Bammer <mrb74@gmx.at>
>>>> Date        : 2009-05-16 12:37 (1 days old)
>>>> References    : http://lkml.org/lkml/2009/5/16/100
>>> that crash is in reiserfs_for_each_xattr(), during sys_unlink()'s
>>> xattr teardown.
>>>
>>> There's been a good deal of reiserfs changes in this cycle - some
>>> touch the xattr code as well. Some of them fairly late in the cycle,
> 
> (Also, the bug is reportedly a post -rc5 regression.)
> 
>>> in the last two weeks:
>>>
>>>  earth4:~/tip> gll v2.6.29..linus --since=two-weeks-ago fs/reiserfs/
>>>  2a32ceb: Fix races around the access to ->s_options
>>>  677c9b2: reiserfs: remove privroot hiding in lookup
>>>  b82bb72: reiserfs: dont associate security.* with xattr files
>>>  ab17c4f: reiserfs: fixup xattr_root caching
>>>  edcc37a: Always lookup priv_root on reiserfs mount and keep it
>>>  5a6059c: reiserfs: Expand i_mutex to enclose lookup_one_len
>>>
>>> Martin, you could try a blind revert of say ... ab17c4f, which looks
>>> the most suspect and which is also a rather large commit.
>>>
>>> Or/and you could try a bisect - perhaps accelerated via:
>>>
>>>    git bisect start fs/reiserfs/
>>
>> I think there's a fix already for this in the works, but it hasn't
>> been merged
>> yet.  It looks like Jeff has just posted some reiserfs fixes. :-)
> 
> I'd say Martin should try Jeff's pending patches before a revert or
> before starting a bisection.  Either apply them from
> http://lkml.org/lkml/2009/5/17/6, or pull from
>  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git for-next
> or wait for them to appear in Linus' tree...
> 
> I for one didn't test the post v2.6.30-rc5 changes to reiserfs, but I
> did try them _together_ with the four pending patches on a system with
> reiserfs root filesystem and extended attributes disabled in the config.
> Everything is fine here after almost a week uptime.

Yes, this bug is known and is fixed with "[patch 2/4] [PATCH] reiserfs:
deal with NULL xattr root w/ xattrs disabled"

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkoQGEIACgkQLPWxlyuTD7K8kwCfUEq36jJvY+FzzuvWbAyOYX+r
BPwAniRe6a7Cj8n5+vC2Zmwfp1hRRUb1
=fh19
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  2:13       ` Linus Torvalds
@ 2009-05-17 15:33         ` Greg KH
  2009-05-18  3:48         ` Greg KH
  1 sibling, 0 replies; 171+ messages in thread
From: Greg KH @ 2009-05-17 15:33 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Kay Sievers, Rafael J. Wysocki, Linux Kernel Mailing List,
	Adrian Bunk, Andrew Morton, Natalie Protasevich

On Sat, May 16, 2009 at 07:13:59PM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 17 May 2009, Kay Sievers wrote:
> > 
> > This makes the oops in the driver-core, caused by the rtc driver
> > unregister, go away. The original issue is also fixed in the rtc driver
> > itself.
> 
> I don't think this is sufficient.
> 
> > --- a/drivers/base/driver.c
> > +++ b/drivers/base/driver.c
> > @@ -257,6 +257,8 @@ EXPORT_SYMBOL_GPL(driver_register);
> >   */
> >  void driver_unregister(struct device_driver *drv)
> >  {
> > +	if (!drv || !drv->p)
> > +		return;
> >  	driver_remove_groups(drv, drv->groups);
> >  	bus_remove_driver(drv);
> >  }
> 
> Ok, fine so far, but look at "driver_register()".
> 
> It will set drv->p, but then not unset it if it fails! (For a certain 
> class of failures)
> 
> So for a certain failure pattern, drv->p will point to some stale value. 
> Should we not clear drv->p in the "out_unregister" patch?
> 
> To confuse the thing more, there are actually "half-way failures" that 
> _succeed_ in driver registration, but then return an error code. See that 
> whole
> 
> 
> 	kobject_uevent(&priv->kobj, KOBJ_ADD);
> 	return error;
> 
> case in the "success" path driver_register(). We may return an error 
> despite the fact that we actually attached the driver to bus, but 
> "add_bind_files()" failed. A caller would be understandable very unhappy.
> 
> So I suspect we should do something like the appended (in addition to your 
> patch). Comments?

That looks good.  I'll add the WARN_ON that Ingo pointed out, and merge
this with Kay's patch.  Give me a few hours to wake up...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17 13:32   ` Frederic Weisbecker
@ 2009-05-17 16:19     ` Borislav Petkov
  2009-05-18 16:35       ` Bartlomiej Zolnierkiewicz
  0 siblings, 1 reply; 171+ messages in thread
From: Borislav Petkov @ 2009-05-17 16:19 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Ingo Molnar, Helge Deller, Bartlomiej Zolnierkiewicz,
	Rafael J. Wysocki, Andrew Morton, Linux Kernel Mailing List,
	Kernel Testers List, Kyle McMartin

Hi,

On Sun, May 17, 2009 at 03:32:11PM +0200, Frederic Weisbecker wrote:
> On Sun, May 17, 2009 at 09:33:27AM +0200, Ingo Molnar wrote:
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> > > Subject		: kernel panic -  not syncing : fatel exception in interupt
> > > Submitter	: rob <rob1@housetosell.net>
> > > Date		: 2009-05-12 19:34 (5 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4
> > 
> > tainted crash, but probably legit. It does show some badness in an 
> > old-IDE legacy codepath:
> > 
> > [<c0371865>] error_code+0x65/0x6c
> > [<c0110155>] do_page_fault+0x0/0x1e0
> > [<c027dafc>] ide_complete_rq+0xf/0x3b
> > [<c02870a0>] cdrom_newpc_intr+0x64d/0x6cd
> > [<c0286a53>] cdrom_newpc_intr+0x0/0x6cd
> > [<c027dcc2>] ide_intr+0x109/0x161
> > [<c0132298>] handle_IRQ_event+0x54/0xc7
> > [<c013354a>] handle_level_irq+0x4f/0x85
> > [<c0103df7>] handle_irq+0x17/0x20
> > [<c0103da5>] do_IRQ+0x2b/0x66
> > [<c0102be9>] common_interupt+0x29/0x30
> > [<c0480000>] cmd40x_init+0x2ac/0x38d
> > [<c0106db3>] default_idle+0x25/0x38
> > [<c01019be>] cpu_idle+0x19/0x2d
> > [<c0468907>] start_kernel+0x23f/0x242
> > 
> > report subject line is too unspecific, it should be changed to 
> > something like:
> > 
> >   legacy IDE cmd40x related bootup crash
> 
> 
> It seems the crash has been rewritten by hand. I don't see
> any cmd40x_init(), I guess it's about cmd640 chipset, then
> cmd640x_init()
> 
> I don't see very recent changes in drivers/ide/cmd640.c
> But there are some in drivers/ide/ide-io.c and drivers/ide/ide-cd.c
> for this cycle.
> 
> Especially commit a1f9a89c90b4ac143c5b6054c2a157572b272cd2 which
> fixed in -rc2:
> 
>  Kernel Fault: Code=26 regs=8ed34c40 (Addr=00000024)
>      IASQ: 00000000 00000000 IAOQ: 1034b5ac 1034b5b0
>      IIR: 4ab30048    ISR: 00000000  IOR: 00000024
>      CPU:        0   CR30: 8ed34000 CR31: ffff55ff
>      ORIG_R28: 00000000
>      IAOQ[0]: ide_complete_rq+0x2c/0x70
>      IAOQ[1]: ide_complete_rq+0x30/0x70
>      RP(r2): cdrom_newpc_intr+0x178/0x46c
>     Backtrace:
>      [<1035c608>] cdrom_newpc_intr+0x178/0x46c
>      [<1034c494>] ide_intr+0x1b0/0x214
>      [<1016d284>] handle_IRQ_event+0x70/0x150
>      [<1016d4b0>] __do_IRQ+0x14c/0x1cc
>      [<102f7864>] superio_interrupt+0x88/0xbc
>      [<1016d284>] handle_IRQ_event+0x70/0x150
>      [<1016d4b0>] __do_IRQ+0x14c/0x1cc
>      [<10112efc>] do_cpu_irq_mask+0x9c/0xd0
>      [<10116068>] intr_return+0x0/0x4
> 
> Looks very similar. But the crash reported in this ticket is for -rc4, which means the
> issue was still there after this fix or it's another one.
> Adding some more Cc's.

yep, I'm already looking into it.

-- 
Regards/Gruss,
    Boris.

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (38 preceding siblings ...)
  2009-05-17  7:33 ` Ingo Molnar
@ 2009-05-17 17:55 ` Alex Bennee
  2009-05-22 16:40 ` Linus Torvalds
  2009-05-25 20:24 ` Frans Pop
  41 siblings, 0 replies; 171+ messages in thread
From: Alex Bennee @ 2009-05-17 17:55 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Kernel Testers List, DRI,
	Jesse Barnes, Eric Anholt

2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> This message contains a list of some regressions from 2.6.29, 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 from 2.6.29, 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.

> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13171
> Subject         : 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
> Submitter       : Alex Bennee <kernel-hacker@bennee.com>
> Date            : 2009-04-19 6:27 (28 days old)
> References      : http://marc.info/?l=linux-kernel&m=124022460014812&w=4

All the main details on this are on the freedesktop bugzilla[1]. I can
confirm it's still a problem and I've been tracking the intel-next
tree for testing.

Fundamentally the problem is that X can't allocate any memory when KMS
is enabled on my chipset. Without knowing how memory should be
allocated from the kernel by the X driver I haven't been able to look
into it deeper. I've had some feedback from the intel guys but nothing
recently.

As always I stand ready to run tests and/or provide additional
diagnostics if required.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=21480

-- 
Alex, homepage: http://www.bennee.com/~alex/
CV: http://www.bennee.com/~alex/cv.php

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1
  2009-05-16 19:20 ` [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1 Rafael J. Wysocki
@ 2009-05-17 19:13   ` Linus Torvalds
  2009-05-18 14:41     ` Oleg Nesterov
  0 siblings, 1 reply; 171+ messages in thread
From: Linus Torvalds @ 2009-05-17 19:13 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
	Kumar Gala, Oleg Nesterov, Sukadev Bhattiprolu



On Sat, 16 May 2009, 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=13107
> Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> Submitter	: Kumar Gala <galak@kernel.crashing.org>
> Date		: 2009-04-09 15:43 (38 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> 		  http://lkml.org/lkml/2009/4/10/193
> Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>

I think we have to revert that thing. I haven't heard of any fixes to that 
commit.

		Linus

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13122] reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)
  2009-05-16 19:20 ` [Bug #13122] reiserfs_delete_xattrs: Couldn't delete all xattrs (-13) Rafael J. Wysocki
@ 2009-05-17 19:16   ` Linus Torvalds
  2009-05-17 20:36     ` Rafael J. Wysocki
  0 siblings, 1 reply; 171+ messages in thread
From: Linus Torvalds @ 2009-05-17 19:16 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Kernel Testers List,
	Alexander Beregalov, Jeff Mahoney



On Sat, 16 May 2009, Rafael J. Wysocki wrote:
>
> 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=13122
> Subject		: reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)
> Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
> Date		: 2009-04-16 19:23 (31 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d984561b326cd0fe0d1183d11b9b4fa1d011d21d
> References	: http://marc.info/?l=linux-kernel&m=123990989515105&w=4
> Handled-By	: Jeff Mahoney <jeffm@suse.com>
> Patch		: http://lkml.org/lkml/2009/5/10/91

The fix should now be merged as b83674c0da6558e357c6b482ccf299eeea77d8ef 
("reiserfs: fixup perms when xattrs are disabled")

		Linus

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13122] reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)
  2009-05-17 19:16   ` Linus Torvalds
@ 2009-05-17 20:36     ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 20:36 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Kernel Testers List,
	Alexander Beregalov, Jeff Mahoney

On Sunday 17 May 2009, Linus Torvalds wrote:
> 
> On Sat, 16 May 2009, Rafael J. Wysocki wrote:
> >
> > 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=13122
> > Subject		: reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)
> > Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
> > Date		: 2009-04-16 19:23 (31 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d984561b326cd0fe0d1183d11b9b4fa1d011d21d
> > References	: http://marc.info/?l=linux-kernel&m=123990989515105&w=4
> > Handled-By	: Jeff Mahoney <jeffm@suse.com>
> > Patch		: http://lkml.org/lkml/2009/5/10/91
> 
> The fix should now be merged as b83674c0da6558e357c6b482ccf299eeea77d8ef 
> ("reiserfs: fixup perms when xattrs are disabled")

Thanks, closed.

Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-05-16 23:36   ` Andrew Morton
@ 2009-05-17 23:16     ` Larry Finger
  2009-05-18  6:31     ` Pekka Enberg
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  2:13       ` Linus Torvalds
  2009-05-17 15:33         ` Greg KH
@ 2009-05-18  3:48         ` Greg KH
  1 sibling, 0 replies; 171+ messages in thread
From: Greg KH @ 2009-05-18  3:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Kay Sievers, Rafael J. Wysocki, Linux Kernel Mailing List,
	Adrian Bunk, Andrew Morton, Natalie Protasevich, Ingo Molnar

On Sat, May 16, 2009 at 07:13:59PM -0700, Linus Torvalds wrote:
> On Sun, 17 May 2009, Kay Sievers wrote:
> > 
> > This makes the oops in the driver-core, caused by the rtc driver
> > unregister, go away. The original issue is also fixed in the rtc driver
> > itself.
> 
> I don't think this is sufficient.
> 
> > --- a/drivers/base/driver.c
> > +++ b/drivers/base/driver.c
> > @@ -257,6 +257,8 @@ EXPORT_SYMBOL_GPL(driver_register);
> >   */
> >  void driver_unregister(struct device_driver *drv)
> >  {
> > +	if (!drv || !drv->p)
> > +		return;
> >  	driver_remove_groups(drv, drv->groups);
> >  	bus_remove_driver(drv);
> >  }
> 
> Ok, fine so far, but look at "driver_register()".
> 
> It will set drv->p, but then not unset it if it fails! (For a certain 
> class of failures)
> 
> So for a certain failure pattern, drv->p will point to some stale value. 
> Should we not clear drv->p in the "out_unregister" patch?
> 
> To confuse the thing more, there are actually "half-way failures" that 
> _succeed_ in driver registration, but then return an error code. See that 
> whole
> 
> 
> 	kobject_uevent(&priv->kobj, KOBJ_ADD);
> 	return error;
> 
> case in the "success" path driver_register(). We may return an error 
> despite the fact that we actually attached the driver to bus, but 
> "add_bind_files()" failed. A caller would be understandable very unhappy.
> 
> So I suspect we should do something like the appended (in addition to your 
> patch). Comments?

Yes, that's needed.  We also don't clean up properly when we do the same
thing for devices (error in the initialization of them).

So, here's a patch that combines everyone's intentions in this thread.
Any objections to it?

thanks,

greg k-h

------------------------
From: Kay Sievers <kay.sievers@vrfy.org>
Subject: Driver Core: do not oops when driver_unregister() is called for unregistered drivers

We also fix a problem with cleaning up properly when initializing
drivers and devices, so checks like this will work successfully.

Portions of the patch by Linus and Greg and Ingo.

Reported-by: Ozan Çağlayan <ozan@pardus.org.tr>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index dc030f1..c659961 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -700,8 +700,10 @@ int bus_add_driver(struct device_driver *drv)
 	}
 
 	kobject_uevent(&priv->kobj, KOBJ_ADD);
-	return error;
+	return 0;
 out_unregister:
+	kfree(drv->p);
+	drv->p = NULL;
 	kobject_put(&priv->kobj);
 out_put_bus:
 	bus_put(bus);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4aa527b..1977d4b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -879,7 +879,7 @@ int device_add(struct device *dev)
 	}
 
 	if (!dev_name(dev))
-		goto done;
+		goto name_error;
 
 	pr_debug("device: '%s': %s\n", dev_name(dev), __func__);
 
@@ -978,6 +978,9 @@ done:
 	cleanup_device_parent(dev);
 	if (parent)
 		put_device(parent);
+name_error:
+	kfree(dev->p);
+	dev->p = NULL;
 	goto done;
 }
 
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index c51f11b..8ae0f63 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -257,6 +257,10 @@ EXPORT_SYMBOL_GPL(driver_register);
  */
 void driver_unregister(struct device_driver *drv)
 {
+	if (!drv || !drv->p) {
+		WARN(1, "Unexpected driver unregister!\n");
+		return;
+	}
 	driver_remove_groups(drv, drv->groups);
 	bus_remove_driver(drv);
 }

^ permalink raw reply related	[flat|nested] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-05-16 23:36   ` Andrew Morton
  2009-05-17 23:16     ` Larry Finger
@ 2009-05-18  6:31     ` Pekka Enberg
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13177] 2.6.30-rc2-git7 build problem
  2009-05-16 19:20 ` [Bug #13177] 2.6.30-rc2-git7 build problem Rafael J. Wysocki
@ 2009-05-18 14:05   ` Martin Knoblauch
  0 siblings, 0 replies; 171+ messages in thread
From: Martin Knoblauch @ 2009-05-18 14:05 UTC (permalink / raw)
  To: Rafael J. Wysocki, Linux Kernel Mailing List; +Cc: Kernel Testers List, oliver




----- Original Message ----
> From: Rafael J. Wysocki <rjw@sisk.pl>
> To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> Sent: Saturday, May 16, 2009 9:20:40 PM
> Subject: [Bug #13177] 2.6.30-rc2-git7 build problem
> 
> 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=13177
> Subject        : 2.6.30-rc2-git7 build problem
> Submitter    : Martin Knoblauch 
> Date        : 2009-04-21 13:39 (26 days old)
> References    : http://marc.info/?l=linux-kernel&m=124032163602132&w=4
>           http://lkml.org/lkml/2009/4/27/56

 Still a problem in 2.6.30-rc6-git3. Adding maintainer

BUILD   arch/x86/boot/bzImage
Root device is (104, 3)
Setup is 12664 bytes (padded to 12800 bytes).
System is 2648 kB
CRC 91a1a400
Kernel: arch/x86/boot/bzImage is ready  (#2)
  Building modules, stage 2.
  MODPOST 471 modules
WARNING: drivers/gpu/drm/i915/i915.o(.text+0x1313e): Section mismatch in reference from the function intel_lvds_init() to the variable .init.data:intel_no_lvds
The function intel_lvds_init() references
the variable __initdata intel_no_lvds.
This is often because intel_lvds_init lacks a __initdata
annotation or the annotation of intel_no_lvds is wrong.

ERROR: ".L192" [drivers/usb/serial/kl5kusb105.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Cheers
Martin

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1
  2009-05-17 19:13   ` Linus Torvalds
@ 2009-05-18 14:41     ` Oleg Nesterov
  2009-05-18 17:54       ` Sukadev Bhattiprolu
  2009-05-19  9:16       ` Ingo Molnar
  0 siblings, 2 replies; 171+ messages in thread
From: Oleg Nesterov @ 2009-05-18 14:41 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
	Kernel Testers List, Andrew Morton, Kumar Gala,
	Sukadev Bhattiprolu, Roland McGrath, Ingo Molnar

Sorry for delay, I had a vacation.

On 05/17, Linus Torvalds wrote:
>
> On Sat, 16 May 2009, 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=13107
> > Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> > Submitter	: Kumar Gala <galak@kernel.crashing.org>
> > Date		: 2009-04-09 15:43 (38 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> > References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> > 		  http://lkml.org/lkml/2009/4/10/193
> > Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
>
> I think we have to revert that thing. I haven't heard of any fixes to that
> commit.

I thought this was already resolved.

And I don't think the kernel is buggy, this is expected behaviour. With
this commit (actually, there were several patches) /sbin/init respects
SIGSTOP if the caller has rights to send it, this change is intentional.
I'd even say this is fix.

Note that even root can't stop init, SIGSTOP should be sent from the
parent namespace, or from ptracer. And ptracer could obviously ptrace_stop()
init even before this patch.


But, Kumar, could you please provide more info? I downloaded
ltp-full-20081130.tgz, and I see that ptrace03.c does:

                        /* since Linux 2.6.26, it's allowed to trace init,
                           so just skip this test case */
                        if (i == 0 && tst_kvercmp(2,6,25) > 0) {
                                tst_resm(TCONF,
                                         "this kernel allows to trace init");
                                continue;
                        }

So, could you explain which test traces init?

Oleg.


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17  7:33 ` Ingo Molnar
  2009-05-17 10:34   ` Rafael J. Wysocki
  2009-05-17 13:32   ` Frederic Weisbecker
@ 2009-05-18 14:57   ` Oleg Nesterov
  2009-05-18 15:11     ` Ingo Molnar
  2 siblings, 1 reply; 171+ messages in thread
From: Oleg Nesterov @ 2009-05-18 14:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rafael J. Wysocki, Jonathan Corbet, Martin Bammer, Jeff Garzik,
	Kumar Gala, Andrew Morton, Linux Kernel Mailing List,
	Adrian Bunk, Linus Torvalds, Natalie Protasevich,
	Kernel Testers List, Network Development, Linux ACPI,
	Linux PM List, Linux SCSI List, Linux Wireless List, DRI

On 05/17, Ingo Molnar wrote:
>
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13107
> > Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> > Submitter	: Kumar Gala <galak@kernel.crashing.org>
> > Date		: 2009-04-09 15:43 (38 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> > References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> > 		  http://lkml.org/lkml/2009/4/10/193
> > Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
>
> Oleg says in that thread that it's as-designed, and followup
> questions were not replied to (yet).

Yes, I think this is false alarm. Perhaps I missed something, and
I am waiting for more info from Kumar, but it looks like ltp was
already changed to skip the "{ PTRACE_ATTACH, 1, EPERM }" test
on kernels after 2.6.25

Oleg.


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-18 14:57   ` Oleg Nesterov
@ 2009-05-18 15:11     ` Ingo Molnar
  2009-05-18 15:31       ` Oleg Nesterov
  2009-05-18 15:32       ` Linus Torvalds
  0 siblings, 2 replies; 171+ messages in thread
From: Ingo Molnar @ 2009-05-18 15:11 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Rafael J. Wysocki, Jonathan Corbet, Martin Bammer, Jeff Garzik,
	Kumar Gala, Andrew Morton, Linux Kernel Mailing List,
	Adrian Bunk, Linus Torvalds, Natalie Protasevich,
	Kernel Testers List, Network Development, Linux ACPI,
	Linux PM List, Linux SCSI List, Linux Wireless List, DRI


* Oleg Nesterov <oleg@redhat.com> wrote:

> On 05/17, Ingo Molnar wrote:
> >
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13107
> > > Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> > > Submitter	: Kumar Gala <galak@kernel.crashing.org>
> > > Date		: 2009-04-09 15:43 (38 days old)
> > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> > > References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> > > 		  http://lkml.org/lkml/2009/4/10/193
> > > Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> >
> > Oleg says in that thread that it's as-designed, and followup
> > questions were not replied to (yet).
> 
> Yes, I think this is false alarm. Perhaps I missed something, and 
> I am waiting for more info from Kumar, but it looks like ltp was 
> already changed to skip the "{ PTRACE_ATTACH, 1, EPERM }" test on 
> kernels after 2.6.25

Btw., why did the patch (and the revert) make any difference to the 
test? Timing differences look improbable.

	Ingo

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-18 15:11     ` Ingo Molnar
@ 2009-05-18 15:31       ` Oleg Nesterov
  2009-05-18 15:32       ` Linus Torvalds
  1 sibling, 0 replies; 171+ messages in thread
From: Oleg Nesterov @ 2009-05-18 15:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rafael J. Wysocki, Jonathan Corbet, Martin Bammer, Jeff Garzik,
	Kumar Gala, Andrew Morton, Linux Kernel Mailing List,
	Adrian Bunk, Linus Torvalds, Natalie Protasevich,
	Kernel Testers List, Network Development, Linux ACPI,
	Linux PM List, Linux SCSI List, Linux Wireless List, DRI

On 05/18, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > On 05/17, Ingo Molnar wrote:
> > >
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13107
> > > > Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> > > > Submitter	: Kumar Gala <galak@kernel.crashing.org>
> > > > Date		: 2009-04-09 15:43 (38 days old)
> > > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> > > > References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> > > > 		  http://lkml.org/lkml/2009/4/10/193
> > > > Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> > >
> > > Oleg says in that thread that it's as-designed, and followup
> > > questions were not replied to (yet).
> >
> > Yes, I think this is false alarm. Perhaps I missed something, and
> > I am waiting for more info from Kumar, but it looks like ltp was
> > already changed to skip the "{ PTRACE_ATTACH, 1, EPERM }" test on
> > kernels after 2.6.25
>
> Btw., why did the patch (and the revert) make any difference to the
> test? Timing differences look improbable.

Because before this series /sbin/init always ignored SIGSTOP. Now,
ptracer does PTRACE_ATTACH and exits without clearing the pending
SIGSTOP. init dequeues this signal and becomes TASK_STOPPED.

Consider:

	$ sleep 1000 &
	[1] 875

	$ grep State: /proc/`pidof sleep`/status
	State:  S (sleeping)

	$ perl -e 'syscall 101, 16, 0+shift, 0,0' `pidof sleep`    # just PTRACE_ATTACH + exit

	[1]+  Stopped                 sleep 1000

	$ grep State: /proc/`pidof sleep`/status
	State:  T (stopped)

This is the "normal" behaviour, afaics the same happens with init now.

Oleg.


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-18 15:11     ` Ingo Molnar
  2009-05-18 15:31       ` Oleg Nesterov
@ 2009-05-18 15:32       ` Linus Torvalds
  2009-05-18 15:45         ` Oleg Nesterov
  1 sibling, 1 reply; 171+ messages in thread
From: Linus Torvalds @ 2009-05-18 15:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Oleg Nesterov, Rafael J. Wysocki, Jonathan Corbet, Martin Bammer,
	Jeff Garzik, Kumar Gala, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk, Natalie Protasevich,
	Kernel Testers List, Network Development, Linux ACPI,
	Linux PM List, Linux SCSI List, Linux Wireless List, DRI



On Mon, 18 May 2009, Ingo Molnar wrote:
> 
> Btw., why did the patch (and the revert) make any difference to the 
> test? Timing differences look improbable.

It's the change from

	!signal_group_exit(signal)

to

	!sig_kernel_only(signr)

and quite frankly, I still don't see the point.

The comment seems to be wrong too:

    If SIGSTOP/SIGKILL originate from a descendant of container-init they are
    never queued (i.e dropped in sig_ignored() in an earler patch).
    
    If SIGSTOP/SIGKILL originate from parent namespace, the signal is queued
    and container-init processes the signal.

since the bug was that the SIGSTOP (from within the same container) was 
_not_ ignored like the comment says.

			Linus

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-18 15:32       ` Linus Torvalds
@ 2009-05-18 15:45         ` Oleg Nesterov
  0 siblings, 0 replies; 171+ messages in thread
From: Oleg Nesterov @ 2009-05-18 15:45 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ingo Molnar, Rafael J. Wysocki, Jonathan Corbet, Martin Bammer,
	Jeff Garzik, Kumar Gala, Andrew Morton,
	Linux Kernel Mailing List, Adrian Bunk, Natalie Protasevich,
	Kernel Testers List, Network Development, Linux ACPI,
	Linux PM List, Linux SCSI List, Linux Wireless List, DRI

On 05/18, Linus Torvalds wrote:
>
> On Mon, 18 May 2009, Ingo Molnar wrote:
> >
> > Btw., why did the patch (and the revert) make any difference to the
> > test? Timing differences look improbable.
>
> It's the change from
>
> 	!signal_group_exit(signal)
>
> to
>
> 	!sig_kernel_only(signr)
>
> and quite frankly, I still don't see the point.

Previously,

	!signal_group_exit(signal)

meant: we do not know what should we do, let's ignore this signal.
Unless the multithreaded init does exec, in this case we should
respect SIGKILL.

With the recent changes, sig_kernel_only() means: we already checked
we should handle SIGKILL/SIGSTOP when this signal was queued.

> The comment seems to be wrong too:
>
>     If SIGSTOP/SIGKILL originate from a descendant of container-init they are
>     never queued (i.e dropped in sig_ignored() in an earler patch).
>
>     If SIGSTOP/SIGKILL originate from parent namespace, the signal is queued
>     and container-init processes the signal.
>
> since the bug was that the SIGSTOP (from within the same container) was
> _not_ ignored like the comment says.

Yes, the changelog could be better because it ignores ptrace issues. But
this was discussed,

>From http://marc.info/?t=123222433100001

	Yes we should handle SIGSTOP fine if it sent from the parent namespace.

	Also. Currently it is possible to ptrace the global init, but even
	ptracer can't stop it (but ptrace_stop() works). With these patches
	ptracer can stop init.

	I forgot to mention this behaviour change, imho this side-effect
	is good.

So, at least this change is not "by accident".

Oleg.


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13188] horizontal strips of the screen frozen
  2009-05-16 19:20 ` [Bug #13188] horizontal strips of the screen frozen Rafael J. Wysocki
@ 2009-05-18 16:35   ` Justin Madru
  2009-05-18 18:03     ` Rafael J. Wysocki
  2009-05-18 18:04     ` Rafael J. Wysocki
  0 siblings, 2 replies; 171+ messages in thread
From: Justin Madru @ 2009-05-18 16:35 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Anholt

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=13188
> Subject		: horizontal strips of the screen frozen
> Submitter	: Justin Madru <jdm64@gawab.com>
> Date		: 2009-04-24 20:59 (23 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=280b713b5b0fd84cf2469098aee88acbb5de859c
> References	: http://marc.info/?l=linux-kernel&m=124060685315937&w=4
>
>
>
>   
As far as I can tell, this seams to be fixed by the intel-2.7.1 driver, 
and the bug only happened with UXA.
I did some minor testing and I couldn't trigger the bug. (earlier 
discussion in http://lkml.org/lkml/2009/4/23/587)
So this seams to be a user space bug, fixed in the intel-2.7.1 bug fix 
release (intel-2.7.0 still has the issue).

Justin Madru


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-17 16:19     ` Borislav Petkov
@ 2009-05-18 16:35       ` Bartlomiej Zolnierkiewicz
  2009-05-19  6:05         ` Borislav Petkov
  2009-05-20  1:14         ` Frederic Weisbecker
  0 siblings, 2 replies; 171+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-05-18 16:35 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Frederic Weisbecker, Ingo Molnar, Helge Deller,
	Rafael J. Wysocki, Andrew Morton, Linux Kernel Mailing List,
	Kernel Testers List, Kyle McMartin

On Sunday 17 May 2009 18:19:16 Borislav Petkov wrote:
> Hi,
> 
> On Sun, May 17, 2009 at 03:32:11PM +0200, Frederic Weisbecker wrote:
> > On Sun, May 17, 2009 at 09:33:27AM +0200, Ingo Molnar wrote:
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> > > > Subject		: kernel panic -  not syncing : fatel exception in interupt
> > > > Submitter	: rob <rob1@housetosell.net>
> > > > Date		: 2009-05-12 19:34 (5 days old)
> > > > References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4
> > > 
> > > tainted crash, but probably legit. It does show some badness in an 
> > > old-IDE legacy codepath:
> > > 
> > > [<c0371865>] error_code+0x65/0x6c
> > > [<c0110155>] do_page_fault+0x0/0x1e0
> > > [<c027dafc>] ide_complete_rq+0xf/0x3b
> > > [<c02870a0>] cdrom_newpc_intr+0x64d/0x6cd
> > > [<c0286a53>] cdrom_newpc_intr+0x0/0x6cd
> > > [<c027dcc2>] ide_intr+0x109/0x161
> > > [<c0132298>] handle_IRQ_event+0x54/0xc7
> > > [<c013354a>] handle_level_irq+0x4f/0x85
> > > [<c0103df7>] handle_irq+0x17/0x20
> > > [<c0103da5>] do_IRQ+0x2b/0x66
> > > [<c0102be9>] common_interupt+0x29/0x30
> > > [<c0480000>] cmd40x_init+0x2ac/0x38d
> > > [<c0106db3>] default_idle+0x25/0x38
> > > [<c01019be>] cpu_idle+0x19/0x2d
> > > [<c0468907>] start_kernel+0x23f/0x242
> > > 
> > > report subject line is too unspecific, it should be changed to 
> > > something like:
> > > 
> > >   legacy IDE cmd40x related bootup crash
> > 
> > 
> > It seems the crash has been rewritten by hand. I don't see
> > any cmd40x_init(), I guess it's about cmd640 chipset, then
> > cmd640x_init()

Frederic, is the oops reproducible?  Is 2.6.30-rc6 any better?

Does it help if you disable CONFIG_BLK_DEV_CMD640?
(this system doesn't have CMD640 chipset)

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1
  2009-05-18 14:41     ` Oleg Nesterov
@ 2009-05-18 17:54       ` Sukadev Bhattiprolu
  2009-05-19  9:16       ` Ingo Molnar
  1 sibling, 0 replies; 171+ messages in thread
From: Sukadev Bhattiprolu @ 2009-05-18 17:54 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Linus Torvalds, Rafael J. Wysocki, Linux Kernel Mailing List,
	Kernel Testers List, Andrew Morton, Kumar Gala, Roland McGrath,
	Ingo Molnar

Oleg Nesterov [oleg@redhat.com] wrote:
| Sorry for delay, I had a vacation.
| 
| On 05/17, Linus Torvalds wrote:
| >
| > On Sat, 16 May 2009, 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=13107
| > > Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
| > > Submitter	: Kumar Gala <galak@kernel.crashing.org>
| > > Date		: 2009-04-09 15:43 (38 days old)
| > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
| > > References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
| > > 		  http://lkml.org/lkml/2009/4/10/193
| > > Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
| >
| > I think we have to revert that thing. I haven't heard of any fixes to that
| > commit.
| 
| I thought this was already resolved.

Yes, so did I. We had asked for more info/confirmation before, most recently
on Apr 25 http://lkml.org/lkml/2009/4/25/132, although finding the LTP
test like below would have helped :-)

| 
| And I don't think the kernel is buggy, this is expected behaviour. With
| this commit (actually, there were several patches) /sbin/init respects
| SIGSTOP if the caller has rights to send it, this change is intentional.
| I'd even say this is fix.
| 
| Note that even root can't stop init, SIGSTOP should be sent from the
| parent namespace, or from ptracer. And ptracer could obviously ptrace_stop()
| init even before this patch.
| 
| 
| But, Kumar, could you please provide more info? I downloaded
| ltp-full-20081130.tgz, and I see that ptrace03.c does:

I beleive Kumar was running an older version of LTP (20080131)

| 
|                         /* since Linux 2.6.26, it's allowed to trace init,
|                            so just skip this test case */
|                         if (i == 0 && tst_kvercmp(2,6,25) > 0) {
|                                 tst_resm(TCONF,
|                                          "this kernel allows to trace init");
|                                 continue;
|                         }
| 
| So, could you explain which test traces init?
| 
| Oleg.

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13188] horizontal strips of the screen frozen
  2009-05-18 16:35   ` Justin Madru
@ 2009-05-18 18:03     ` Rafael J. Wysocki
  2009-05-18 18:04     ` Rafael J. Wysocki
  1 sibling, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-18 18:03 UTC (permalink / raw)
  To: Justin Madru; +Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Anholt

On Monday 18 May 2009, Justin Madru 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=13188
> > Subject		: horizontal strips of the screen frozen
> > Submitter	: Justin Madru <jdm64@gawab.com>
> > Date		: 2009-04-24 20:59 (23 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=280b713b5b0fd84cf2469098aee88acbb5de859c
> > References	: http://marc.info/?l=linux-kernel&m=124060685315937&w=4
> >
> >
> >
> >   
> As far as I can tell, this seams to be fixed by the intel-2.7.1 driver, 
> and the bug only happened with UXA.
> I did some minor testing and I couldn't trigger the bug. (earlier 
> discussion in http://lkml.org/lkml/2009/4/23/587)
> So this seams to be a user space bug, fixed in the intel-2.7.1 bug fix 
> release (intel-2.7.0 still has the issue).

I have closed the bug.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13188] horizontal strips of the screen frozen
  2009-05-18 16:35   ` Justin Madru
  2009-05-18 18:03     ` Rafael J. Wysocki
@ 2009-05-18 18:04     ` Rafael J. Wysocki
  1 sibling, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-18 18:04 UTC (permalink / raw)
  To: Justin Madru; +Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Anholt

On Monday 18 May 2009, Justin Madru 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=13188
> > Subject		: horizontal strips of the screen frozen
> > Submitter	: Justin Madru <jdm64@gawab.com>
> > Date		: 2009-04-24 20:59 (23 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=280b713b5b0fd84cf2469098aee88acbb5de859c
> > References	: http://marc.info/?l=linux-kernel&m=124060685315937&w=4
> >
> >
> >
> >   
> As far as I can tell, this seams to be fixed by the intel-2.7.1 driver, 
> and the bug only happened with UXA.
> I did some minor testing and I couldn't trigger the bug. (earlier 
> discussion in http://lkml.org/lkml/2009/4/23/587)
> So this seams to be a user space bug, fixed in the intel-2.7.1 bug fix 
> release (intel-2.7.0 still has the issue).

I have closed the bug.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-18 16:35       ` Bartlomiej Zolnierkiewicz
@ 2009-05-19  6:05         ` Borislav Petkov
  2009-05-20  1:14         ` Frederic Weisbecker
  1 sibling, 0 replies; 171+ messages in thread
From: Borislav Petkov @ 2009-05-19  6:05 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Frederic Weisbecker, Ingo Molnar, Helge Deller,
	Rafael J. Wysocki, Andrew Morton, Linux Kernel Mailing List,
	Kernel Testers List, Kyle McMartin

Hi,

On Mon, May 18, 2009 at 06:35:28PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 17 May 2009 18:19:16 Borislav Petkov wrote:
> > Hi,
> > 
> > On Sun, May 17, 2009 at 03:32:11PM +0200, Frederic Weisbecker wrote:
> > > On Sun, May 17, 2009 at 09:33:27AM +0200, Ingo Molnar wrote:
> > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> > > > > Subject		: kernel panic -  not syncing : fatel exception in interupt
> > > > > Submitter	: rob <rob1@housetosell.net>
> > > > > Date		: 2009-05-12 19:34 (5 days old)
> > > > > References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4
> > > > 
> > > > tainted crash, but probably legit. It does show some badness in an 
> > > > old-IDE legacy codepath:
> > > > 
> > > > [<c0371865>] error_code+0x65/0x6c
> > > > [<c0110155>] do_page_fault+0x0/0x1e0
> > > > [<c027dafc>] ide_complete_rq+0xf/0x3b
> > > > [<c02870a0>] cdrom_newpc_intr+0x64d/0x6cd
> > > > [<c0286a53>] cdrom_newpc_intr+0x0/0x6cd
> > > > [<c027dcc2>] ide_intr+0x109/0x161
> > > > [<c0132298>] handle_IRQ_event+0x54/0xc7
> > > > [<c013354a>] handle_level_irq+0x4f/0x85
> > > > [<c0103df7>] handle_irq+0x17/0x20
> > > > [<c0103da5>] do_IRQ+0x2b/0x66
> > > > [<c0102be9>] common_interupt+0x29/0x30
> > > > [<c0480000>] cmd40x_init+0x2ac/0x38d
> > > > [<c0106db3>] default_idle+0x25/0x38
> > > > [<c01019be>] cpu_idle+0x19/0x2d
> > > > [<c0468907>] start_kernel+0x23f/0x242
> > > > 
> > > > report subject line is too unspecific, it should be changed to 
> > > > something like:
> > > > 
> > > >   legacy IDE cmd40x related bootup crash
> > > 
> > > 
> > > It seems the crash has been rewritten by hand. I don't see
> > > any cmd40x_init(), I guess it's about cmd640 chipset, then
> > > cmd640x_init()

No, you don't because its a via82cxxx chipset. I've CC'ed the bug
reporter's mail to linux-ide, see

http://marc.info/?l=linux-ide&m=124271263912107&w=2

-- 
Regards/Gruss,
    Boris.

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1
  2009-05-18 14:41     ` Oleg Nesterov
  2009-05-18 17:54       ` Sukadev Bhattiprolu
@ 2009-05-19  9:16       ` Ingo Molnar
  2009-05-19 13:32         ` Oleg Nesterov
  1 sibling, 1 reply; 171+ messages in thread
From: Ingo Molnar @ 2009-05-19  9:16 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Linus Torvalds, Rafael J. Wysocki, Linux Kernel Mailing List,
	Kernel Testers List, Andrew Morton, Kumar Gala,
	Sukadev Bhattiprolu, Roland McGrath


* Oleg Nesterov <oleg@redhat.com> wrote:

> Sorry for delay, I had a vacation.
> 
> On 05/17, Linus Torvalds wrote:
> >
> > On Sat, 16 May 2009, 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=13107
> > > Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> > > Submitter	: Kumar Gala <galak@kernel.crashing.org>
> > > Date		: 2009-04-09 15:43 (38 days old)
> > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> > > References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> > > 		  http://lkml.org/lkml/2009/4/10/193
> > > Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> >
> > I think we have to revert that thing. I haven't heard of any fixes to that
> > commit.
> 
> I thought this was already resolved.
> 
> And I don't think the kernel is buggy, this is expected behaviour. 
> With this commit (actually, there were several patches) /sbin/init 
> respects SIGSTOP if the caller has rights to send it, this change 
> is intentional. I'd even say this is fix.
> 
> Note that even root can't stop init, SIGSTOP should be sent from 
> the parent namespace, or from ptracer. And ptracer could obviously 
> ptrace_stop() init even before this patch.

There's one important aspect here: _if_ a change results in 
user-space visible behavioral change, it does not matter how correct 
it is in the grand scheme of things. (beyond plain bugfixes solving 
crashes, etc.) What matters is whether there's any app out there 
that might possibly rely on the old behavior.

The LTP testcase might be synthetic, and it could be fixed and the 
commit might even end up being correct - but some thought should be 
expended on compatibility and real-life impact (and scope) here - 
not just on strict 'correctness'.

	Ingo

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1
  2009-05-19  9:16       ` Ingo Molnar
@ 2009-05-19 13:32         ` Oleg Nesterov
  0 siblings, 0 replies; 171+ messages in thread
From: Oleg Nesterov @ 2009-05-19 13:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Rafael J. Wysocki, Linux Kernel Mailing List,
	Kernel Testers List, Andrew Morton, Kumar Gala,
	Sukadev Bhattiprolu, Roland McGrath

On 05/19, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > And I don't think the kernel is buggy, this is expected behaviour.
> > With this commit (actually, there were several patches) /sbin/init
> > respects SIGSTOP if the caller has rights to send it, this change
> > is intentional. I'd even say this is fix.
> >
> > Note that even root can't stop init, SIGSTOP should be sent from
> > the parent namespace, or from ptracer. And ptracer could obviously
> > ptrace_stop() init even before this patch.
>
> There's one important aspect here: _if_ a change results in
> user-space visible behavioral change, it does not matter how correct
> it is in the grand scheme of things. (beyond plain bugfixes solving
> crashes, etc.) What matters is whether there's any app out there
> that might possibly rely on the old behavior.
>
> The LTP testcase might be synthetic, and it could be fixed and the
> commit might even end up being correct - but some thought should be
> expended on compatibility and real-life impact (and scope) here -
> not just on strict 'correctness'.

Yes, agreed.

But hopefully in this case we can't break the user-space. Because the
tracing of /sbin/init is special, and this was forbidden till 2.6.25.
Not only you can make the system unusable, it is very easy to crash
the kernel if you trace init. I don't think any "good" app can rely
on the wrong old behaviour, but of course any behavioral change is
dangerous.

And please note that the old behaviour was known to be wrong. If we
take the sub-namespace inits into account, it was very wrong. Of course,
we can add the special is_global_init() hack to preserve the current
behaviour at least for the root namespace, but this doesn't look good.

Oleg.


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-18 16:35       ` Bartlomiej Zolnierkiewicz
  2009-05-19  6:05         ` Borislav Petkov
@ 2009-05-20  1:14         ` Frederic Weisbecker
  1 sibling, 0 replies; 171+ messages in thread
From: Frederic Weisbecker @ 2009-05-20  1:14 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz, rob
  Cc: Borislav Petkov, Ingo Molnar, Helge Deller, Rafael J. Wysocki,
	Andrew Morton, Linux Kernel Mailing List, Kernel Testers List,
	Kyle McMartin

On Mon, May 18, 2009 at 06:35:28PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 17 May 2009 18:19:16 Borislav Petkov wrote:
> > Hi,
> > 
> > On Sun, May 17, 2009 at 03:32:11PM +0200, Frederic Weisbecker wrote:
> > > On Sun, May 17, 2009 at 09:33:27AM +0200, Ingo Molnar wrote:
> > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> > > > > Subject		: kernel panic -  not syncing : fatel exception in interupt
> > > > > Submitter	: rob <rob1@housetosell.net>
> > > > > Date		: 2009-05-12 19:34 (5 days old)
> > > > > References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4
> > > > 
> > > > tainted crash, but probably legit. It does show some badness in an 
> > > > old-IDE legacy codepath:
> > > > 
> > > > [<c0371865>] error_code+0x65/0x6c
> > > > [<c0110155>] do_page_fault+0x0/0x1e0
> > > > [<c027dafc>] ide_complete_rq+0xf/0x3b
> > > > [<c02870a0>] cdrom_newpc_intr+0x64d/0x6cd
> > > > [<c0286a53>] cdrom_newpc_intr+0x0/0x6cd
> > > > [<c027dcc2>] ide_intr+0x109/0x161
> > > > [<c0132298>] handle_IRQ_event+0x54/0xc7
> > > > [<c013354a>] handle_level_irq+0x4f/0x85
> > > > [<c0103df7>] handle_irq+0x17/0x20
> > > > [<c0103da5>] do_IRQ+0x2b/0x66
> > > > [<c0102be9>] common_interupt+0x29/0x30
> > > > [<c0480000>] cmd40x_init+0x2ac/0x38d
> > > > [<c0106db3>] default_idle+0x25/0x38
> > > > [<c01019be>] cpu_idle+0x19/0x2d
> > > > [<c0468907>] start_kernel+0x23f/0x242
> > > > 
> > > > report subject line is too unspecific, it should be changed to 
> > > > something like:
> > > > 
> > > >   legacy IDE cmd40x related bootup crash
> > > 
> > > 
> > > It seems the crash has been rewritten by hand. I don't see
> > > any cmd40x_init(), I guess it's about cmd640 chipset, then
> > > cmd640x_init()
> 
> Frederic, is the oops reproducible?  Is 2.6.30-rc6 any better?
> 
> Does it help if you disable CONFIG_BLK_DEV_CMD640?
> (this system doesn't have CMD640 chipset)


Sorry, I'm not the author of this bug report and I don't have this
hardware. I've just added you in Cc's :-)

But I'm adding the bug reporter in Cc.

Rob, could you test above Bartlomiej's suggestion?

Thanks,

Frederic.


^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-05-16 19:20 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
  2009-05-16 23:36   ` Andrew Morton
@ 2009-05-21 13:21   ` Larry Finger
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (39 preceding siblings ...)
  2009-05-17 17:55 ` Alex Bennee
@ 2009-05-22 16:40 ` Linus Torvalds
  2009-05-23  0:10   ` Rafael J. Wysocki
  2009-05-25 20:24 ` Frans Pop
  41 siblings, 1 reply; 171+ messages in thread
From: Linus Torvalds @ 2009-05-22 16:40 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
	Natalie Protasevich, Kernel Testers List, Network Development,
	Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
	DRI



On Sat, 16 May 2009, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13329
> Subject		: cifs_close: NULL pointer dereference
> Submitter	: Luca Tettamanti <kronos.it@gmail.com>
> Date		: 2009-05-16 16:28 (1 days old)
> References	: http://marc.info/?l=linux-kernel&m=124249133701702&w=4

Fixed by 703a3b8e5c01cf6fb33c6d8dc99905f889a4e992.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13298
> Subject		: modprobe ipmi_si hangs under 2.6.30-rc5
> Submitter	: Ferenc Wagner <wferi@niif.hu>
> Date		: 2009-05-12 21:28 (5 days old)
> References	: http://marc.info/?l=linux-kernel&m=124216379407177&w=4

Fixed by 9a2845c453d170e4e9b1437fa671dbf39b0e7bd8.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> Subject		: kernel panic -  not syncing : fatel exception in interupt
> Submitter	: rob <rob1@housetosell.net>
> Date		: 2009-05-12 19:34 (5 days old)
> References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4

This should be fixed by e3b29f05124b07303088795396ff858811d2acb8.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13177
> Subject		: 2.6.30-rc2-git7 build problem
> Submitter	: Martin Knoblauch <spamtrap@knobisoft.de>
> Date		: 2009-04-21 13:39 (26 days old)
> References	: http://marc.info/?l=linux-kernel&m=124032163602132&w=4
> 		  http://lkml.org/lkml/2009/4/27/56

This one really looks like a compiler bug (the undefined symbol is an 
internal gcc one: ".L192"). And the driver that gets it (kl5kusb105) has 
not actually had any changes since 2.6.29 - although header files that it 
includes obviously do have some, so it's entirely possible that some 
infrastructure change causes it to trigger.

Martin hit another bug with his compiler (an ICE in gcc, fixed by commit 
26a9a418237c0b06528941bca693c49c8d97edbe), which is why I'm so willing to 
blame that.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13107
> Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> Submitter	: Kumar Gala <galak@kernel.crashing.org>
> Date		: 2009-04-09 15:43 (38 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> 		  http://lkml.org/lkml/2009/4/10/193
> Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>

This one seems to have become "not-a-bug". Yes, LTP used to check that you 
cannot send SIGSTP to init, but people do want to send signals to init 
(especially when they are inside pid-namespace containers), and as long as 
it's only a LTP test that already got modified (and not some actual 
real-life usage), I'm considering this a "test failed because it was 
testing for behavior that we want to change" at least for now.

				Linus

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-22 16:40 ` Linus Torvalds
@ 2009-05-23  0:10   ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-23  0:10 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
	Natalie Protasevich, Kernel Testers List, Network Development,
	Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
	DRI

On Friday 22 May 2009, Linus Torvalds wrote:
> 
> On Sat, 16 May 2009, Rafael J. Wysocki wrote:
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13329
> > Subject		: cifs_close: NULL pointer dereference
> > Submitter	: Luca Tettamanti <kronos.it@gmail.com>
> > Date		: 2009-05-16 16:28 (1 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124249133701702&w=4
> 
> Fixed by 703a3b8e5c01cf6fb33c6d8dc99905f889a4e992.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13298
> > Subject		: modprobe ipmi_si hangs under 2.6.30-rc5
> > Submitter	: Ferenc Wagner <wferi@niif.hu>
> > Date		: 2009-05-12 21:28 (5 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124216379407177&w=4
> 
> Fixed by 9a2845c453d170e4e9b1437fa671dbf39b0e7bd8.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13297
> > Subject		: kernel panic -  not syncing : fatel exception in interupt
> > Submitter	: rob <rob1@housetosell.net>
> > Date		: 2009-05-12 19:34 (5 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124216126903309&w=4
> 
> This should be fixed by e3b29f05124b07303088795396ff858811d2acb8.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13177
> > Subject		: 2.6.30-rc2-git7 build problem
> > Submitter	: Martin Knoblauch <spamtrap@knobisoft.de>
> > Date		: 2009-04-21 13:39 (26 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124032163602132&w=4
> > 		  http://lkml.org/lkml/2009/4/27/56
> 
> This one really looks like a compiler bug (the undefined symbol is an 
> internal gcc one: ".L192"). And the driver that gets it (kl5kusb105) has 
> not actually had any changes since 2.6.29 - although header files that it 
> includes obviously do have some, so it's entirely possible that some 
> infrastructure change causes it to trigger.
> 
> Martin hit another bug with his compiler (an ICE in gcc, fixed by commit 
> 26a9a418237c0b06528941bca693c49c8d97edbe), which is why I'm so willing to 
> blame that.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13107
> > Subject		: LTP 20080131 causes defunct processes w/2.6.30-rc1
> > Submitter	: Kumar Gala <galak@kernel.crashing.org>
> > Date		: 2009-04-09 15:43 (38 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
> > References	: http://marc.info/?l=linux-kernel&m=123929187208953&w=4
> > 		  http://lkml.org/lkml/2009/4/10/193
> > Handled-By	: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> 
> This one seems to have become "not-a-bug". Yes, LTP used to check that you 
> cannot send SIGSTP to init, but people do want to send signals to init 
> (especially when they are inside pid-namespace containers), and as long as 
> it's only a LTP test that already got modified (and not some actual 
> real-life usage), I'm considering this a "test failed because it was 
> testing for behavior that we want to change" at least for now.

Thanks a lot, this really helps! :-)

I've closed all of the bugs above.

Best,
Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
                   ` (40 preceding siblings ...)
  2009-05-22 16:40 ` Linus Torvalds
@ 2009-05-25 20:24 ` Frans Pop
  2009-05-25 23:02   ` Rafael J. Wysocki
  41 siblings, 1 reply; 171+ messages in thread
From: Frans Pop @ 2009-05-25 20:24 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: linux-kernel, akpm, torvalds, kernel-testers, linux-acpi

Rafael J. Wysocki wrote:
> If you know of any other unresolved regressions from 2.6.29, please let
> me know either and I'll add them to the list.

It may be worth tracking a possible regression introduced with -rc6 as a 
result of http://bugzilla.kernel.org/show_bug.cgi?id=13259.

A new warning that was added in drivers/acpi/processor_throttling.c 
(commit 4973b22a: 'ACPI processor: reset the throttling state once it's 
invalid') may be triggering in cases where it shouldn't. It seems to 
trigger during boot and on 'cat /proc/acpi/processor/*/throttling'.
Otherwise it's probably relatively harmless.

See the comments starting at #23 for details.

Cheers,
FJP

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-25 20:24 ` Frans Pop
@ 2009-05-25 23:02   ` Rafael J. Wysocki
  2009-05-26 15:30     ` Frans Pop
  0 siblings, 1 reply; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-25 23:02 UTC (permalink / raw)
  To: Frans Pop; +Cc: linux-kernel, akpm, torvalds, kernel-testers, linux-acpi

On Monday 25 May 2009, Frans Pop wrote:
> Rafael J. Wysocki wrote:
> > If you know of any other unresolved regressions from 2.6.29, please let
> > me know either and I'll add them to the list.
> 
> It may be worth tracking a possible regression introduced with -rc6 as a 
> result of http://bugzilla.kernel.org/show_bug.cgi?id=13259.
> 
> A new warning that was added in drivers/acpi/processor_throttling.c 
> (commit 4973b22a: 'ACPI processor: reset the throttling state once it's 
> invalid') may be triggering in cases where it shouldn't. It seems to 
> trigger during boot and on 'cat /proc/acpi/processor/*/throttling'.
> Otherwise it's probably relatively harmless.
> 
> See the comments starting at #23 for details.

Hmm.  It's really better if you file a separate bug for that with a reference
to the previous discussion.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-25 23:02   ` Rafael J. Wysocki
@ 2009-05-26 15:30     ` Frans Pop
  2009-05-26 18:48       ` Rafael J. Wysocki
  0 siblings, 1 reply; 171+ messages in thread
From: Frans Pop @ 2009-05-26 15:30 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: linux-kernel, akpm, torvalds, kernel-testers, linux-acpi

On Tuesday 26 May 2009, Rafael J. Wysocki wrote:
> On Monday 25 May 2009, Frans Pop wrote:
> > Rafael J. Wysocki wrote:
> > > If you know of any other unresolved regressions from 2.6.29, please
> > > let me know either and I'll add them to the list.
> >
> > It may be worth tracking a possible regression introduced with -rc6
> > as a result of http://bugzilla.kernel.org/show_bug.cgi?id=13259.
> >
> > A new warning that was added in drivers/acpi/processor_throttling.c
> > (commit 4973b22a: 'ACPI processor: reset the throttling state once
> > it's invalid') may be triggering in cases where it shouldn't. It
> > seems to trigger during boot and on 'cat
> > /proc/acpi/processor/*/throttling'. Otherwise it's probably
> > relatively harmless.
> >
> > See the comments starting at #23 for details.
>
> Hmm.  It's really better if you file a separate bug for that with a
> reference to the previous discussion.

Done (after doing additional debugging):
http://bugzilla.kernel.org/show_bug.cgi?id=13389

Marked as regression and set as blocking for #13070.

Cheers,
FJP

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: 2.6.30-rc6: Reported regressions from 2.6.29
  2009-05-26 15:30     ` Frans Pop
@ 2009-05-26 18:48       ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ messages in thread
From: Rafael J. Wysocki @ 2009-05-26 18:48 UTC (permalink / raw)
  To: Frans Pop; +Cc: linux-kernel, akpm, torvalds, kernel-testers, linux-acpi

On Tuesday 26 May 2009, Frans Pop wrote:
> On Tuesday 26 May 2009, Rafael J. Wysocki wrote:
> > On Monday 25 May 2009, Frans Pop wrote:
> > > Rafael J. Wysocki wrote:
> > > > If you know of any other unresolved regressions from 2.6.29, please
> > > > let me know either and I'll add them to the list.
> > >
> > > It may be worth tracking a possible regression introduced with -rc6
> > > as a result of http://bugzilla.kernel.org/show_bug.cgi?id=13259.
> > >
> > > A new warning that was added in drivers/acpi/processor_throttling.c
> > > (commit 4973b22a: 'ACPI processor: reset the throttling state once
> > > it's invalid') may be triggering in cases where it shouldn't. It
> > > seems to trigger during boot and on 'cat
> > > /proc/acpi/processor/*/throttling'. Otherwise it's probably
> > > relatively harmless.
> > >
> > > See the comments starting at #23 for details.
> >
> > Hmm.  It's really better if you file a separate bug for that with a
> > reference to the previous discussion.
> 
> Done (after doing additional debugging):
> http://bugzilla.kernel.org/show_bug.cgi?id=13389
> 
> Marked as regression and set as blocking for #13070.

Thanks!

Best,
Rafael

^ permalink raw reply	[flat|nested] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-08-26  6:25   ` Pekka Enberg
@ 2009-08-26 20:53     ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-08-25 21:05 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
@ 2009-08-26  6:25   ` Pekka Enberg
  2009-08-26 20:53     ` Rafael J. Wysocki
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* [Bug #13319] Page allocation failures with b43 and p54usb
  2009-08-25 20:37 2.6.31-rc7-git2: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
@ 2009-08-25 21:05 ` Rafael J. Wysocki
  2009-08-26  6:25   ` Pekka Enberg
  0 siblings, 1 reply; 171+ 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] 171+ 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; 171+ 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] 171+ 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; 171+ 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] 171+ messages in thread

* [Bug #13319] Page allocation failures with b43 and p54usb
  2009-08-02 19:06 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
@ 2009-08-02 19:09 ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-27 18:16             ` David Rientjes
@ 2009-07-27 21:43               ` Christoph Lameter
  2009-07-27 22:38                 ` David Rientjes
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-27 17:20           ` Christoph Lameter
@ 2009-07-27 18:16             ` David Rientjes
  2009-07-27 21:43               ` Christoph Lameter
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-27  9:37         ` David Rientjes
@ 2009-07-27 17:20           ` Christoph Lameter
  2009-07-27 18:16             ` David Rientjes
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-27  7:08       ` Pekka Enberg
@ 2009-07-27  9:37         ` David Rientjes
  2009-07-27 17:20           ` Christoph Lameter
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-27  0:24     ` David Rientjes
@ 2009-07-27  7:08       ` Pekka Enberg
  2009-07-27  9:37         ` David Rientjes
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-27  0:17   ` Larry Finger
@ 2009-07-27  0:24     ` David Rientjes
  2009-07-27  7:08       ` Pekka Enberg
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2009-07-27  0:24     ` David Rientjes
  0 siblings, 1 reply; 171+ 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] 171+ 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; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-07  6:57       ` Pekka Enberg
@ 2009-07-08 13:18         ` Larry Finger
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-07  6:29     ` David Rientjes
@ 2009-07-07  6:57       ` Pekka Enberg
  2009-07-08 13:18         ` Larry Finger
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-07  1:05   ` Larry Finger
@ 2009-07-07  6:29     ` David Rientjes
  2009-07-07  6:57       ` Pekka Enberg
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-07  0:00 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
@ 2009-07-07  1:05   ` Larry Finger
  2009-07-07  6:29     ` David Rientjes
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2009-07-07  1:05   ` Larry Finger
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-02 17:18                           ` David Rientjes
@ 2009-07-03  7:23                             ` Pekka Enberg
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-07-01  5:53                         ` Pekka Enberg
@ 2009-07-02 17:18                           ` David Rientjes
  2009-07-03  7:23                             ` Pekka Enberg
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30 21:52                       ` David Rientjes
  2009-06-30 22:18                         ` Christoph Lameter
@ 2009-07-01  5:53                         ` Pekka Enberg
  2009-07-02 17:18                           ` David Rientjes
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30 21:52                       ` David Rientjes
@ 2009-06-30 22:18                         ` Christoph Lameter
  2009-07-01  5:53                         ` Pekka Enberg
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30 21:23                     ` Christoph Lameter
@ 2009-06-30 21:52                       ` David Rientjes
  2009-06-30 22:18                         ` Christoph Lameter
  2009-07-01  5:53                         ` Pekka Enberg
  0 siblings, 2 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30 21:15                   ` David Rientjes
@ 2009-06-30 21:23                     ` Christoph Lameter
  2009-06-30 21:52                       ` David Rientjes
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30 21:05                 ` Christoph Lameter
@ 2009-06-30 21:15                   ` David Rientjes
  2009-06-30 21:23                     ` Christoph Lameter
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30 20:04               ` David Rientjes
@ 2009-06-30 21:05                 ` Christoph Lameter
  2009-06-30 21:15                   ` David Rientjes
  0 siblings, 1 reply; 171+ 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] 171+ 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
@ 2009-06-30 20:25             ` David Rientjes
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30 15:14             ` Christoph Lameter
@ 2009-06-30 20:04               ` David Rientjes
  2009-06-30 21:05                 ` Christoph Lameter
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2009-06-30 20:04               ` David Rientjes
  0 siblings, 1 reply; 171+ 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] 171+ 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
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2009-06-30 20:25             ` David Rientjes
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30  6:55       ` Pekka Enberg
  2009-06-30  7:47         ` David Rientjes
@ 2009-06-30 14:32         ` Christoph Lameter
  2009-06-30 15:01           ` Pekka Enberg
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30  7:47         ` David Rientjes
@ 2009-06-30  8:24           ` Pekka Enberg
  2009-06-30 14:38             ` Larry Finger
  2009-06-30 20:25             ` David Rientjes
  0 siblings, 2 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-30  6:55       ` Pekka Enberg
@ 2009-06-30  7:47         ` David Rientjes
  2009-06-30  8:24           ` Pekka Enberg
  2009-06-30 14:32         ` Christoph Lameter
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-29 23:47     ` David Rientjes
  2009-06-30  2:06       ` Larry Finger
@ 2009-06-30  6:55       ` Pekka Enberg
  2009-06-30  7:47         ` David Rientjes
  2009-06-30 14:32         ` Christoph Lameter
  1 sibling, 2 replies; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-29 23:47     ` David Rientjes
@ 2009-06-30  2:06       ` Larry Finger
  2009-06-30  5:47         ` David Rientjes
  2009-06-30  6:55       ` Pekka Enberg
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-29 16:51   ` Larry Finger
  2009-06-29 23:15     ` Rafael J. Wysocki
@ 2009-06-29 23:47     ` David Rientjes
  2009-06-30  2:06       ` Larry Finger
  2009-06-30  6:55       ` Pekka Enberg
  1 sibling, 2 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-29 16:51   ` Larry Finger
@ 2009-06-29 23:15     ` Rafael J. Wysocki
  2009-06-29 23:47     ` David Rientjes
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-29  0:30 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
@ 2009-06-29 16:51   ` Larry Finger
  2009-06-29 23:15     ` Rafael J. Wysocki
  2009-06-29 23:47     ` David Rientjes
  0 siblings, 2 replies; 171+ 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] 171+ 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
  2009-06-29 16:51   ` Larry Finger
  0 siblings, 1 reply; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-11 14:41                                   ` Christoph Lameter
@ 2009-06-11 15:09                                     ` Pekka Enberg
  2009-06-11 18:41                                       ` Johannes Berg
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2009-06-11 15:09                                     ` Pekka Enberg
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-10 15:56                       ` Mel Gorman
@ 2009-06-10 18:03                         ` Pekka Enberg
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-10 15:52                                     ` Johannes Berg
  2009-06-10 16:06                                       ` Pekka Enberg
@ 2009-06-10 16:16                                       ` Pekka Enberg
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2009-06-10 16:10                                     ` Larry Finger
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-10 15:52                                     ` Johannes Berg
@ 2009-06-10 16:06                                       ` Pekka Enberg
  2009-06-10 16:16                                       ` Pekka Enberg
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2009-06-10 15:56                       ` Mel Gorman
  2009-06-10 18:03                         ` Pekka Enberg
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2009-06-10 16:06                                       ` Pekka Enberg
  2009-06-10 16:16                                       ` Pekka Enberg
  2009-06-10 16:10                                     ` Larry Finger
  1 sibling, 2 replies; 171+ 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] 171+ 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-10 15:52                                     ` Johannes Berg
  2009-06-10 16:10                                     ` Larry Finger
  2009-06-11 14:41                                   ` Christoph Lameter
  1 sibling, 2 replies; 171+ 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] 171+ 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; 171+ 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] 171+ 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
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-09  8:14                           ` David Rientjes
@ 2009-06-09  8:28                             ` Pekka Enberg
  2009-06-10 14:41                               ` Larry Finger
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2009-06-09  8:28                             ` Pekka Enberg
  0 siblings, 1 reply; 171+ 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] 171+ 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
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2009-06-09  7:58                         ` Pekka Enberg
  2009-06-10 15:56                       ` Mel Gorman
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 14:12                   ` Mel Gorman
  2009-06-08 14:42                     ` Christoph Lameter
  2009-06-09  7:06                     ` Pekka Enberg
@ 2009-06-09  7:50                     ` Pekka Enberg
  2 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 14:12                   ` Mel Gorman
  2009-06-08 14:42                     ` Christoph Lameter
@ 2009-06-09  7:06                     ` Pekka Enberg
  2009-06-09  7:54                       ` David Rientjes
  2009-06-10 15:56                       ` Mel Gorman
  2009-06-09  7:50                     ` Pekka Enberg
  2 siblings, 2 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08  8:32             ` KAMEZAWA Hiroyuki
@ 2009-06-08 17:20               ` Larry Finger
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 14:12                   ` Mel Gorman
@ 2009-06-08 14:42                     ` Christoph Lameter
  2009-06-09  7:06                     ` Pekka Enberg
  2009-06-09  7:50                     ` Pekka Enberg
  2 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 13:58                 ` Pekka J Enberg
@ 2009-06-08 14:12                   ` Mel Gorman
  2009-06-08 14:42                     ` Christoph Lameter
                                       ` (2 more replies)
  0 siblings, 3 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 11:03               ` Mel Gorman
@ 2009-06-08 13:58                 ` Pekka J Enberg
  2009-06-08 14:12                   ` Mel Gorman
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 13:20             ` Rik van Riel
@ 2009-06-08 13:35               ` Mel Gorman
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 10:17           ` Mel Gorman
  2009-06-08 10:52             ` Pekka Enberg
  2009-06-08 13:20             ` Rik van Riel
@ 2009-06-08 13:34             ` Larry Finger
  2 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 10:17           ` Mel Gorman
  2009-06-08 10:52             ` Pekka Enberg
@ 2009-06-08 13:20             ` Rik van Riel
  2009-06-08 13:35               ` Mel Gorman
  2009-06-08 13:34             ` Larry Finger
  2 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 10:52             ` Pekka Enberg
@ 2009-06-08 11:03               ` Mel Gorman
  2009-06-08 13:58                 ` Pekka J Enberg
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-08 10:17           ` Mel Gorman
@ 2009-06-08 10:52             ` Pekka Enberg
  2009-06-08 11:03               ` Mel Gorman
  2009-06-08 13:20             ` Rik van Riel
  2009-06-08 13:34             ` Larry Finger
  2 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-07 14:32         ` Pekka Enberg
  2009-06-07 16:35           ` Larry Finger
@ 2009-06-08 10:17           ` Mel Gorman
  2009-06-08 10:52             ` Pekka Enberg
                               ` (2 more replies)
  1 sibling, 3 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-07 16:35           ` Larry Finger
@ 2009-06-08  8:32             ` KAMEZAWA Hiroyuki
  2009-06-08 17:20               ` Larry Finger
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-07 14:32         ` Pekka Enberg
@ 2009-06-07 16:35           ` Larry Finger
  2009-06-08  8:32             ` KAMEZAWA Hiroyuki
  2009-06-08 10:17           ` Mel Gorman
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-07 14:19       ` Rik van Riel
@ 2009-06-07 14:32         ` Pekka Enberg
  2009-06-07 16:35           ` Larry Finger
  2009-06-08 10:17           ` Mel Gorman
  0 siblings, 2 replies; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-07 13:40     ` Pekka Enberg
@ 2009-06-07 14:19       ` Rik van Riel
  2009-06-07 14:32         ` Pekka Enberg
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-07 13:10   ` Larry Finger
@ 2009-06-07 13:40     ` Pekka Enberg
  2009-06-07 14:19       ` Rik van Riel
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [Bug #13319] Page allocation failures with b43 and p54usb
  2009-06-07  9:52 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
@ 2009-06-07 13:10   ` Larry Finger
  2009-06-07 13:40     ` Pekka Enberg
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2009-06-07 13:10   ` Larry Finger
  0 siblings, 1 reply; 171+ 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] 171+ 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; 171+ 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] 171+ messages in thread

* [Bug #13319] Page allocation failures with b43 and p54usb
  2009-05-24 19:06 2.6.30-rc7: " Rafael J. Wysocki
@ 2009-05-24 19:11 ` Rafael J. Wysocki
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

end of thread, other threads:[~2009-08-26 20:52 UTC | newest]

Thread overview: 171+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki
2009-05-16 19:14 ` [Bug #13068] Lockdep warining in inotify_dev_queue_event Rafael J. Wysocki
2009-05-17  6:35   ` Ingo Molnar
2009-05-17  8:13     ` Sachin Sant
2009-05-17 10:25       ` Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13069] regression in 2.6.29-git3 on SH/Dreamcast Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13118] iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 Rafael J. Wysocki
2009-05-17  6:06   ` Jeff Chua
2009-05-17 10:26     ` Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13116] Can't boot with nosmp Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13109] High latency on /sys/class/thermal Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1 Rafael J. Wysocki
2009-05-17 19:13   ` Linus Torvalds
2009-05-18 14:41     ` Oleg Nesterov
2009-05-18 17:54       ` Sukadev Bhattiprolu
2009-05-19  9:16       ` Ingo Molnar
2009-05-19 13:32         ` Oleg Nesterov
2009-05-16 19:20 ` [Bug #13125] active uvcvideo breaks over suspend Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13119] Trouble with make-install from a NFS mount Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13122] reiserfs_delete_xattrs: Couldn't delete all xattrs (-13) Rafael J. Wysocki
2009-05-17 19:16   ` Linus Torvalds
2009-05-17 20:36     ` Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13156] keyboard backlight brightness up/down keys doesn't work Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13177] 2.6.30-rc2-git7 build problem Rafael J. Wysocki
2009-05-18 14:05   ` Martin Knoblauch
2009-05-16 19:20 ` [Bug #13179] CD-R: wodim intermittent failures Rafael J. Wysocki
2009-05-16 22:51   ` Robert Hancock
2009-05-16 19:20 ` [Bug #13171] 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13188] horizontal strips of the screen frozen Rafael J. Wysocki
2009-05-18 16:35   ` Justin Madru
2009-05-18 18:03     ` Rafael J. Wysocki
2009-05-18 18:04     ` Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13245] possible circular locking dependency detected Rafael J. Wysocki
2009-05-17  3:22   ` Ming Lei
2009-05-17 10:26     ` Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13250] Side channel of Intel HDA chip doesn't work anymore, did work with 2.6.29 Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13293] Kernel BUG under network load with gianfar Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13285] INTELFB: Colors display incorrectly Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13296] Lockdep violation at cleanup_workqueue_thread during suspend Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13297] kernel panic - not syncing : fatel exception in interupt Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13294] i915: drm: xorg leaks drm objects massively Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13306] hibernate slow on _second_ run Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13298] modprobe ipmi_si hangs under 2.6.30-rc5 Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-05-16 23:36   ` Andrew Morton
2009-05-17 23:16     ` Larry Finger
2009-05-18  6:31     ` Pekka Enberg
2009-05-21 13:21   ` Larry Finger
2009-05-16 19:20 ` [Bug #13318] AGP doesn't work anymore on nforce2 Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13323] 2.6.30-rc deadline scheduler performance regression for iozone over NFS Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13321] kernel crash with NULL pointer when boot Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13324] panic when loading oprofile Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13327] Regression: 2.6.30-rc5 and rt2x00 / rt2500pci Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13325] 2.6.30-rc kills my box hard - and lockdep chains Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13326] Null pointer dereference in rtc-cmos driver Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13329] cifs_close: NULL pointer dereference Rafael J. Wysocki
2009-05-16 19:20 ` [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear Rafael J. Wysocki
2009-05-16 23:44 ` 2.6.30-rc6: Reported regressions from 2.6.29 Linus Torvalds
2009-05-17  0:01 ` Linus Torvalds
2009-05-17  0:15   ` Kay Sievers
2009-05-17  1:01     ` Kay Sievers
2009-05-17  2:13       ` Linus Torvalds
2009-05-17 15:33         ` Greg KH
2009-05-18  3:48         ` Greg KH
2009-05-17  6:32       ` Ingo Molnar
2009-05-17  0:32   ` Ozan Çağlayan
2009-05-17  2:06     ` Linus Torvalds
2009-05-17  7:33 ` Ingo Molnar
2009-05-17 10:34   ` Rafael J. Wysocki
2009-05-17 12:56     ` Stefan Richter
2009-05-17 13:59       ` Jeff Mahoney
2009-05-17 13:32   ` Frederic Weisbecker
2009-05-17 16:19     ` Borislav Petkov
2009-05-18 16:35       ` Bartlomiej Zolnierkiewicz
2009-05-19  6:05         ` Borislav Petkov
2009-05-20  1:14         ` Frederic Weisbecker
2009-05-18 14:57   ` Oleg Nesterov
2009-05-18 15:11     ` Ingo Molnar
2009-05-18 15:31       ` Oleg Nesterov
2009-05-18 15:32       ` Linus Torvalds
2009-05-18 15:45         ` Oleg Nesterov
2009-05-17 17:55 ` Alex Bennee
2009-05-22 16:40 ` Linus Torvalds
2009-05-23  0:10   ` Rafael J. Wysocki
2009-05-25 20:24 ` Frans Pop
2009-05-25 23:02   ` Rafael J. Wysocki
2009-05-26 15:30     ` Frans Pop
2009-05-26 18:48       ` Rafael J. Wysocki
2009-05-24 19:06 2.6.30-rc7: " Rafael J. Wysocki
2009-05-24 19:11 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
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-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 13:10   ` Larry Finger
2009-06-07 13:40     ` Pekka Enberg
2009-06-07 14:19       ` Rik van Riel
2009-06-07 14:32         ` Pekka Enberg
2009-06-07 16:35           ` Larry Finger
2009-06-08  8:32             ` KAMEZAWA Hiroyuki
2009-06-08 17:20               ` Larry Finger
2009-06-08 10:17           ` Mel Gorman
2009-06-08 10:52             ` Pekka Enberg
2009-06-08 11:03               ` Mel Gorman
2009-06-08 13:58                 ` Pekka J Enberg
2009-06-08 14:12                   ` Mel Gorman
2009-06-08 14:42                     ` Christoph Lameter
2009-06-09  7:06                     ` Pekka Enberg
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: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:52                                     ` Johannes Berg
2009-06-10 16:06                                       ` Pekka Enberg
2009-06-10 16:16                                       ` Pekka Enberg
2009-06-10 16:10                                     ` Larry Finger
2009-06-11 14:41                                   ` Christoph Lameter
2009-06-11 15:09                                     ` Pekka Enberg
2009-06-11 18:41                                       ` Johannes Berg
2009-06-10 15:56                       ` Mel Gorman
2009-06-10 18:03                         ` Pekka Enberg
2009-06-09  7:50                     ` Pekka Enberg
2009-06-08 13:20             ` Rik van Riel
2009-06-08 13:35               ` Mel Gorman
2009-06-08 13:34             ` 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 16:51   ` Larry Finger
2009-06-29 23:15     ` Rafael J. Wysocki
2009-06-29 23:47     ` David Rientjes
2009-06-30  2:06       ` Larry Finger
2009-06-30  5:47         ` David Rientjes
2009-06-30  6:55       ` Pekka Enberg
2009-06-30  7:47         ` David Rientjes
2009-06-30  8:24           ` Pekka Enberg
2009-06-30 14:38             ` Larry Finger
2009-06-30 20:25             ` David Rientjes
2009-06-30 14:32         ` Christoph Lameter
2009-06-30 15:01           ` Pekka Enberg
2009-06-30 15:14             ` Christoph Lameter
2009-06-30 20:04               ` David Rientjes
2009-06-30 21:05                 ` Christoph Lameter
2009-06-30 21:15                   ` David Rientjes
2009-06-30 21:23                     ` Christoph Lameter
2009-06-30 21:52                       ` David Rientjes
2009-06-30 22:18                         ` Christoph Lameter
2009-07-01  5:53                         ` Pekka Enberg
2009-07-02 17:18                           ` David Rientjes
2009-07-03  7:23                             ` Pekka Enberg
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  1:05   ` Larry Finger
2009-07-07  6:29     ` David Rientjes
2009-07-07  6:57       ` Pekka Enberg
2009-07-08 13:18         ` Larry Finger
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:24     ` David Rientjes
2009-07-27  7:08       ` Pekka Enberg
2009-07-27  9:37         ` David Rientjes
2009-07-27 17:20           ` Christoph Lameter
2009-07-27 18:16             ` David Rientjes
2009-07-27 21:43               ` Christoph Lameter
2009-07-27 22:38                 ` David Rientjes
2009-08-02 19:06 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
2009-08-02 19:09 ` [Bug #13319] Page allocation failures with b43 and p54usb 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-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-25 20:37 2.6.31-rc7-git2: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki
2009-08-25 21:05 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki
2009-08-26  6:25   ` Pekka Enberg
2009-08-26 20:53     ` Rafael J. Wysocki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).