* 2.6.31-rc2: Reported regressions 2.6.29 -> 2.6.30 @ 2009-07-06 23:57 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-06 23:57 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-07-07 138 50 46 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (5 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (7 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 Subject : A number of usb Devices causes Oops messages and kernel panics. Submitter : Alexander Kaltsas <alexkaltsas@gmail.com> Date : 2009-06-30 13:06 (7 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte@naasa.net> Date : 2009-06-14 21:00 (23 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13668 Subject : Can't boot 2.6.30 powerpc kernel under qemu. Submitter : Rob Landley <rob@landley.net> Date : 2009-06-27 18:08 (10 days old) References : http://lkml.org/lkml/2009/6/27/159 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (10 days old) References : http://lkml.org/lkml/2009/6/27/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13651 Subject : Anyone know what happened with PC speaker in 2.6.30? Submitter : Michael Tokarev <mjt@tls.msk.ru> Date : 2009-06-15 14:41 (22 days old) References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-06-22 12:08 (15 days old) References : http://lkml.org/lkml/2009/6/22/309 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 Subject : fb/mmap lockdep report. Submitter : Dave Jones <davej@redhat.com> Date : 2009-06-21 13:33 (16 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 References : http://lkml.org/lkml/2009/6/21/90 http://lkml.org/lkml/2009/6/21/122 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (18 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js@sig21.net> Date : 2009-06-16 01:27 (21 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber@kabelnet.at> Date : 2009-06-27 17:33 (10 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (10 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list@phuk.ath.cx> Date : 2009-06-25 18:18 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (12 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (19 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> Date : 2009-06-17 06:28 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik@mail.ru> Date : 2009-06-12 09:51 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (26 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> Date : 2009-06-05 1:37 (32 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (33 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-05-31 16:36 (37 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html http://lkml.org/lkml/2009/6/28/405 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (38 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (40 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (40 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (45 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (45 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (46 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (48 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (49 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (50 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (65 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (69 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 Handled-By : Johannes Berg <johannes@sipsolutions.net> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (68 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 Subject : hibernate slow on _second_ run Submitter : Johannes Berg <johannes@sipsolutions.net> Date : 2009-05-14 09:34 (54 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13277 Subject : 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 Submitter : Daniel Vetter <daniel@ffwll.ch> Date : 2009-05-11 10:08 (57 days old) Handled-By : Len Brown <len.brown@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (67 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13179 Subject : CD-R: wodim intermittent failures Submitter : Andy Isaacson <adi@hexapodia.org> Date : 2009-04-21 1:52 (77 days old) References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13119 Subject : Trouble with make-install from a NFS mount Submitter : Gregory Haskins <ghaskins@novell.com> Date : 2009-04-14 21:32 (84 days old) References : http://marc.info/?l=linux-kernel&m=123974482327044&w=4 Handled-By : H. Peter Anvin <hpa@zytor.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (87 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13663 Subject : suspend to ram regression (IDE related) Submitter : Etienne Basset <etienne.basset@numericable.fr> Date : 2009-06-26 17:40 (11 days old) References : http://lkml.org/lkml/2009/6/26/242 http://lkml.org/lkml/2009/6/29/126 Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Patch : http://patchwork.kernel.org/patch/32719/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-06-20 15:27 (17 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel@csn.ul.ie> Patch : http://patchwork.kernel.org/patch/33130/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar@gmail.com> Date : 2009-06-02 10:00 (35 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Patch : http://patchwork.kernel.org/patch/28660/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (42 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.31-rc2: Reported regressions 2.6.29 -> 2.6.30 @ 2009-07-06 23:57 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-06 23:57 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List, Natalie Protasevich, Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-07-07 138 50 46 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (5 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (7 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 Subject : A number of usb Devices causes Oops messages and kernel panics. Submitter : Alexander Kaltsas <alexkaltsas@gmail.com> Date : 2009-06-30 13:06 (7 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte@naasa.net> Date : 2009-06-14 21:00 (23 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13668 Subject : Can't boot 2.6.30 powerpc kernel under qemu. Submitter : Rob Landley <rob@landley.net> Date : 2009-06-27 18:08 (10 days old) References : http://lkml.org/lkml/2009/6/27/159 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (10 days old) References : http://lkml.org/lkml/2009/6/27/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13651 Subject : Anyone know what happened with PC speaker in 2.6.30? Submitter : Michael Tokarev <mjt@tls.msk.ru> Date : 2009-06-15 14:41 (22 days old) References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-06-22 12:08 (15 days old) References : http://lkml.org/lkml/2009/6/22/309 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 Subject : fb/mmap lockdep report. Submitter : Dave Jones <davej@redhat.com> Date : 2009-06-21 13:33 (16 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 References : http://lkml.org/lkml/2009/6/21/90 http://lkml.org/lkml/2009/6/21/122 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (18 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js@sig21.net> Date : 2009-06-16 01:27 (21 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber@kabelnet.at> Date : 2009-06-27 17:33 (10 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (10 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list@phuk.ath.cx> Date : 2009-06-25 18:18 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (12 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (19 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> Date : 2009-06-17 06:28 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik@mail.ru> Date : 2009-06-12 09:51 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (26 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> Date : 2009-06-05 1:37 (32 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (33 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-05-31 16:36 (37 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html http://lkml.org/lkml/2009/6/28/405 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (38 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (40 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (40 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (45 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (45 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (46 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (48 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (49 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (50 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (65 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (69 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 Handled-By : Johannes Berg <johannes@sipsolutions.net> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (68 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 Subject : hibernate slow on _second_ run Submitter : Johannes Berg <johannes@sipsolutions.net> Date : 2009-05-14 09:34 (54 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13277 Subject : 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 Submitter : Daniel Vetter <daniel@ffwll.ch> Date : 2009-05-11 10:08 (57 days old) Handled-By : Len Brown <len.brown@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (67 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13179 Subject : CD-R: wodim intermittent failures Submitter : Andy Isaacson <adi@hexapodia.org> Date : 2009-04-21 1:52 (77 days old) References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13119 Subject : Trouble with make-install from a NFS mount Submitter : Gregory Haskins <ghaskins@novell.com> Date : 2009-04-14 21:32 (84 days old) References : http://marc.info/?l=linux-kernel&m=123974482327044&w=4 Handled-By : H. Peter Anvin <hpa@zytor.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (87 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13663 Subject : suspend to ram regression (IDE related) Submitter : Etienne Basset <etienne.basset@numericable.fr> Date : 2009-06-26 17:40 (11 days old) References : http://lkml.org/lkml/2009/6/26/242 http://lkml.org/lkml/2009/6/29/126 Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Patch : http://patchwork.kernel.org/patch/32719/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-06-20 15:27 (17 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel@csn.ul.ie> Patch : http://patchwork.kernel.org/patch/33130/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar@gmail.com> Date : 2009-06-02 10:00 (35 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Patch : http://patchwork.kernel.org/patch/28660/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (42 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13109] High latency on /sys/class/thermal 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-06 23:57 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-06 23:57 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexey Starikovskiy, Tiago Simões Batista, Zhang Rui This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (87 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13109] High latency on /sys/class/thermal @ 2009-07-06 23:57 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-06 23:57 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexey Starikovskiy, Tiago Simões Batista, Zhang Rui This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Sim√µes Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (87 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13277] 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Daniel Vetter, Len Brown This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13277 Subject : 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 Submitter : Daniel Vetter <daniel@ffwll.ch> Date : 2009-05-11 10:08 (57 days old) Handled-By : Len Brown <len.brown@intel.com> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13277] 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Daniel Vetter, Len Brown This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13277 Subject : 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 Submitter : Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> Date : 2009-05-11 10:08 (57 days old) Handled-By : Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13119] Trouble with make-install from a NFS mount 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 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 regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. 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 (84 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] 467+ messages in thread
* [Bug #13119] Trouble with make-install from a NFS mount @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 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 regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13119 Subject : Trouble with make-install from a NFS mount Submitter : Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> Date : 2009-04-14 21:32 (84 days old) References : http://marc.info/?l=linux-kernel&m=123974482327044&w=4 Handled-By : H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13179] CD-R: wodim intermittent failures 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 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 regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. 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 (77 days old) References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13179] CD-R: wodim intermittent failures @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 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 regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13179 Subject : CD-R: wodim intermittent failures Submitter : Andy Isaacson <adi-3HqRAUrWAWyGglJvpFV4uA@public.gmane.org> Date : 2009-04-21 1:52 (77 days old) References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, David Hill This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (67 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, David Hill This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Submitter : David Hill <hilld-HTiBYHdybX7UkGsOFmftXw@public.gmane.org> Date : 2009-05-01 16:57 (67 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13306] hibernate slow on _second_ run 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ 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 This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. 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 (54 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13306] hibernate slow on _second_ run @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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 This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 Subject : hibernate slow on _second_ run Submitter : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> Date : 2009-05-14 09:34 (54 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13306] hibernate slow on _second_ run 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-07 0:12 ` Johannes Berg -1 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-07 0:12 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 636 bytes --] On Tue, 2009-07-07 at 02:00 +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 > Subject : hibernate slow on _second_ run > Submitter : Johannes Berg <johannes@sipsolutions.net> > Date : 2009-05-14 09:34 (54 days old) Still exists in 31-rc2. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13306] hibernate slow on _second_ run @ 2009-07-07 0:12 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-07 0:12 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 659 bytes --] On Tue, 2009-07-07 at 02:00 +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 > Subject : hibernate slow on _second_ run > Submitter : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > Date : 2009-05-14 09:34 (54 days old) Still exists in 31-rc2. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13306] hibernate slow on _second_ run @ 2009-07-07 10:58 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 10:58 UTC (permalink / raw) To: Johannes Berg; +Cc: Linux Kernel Mailing List, Kernel Testers List On Tuesday 07 July 2009, Johannes Berg wrote: > On Tue, 2009-07-07 at 02:00 +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 > > Subject : hibernate slow on _second_ run > > Submitter : Johannes Berg <johannes@sipsolutions.net> > > Date : 2009-05-14 09:34 (54 days old) > > Still exists in 31-rc2. Thanks for the update. Last time I remember you managed to collect some ftrace output from the failing case, but they didn't reveal anything directly. We know, however, that is [suspend|resume]_device_irqs() in driver/base/power/main.c are disabled, the issue doesn't show up. Is that correct? Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13306] hibernate slow on _second_ run @ 2009-07-07 10:58 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 10:58 UTC (permalink / raw) To: Johannes Berg; +Cc: Linux Kernel Mailing List, Kernel Testers List On Tuesday 07 July 2009, Johannes Berg wrote: > On Tue, 2009-07-07 at 02:00 +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 > > Subject : hibernate slow on _second_ run > > Submitter : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > > Date : 2009-05-14 09:34 (54 days old) > > Still exists in 31-rc2. Thanks for the update. Last time I remember you managed to collect some ftrace output from the failing case, but they didn't reveal anything directly. We know, however, that is [suspend|resume]_device_irqs() in driver/base/power/main.c are disabled, the issue doesn't show up. Is that correct? Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13306] hibernate slow on _second_ run 2009-07-07 10:58 ` Rafael J. Wysocki (?) @ 2009-07-07 11:27 ` Johannes Berg -1 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-07 11:27 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 539 bytes --] On Tue, 2009-07-07 at 12:58 +0200, Rafael J. Wysocki wrote: > Thanks for the update. > > Last time I remember you managed to collect some ftrace output from the failing > case, but they didn't reveal anything directly. > > We know, however, that is [suspend|resume]_device_irqs() in > driver/base/power/main.c are disabled, the issue doesn't show up. > > Is that correct? I'm not sure -- did we verify that somehow? I was running with some trial patch from you for a long time but it had no apparent effect. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (69 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-07 1:05 ` Larry Finger -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-07 1:05 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-07-07 1:05 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > Subject : Page allocation failures with b43 and p54usb > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > Date : 2009-04-29 21:01 (69 days old) > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > http://lkml.org/lkml/2009/6/7/136 > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> I have not seen the fix yet, but one is being prepared. I think the bug can be closed. Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-07 6:29 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-07 6:29 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-07 6:57 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-07 6:57 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-07-07 6:57 UTC (permalink / raw) To: David Rientjes Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Hi, On Mon, 6 Jul 2009, Larry Finger wrote: >> I have not seen the fix yet, but one is being prepared. I think the >> bug can be closed. On Tue, Jul 7, 2009 at 9:29 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > http://patchwork.kernel.org/patch/34385 should fix your issue (try with > CONFIG_SLUB_DEBUG_ON still enabled and slub_debug=O on the command line). > > Pekka indicated he wanted this fixed in 2.6.31, so he'll probably push it > to Linus before the 2.6.31-rc3. Yup, if it's not too much trouble Larry, I'd appreciate if you gave it a spin before I apply the sucker. Note to regression trackers, I don't think this should go to -stable because it depends on other patches in mainline and there's an obvious workaround for the problem (disable CONFIG_SLUB_DEBUG_ON). Furthermore, it's very unlikely people will hit this on production configurations anyway. Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-08 13:18 ` Larry Finger 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-08 13:18 ` Larry Finger 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* [Bug #13318] AGP doesn't work anymore on nforce2 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer, Shaohua Li This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (68 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li@intel.com> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13318] AGP doesn't work anymore on nforce2 @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer, Shaohua Li This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org> Date : 2009-04-30 8:51 (68 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13318] AGP doesn't work anymore on nforce2 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-07 2:12 ` Shaohua Li -1 siblings, 0 replies; 467+ messages in thread From: Shaohua Li @ 2009-07-07 2:12 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer On Tue, Jul 07, 2009 at 08:00:36AM +0800, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 > Subject : AGP doesn't work anymore on nforce2 > Submitter : Karsten Mehrhoff <kawime@gmx.de> > Date : 2009-04-30 8:51 (68 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e > References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 > Handled-By : Shaohua Li <shaohua.li@intel.com> Can anybody else help look at this issue? I really have no idea why this could happens. Thanks, Shaohua ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13318] AGP doesn't work anymore on nforce2 @ 2009-07-07 2:12 ` Shaohua Li 0 siblings, 0 replies; 467+ messages in thread From: Shaohua Li @ 2009-07-07 2:12 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer On Tue, Jul 07, 2009 at 08:00:36AM +0800, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 > Subject : AGP doesn't work anymore on nforce2 > Submitter : Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org> > Date : 2009-04-30 8:51 (68 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e > References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 > Handled-By : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Can anybody else help look at this issue? I really have no idea why this could happens. Thanks, Shaohua ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13318] AGP doesn't work anymore on nforce2 @ 2009-07-07 11:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 11:00 UTC (permalink / raw) To: Shaohua Li Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer On Tuesday 07 July 2009, Shaohua Li wrote: > On Tue, Jul 07, 2009 at 08:00:36AM +0800, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 > > Subject : AGP doesn't work anymore on nforce2 > > Submitter : Karsten Mehrhoff <kawime@gmx.de> > > Date : 2009-04-30 8:51 (68 days old) > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e > > References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 > > Handled-By : Shaohua Li <shaohua.li@intel.com> > Can anybody else help look at this issue? I really have no idea why this could > happens. Quirky hardware? Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13318] AGP doesn't work anymore on nforce2 @ 2009-07-07 11:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 11:00 UTC (permalink / raw) To: Shaohua Li Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer On Tuesday 07 July 2009, Shaohua Li wrote: > On Tue, Jul 07, 2009 at 08:00:36AM +0800, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 > > Subject : AGP doesn't work anymore on nforce2 > > Submitter : Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org> > > Date : 2009-04-30 8:51 (68 days old) > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e > > References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 > > Handled-By : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > Can anybody else help look at this issue? I really have no idea why this could > happens. Quirky hardware? Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13318] AGP doesn't work anymore on nforce2 2009-07-07 11:00 ` Rafael J. Wysocki (?) @ 2009-07-07 11:46 ` Bartlomiej Zolnierkiewicz -1 siblings, 0 replies; 467+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2009-07-07 11:46 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Shaohua Li, Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer On Tuesday 07 July 2009 13:00:11 Rafael J. Wysocki wrote: > On Tuesday 07 July 2009, Shaohua Li wrote: > > On Tue, Jul 07, 2009 at 08:00:36AM +0800, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > > of regressions introduced between 2.6.29 and 2.6.30. > > > > > > The following bug entry is on the current list of known regressions > > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > > be listed and let me know (either way). > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 > > > Subject : AGP doesn't work anymore on nforce2 > > > Submitter : Karsten Mehrhoff <kawime@gmx.de> > > > Date : 2009-04-30 8:51 (68 days old) > > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e > > > References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 > > > Handled-By : Shaohua Li <shaohua.li@intel.com> > > Can anybody else help look at this issue? I really have no idea why this could > > happens. > > Quirky hardware? Could be a weird interaction between CONFIG_X86_USE_3DNOW and AGP or "simply" some timing issue. Either way it means a lot of "fun". ;) The latter theory can be verified by adding some {u,m}delay() to agp_generic_alloc_page{s}() and the former one with: --- arch/x86/Kconfig.cpu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/arch/x86/Kconfig.cpu =================================================================== --- a/arch/x86/Kconfig.cpu +++ b/arch/x86/Kconfig.cpu @@ -363,7 +363,7 @@ config X86_USE_PPRO_CHECKSUM config X86_USE_3DNOW def_bool y - depends on (MCYRIXIII || MK7 || MGEODE_LX) && !UML + depends on (MCYRIXIII || MGEODE_LX) && !UML config X86_OOSTORE def_bool y ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. 2009-07-06 23:57 ` Rafael J. Wysocki ` (8 preceding siblings ...) (?) @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Francis Moreau, netdev This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (65 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Tomas Janousek This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (50 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Tomas Janousek This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org> Date : 2009-05-18 10:59 (50 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-08 22:02 ` Jan Scholz -1 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-08 22:02 UTC (permalink / raw) To: Rafael J. Wysocki, johannes Cc: Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek Hi, I'm not sure if I experience the same bug on my apple iBook G4 (ppc 7447A, altivec supported PowerBook6,5) or just something very similar. With v2.6.30-rc1 I noticed, that suspending to ram does not work if my wireless card is 'up'. The wireless card is an apple airport extreme card, this is its lspci output: 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) I tested suspend like this: # unload the wireless module modprobe -r b43 echo mem > /sys/power/state # wake up works fine #loading b43 modprobe b43 echo mem > /sys/power/state # wake up still works fine ifconfig wlan0 up echo mem > /sys/power/state # the box does not wake up, I guess it's not really sleeping, because # the sleep led is not on I bisected this and got: 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 Author: Johannes Berg <johannes@sipsolutions.net> Date: Sun May 17 11:40:42 2009 +0200 mac80211: cancel/restart all timers across suspend/resume Best regards, Jan Scholz "Rafael J. Wysocki" <rjw@sisk.pl> writes: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 > Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules > Submitter : Tomas Janousek <tomi@nomi.cz> > Date : 2009-05-18 10:59 (50 days old) > ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-08 22:02 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-08 22:02 UTC (permalink / raw) To: Rafael J. Wysocki, johannes-cdvu00un1VgdHxzADdlk8Q Cc: Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek Hi, I'm not sure if I experience the same bug on my apple iBook G4 (ppc 7447A, altivec supported PowerBook6,5) or just something very similar. With v2.6.30-rc1 I noticed, that suspending to ram does not work if my wireless card is 'up'. The wireless card is an apple airport extreme card, this is its lspci output: 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) I tested suspend like this: # unload the wireless module modprobe -r b43 echo mem > /sys/power/state # wake up works fine #loading b43 modprobe b43 echo mem > /sys/power/state # wake up still works fine ifconfig wlan0 up echo mem > /sys/power/state # the box does not wake up, I guess it's not really sleeping, because # the sleep led is not on I bisected this and got: 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 Author: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> Date: Sun May 17 11:40:42 2009 +0200 mac80211: cancel/restart all timers across suspend/resume Best regards, Jan Scholz "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 > Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules > Submitter : Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org> > Date : 2009-05-18 10:59 (50 days old) > ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-09 15:14 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-09 15:14 UTC (permalink / raw) To: Jan Scholz Cc: Rafael J. Wysocki, johannes, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek Hi, I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 (I wanted to test this on v2.6.31-rc2 as well, but there I had other suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails with the test procedure described below, but it works fine when I revert commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 "mac80211: cancel/restart all timers across suspend/resume" Best regards, Jan Jan Scholz <scholz@fias.uni-frankfurt.de> writes: > Hi, > > I'm not sure if I experience the same bug on my apple iBook G4 (ppc > 7447A, altivec supported PowerBook6,5) or just something very similar. > > With v2.6.30-rc1 I noticed, that suspending to ram does not work if my > wireless card is 'up'. The wireless card is an apple airport extreme > card, this is its lspci output: > > 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) > > I tested suspend like this: > > # unload the wireless module > modprobe -r b43 > echo mem > /sys/power/state > > # wake up works fine > > #loading b43 > modprobe b43 > echo mem > /sys/power/state > > # wake up still works fine > > ifconfig wlan0 up > echo mem > /sys/power/state > > # the box does not wake up, I guess it's not really sleeping, because > # the sleep led is not on > > I bisected this and got: > > 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 > Author: Johannes Berg <johannes@sipsolutions.net> > Date: Sun May 17 11:40:42 2009 +0200 > > mac80211: cancel/restart all timers across suspend/resume > > > Best regards, > Jan Scholz > > "Rafael J. Wysocki" <rjw@sisk.pl> writes: > >> This message has been generated automatically as a part of a report >> of regressions introduced between 2.6.29 and 2.6.30. >> >> The following bug entry is on the current list of known regressions >> introduced between 2.6.29 and 2.6.30. Please verify if it still should >> be listed and let me know (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 >> Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules >> Submitter : Tomas Janousek <tomi@nomi.cz> >> Date : 2009-05-18 10:59 (50 days old) >> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-09 15:14 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-09 15:14 UTC (permalink / raw) To: Jan Scholz Cc: Rafael J. Wysocki, johannes-cdvu00un1VgdHxzADdlk8Q, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek Hi, I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 (I wanted to test this on v2.6.31-rc2 as well, but there I had other suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails with the test procedure described below, but it works fine when I revert commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 "mac80211: cancel/restart all timers across suspend/resume" Best regards, Jan Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org> writes: > Hi, > > I'm not sure if I experience the same bug on my apple iBook G4 (ppc > 7447A, altivec supported PowerBook6,5) or just something very similar. > > With v2.6.30-rc1 I noticed, that suspending to ram does not work if my > wireless card is 'up'. The wireless card is an apple airport extreme > card, this is its lspci output: > > 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) > > I tested suspend like this: > > # unload the wireless module > modprobe -r b43 > echo mem > /sys/power/state > > # wake up works fine > > #loading b43 > modprobe b43 > echo mem > /sys/power/state > > # wake up still works fine > > ifconfig wlan0 up > echo mem > /sys/power/state > > # the box does not wake up, I guess it's not really sleeping, because > # the sleep led is not on > > I bisected this and got: > > 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 > Author: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > Date: Sun May 17 11:40:42 2009 +0200 > > mac80211: cancel/restart all timers across suspend/resume > > > Best regards, > Jan Scholz > > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes: > >> This message has been generated automatically as a part of a report >> of regressions introduced between 2.6.29 and 2.6.30. >> >> The following bug entry is on the current list of known regressions >> introduced between 2.6.29 and 2.6.30. Please verify if it still should >> be listed and let me know (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 >> Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules >> Submitter : Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org> >> Date : 2009-05-18 10:59 (50 days old) >> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-09 20:03 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-09 20:03 UTC (permalink / raw) To: Jan Scholz, johannes Cc: Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville On Thursday 09 July 2009, Jan Scholz wrote: > Hi, > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 > (I wanted to test this on v2.6.31-rc2 as well, but there I had other > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails > with the test procedure described below, but it works fine when I revert > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 > "mac80211: cancel/restart all timers across suspend/resume" Thanks for the update. Johannes, do you have any idea what can go wrong here? Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-09 20:03 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-09 20:03 UTC (permalink / raw) To: Jan Scholz, johannes-cdvu00un1VgdHxzADdlk8Q Cc: Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville On Thursday 09 July 2009, Jan Scholz wrote: > Hi, > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 > (I wanted to test this on v2.6.31-rc2 as well, but there I had other > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails > with the test procedure described below, but it works fine when I revert > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 > "mac80211: cancel/restart all timers across suspend/resume" Thanks for the update. Johannes, do you have any idea what can go wrong here? Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-09 20:28 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-09 20:28 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jan Scholz, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville [-- Attachment #1: Type: text/plain, Size: 1109 bytes --] On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote: > On Thursday 09 July 2009, Jan Scholz wrote: > > Hi, > > > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 > > (I wanted to test this on v2.6.31-rc2 as well, but there I had other > > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) > > > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails > > with the test procedure described below, but it works fine when I revert > > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 > > "mac80211: cancel/restart all timers across suspend/resume" > > Thanks for the update. > > Johannes, do you have any idea what can go wrong here? Not really, no. __ieee80211_suspend isn't holding any locks that the cancel_work_sync() calls could require or so afaict... Jan, can you run with console_suspend=0 (or whatever it is now, Rafael will correct me if I'm wrong) that should work on your platform, and put a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to see where in there it's hanging? johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-09 20:28 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-09 20:28 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jan Scholz, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville [-- Attachment #1: Type: text/plain, Size: 1109 bytes --] On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote: > On Thursday 09 July 2009, Jan Scholz wrote: > > Hi, > > > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 > > (I wanted to test this on v2.6.31-rc2 as well, but there I had other > > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) > > > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails > > with the test procedure described below, but it works fine when I revert > > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 > > "mac80211: cancel/restart all timers across suspend/resume" > > Thanks for the update. > > Johannes, do you have any idea what can go wrong here? Not really, no. __ieee80211_suspend isn't holding any locks that the cancel_work_sync() calls could require or so afaict... Jan, can you run with console_suspend=0 (or whatever it is now, Rafael will correct me if I'm wrong) that should work on your platform, and put a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to see where in there it's hanging? johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-09 20:34 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-09 20:34 UTC (permalink / raw) To: Johannes Berg Cc: Jan Scholz, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville On Thursday 09 July 2009, Johannes Berg wrote: > On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote: > > On Thursday 09 July 2009, Jan Scholz wrote: > > > Hi, > > > > > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 > > > (I wanted to test this on v2.6.31-rc2 as well, but there I had other > > > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) > > > > > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails > > > with the test procedure described below, but it works fine when I revert > > > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 > > > "mac80211: cancel/restart all timers across suspend/resume" > > > > Thanks for the update. > > > > Johannes, do you have any idea what can go wrong here? > > Not really, no. __ieee80211_suspend isn't holding any locks that the > cancel_work_sync() calls could require or so afaict... > > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael > will correct me if I'm wrong) That's just 'no_console_suspend'. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-09 20:34 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-09 20:34 UTC (permalink / raw) To: Johannes Berg Cc: Jan Scholz, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville On Thursday 09 July 2009, Johannes Berg wrote: > On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote: > > On Thursday 09 July 2009, Jan Scholz wrote: > > > Hi, > > > > > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 > > > (I wanted to test this on v2.6.31-rc2 as well, but there I had other > > > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) > > > > > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails > > > with the test procedure described below, but it works fine when I revert > > > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 > > > "mac80211: cancel/restart all timers across suspend/resume" > > > > Thanks for the update. > > > > Johannes, do you have any idea what can go wrong here? > > Not really, no. __ieee80211_suspend isn't holding any locks that the > cancel_work_sync() calls could require or so afaict... > > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael > will correct me if I'm wrong) That's just 'no_console_suspend'. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-11 14:07 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-11 14:07 UTC (permalink / raw) To: Johannes Berg Cc: Rafael J. Wysocki, Jan Scholz, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville Johannes Berg <johannes@sipsolutions.net> writes: > On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote: >> On Thursday 09 July 2009, Jan Scholz wrote: >> > Hi, >> > >> > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 >> > (I wanted to test this on v2.6.31-rc2 as well, but there I had other >> > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) >> > >> > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails >> > with the test procedure described below, but it works fine when I revert >> > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 >> > "mac80211: cancel/restart all timers across suspend/resume" >> >> Thanks for the update. >> >> Johannes, do you have any idea what can go wrong here? > > Not really, no. __ieee80211_suspend isn't holding any locks that the > cancel_work_sync() calls could require or so afaict... > > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael > will correct me if I'm wrong) that should work on your platform, and put > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to > see where in there it's hanging? Did that, seems like it hangs in drv_remove_interface(local, &conf); Jan ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-11 14:07 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-11 14:07 UTC (permalink / raw) To: Johannes Berg Cc: Rafael J. Wysocki, Jan Scholz, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes: > On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote: >> On Thursday 09 July 2009, Jan Scholz wrote: >> > Hi, >> > >> > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 >> > (I wanted to test this on v2.6.31-rc2 as well, but there I had other >> > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547) >> > >> > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails >> > with the test procedure described below, but it works fine when I revert >> > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 >> > "mac80211: cancel/restart all timers across suspend/resume" >> >> Thanks for the update. >> >> Johannes, do you have any idea what can go wrong here? > > Not really, no. __ieee80211_suspend isn't holding any locks that the > cancel_work_sync() calls could require or so afaict... > > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael > will correct me if I'm wrong) that should work on your platform, and put > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to > see where in there it's hanging? Did that, seems like it hangs in drv_remove_interface(local, &conf); Jan ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-11 14:36 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-11 14:36 UTC (permalink / raw) To: Jan Scholz Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville [-- Attachment #1: Type: text/plain, Size: 897 bytes --] On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote: > > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael > > will correct me if I'm wrong) that should work on your platform, and put > > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to > > see where in there it's hanging? > > Did that, seems like it hangs in > drv_remove_interface(local, &conf); Ok, thanks! I was going to suggest doing the same in b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think the problem is just that we have an ordering problem and call drv_stop before drv_remove_interface. I'll try to come up with a fix soon -- might not be able to today though, in the meantime I guess you can just move the drv_stop call to the end of the function and tell me if that works -- that would be racy but should be ok most of the time. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-11 14:36 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-11 14:36 UTC (permalink / raw) To: Jan Scholz Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville [-- Attachment #1: Type: text/plain, Size: 897 bytes --] On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote: > > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael > > will correct me if I'm wrong) that should work on your platform, and put > > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to > > see where in there it's hanging? > > Did that, seems like it hangs in > drv_remove_interface(local, &conf); Ok, thanks! I was going to suggest doing the same in b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think the problem is just that we have an ordering problem and call drv_stop before drv_remove_interface. I'll try to come up with a fix soon -- might not be able to today though, in the meantime I guess you can just move the drv_stop call to the end of the function and tell me if that works -- that would be racy but should be ok most of the time. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-11 17:20 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-11 17:20 UTC (permalink / raw) To: Johannes Berg Cc: Jan Scholz, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville Johannes Berg <johannes@sipsolutions.net> writes: > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote: > >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael >> > will correct me if I'm wrong) that should work on your platform, and put >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to >> > see where in there it's hanging? >> >> Did that, seems like it hangs in >> drv_remove_interface(local, &conf); > > Ok, thanks! I was going to suggest doing the same in > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think > the problem is just that we have an ordering problem and call drv_stop > before drv_remove_interface. I'll try to come up with a fix soon -- > might not be able to today though, in the meantime I guess you can just > move the drv_stop call to the end of the function and tell me if that > works -- that would be racy but should be ok most of the time. I moved drv_stop to the end of the function (see patch below) and now suspend works fine. Jan diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c index 7a549f9..0ac15fb 100644 --- a/net/mac80211/pm.c +++ b/net/mac80211/pm.c @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) /* flush again, in case driver queued work */ flush_workqueue(local->hw.workqueue); - /* stop hardware - this must stop RX */ - if (local->open_count) { - ieee80211_led_radio(local, false); - drv_stop(local); - } - /* remove STAs */ spin_lock_irqsave(&local->sta_lock, flags); list_for_each_entry(sta, &local->sta_list, list) { @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) drv_remove_interface(local, &conf); } + /* stop hardware - this must stop RX */ + if (local->open_count) { + ieee80211_led_radio(local, false); + drv_stop(local); + } + local->suspended = true; local->quiescing = false; ^ permalink raw reply related [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-11 17:20 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-11 17:20 UTC (permalink / raw) To: Johannes Berg Cc: Jan Scholz, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes: > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote: > >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael >> > will correct me if I'm wrong) that should work on your platform, and put >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to >> > see where in there it's hanging? >> >> Did that, seems like it hangs in >> drv_remove_interface(local, &conf); > > Ok, thanks! I was going to suggest doing the same in > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think > the problem is just that we have an ordering problem and call drv_stop > before drv_remove_interface. I'll try to come up with a fix soon -- > might not be able to today though, in the meantime I guess you can just > move the drv_stop call to the end of the function and tell me if that > works -- that would be racy but should be ok most of the time. I moved drv_stop to the end of the function (see patch below) and now suspend works fine. Jan diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c index 7a549f9..0ac15fb 100644 --- a/net/mac80211/pm.c +++ b/net/mac80211/pm.c @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) /* flush again, in case driver queued work */ flush_workqueue(local->hw.workqueue); - /* stop hardware - this must stop RX */ - if (local->open_count) { - ieee80211_led_radio(local, false); - drv_stop(local); - } - /* remove STAs */ spin_lock_irqsave(&local->sta_lock, flags); list_for_each_entry(sta, &local->sta_list, list) { @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) drv_remove_interface(local, &conf); } + /* stop hardware - this must stop RX */ + if (local->open_count) { + ieee80211_led_radio(local, false); + drv_stop(local); + } + local->suspended = true; local->quiescing = false; ^ permalink raw reply related [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-11 17:47 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-11 17:47 UTC (permalink / raw) To: Jan Scholz Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville [-- Attachment #1: Type: text/plain, Size: 2231 bytes --] On Sat, 2009-07-11 at 19:20 +0200, Jan Scholz wrote: > Johannes Berg <johannes@sipsolutions.net> writes: > > > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote: > > > >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael > >> > will correct me if I'm wrong) that should work on your platform, and put > >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to > >> > see where in there it's hanging? > >> > >> Did that, seems like it hangs in > >> drv_remove_interface(local, &conf); > > > > Ok, thanks! I was going to suggest doing the same in > > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think > > the problem is just that we have an ordering problem and call drv_stop > > before drv_remove_interface. I'll try to come up with a fix soon -- > > might not be able to today though, in the meantime I guess you can just > > move the drv_stop call to the end of the function and tell me if that > > works -- that would be racy but should be ok most of the time. > > I moved drv_stop to the end of the function (see patch below) and now > suspend works fine. Thanks, that's what I suspected -- I'll take a closer look into what is required to make it race-free against RX. johannes > Jan > > diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c > index 7a549f9..0ac15fb 100644 > --- a/net/mac80211/pm.c > +++ b/net/mac80211/pm.c > @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) > /* flush again, in case driver queued work */ > flush_workqueue(local->hw.workqueue); > > - /* stop hardware - this must stop RX */ > - if (local->open_count) { > - ieee80211_led_radio(local, false); > - drv_stop(local); > - } > - > /* remove STAs */ > spin_lock_irqsave(&local->sta_lock, flags); > list_for_each_entry(sta, &local->sta_list, list) { > @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) > drv_remove_interface(local, &conf); > } > > + /* stop hardware - this must stop RX */ > + if (local->open_count) { > + ieee80211_led_radio(local, false); > + drv_stop(local); > + } > + > local->suspended = true; > local->quiescing = false; > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-11 17:47 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-11 17:47 UTC (permalink / raw) To: Jan Scholz Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville [-- Attachment #1: Type: text/plain, Size: 2254 bytes --] On Sat, 2009-07-11 at 19:20 +0200, Jan Scholz wrote: > Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes: > > > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote: > > > >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael > >> > will correct me if I'm wrong) that should work on your platform, and put > >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to > >> > see where in there it's hanging? > >> > >> Did that, seems like it hangs in > >> drv_remove_interface(local, &conf); > > > > Ok, thanks! I was going to suggest doing the same in > > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think > > the problem is just that we have an ordering problem and call drv_stop > > before drv_remove_interface. I'll try to come up with a fix soon -- > > might not be able to today though, in the meantime I guess you can just > > move the drv_stop call to the end of the function and tell me if that > > works -- that would be racy but should be ok most of the time. > > I moved drv_stop to the end of the function (see patch below) and now > suspend works fine. Thanks, that's what I suspected -- I'll take a closer look into what is required to make it race-free against RX. johannes > Jan > > diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c > index 7a549f9..0ac15fb 100644 > --- a/net/mac80211/pm.c > +++ b/net/mac80211/pm.c > @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) > /* flush again, in case driver queued work */ > flush_workqueue(local->hw.workqueue); > > - /* stop hardware - this must stop RX */ > - if (local->open_count) { > - ieee80211_led_radio(local, false); > - drv_stop(local); > - } > - > /* remove STAs */ > spin_lock_irqsave(&local->sta_lock, flags); > list_for_each_entry(sta, &local->sta_list, list) { > @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) > drv_remove_interface(local, &conf); > } > > + /* stop hardware - this must stop RX */ > + if (local->open_count) { > + ieee80211_led_radio(local, false); > + drv_stop(local); > + } > + > local->suspended = true; > local->quiescing = false; > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.31-rc4: Reported regressions 2.6.29 -> 2.6.30 @ 2009-07-26 20:41 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:41 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-07-27 143 48 45 2009-07-07 138 50 46 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797 Subject : iBook G4 doesn't suspend since 2ed8d2b3a8 Submitter : Jörg Sommer <joerg@alea.gnuu.de> Date : 2009-07-18 20:18 (9 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795 Subject : abnormal boot and no suspend due to 'async' (fastboot) Submitter : Rafal Kaczynski <fscnoboot@wp.pl> Date : 2009-07-18 17:19 (9 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 Subject : NULL pointer dereference loading powernowk8 Submitter : Kurt Roeckx <kurt@roeckx.be> Date : 2009-07-15 18:00 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13751 Subject : oops on HP/Compaq 6910p lid closure Submitter : Bjorn Helgaas <bjorn.helgaas@hp.com> Date : 2009-07-09 15:17 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739 Subject : 2.6.30 leaking keys on console switch Submitter : Andi Kleen <andi@firstfloor.org> Date : 2009-07-07 8:44 (20 days old) References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4 Handled-By : Jiri Kosina <jkosina@suse.cz> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 Subject : A number of usb Devices causes Oops messages and kernel panics. Submitter : Alexander Kaltsas <alexkaltsas@gmail.com> Date : 2009-06-30 13:06 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte@naasa.net> Date : 2009-06-14 21:00 (43 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (30 days old) References : http://lkml.org/lkml/2009/6/27/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-06-22 12:08 (35 days old) References : http://lkml.org/lkml/2009/6/22/309 http://marc.info/?l=linux-kernel&m=124748600712853&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (38 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js@sig21.net> Date : 2009-06-16 01:27 (41 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber@kabelnet.at> Date : 2009-06-27 17:33 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list@phuk.ath.cx> Date : 2009-06-25 18:18 (32 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (32 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (32 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (38 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (38 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (39 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (40 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> Date : 2009-06-17 06:28 (40 days old) References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik@mail.ru> Date : 2009-06-12 09:51 (45 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (45 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (46 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (47 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> Date : 2009-06-05 1:37 (52 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (53 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-05-31 16:36 (57 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html http://lkml.org/lkml/2009/6/28/405 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (58 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (60 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (60 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (65 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (65 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (66 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (68 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (69 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (70 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (85 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (89 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 Handled-By : Johannes Berg <johannes@sipsolutions.net> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (88 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 Subject : hibernate slow on _second_ run Submitter : Johannes Berg <johannes@sipsolutions.net> Date : 2009-05-14 09:34 (74 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (87 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (107 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-06-20 15:27 (37 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel@csn.ul.ie> Patch : http://patchwork.kernel.org/patch/33130/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar@gmail.com> Date : 2009-06-02 10:00 (55 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Patch : http://patchwork.kernel.org/patch/28660/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (62 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.31-rc4: Reported regressions 2.6.29 -> 2.6.30 @ 2009-07-26 20:41 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:41 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List, Natalie Protasevich, Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-07-27 143 48 45 2009-07-07 138 50 46 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797 Subject : iBook G4 doesn't suspend since 2ed8d2b3a8 Submitter : Jörg Sommer <joerg@alea.gnuu.de> Date : 2009-07-18 20:18 (9 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795 Subject : abnormal boot and no suspend due to 'async' (fastboot) Submitter : Rafal Kaczynski <fscnoboot@wp.pl> Date : 2009-07-18 17:19 (9 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 Subject : NULL pointer dereference loading powernowk8 Submitter : Kurt Roeckx <kurt@roeckx.be> Date : 2009-07-15 18:00 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13751 Subject : oops on HP/Compaq 6910p lid closure Submitter : Bjorn Helgaas <bjorn.helgaas@hp.com> Date : 2009-07-09 15:17 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739 Subject : 2.6.30 leaking keys on console switch Submitter : Andi Kleen <andi@firstfloor.org> Date : 2009-07-07 8:44 (20 days old) References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4 Handled-By : Jiri Kosina <jkosina@suse.cz> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 Subject : A number of usb Devices causes Oops messages and kernel panics. Submitter : Alexander Kaltsas <alexkaltsas@gmail.com> Date : 2009-06-30 13:06 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte@naasa.net> Date : 2009-06-14 21:00 (43 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (30 days old) References : http://lkml.org/lkml/2009/6/27/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-06-22 12:08 (35 days old) References : http://lkml.org/lkml/2009/6/22/309 http://marc.info/?l=linux-kernel&m=124748600712853&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (38 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js@sig21.net> Date : 2009-06-16 01:27 (41 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber@kabelnet.at> Date : 2009-06-27 17:33 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list@phuk.ath.cx> Date : 2009-06-25 18:18 (32 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (32 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (32 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (38 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (38 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (39 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (40 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> Date : 2009-06-17 06:28 (40 days old) References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik@mail.ru> Date : 2009-06-12 09:51 (45 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (45 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (46 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (47 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> Date : 2009-06-05 1:37 (52 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (53 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-05-31 16:36 (57 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html http://lkml.org/lkml/2009/6/28/405 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (58 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (60 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (60 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (65 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (65 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (66 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (68 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (69 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (70 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (85 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (89 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 Handled-By : Johannes Berg <johannes@sipsolutions.net> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (88 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 Subject : hibernate slow on _second_ run Submitter : Johannes Berg <johannes@sipsolutions.net> Date : 2009-05-14 09:34 (74 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (87 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (107 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-06-20 15:27 (37 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel@csn.ul.ie> Patch : http://patchwork.kernel.org/patch/33130/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar@gmail.com> Date : 2009-06-02 10:00 (55 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Patch : http://patchwork.kernel.org/patch/28660/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (62 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13109] High latency on /sys/class/thermal 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:41 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:41 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexey Starikovskiy, Tiago Simões Batista, Zhang Rui This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (107 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13109] High latency on /sys/class/thermal @ 2009-07-26 20:41 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:41 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexey Starikovskiy, Tiago Simões Batista, Zhang Rui This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Sim√µes Batista <tiagosbatista-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-04-11 14:56 (107 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Alexey Starikovskiy <astarikovskiy-l3A5Bk7waGM@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb 2009-07-26 20:41 ` Rafael J. Wysocki (?) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 0:17 ` Larry Finger -1 siblings, 1 reply; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-07-26 20:45 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki @ 2009-07-27 0:17 ` Larry Finger 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 0:17 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-07-27 0:17 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > Subject : Page allocation failures with b43 and p54usb > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > Date : 2009-04-29 21:01 (89 days old) > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > http://lkml.org/lkml/2009/6/7/136 > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60 entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org> and dated Wed Jun 10 18:50:32 2009 +0300. The fault occurred because when CONFIG_SLUB_DEBUG was set, many of the memory allocations for wireless buffers were increased from O(0) to O(1) causing memory fragmentation, and eventually there were no remaining O(1) fragments. This problem is unlikely to affect most users as none of the distos turn on the above debug option. This bug should be marked "closed with patch". Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 0:24 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 0:24 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-27 0:24 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Pekka Enberg On Sun, 26 Jul 2009, Larry Finger wrote: > Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > > Subject : Page allocation failures with b43 and p54usb > > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > > Date : 2009-04-29 21:01 (89 days old) > > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > > http://lkml.org/lkml/2009/6/7/136 > > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > > This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60 > entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg > <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org> and dated Wed Jun 10 18:50:32 2009 +0300. > Hmm, I'm remembering differently. I thought the root problem here has only been fixed in Pekka's slab-2.6.git tree with "slub: add option to disable higher order debugging slabs" and isn't currently in Linus' tree. > The fault occurred because when CONFIG_SLUB_DEBUG was set, many of the > memory allocations for wireless buffers were increased from O(0) to > O(1) causing memory fragmentation, and eventually there were no > remaining O(1) fragments. This problem is unlikely to affect most > users as none of the distos turn on the above debug option. > It only happens when CONFIG_SLUB_DEBUG_ON is enabled for caches with sizes that increase as the result of the added metadata. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 7:08 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 7:08 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-07-27 7:08 UTC (permalink / raw) To: David Rientjes Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Christoph Lameter On Mon, Jul 27, 2009 at 3:24 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > On Sun, 26 Jul 2009, Larry Finger wrote: > >> Rafael J. Wysocki wrote: >> > This message has been generated automatically as a part of a report >> > of regressions introduced between 2.6.29 and 2.6.30. >> > >> > The following bug entry is on the current list of known regressions >> > introduced between 2.6.29 and 2.6.30. Please verify if it still should >> > be listed and let me know (either way). >> > >> > >> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 >> > Subject : Page allocation failures with b43 and p54usb >> > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> >> > Date : 2009-04-29 21:01 (89 days old) >> > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 >> > http://lkml.org/lkml/2009/6/7/136 >> > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> >> >> This bug was fixed by commit 781b2ba6eb5f22440afac9c79a89ebd6e3674a60 >> entitled "SLUB: Out-of-memory diagnostics" by Pekka Enberg >> <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org> and dated Wed Jun 10 18:50:32 2009 +0300. >> > > Hmm, I'm remembering differently. I thought the root problem here has > only been fixed in Pekka's slab-2.6.git tree with "slub: add option to > disable higher order debugging slabs" and isn't currently in Linus' tree. Yup, the fix is in slab.git and queued for 2.6.32. There was some complaints from Christoph from the patch that need to be addressed still. Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 9:37 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 9:37 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-27 9:37 UTC (permalink / raw) To: Pekka Enberg Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Christoph Lameter [-- Attachment #1: Type: TEXT/PLAIN, Size: 1169 bytes --] On Mon, 27 Jul 2009, Pekka Enberg wrote: > > Hmm, I'm remembering differently. I thought the root problem here has > > only been fixed in Pekka's slab-2.6.git tree with "slub: add option to > > disable higher order debugging slabs" and isn't currently in Linus' tree. > > Yup, the fix is in slab.git and queued for 2.6.32. There was some > complaints from Christoph from the patch that need to be addressed > still. > From what I recall, he asked that calculate_sizes() be called twice, first to determine if get_order(s->size) increased as the result of the metadata and, if so, a second time with the flags disabled. slab_debug=O only disables debugging options that increase the min order of slab as defined in DEBUG_FLAGS; it doesn't selectively disable some of them when get_order(s->size) grows. So it's quite sane, like my patch does, to disable all DEBUG_FLAGS when get_order(s->objsize) + DEBUG_SIZE_FLAGS > get_order(s->objsize) without calling calculate_sizes() twice. We need DEBUG_FLAGS to determine which flags to mask off to reduce the minimum order, so I don't see DEBUG_FLAGS_SIZE as troublesome. Christoph? ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 17:20 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 17:20 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 18:16 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 18:16 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 21:43 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-27 21:43 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ 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 2009-07-28 1:30 ` David Rientjes -1 siblings, 1 reply; 467+ 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] 467+ messages in thread
* [patch] slub: use size and objsize orders to disable debug flags @ 2009-07-28 1:30 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-28 1:30 UTC (permalink / raw) To: Pekka Enberg Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg This patch moves the masking of debugging flags which increase a cache's min order due to metadata when `slub_debug=O' is used from kmem_cache_flags() to kmem_cache_open(). Instead of defining the maximum metadata size increase in a preprocessor macro, this approach uses the cache's ->size and ->objsize members to determine if the min order increased due to debugging options. If so, the flags specified in the more appropriately named DEBUG_METADATA_FLAGS are masked off. This approach was suggested by Christoph Lameter <cl@linux-foundation.org>. Cc: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: David Rientjes <rientjes@google.com> --- mm/slub.c | 40 +++++++++++++++++++--------------------- 1 files changed, 19 insertions(+), 21 deletions(-) diff --git a/mm/slub.c b/mm/slub.c --- a/mm/slub.c +++ b/mm/slub.c @@ -142,11 +142,11 @@ SLAB_POISON | SLAB_STORE_USER) /* - * Debugging flags that require metadata to be stored in the slab, up to - * DEBUG_SIZE in size. + * Debugging flags that require metadata to be stored in the slab. These get + * disabled when slub_debug=O is used and a cache's min order increases with + * metadata. */ -#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER) -#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track)) +#define DEBUG_METADATA_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER) /* * Set of flags that will prevent slab merging @@ -1040,27 +1040,13 @@ static unsigned long kmem_cache_flags(unsigned long objsize, unsigned long flags, const char *name, void (*ctor)(void *)) { - int debug_flags = slub_debug; - /* * Enable debugging if selected on the kernel commandline. */ - if (debug_flags) { - if (slub_debug_slabs && - strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs))) - goto out; - - /* - * Disable debugging that increases slab size if the minimum - * slab order would have increased as a result. - */ - if (disable_higher_order_debug && - get_order(objsize + DEBUG_SIZE) > get_order(objsize)) - debug_flags &= ~DEBUG_SIZE_FLAGS; + if (slub_debug && (!slub_debug_slabs || + !strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs)))) + flags |= slub_debug; - flags |= debug_flags; - } -out: return flags; } #else @@ -2488,6 +2474,18 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, if (!calculate_sizes(s, -1)) goto error; + if (disable_higher_order_debug) { + /* + * Disable debugging flags that store metadata if the min slab + * order increased. + */ + if (get_order(s->size) > get_order(s->objsize)) { + s->flags &= ~DEBUG_METADATA_FLAGS; + s->offset = 0; + if (!calculate_sizes(s, -1)) + goto error; + } + } /* * The larger the object size is, the more pages we want on the partial ^ permalink raw reply [flat|nested] 467+ messages in thread
* [patch] slub: use size and objsize orders to disable debug flags @ 2009-07-28 1:30 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-28 1:30 UTC (permalink / raw) To: Pekka Enberg Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg This patch moves the masking of debugging flags which increase a cache's min order due to metadata when `slub_debug=O' is used from kmem_cache_flags() to kmem_cache_open(). Instead of defining the maximum metadata size increase in a preprocessor macro, this approach uses the cache's ->size and ->objsize members to determine if the min order increased due to debugging options. If so, the flags specified in the more appropriately named DEBUG_METADATA_FLAGS are masked off. This approach was suggested by Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>. Cc: Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Signed-off-by: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> --- mm/slub.c | 40 +++++++++++++++++++--------------------- 1 files changed, 19 insertions(+), 21 deletions(-) diff --git a/mm/slub.c b/mm/slub.c --- a/mm/slub.c +++ b/mm/slub.c @@ -142,11 +142,11 @@ SLAB_POISON | SLAB_STORE_USER) /* - * Debugging flags that require metadata to be stored in the slab, up to - * DEBUG_SIZE in size. + * Debugging flags that require metadata to be stored in the slab. These get + * disabled when slub_debug=O is used and a cache's min order increases with + * metadata. */ -#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER) -#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track)) +#define DEBUG_METADATA_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER) /* * Set of flags that will prevent slab merging @@ -1040,27 +1040,13 @@ static unsigned long kmem_cache_flags(unsigned long objsize, unsigned long flags, const char *name, void (*ctor)(void *)) { - int debug_flags = slub_debug; - /* * Enable debugging if selected on the kernel commandline. */ - if (debug_flags) { - if (slub_debug_slabs && - strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs))) - goto out; - - /* - * Disable debugging that increases slab size if the minimum - * slab order would have increased as a result. - */ - if (disable_higher_order_debug && - get_order(objsize + DEBUG_SIZE) > get_order(objsize)) - debug_flags &= ~DEBUG_SIZE_FLAGS; + if (slub_debug && (!slub_debug_slabs || + !strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs)))) + flags |= slub_debug; - flags |= debug_flags; - } -out: return flags; } #else @@ -2488,6 +2474,18 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, if (!calculate_sizes(s, -1)) goto error; + if (disable_higher_order_debug) { + /* + * Disable debugging flags that store metadata if the min slab + * order increased. + */ + if (get_order(s->size) > get_order(s->objsize)) { + s->flags &= ~DEBUG_METADATA_FLAGS; + s->offset = 0; + if (!calculate_sizes(s, -1)) + goto error; + } + } /* * The larger the object size is, the more pages we want on the partial ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [patch] slub: use size and objsize orders to disable debug flags @ 2009-07-28 7:53 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-07-28 7:53 UTC (permalink / raw) To: David Rientjes Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg David Rientjes wrote: > This patch moves the masking of debugging flags which increase a cache's > min order due to metadata when `slub_debug=O' is used from > kmem_cache_flags() to kmem_cache_open(). > > Instead of defining the maximum metadata size increase in a preprocessor > macro, this approach uses the cache's ->size and ->objsize members to > determine if the min order increased due to debugging options. If so, > the flags specified in the more appropriately named DEBUG_METADATA_FLAGS > are masked off. > > This approach was suggested by Christoph Lameter > <cl@linux-foundation.org>. > > Cc: Christoph Lameter <cl@linux-foundation.org> > Signed-off-by: David Rientjes <rientjes@google.com> Applied, thanks! ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [patch] slub: use size and objsize orders to disable debug flags @ 2009-07-28 7:53 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-07-28 7:53 UTC (permalink / raw) To: David Rientjes Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg David Rientjes wrote: > This patch moves the masking of debugging flags which increase a cache's > min order due to metadata when `slub_debug=O' is used from > kmem_cache_flags() to kmem_cache_open(). > > Instead of defining the maximum metadata size increase in a preprocessor > macro, this approach uses the cache's ->size and ->objsize members to > determine if the min order increased due to debugging options. If so, > the flags specified in the more appropriately named DEBUG_METADATA_FLAGS > are masked off. > > This approach was suggested by Christoph Lameter > <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>. > > Cc: Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> > Signed-off-by: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Applied, thanks! ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [patch] slub: use size and objsize orders to disable debug flags @ 2009-08-03 14:56 ` Christoph Lameter 0 siblings, 0 replies; 467+ messages in thread From: Christoph Lameter @ 2009-08-03 14:56 UTC (permalink / raw) To: David Rientjes Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Acked-by: Christoph Lameter <cl@linux-foundation.org> On Mon, 27 Jul 2009, David Rientjes wrote: > @@ -2488,6 +2474,18 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, > > if (!calculate_sizes(s, -1)) > goto error; > + if (disable_higher_order_debug) { > + /* > + * Disable debugging flags that store metadata if the min slab > + * order increased. > + */ > + if (get_order(s->size) > get_order(s->objsize)) { > + s->flags &= ~DEBUG_METADATA_FLAGS; > + s->offset = 0; Hmmm... Move this line into calculate_sizes()? ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [patch] slub: use size and objsize orders to disable debug flags @ 2009-08-03 14:56 ` Christoph Lameter 0 siblings, 0 replies; 467+ messages in thread From: Christoph Lameter @ 2009-08-03 14:56 UTC (permalink / raw) To: David Rientjes Cc: Pekka Enberg, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Acked-by: Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> On Mon, 27 Jul 2009, David Rientjes wrote: > @@ -2488,6 +2474,18 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, > > if (!calculate_sizes(s, -1)) > goto error; > + if (disable_higher_order_debug) { > + /* > + * Disable debugging flags that store metadata if the min slab > + * order increased. > + */ > + if (get_order(s->size) > get_order(s->objsize)) { > + s->flags &= ~DEBUG_METADATA_FLAGS; > + s->offset = 0; Hmmm... Move this line into calculate_sizes()? ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13341] Random Oops at boot at loading ip6tables rules 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, patrick, Rusty Russell This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (69 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13341] Random Oops at boot at loading ip6tables rules @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, patrick-nxAOmsU53hB6lmGzAMPh1A, Rusty Russell This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick-nxAOmsU53hB6lmGzAMPh1A@public.gmane.org> Date : 2009-05-19 09:08 (69 days old) Handled-By : Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13318] AGP doesn't work anymore on nforce2 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer, Shaohua Li This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (88 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li@intel.com> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13318] AGP doesn't work anymore on nforce2 @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Airlie, Jerome Glisse, Karsten Mehrhoff, Michel Dänzer, Shaohua Li This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org> Date : 2009-04-30 8:51 (88 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 2009-07-26 20:41 ` Rafael J. Wysocki ` (4 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, David Hill This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (87 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Tomas Janousek This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (70 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Tomas Janousek This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org> Date : 2009-05-18 10:59 (70 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13306] hibernate slow on _second_ run 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ 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 This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. 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 (74 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13306] hibernate slow on _second_ run @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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 This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 Subject : hibernate slow on _second_ run Submitter : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> Date : 2009-05-14 09:34 (74 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13306] hibernate slow on _second_ run 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-27 8:16 ` Johannes Berg -1 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-27 8:16 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 428 bytes --] On Sun, 2009-07-26 at 22:45 +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). The problem persists in 31-rc3. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13306] hibernate slow on _second_ run @ 2009-07-27 8:16 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-27 8:16 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 428 bytes --] On Sun, 2009-07-26 at 22:45 +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). The problem persists in 31-rc3. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug 13306] hibernate slow on _second_ run 2009-07-27 8:16 ` Johannes Berg (?) @ 2009-07-27 21:09 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:09 UTC (permalink / raw) To: Johannes Berg Cc: Linux Kernel Mailing List, Kernel Testers List, bugzilla-daemon On Monday 27 July 2009, Johannes Berg wrote: > On Sun, 2009-07-26 at 22:45 +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > The problem persists in 31-rc3. Thanks for the update. Unfortunately, I have no idea about what's wrong here. Generally, there are three possible areas the problem may be related to: (1) interrupts, (2) CPU hotplug, (3) ordering of the platform callbacks, but I can't say much more than that. ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. 2009-07-26 20:41 ` Rafael J. Wysocki ` (7 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Francis Moreau, netdev This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (85 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Ingo Molnar, unggnu, Yinghai Lu This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (68 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Ingo Molnar, unggnu-gM/Ye1E23mwN+BqQ9rBEUg, Yinghai Lu This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> Date : 2009-05-20 14:09 (68 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Frans Pop This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (62 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Frans Pop This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> Date : 2009-05-26 15:24 (62 days old) Handled-By : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-27 1:22 ` Frans Pop -1 siblings, 0 replies; 467+ messages in thread From: Frans Pop @ 2009-07-27 1:22 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Len Brown, rui.zhang On Sunday 26 July 2009, Rafael J. Wysocki wrote: > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > Subject : Warning 'Invalid throttling state, reset' gets displayed > when it should not be > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > http://bugzilla.kernel.org/attachment.cgi?id=21672 Rui has acked the patches [1], but AFAIK Len has not yet picked them up. [1] http://lkml.org/lkml/2009/7/7/474 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-27 1:22 ` Frans Pop 0 siblings, 0 replies; 467+ messages in thread From: Frans Pop @ 2009-07-27 1:22 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Len Brown, rui.zhang-ral2JQCrhuEAvxtiuMwx3w On Sunday 26 July 2009, Rafael J. Wysocki wrote: > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > Subject : Warning 'Invalid throttling state, reset' gets displayed > when it should not be > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > http://bugzilla.kernel.org/attachment.cgi?id=21672 Rui has acked the patches [1], but AFAIK Len has not yet picked them up. [1] http://lkml.org/lkml/2009/7/7/474 ^ permalink raw reply [flat|nested] 467+ messages in thread
[parent not found: <200907270322.47523.elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>]
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be 2009-07-27 1:22 ` Frans Pop @ 2009-07-27 21:25 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:25 UTC (permalink / raw) To: Frans Pop Cc: Linux Kernel Mailing List, Kernel Testers List, rui.zhang-ral2JQCrhuEAvxtiuMwx3w, ACPI Devel Maling List, Len Brown On Monday 27 July 2009, Frans Pop wrote: > On Sunday 26 July 2009, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > > Subject : Warning 'Invalid throttling state, reset' gets displayed > > when it should not be > > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > > http://bugzilla.kernel.org/attachment.cgi?id=21672 > > Rui has acked the patches [1], but AFAIK Len has not yet picked them up. > > [1] http://lkml.org/lkml/2009/7/7/474 No, Len hasn't picked them up, but he's not been responsive recently in general. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-27 21:25 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:25 UTC (permalink / raw) To: Frans Pop Cc: Linux Kernel Mailing List, Kernel Testers List, rui.zhang, ACPI Devel Maling List, Len Brown On Monday 27 July 2009, Frans Pop wrote: > On Sunday 26 July 2009, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > > Subject : Warning 'Invalid throttling state, reset' gets displayed > > when it should not be > > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > > http://bugzilla.kernel.org/attachment.cgi?id=21672 > > Rui has acked the patches [1], but AFAIK Len has not yet picked them up. > > [1] http://lkml.org/lkml/2009/7/7/474 No, Len hasn't picked them up, but he's not been responsive recently in general. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alejandro Riveira, Chris Wright, Johannes Berg, John W. Linville This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (66 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alejandro Riveira, Chris Wright, Johannes Berg, John W. Linville This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-05-22 13:32 (66 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-08-02 13:45 ` Alejandro Riveira Fernández -1 siblings, 0 replies; 467+ messages in thread From: Alejandro Riveira Fernández @ 2009-08-02 13:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright, Johannes Berg, John W. Linville El Sun, 26 Jul 2009 22:45:27 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> escribió: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). Sorry for the delay i did not have the time to test 2.6.31-rc* until now. Tried 2.6.31-rc5 the problem persist. The revert still fixes the issue; so the bug should be still present. > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 > Subject : rt2x00: slow wifi with correct basic rate bitmap > Submitter : Alejandro Riveira <ariveira@gmail.com> > Date : 2009-05-22 13:32 (66 days old) > > Thanks; Alejandro ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap @ 2009-08-02 13:45 ` Alejandro Riveira Fernández 0 siblings, 0 replies; 467+ messages in thread From: Alejandro Riveira Fernández @ 2009-08-02 13:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright, Johannes Berg, John W. Linville El Sun, 26 Jul 2009 22:45:27 +0200 (CEST) "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> escribió: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). Sorry for the delay i did not have the time to test 2.6.31-rc* until now. Tried 2.6.31-rc5 the problem persist. The revert still fixes the issue; so the bug should be still present. > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 > Subject : rt2x00: slow wifi with correct basic rate bitmap > Submitter : Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2009-05-22 13:32 (66 days old) > > Thanks; Alejandro ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap 2009-08-02 13:45 ` Alejandro Riveira Fernández @ 2009-08-02 20:30 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-02 20:30 UTC (permalink / raw) To: Alejandro Riveira Fernández Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright, Johannes Berg, John W. Linville On Sunday 02 August 2009, Alejandro Riveira Fernández wrote: > El Sun, 26 Jul 2009 22:45:27 +0200 (CEST) > "Rafael J. Wysocki" <rjw@sisk.pl> escribió: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > Sorry for the delay i did not have the time to test 2.6.31-rc* until now. > Tried 2.6.31-rc5 the problem persist. The revert still fixes the issue; so > the bug should be still present. > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 > > Subject : rt2x00: slow wifi with correct basic rate bitmap > > Submitter : Alejandro Riveira <ariveira@gmail.com> > > Date : 2009-05-22 13:32 (66 days old) Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap @ 2009-08-02 20:30 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-02 20:30 UTC (permalink / raw) To: Alejandro Riveira Fernández Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright, Johannes Berg, John W. Linville On Sunday 02 August 2009, Alejandro Riveira Fernández wrote: > El Sun, 26 Jul 2009 22:45:27 +0200 (CEST) > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> escribió: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > Sorry for the delay i did not have the time to test 2.6.31-rc* until now. > Tried 2.6.31-rc5 the problem persist. The revert still fixes the issue; so > the bug should be still present. > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 > > Subject : rt2x00: slow wifi with correct basic rate bitmap > > Submitter : Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Date : 2009-05-22 13:32 (66 days old) Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Miles Lane This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (65 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Miles Lane This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-05-23 5:08 (65 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected) 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jens Axboe, Laurent Riffard This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (60 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected) @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jens Axboe, Laurent Riffard This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard-GANU6spQydw@public.gmane.org> Date : 2009-05-28 18:43 (60 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13374] reiserfs blocked for more than 120secs 2009-07-26 20:41 ` Rafael J. Wysocki ` (13 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Harald Dunkel This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (65 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13407] adb trackpad disappears after suspend to ram 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Benjamin Herrenschmidt, Jan Scholz, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (60 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13407] adb trackpad disappears after suspend to ram @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Benjamin Herrenschmidt, Jan Scholz, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org> Date : 2009-05-28 7:59 (60 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13407] adb trackpad disappears after suspend to ram 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-28 14:49 ` Jan Scholz -1 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-28 14:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Benjamin Herrenschmidt, Jan Scholz Hi, The bug is still present in v2.6.31-rc4, it is fixed by commenting out {suspend,resume}_device_irqs() in drivers/base/power/main.c as suggested by Rafael. Any success in reproducing it? Regards, Jan "Rafael J. Wysocki" <rjw@sisk.pl> writes: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 > Subject : adb trackpad disappears after suspend to ram > Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> > Date : 2009-05-28 7:59 (60 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 > References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 > Handled-By : Rafael J. Wysocki <rjw@sisk.pl> > > > -- Jan Scholz ____ ____ __ ___ ( ___)(_ _) /__\ / __) Frankfurt Institute for Advanced Studies )__) _)(_ /(__)\ \__ \ (__) (____)(__)(__)(___/ Goethe Universitaet Frankfurt Ruth-Moufang-Str. 1 Tel. 069-798-47534 60438 Frankfurt am Main ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13407] adb trackpad disappears after suspend to ram @ 2009-07-28 14:49 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-28 14:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Benjamin Herrenschmidt, Jan Scholz Hi, The bug is still present in v2.6.31-rc4, it is fixed by commenting out {suspend,resume}_device_irqs() in drivers/base/power/main.c as suggested by Rafael. Any success in reproducing it? Regards, Jan "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 > Subject : adb trackpad disappears after suspend to ram > Submitter : Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org> > Date : 2009-05-28 7:59 (60 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 > References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 > Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> > > > -- Jan Scholz ____ ____ __ ___ ( ___)(_ _) /__\ / __) Frankfurt Institute for Advanced Studies )__) _)(_ /(__)\ \__ \ (__) (____)(__)(__)(___/ Goethe Universitaet Frankfurt Ruth-Moufang-Str. 1 Tel. 069-798-47534 60438 Frankfurt am Main ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13424] possible deadlock when doing governor switching 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Mathieu Desnoyers, Shaohua Li This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-05-31 16:36 (57 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html http://lkml.org/lkml/2009/6/28/405 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13424] possible deadlock when doing governor switching @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Mathieu Desnoyers, Shaohua Li This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Date : 2009-05-31 16:36 (57 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html http://lkml.org/lkml/2009/6/28/405 Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-27 16:48 ` Mathieu Desnoyers -1 siblings, 0 replies; 467+ messages in thread From: Mathieu Desnoyers @ 2009-07-27 16:48 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Shaohua Li It should be fixed now by recents commits to the cpufreq tree, which got into mainline: 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9 b253d2b2d28ead6fed012feb54694b3d0562839a b14893a62c73af0eca414cfed505b8c09efc613c 7d26e2d5e2da37e92c6c7644b26b294dedd8c982 37c90e8887efd218dc4af949b7f498ca2da4af9f 5a75c82828e7c088ca6e7b4827911dc29cc8e774 ee88415caf736b89500f16e0a545614541a45005 3f4a782b5ce2698b1870b5a7b573cd721d4fce33 5e1596f75395e7a402e1059c518e633d2732dcf8 Mathieu * Rafael J. Wysocki (rjw@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=13424 > Subject : possible deadlock when doing governor switching > Submitter : Shaohua Li <shaohua.li@intel.com> > Date : 2009-05-31 16:36 (57 days old) > References : http://www.spinics.net/lists/cpufreq/msg00711.html > http://lkml.org/lkml/2009/6/28/405 > Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> > > > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching @ 2009-07-27 16:48 ` Mathieu Desnoyers 0 siblings, 0 replies; 467+ messages in thread From: Mathieu Desnoyers @ 2009-07-27 16:48 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Shaohua Li It should be fixed now by recents commits to the cpufreq tree, which got into mainline: 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9 b253d2b2d28ead6fed012feb54694b3d0562839a b14893a62c73af0eca414cfed505b8c09efc613c 7d26e2d5e2da37e92c6c7644b26b294dedd8c982 37c90e8887efd218dc4af949b7f498ca2da4af9f 5a75c82828e7c088ca6e7b4827911dc29cc8e774 ee88415caf736b89500f16e0a545614541a45005 3f4a782b5ce2698b1870b5a7b573cd721d4fce33 5e1596f75395e7a402e1059c518e633d2732dcf8 Mathieu * Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 > Subject : possible deadlock when doing governor switching > Submitter : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > Date : 2009-05-31 16:36 (57 days old) > References : http://www.spinics.net/lists/cpufreq/msg00711.html > http://lkml.org/lkml/2009/6/28/405 > Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org> > > > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching 2009-07-27 16:48 ` Mathieu Desnoyers @ 2009-07-27 21:38 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:38 UTC (permalink / raw) To: Mathieu Desnoyers Cc: Linux Kernel Mailing List, Kernel Testers List, Shaohua Li On Monday 27 July 2009, Mathieu Desnoyers wrote: > It should be fixed now by recents commits to the cpufreq tree, which got > into mainline: > > 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9 > b253d2b2d28ead6fed012feb54694b3d0562839a > b14893a62c73af0eca414cfed505b8c09efc613c > 7d26e2d5e2da37e92c6c7644b26b294dedd8c982 > 37c90e8887efd218dc4af949b7f498ca2da4af9f > 5a75c82828e7c088ca6e7b4827911dc29cc8e774 > ee88415caf736b89500f16e0a545614541a45005 > 3f4a782b5ce2698b1870b5a7b573cd721d4fce33 > 5e1596f75395e7a402e1059c518e633d2732dcf8 Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching @ 2009-07-27 21:38 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:38 UTC (permalink / raw) To: Mathieu Desnoyers Cc: Linux Kernel Mailing List, Kernel Testers List, Shaohua Li On Monday 27 July 2009, Mathieu Desnoyers wrote: > It should be fixed now by recents commits to the cpufreq tree, which got > into mainline: > > 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9 > b253d2b2d28ead6fed012feb54694b3d0562839a > b14893a62c73af0eca414cfed505b8c09efc613c > 7d26e2d5e2da37e92c6c7644b26b294dedd8c982 > 37c90e8887efd218dc4af949b7f498ca2da4af9f > 5a75c82828e7c088ca6e7b4827911dc29cc8e774 > ee88415caf736b89500f16e0a545614541a45005 > 3f4a782b5ce2698b1870b5a7b573cd721d4fce33 > 5e1596f75395e7a402e1059c518e633d2732dcf8 Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13408] Performance regression in 2.6.30-rc7 2009-07-26 20:41 ` Rafael J. Wysocki ` (16 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrew Morton, Diego Calleja This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (58 days old) References : http://lkml.org/lkml/2009/5/30/146 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, ACPI Devel Maling List, Ozan Çağlayan This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan-caicS1wCkhO6A22drWdTBw@public.gmane.org> Date : 2009-06-04 9:12 (53 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, ACPI Devel Maling List, Ozan Çağlayan This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (53 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled 2009-07-26 20:45 ` Rafael J. Wysocki (?) @ 2009-07-31 14:14 ` Alan Cox [not found] ` <20090731151417.568094e5-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> -1 siblings, 1 reply; 467+ messages in thread From: Alan Cox @ 2009-07-31 14:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, ACPI Devel Maling List, Ozan Çağlayan On Sun, 26 Jul 2009 22:45:29 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). Ozan - can you confirm it broke between 2.6.29 (ie you tested 2.6.29), and 2.6.30-rc1. If so I have an idea what is going on Alan ^ permalink raw reply [flat|nested] 467+ messages in thread
[parent not found: <20090731151417.568094e5-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>]
* Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled 2009-07-31 14:14 ` Alan Cox [not found] ` <20090731151417.568094e5-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> @ 2009-07-31 15:08 ` Ozan Çağlayan 0 siblings, 0 replies; 467+ messages in thread From: Ozan Çağlayan @ 2009-07-31 15:08 UTC (permalink / raw) To: Alan Cox Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, ACPI Devel Maling List Alan Cox wrote: > On Sun, 26 Jul 2009 22:45:29 +0200 (CEST) > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > >> This message has been generated automatically as a part of a report >> of regressions introduced between 2.6.29 and 2.6.30. >> >> The following bug entry is on the current list of known regressions >> introduced between 2.6.29 and 2.6.30. Please verify if it still should >> be listed and let me know (either way). >> > > > Ozan - can you confirm it broke between 2.6.29 (ie you tested 2.6.29), > and 2.6.30-rc1. If so I have an idea what is going on > >From my last comment on bugzilla.kernel.org: "I tried with 2.6.30.1 but the problem still persists. I really don't have time to bisect it, but I can help with any other debugging outputs. I also started think that my board could somehow be faulty as no other people complains about a similar issue. Finally, it seems that the problem is available with 2.6.28, so the starting point is still fuzzy to me. I remember that the keyboard was working OK with 2.6.29_rc7 but now it's not. Maybe we should drop this report from the regression list." Monday I'll have access to the computer. I'll build and try to find the last working version. Meanwhile, I'd like to hear about your possible finding. Thanks, ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled @ 2009-07-31 15:08 ` Ozan Çağlayan 0 siblings, 0 replies; 467+ messages in thread From: Ozan Çağlayan @ 2009-07-31 15:08 UTC (permalink / raw) To: Alan Cox Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, ACPI Devel Maling List Alan Cox wrote: > On Sun, 26 Jul 2009 22:45:29 +0200 (CEST) > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > >> This message has been generated automatically as a part of a report >> of regressions introduced between 2.6.29 and 2.6.30. >> >> The following bug entry is on the current list of known regressions >> introduced between 2.6.29 and 2.6.30. Please verify if it still should >> be listed and let me know (either way). >> > > > Ozan - can you confirm it broke between 2.6.29 (ie you tested 2.6.29), > and 2.6.30-rc1. If so I have an idea what is going on > From my last comment on bugzilla.kernel.org: "I tried with 2.6.30.1 but the problem still persists. I really don't have time to bisect it, but I can help with any other debugging outputs. I also started think that my board could somehow be faulty as no other people complains about a similar issue. Finally, it seems that the problem is available with 2.6.28, so the starting point is still fuzzy to me. I remember that the keyboard was working OK with 2.6.29_rc7 but now it's not. Maybe we should drop this report from the regression list." Monday I'll have access to the computer. I'll build and try to find the last working version. Meanwhile, I'd like to hear about your possible finding. Thanks, ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled @ 2009-07-31 15:08 ` Ozan Çağlayan 0 siblings, 0 replies; 467+ messages in thread From: Ozan Çağlayan @ 2009-07-31 15:08 UTC (permalink / raw) To: Alan Cox Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, ACPI Devel Maling List Alan Cox wrote: > On Sun, 26 Jul 2009 22:45:29 +0200 (CEST) > "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > > >> This message has been generated automatically as a part of a report >> of regressions introduced between 2.6.29 and 2.6.30. >> >> The following bug entry is on the current list of known regressions >> introduced between 2.6.29 and 2.6.30. Please verify if it still should >> be listed and let me know (either way). >> > > > Ozan - can you confirm it broke between 2.6.29 (ie you tested 2.6.29), > and 2.6.30-rc1. If so I have an idea what is going on > >From my last comment on bugzilla.kernel.org: "I tried with 2.6.30.1 but the problem still persists. I really don't have time to bisect it, but I can help with any other debugging outputs. I also started think that my board could somehow be faulty as no other people complains about a similar issue. Finally, it seems that the problem is available with 2.6.28, so the starting point is still fuzzy to me. I remember that the keyboard was working OK with 2.6.29_rc7 but now it's not. Maybe we should drop this report from the regression list." Monday I'll have access to the computer. I'll build and try to find the last working version. Meanwhile, I'd like to hear about your possible finding. Thanks, ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled 2009-07-31 15:08 ` Ozan Çağlayan (?) (?) @ 2009-07-31 15:17 ` Alan Cox [not found] ` <20090731161735.6a94ad9c-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> -1 siblings, 1 reply; 467+ messages in thread From: Alan Cox @ 2009-07-31 15:17 UTC (permalink / raw) To: Ozan Çağlayan Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, ACPI Devel Maling List O> Finally, it seems that the problem is available with 2.6.28, so the starting > point is still fuzzy to me. I remember that the keyboard was working OK with > 2.6.29_rc7 but now it's not. > > Maybe we should drop this report from the regression list." > > > Monday I'll have access to the computer. I'll build and try to find the last working version. > Meanwhile, I'd like to hear about your possible finding. There have been few changes to parport_pc but one thing recent changed the probe for SuperIO chips via low addresses and that could be interfering. commit e2434dc1c19412639dd047a4d4eff8ed0e5d0d50 Author: Jens Rottmann <JRottmann@LiPPERTEmbedded.de> Date: Mon Jun 22 16:51:49 2009 +0100 changed the behaviour slightly (hence asking about which release if it was a recent breakage). Its also a code area with very few changes so if you can find which one worked last, you should be able to transplant that parport_pc into 2.6.current and see if its parport or acpi triggered breakage. Alan ^ permalink raw reply [flat|nested] 467+ messages in thread
[parent not found: <20090731161735.6a94ad9c-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>]
* Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled 2009-07-31 15:17 ` Alan Cox @ 2009-08-04 11:33 ` Ozan Çağlayan 0 siblings, 0 replies; 467+ messages in thread From: Ozan Çağlayan @ 2009-08-04 11:33 UTC (permalink / raw) To: Alan Cox Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, ACPI Devel Maling List Alan Cox wrote On 31-07-2009 18:17: > There have been few changes to parport_pc but one thing recent changed > the probe for SuperIO chips via low addresses and that could be > interfering. > > commit e2434dc1c19412639dd047a4d4eff8ed0e5d0d50 > Author: Jens Rottmann <JRottmann-pZAVvlj+WpoXz/+GnIZSFIQuADTiUCJX@public.gmane.org> > Date: Mon Jun 22 16:51:49 2009 +0100 > > changed the behaviour slightly (hence asking about which release if it > was a recent breakage). Its also a code area with very few changes so if > you can find which one worked last, you should be able to transplant that > parport_pc into 2.6.current and see if its parport or acpi triggered > breakage. > I've tested on 2.6.30.4 which has apparently this commit, no changes. I've booted into Ubuntu 8.10 which has 2.6.28. The keyboard was working correctly eventhough parport_pc was loaded. I removed and re-probed and the keyboard is gone. I've set BIOS settings to default, nope. I'll try bisecting when I find the last-good/first-bad kernel version. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled @ 2009-08-04 11:33 ` Ozan Çağlayan 0 siblings, 0 replies; 467+ messages in thread From: Ozan Çağlayan @ 2009-08-04 11:33 UTC (permalink / raw) To: Alan Cox Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, ACPI Devel Maling List Alan Cox wrote On 31-07-2009 18:17: > There have been few changes to parport_pc but one thing recent changed > the probe for SuperIO chips via low addresses and that could be > interfering. > > commit e2434dc1c19412639dd047a4d4eff8ed0e5d0d50 > Author: Jens Rottmann <JRottmann@LiPPERTEmbedded.de> > Date: Mon Jun 22 16:51:49 2009 +0100 > > changed the behaviour slightly (hence asking about which release if it > was a recent breakage). Its also a code area with very few changes so if > you can find which one worked last, you should be able to transplant that > parport_pc into 2.6.current and see if its parport or acpi triggered > breakage. > I've tested on 2.6.30.4 which has apparently this commit, no changes. I've booted into Ubuntu 8.10 which has 2.6.28. The keyboard was working correctly eventhough parport_pc was loaded. I removed and re-probed and the keyboard is gone. I've set BIOS settings to default, nope. I'll try bisecting when I find the last-good/first-bad kernel version. ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jesse Barnes, Jos van Wolput This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> Date : 2009-06-17 06:28 (40 days old) References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jesse Barnes, Jos van Wolput This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org> Date : 2009-06-17 06:28 (40 days old) References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13472] Oops with minicom and USB serial 2009-07-26 20:41 ` Rafael J. Wysocki ` (19 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 14:40 ` Alan Stern -1 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Stern, Peter Chubb This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> Date : 2009-06-05 1:37 (52 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13472] Oops with minicom and USB serial 2009-07-26 20:45 ` [Bug #13472] Oops with minicom and USB serial Rafael J. Wysocki @ 2009-07-27 14:40 ` Alan Stern 0 siblings, 0 replies; 467+ messages in thread From: Alan Stern @ 2009-07-27 14:40 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Peter Chubb On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 > Subject : Oops with minicom and USB serial > Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> > Date : 2009-06-05 1:37 (52 days old) > References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 > Handled-By : Alan Stern <stern@rowland.harvard.edu> This bug has been fixed in 2.6.30.stable by commit b6cd9d132aa5e2ef0abdd1d5171e45dad9aafc29. Alan Stern ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13472] Oops with minicom and USB serial @ 2009-07-27 14:40 ` Alan Stern 0 siblings, 0 replies; 467+ messages in thread From: Alan Stern @ 2009-07-27 14:40 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Peter Chubb On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 > Subject : Oops with minicom and USB serial > Submitter : Peter Chubb <peterc-M3ycANVxPotyL3EAZA59ERCuuivNXqWP@public.gmane.org> > Date : 2009-06-05 1:37 (52 days old) > References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 > Handled-By : Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> This bug has been fixed in 2.6.30.stable by commit b6cd9d132aa5e2ef0abdd1d5171e45dad9aafc29. Alan Stern ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13472] Oops with minicom and USB serial 2009-07-27 14:40 ` Alan Stern (?) @ 2009-07-27 21:55 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:55 UTC (permalink / raw) To: Alan Stern; +Cc: Linux Kernel Mailing List, Kernel Testers List, Peter Chubb On Monday 27 July 2009, Alan Stern wrote: > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 > > Subject : Oops with minicom and USB serial > > Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> > > Date : 2009-06-05 1:37 (52 days old) > > References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 > > Handled-By : Alan Stern <stern@rowland.harvard.edu> > > This bug has been fixed in 2.6.30.stable by commit > b6cd9d132aa5e2ef0abdd1d5171e45dad9aafc29. Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, sveina This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (47 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, sveina-Re5JQEeQqe8AvxtiuMwx3w This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-10 20:04 (47 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13514] acer_wmi causes stack corruption 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Rus This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (45 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13514] acer_wmi causes stack corruption @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Rus This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour-K87ZgELTUEPsG83rWm+8vg@public.gmane.org> Date : 2009-06-12 08:13 (45 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13518] slab grows with NFS write activity. 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrew Randrianasulu, Linus Torvalds This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik@mail.ru> Date : 2009-06-12 09:51 (45 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13518] slab grows with NFS write activity. @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrew Randrianasulu, Linus Torvalds This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik-JGs/UdohzUI@public.gmane.org> Date : 2009-06-12 09:51 (45 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13475] suspend/hibernate lockdep warning 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Young, Mathieu Desnoyers This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar@gmail.com> Date : 2009-06-02 10:00 (55 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Patch : http://patchwork.kernel.org/patch/28660/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13475] suspend/hibernate lockdep warning @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Young, Mathieu Desnoyers This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-02 10:00 (55 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org> Patch : http://patchwork.kernel.org/patch/28660/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13475] suspend/hibernate lockdep warning 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-27 1:59 ` Dave Young -1 siblings, 0 replies; 467+ messages in thread From: Dave Young @ 2009-07-27 1:59 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Mathieu Desnoyers On Mon, Jul 27, 2009 at 4:45 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). It has been fixed, at least I did not see it in recent rc4 kernel. > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 > Subject : suspend/hibernate lockdep warning > Submitter : Dave Young <hidave.darkstar@gmail.com> > Date : 2009-06-02 10:00 (55 days old) > References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 > Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> > Patch : http://patchwork.kernel.org/patch/28660/ > > > -- Regards dave ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13475] suspend/hibernate lockdep warning @ 2009-07-27 1:59 ` Dave Young 0 siblings, 0 replies; 467+ messages in thread From: Dave Young @ 2009-07-27 1:59 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Mathieu Desnoyers On Mon, Jul 27, 2009 at 4:45 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). It has been fixed, at least I did not see it in recent rc4 kernel. > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 > Subject : suspend/hibernate lockdep warning > Submitter : Dave Young <hidave.darkstar-Re5JQEeQqe8@public.gmane.orgm> > Date : 2009-06-02 10:00 (55 days old) > References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 > Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> > Patch : http://patchwork.kernel.org/patch/28660/ > > > -- Regards dave ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13475] suspend/hibernate lockdep warning 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-27 16:52 ` Mathieu Desnoyers -1 siblings, 0 replies; 467+ messages in thread From: Mathieu Desnoyers @ 2009-07-27 16:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Young It should be fixed now by recents commits to the cpufreq tree, which got into mainline: 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9 b253d2b2d28ead6fed012feb54694b3d0562839a b14893a62c73af0eca414cfed505b8c09efc613c 7d26e2d5e2da37e92c6c7644b26b294dedd8c982 37c90e8887efd218dc4af949b7f498ca2da4af9f 5a75c82828e7c088ca6e7b4827911dc29cc8e774 ee88415caf736b89500f16e0a545614541a45005 3f4a782b5ce2698b1870b5a7b573cd721d4fce33 5e1596f75395e7a402e1059c518e633d2732dcf8 Mathieu * Rafael J. Wysocki (rjw@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=13475 > Subject : suspend/hibernate lockdep warning > Submitter : Dave Young <hidave.darkstar@gmail.com> > Date : 2009-06-02 10:00 (55 days old) > References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 > Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> > Patch : http://patchwork.kernel.org/patch/28660/ > > > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13475] suspend/hibernate lockdep warning @ 2009-07-27 16:52 ` Mathieu Desnoyers 0 siblings, 0 replies; 467+ messages in thread From: Mathieu Desnoyers @ 2009-07-27 16:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Young It should be fixed now by recents commits to the cpufreq tree, which got into mainline: 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9 b253d2b2d28ead6fed012feb54694b3d0562839a b14893a62c73af0eca414cfed505b8c09efc613c 7d26e2d5e2da37e92c6c7644b26b294dedd8c982 37c90e8887efd218dc4af949b7f498ca2da4af9f 5a75c82828e7c088ca6e7b4827911dc29cc8e774 ee88415caf736b89500f16e0a545614541a45005 3f4a782b5ce2698b1870b5a7b573cd721d4fce33 5e1596f75395e7a402e1059c518e633d2732dcf8 Mathieu * Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 > Subject : suspend/hibernate lockdep warning > Submitter : Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2009-06-02 10:00 (55 days old) > References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 > Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org> > Patch : http://patchwork.kernel.org/patch/28660/ > > > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13475] suspend/hibernate lockdep warning 2009-07-27 16:52 ` Mathieu Desnoyers @ 2009-07-27 21:57 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:57 UTC (permalink / raw) To: Mathieu Desnoyers Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Young On Monday 27 July 2009, Mathieu Desnoyers wrote: > It should be fixed now by recents commits to the cpufreq tree, which got > into mainline: > > 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9 > b253d2b2d28ead6fed012feb54694b3d0562839a > b14893a62c73af0eca414cfed505b8c09efc613c > 7d26e2d5e2da37e92c6c7644b26b294dedd8c982 > 37c90e8887efd218dc4af949b7f498ca2da4af9f > 5a75c82828e7c088ca6e7b4827911dc29cc8e774 > ee88415caf736b89500f16e0a545614541a45005 > 3f4a782b5ce2698b1870b5a7b573cd721d4fce33 > 5e1596f75395e7a402e1059c518e633d2732dcf8 Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13475] suspend/hibernate lockdep warning @ 2009-07-27 21:57 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:57 UTC (permalink / raw) To: Mathieu Desnoyers Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Young On Monday 27 July 2009, Mathieu Desnoyers wrote: > It should be fixed now by recents commits to the cpufreq tree, which got > into mainline: > > 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9 > b253d2b2d28ead6fed012feb54694b3d0562839a > b14893a62c73af0eca414cfed505b8c09efc613c > 7d26e2d5e2da37e92c6c7644b26b294dedd8c982 > 37c90e8887efd218dc4af949b7f498ca2da4af9f > 5a75c82828e7c088ca6e7b4827911dc29cc8e774 > ee88415caf736b89500f16e0a545614541a45005 > 3f4a782b5ce2698b1870b5a7b573cd721d4fce33 > 5e1596f75395e7a402e1059c518e633d2732dcf8 Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13512] D43 on 2.6.30 doesn't suspend anymore 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Daniel Smolik, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (46 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13512] D43 on 2.6.30 doesn't suspend anymore @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Daniel Smolik, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin-0pWKB23IDFjrBKCeMvbIDA@public.gmane.org> Date : 2009-06-11 20:12 (46 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13564] random general protection fault at boot time caused by khubd. 2009-07-26 20:41 ` Rafael J. Wysocki ` (25 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pauli This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (39 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs 2009-07-26 20:41 ` Rafael J. Wysocki ` (26 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Jenkins, Bob Moore This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (32 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13583] pdflush uses 5% CPU on otherwise idle system 2009-07-26 20:41 ` Rafael J. Wysocki ` (27 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Paul Martin This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (38 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13558] Tracelog during resume 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (40 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13558] Tracelog during resume @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org> Date : 2009-06-17 11:32 (40 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13581] ath9k doesn't work with newer kernels 2009-07-26 20:41 ` Rafael J. Wysocki ` (29 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Matteo This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (38 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13638] rt2870 driver is broken for (some) cards 2009-07-26 20:41 ` Rafael J. Wysocki ` (30 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, jakob gruber This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber@kabelnet.at> Date : 2009-06-27 17:33 (30 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (30 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org> Date : 2009-06-27 07:02 (30 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13624] usb: wrong autosuspend initialization 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Stern, list This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list@phuk.ath.cx> Date : 2009-06-25 18:18 (32 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alan Stern, list-2tUql6aCh3Vfq8cQ1yknNg This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org> Date : 2009-06-25 18:18 (32 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-27 14:42 ` Alan Stern -1 siblings, 0 replies; 467+ messages in thread From: Alan Stern @ 2009-07-27 14:42 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Oliver Neukum, Linux Kernel Mailing List, Kernel Testers List, list On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 > Subject : usb: wrong autosuspend initialization > Submitter : <list@phuk.ath.cx> > Date : 2009-06-25 18:18 (32 days old) There's some question as to whether this should be considered a kernel bug. The kernel isn't doing anything wrong; the problem is that various userspace programs enable autosuspend for devices that can't support it properly. Alan Stern ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-27 14:42 ` Alan Stern 0 siblings, 0 replies; 467+ messages in thread From: Alan Stern @ 2009-07-27 14:42 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Oliver Neukum, Linux Kernel Mailing List, Kernel Testers List, list-2tUql6aCh3Vfq8cQ1yknNg On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 > Subject : usb: wrong autosuspend initialization > Submitter : <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org> > Date : 2009-06-25 18:18 (32 days old) There's some question as to whether this should be considered a kernel bug. The kernel isn't doing anything wrong; the problem is that various userspace programs enable autosuspend for devices that can't support it properly. Alan Stern ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-27 14:44 ` list-2tUql6aCh3Vfq8cQ1yknNg 0 siblings, 0 replies; 467+ messages in thread From: list @ 2009-07-27 14:44 UTC (permalink / raw) To: Alan Stern Cc: Rafael J. Wysocki, Oliver Neukum, Linux Kernel Mailing List, Kernel Testers List Alan Stern wrote: > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > >> This message has been generated automatically as a part of a report >> of regressions introduced between 2.6.29 and 2.6.30. >> >> The following bug entry is on the current list of known regressions >> introduced between 2.6.29 and 2.6.30. Please verify if it still should >> be listed and let me know (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 >> Subject : usb: wrong autosuspend initialization >> Submitter : <list@phuk.ath.cx> >> Date : 2009-06-25 18:18 (32 days old) > > There's some question as to whether this should be considered a kernel > bug. The kernel isn't doing anything wrong; the problem is that > various userspace programs enable autosuspend for devices that can't > support it properly. > > Alan Stern > I'm currently working on a patch for laptop_mode. The maintainer tells me there's work going on in the kernel to blacklist USB devices that don't implement autosuspend correctly (like mice turning their light off, etc...). Is that true? ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-27 14:44 ` list-2tUql6aCh3Vfq8cQ1yknNg 0 siblings, 0 replies; 467+ messages in thread From: list-2tUql6aCh3Vfq8cQ1yknNg @ 2009-07-27 14:44 UTC (permalink / raw) To: Alan Stern Cc: Rafael J. Wysocki, Oliver Neukum, Linux Kernel Mailing List, Kernel Testers List Alan Stern wrote: > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > >> This message has been generated automatically as a part of a report >> of regressions introduced between 2.6.29 and 2.6.30. >> >> The following bug entry is on the current list of known regressions >> introduced between 2.6.29 and 2.6.30. Please verify if it still should >> be listed and let me know (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 >> Subject : usb: wrong autosuspend initialization >> Submitter : <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org> >> Date : 2009-06-25 18:18 (32 days old) > > There's some question as to whether this should be considered a kernel > bug. The kernel isn't doing anything wrong; the problem is that > various userspace programs enable autosuspend for devices that can't > support it properly. > > Alan Stern > I'm currently working on a patch for laptop_mode. The maintainer tells me there's work going on in the kernel to blacklist USB devices that don't implement autosuspend correctly (like mice turning their light off, etc...). Is that true? ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-27 15:09 ` Alan Stern 0 siblings, 0 replies; 467+ messages in thread From: Alan Stern @ 2009-07-27 15:09 UTC (permalink / raw) To: list Cc: Rafael J. Wysocki, Oliver Neukum, Linux Kernel Mailing List, Kernel Testers List On Mon, 27 Jul 2009 list@phuk.ath.cx wrote: > Alan Stern wrote: > > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > > > >> This message has been generated automatically as a part of a report > >> of regressions introduced between 2.6.29 and 2.6.30. > >> > >> The following bug entry is on the current list of known regressions > >> introduced between 2.6.29 and 2.6.30. Please verify if it still should > >> be listed and let me know (either way). > >> > >> > >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 > >> Subject : usb: wrong autosuspend initialization > >> Submitter : <list@phuk.ath.cx> > >> Date : 2009-06-25 18:18 (32 days old) > > > > There's some question as to whether this should be considered a kernel > > bug. The kernel isn't doing anything wrong; the problem is that > > various userspace programs enable autosuspend for devices that can't > > support it properly. > > > > Alan Stern > > > > I'm currently working on a patch for laptop_mode. The maintainer tells > me there's work going on in the kernel to blacklist USB devices that > don't implement autosuspend correctly (like mice turning their light > off, etc...). Is that true? No, it isn't. The kernel has no way to tell whether mice behave that way or not. The only suspend-related blacklisting in the kernel is concerned with broken devices that can't be resumed after they have been suspended. The kernel has to reset these devices instead of resuming them. Alan Stern ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-27 15:09 ` Alan Stern 0 siblings, 0 replies; 467+ messages in thread From: Alan Stern @ 2009-07-27 15:09 UTC (permalink / raw) To: list-2tUql6aCh3Vfq8cQ1yknNg Cc: Rafael J. Wysocki, Oliver Neukum, Linux Kernel Mailing List, Kernel Testers List On Mon, 27 Jul 2009 list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org wrote: > Alan Stern wrote: > > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > > > >> This message has been generated automatically as a part of a report > >> of regressions introduced between 2.6.29 and 2.6.30. > >> > >> The following bug entry is on the current list of known regressions > >> introduced between 2.6.29 and 2.6.30. Please verify if it still should > >> be listed and let me know (either way). > >> > >> > >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 > >> Subject : usb: wrong autosuspend initialization > >> Submitter : <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org> > >> Date : 2009-06-25 18:18 (32 days old) > > > > There's some question as to whether this should be considered a kernel > > bug. The kernel isn't doing anything wrong; the problem is that > > various userspace programs enable autosuspend for devices that can't > > support it properly. > > > > Alan Stern > > > > I'm currently working on a patch for laptop_mode. The maintainer tells > me there's work going on in the kernel to blacklist USB devices that > don't implement autosuspend correctly (like mice turning their light > off, etc...). Is that true? No, it isn't. The kernel has no way to tell whether mice behave that way or not. The only suspend-related blacklisting in the kernel is concerned with broken devices that can't be resumed after they have been suspended. The kernel has to reset these devices instead of resuming them. Alan Stern ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-27 21:59 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:59 UTC (permalink / raw) To: Alan Stern Cc: Oliver Neukum, Linux Kernel Mailing List, Kernel Testers List, list On Monday 27 July 2009, Alan Stern wrote: > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 > > Subject : usb: wrong autosuspend initialization > > Submitter : <list@phuk.ath.cx> > > Date : 2009-06-25 18:18 (32 days old) > > There's some question as to whether this should be considered a kernel > bug. The kernel isn't doing anything wrong; the problem is that > various userspace programs enable autosuspend for devices that can't > support it properly. OK, I'll drop it from the list of recent regressions. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-27 21:59 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 21:59 UTC (permalink / raw) To: Alan Stern Cc: Oliver Neukum, Linux Kernel Mailing List, Kernel Testers List, list-2tUql6aCh3Vfq8cQ1yknNg On Monday 27 July 2009, Alan Stern wrote: > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 > > Subject : usb: wrong autosuspend initialization > > Submitter : <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org> > > Date : 2009-06-25 18:18 (32 days old) > > There's some question as to whether this should be considered a kernel > bug. The kernel isn't doing anything wrong; the problem is that > various userspace programs enable autosuspend for devices that can't > support it properly. OK, I'll drop it from the list of recent regressions. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13621] xfs hangs with assertion failed 2009-07-26 20:41 ` Rafael J. Wysocki ` (33 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ 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 Engel This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (32 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13646] warn_on tty_io.c, broken bluetooth 2009-07-26 20:41 ` Rafael J. Wysocki ` (34 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pavel Machek This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (38 days old) References : http://lkml.org/lkml/2009/6/19/187 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs 2009-07-26 20:41 ` Rafael J. Wysocki ` (35 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Joao Correia This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (30 days old) References : http://lkml.org/lkml/2009/6/27/95 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13648] nfsd: page allocation failure 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, David Rientjes, Justin Piszcz, Stephan von Krawczynski This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-06-22 12:08 (35 days old) References : http://lkml.org/lkml/2009/6/22/309 http://marc.info/?l=linux-kernel&m=124748600712853&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13648] nfsd: page allocation failure @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, David Rientjes, Justin Piszcz, Stephan von Krawczynski This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org> Date : 2009-06-22 12:08 (35 days old) References : http://lkml.org/lkml/2009/6/22/309 http://marc.info/?l=linux-kernel&m=124748600712853&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure 2009-07-26 20:45 ` Rafael J. Wysocki (?) @ 2009-07-27 11:04 ` Stephan von Krawczynski 2009-07-27 22:04 ` Rafael J. Wysocki 2009-07-30 21:30 ` David Rientjes -1 siblings, 2 replies; 467+ messages in thread From: Stephan von Krawczynski @ 2009-07-27 11:04 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes, Justin Piszcz On Sun, 26 Jul 2009 22:45:33 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 > Subject : nfsd: page allocation failure > Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> > Date : 2009-06-22 12:08 (35 days old) > References : http://lkml.org/lkml/2009/6/22/309 > http://marc.info/?l=linux-kernel&m=124748600712853&w=4 > This is no regression between 2.6.29 and 2.6.30. In fact we could reproduce the problem with kernel versions: 2.6.27.26 < X <= 2.6.30.3 (Meaning 2.6.27.26 is the last one _not_ showing the problem). -- Regards, Stephan ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure @ 2009-07-27 22:04 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 22:04 UTC (permalink / raw) To: Stephan von Krawczynski Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes, Justin Piszcz On Monday 27 July 2009, Stephan von Krawczynski wrote: > On Sun, 26 Jul 2009 22:45:33 +0200 (CEST) > "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 > > Subject : nfsd: page allocation failure > > Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> > > Date : 2009-06-22 12:08 (35 days old) > > References : http://lkml.org/lkml/2009/6/22/309 > > http://marc.info/?l=linux-kernel&m=124748600712853&w=4 > > > > This is no regression between 2.6.29 and 2.6.30. > In fact we could reproduce the problem with kernel versions: > > 2.6.27.26 < X <= 2.6.30.3 > > (Meaning 2.6.27.26 is the last one _not_ showing the problem). Thanks, moved to the list of regressions from 2.6.27. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure @ 2009-07-27 22:04 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 22:04 UTC (permalink / raw) To: Stephan von Krawczynski Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes, Justin Piszcz On Monday 27 July 2009, Stephan von Krawczynski wrote: > On Sun, 26 Jul 2009 22:45:33 +0200 (CEST) > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 > > Subject : nfsd: page allocation failure > > Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org> > > Date : 2009-06-22 12:08 (35 days old) > > References : http://lkml.org/lkml/2009/6/22/309 > > http://marc.info/?l=linux-kernel&m=124748600712853&w=4 > > > > This is no regression between 2.6.29 and 2.6.30. > In fact we could reproduce the problem with kernel versions: > > 2.6.27.26 < X <= 2.6.30.3 > > (Meaning 2.6.27.26 is the last one _not_ showing the problem). Thanks, moved to the list of regressions from 2.6.27. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure 2009-07-27 11:04 ` Stephan von Krawczynski 2009-07-27 22:04 ` Rafael J. Wysocki @ 2009-07-30 21:30 ` David Rientjes 2009-07-31 11:48 ` Stephan von Krawczynski 1 sibling, 1 reply; 467+ messages in thread From: David Rientjes @ 2009-07-30 21:30 UTC (permalink / raw) To: Stephan von Krawczynski Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Justin Piszcz, Jeff Kirsher, Jesse Brandeburg, David S. Miller On Mon, 27 Jul 2009, Stephan von Krawczynski wrote: > This is no regression between 2.6.29 and 2.6.30. > In fact we could reproduce the problem with kernel versions: > > 2.6.27.26 < X <= 2.6.30.3 > > (Meaning 2.6.27.26 is the last one _not_ showing the problem). > And 2.6.28.10 is showing the exact same problem as initially reported, right? I noticed your /var/log/messages is showing you're using slub as opposed to slab (which Justin was using, and causing order-0 allocations errors). SLUB uses order-1 allocations for this cache growth and it's failing because of memory fragmentation, not because you're truly oom. The only thing that is immediately apparent that changed in this path over these kernel versions (there were significant changes to e1000e) is the CRC stripping. If it's loaded as a module, perhaps you could try modprobe e1000e CrcStripping=0,0 (assuming you have two adapters). I've cc'd some relevant e1000e driver people in the hopes they'll be able to diagnose this problem. Memory fragmentation as the result of page group changes wouldn't affect order-0 allocations such as this on slab, so it's doubtful the VM regressed if you can reproduce the problem with CONFIG_SLAB. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure @ 2009-07-31 11:48 ` Stephan von Krawczynski 0 siblings, 0 replies; 467+ messages in thread From: Stephan von Krawczynski @ 2009-07-31 11:48 UTC (permalink / raw) To: David Rientjes Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Justin Piszcz, Jeff Kirsher, Jesse Brandeburg, David S. Miller On Thu, 30 Jul 2009 14:30:42 -0700 (PDT) David Rientjes <rientjes@google.com> wrote: > On Mon, 27 Jul 2009, Stephan von Krawczynski wrote: > > > This is no regression between 2.6.29 and 2.6.30. > > In fact we could reproduce the problem with kernel versions: > > > > 2.6.27.26 < X <= 2.6.30.3 > > > > (Meaning 2.6.27.26 is the last one _not_ showing the problem). > > > > And 2.6.28.10 is showing the exact same problem as initially reported, > right? Yes, that is correct. > I noticed your /var/log/messages is showing you're using slub as opposed > to slab (which Justin was using, and causing order-0 allocations errors). > SLUB uses order-1 allocations for this cache growth and it's failing > because of memory fragmentation, not because you're truly oom. Originally I used slab, and as someone wanted me to test slub I tried. The results looked pretty much the same to me. > The only thing that is immediately apparent that changed in this path over > these kernel versions (there were significant changes to e1000e) is the > CRC stripping. If it's loaded as a module, perhaps you could try > > modprobe e1000e CrcStripping=0,0 > > (assuming you have two adapters). I will try that. > I've cc'd some relevant e1000e driver people in the hopes they'll be able > to diagnose this problem. Memory fragmentation as the result of page > group changes wouldn't affect order-0 allocations such as this on slab, so > it's doubtful the VM regressed if you can reproduce the problem with > CONFIG_SLAB. I can, as said before, the problem first showed up with slab. -- Regards, Stephan ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure @ 2009-07-31 11:48 ` Stephan von Krawczynski 0 siblings, 0 replies; 467+ messages in thread From: Stephan von Krawczynski @ 2009-07-31 11:48 UTC (permalink / raw) To: David Rientjes Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Justin Piszcz, Jeff Kirsher, Jesse Brandeburg, David S. Miller On Thu, 30 Jul 2009 14:30:42 -0700 (PDT) David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > On Mon, 27 Jul 2009, Stephan von Krawczynski wrote: > > > This is no regression between 2.6.29 and 2.6.30. > > In fact we could reproduce the problem with kernel versions: > > > > 2.6.27.26 < X <= 2.6.30.3 > > > > (Meaning 2.6.27.26 is the last one _not_ showing the problem). > > > > And 2.6.28.10 is showing the exact same problem as initially reported, > right? Yes, that is correct. > I noticed your /var/log/messages is showing you're using slub as opposed > to slab (which Justin was using, and causing order-0 allocations errors). > SLUB uses order-1 allocations for this cache growth and it's failing > because of memory fragmentation, not because you're truly oom. Originally I used slab, and as someone wanted me to test slub I tried. The results looked pretty much the same to me. > The only thing that is immediately apparent that changed in this path over > these kernel versions (there were significant changes to e1000e) is the > CRC stripping. If it's loaded as a module, perhaps you could try > > modprobe e1000e CrcStripping=0,0 > > (assuming you have two adapters). I will try that. > I've cc'd some relevant e1000e driver people in the hopes they'll be able > to diagnose this problem. Memory fragmentation as the result of page > group changes wouldn't affect order-0 allocations such as this on slab, so > it's doubtful the VM regressed if you can reproduce the problem with > CONFIG_SLAB. I can, as said before, the problem first showed up with slab. -- Regards, Stephan ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ 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 Stezenbach, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js@sig21.net> Date : 2009-06-16 01:27 (41 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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 Stezenbach, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org> Date : 2009-06-16 01:27 (41 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13649] Bad page state in process with various applications 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maxim Levitsky, Mel Gorman This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-06-20 15:27 (37 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel@csn.ul.ie> Patch : http://patchwork.kernel.org/patch/33130/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13649] Bad page state in process with various applications @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maxim Levitsky, Mel Gorman This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-20 15:27 (37 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> Patch : http://patchwork.kernel.org/patch/33130/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13649] Bad page state in process with various applications 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-27 9:05 ` Johannes Weiner -1 siblings, 0 replies; 467+ messages in thread From: Johannes Weiner @ 2009-07-27 9:05 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maxim Levitsky, Mel Gorman On Sun, Jul 26, 2009 at 10:45:33PM +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 > Subject : Bad page state in process with various applications > Submitter : Maxim Levitsky <maximlevitsky@gmail.com> > Date : 2009-06-20 15:27 (37 days old) > References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 > Handled-By : Mel Gorman <mel@csn.ul.ie> > Patch : http://patchwork.kernel.org/patch/33130/ Fixed in mainline: c277331d5fbaae5772ed19862feefa91f4e477d3 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13649] Bad page state in process with various applications @ 2009-07-27 9:05 ` Johannes Weiner 0 siblings, 0 replies; 467+ messages in thread From: Johannes Weiner @ 2009-07-27 9:05 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maxim Levitsky, Mel Gorman On Sun, Jul 26, 2009 at 10:45:33PM +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 > Subject : Bad page state in process with various applications > Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2009-06-20 15:27 (37 days old) > References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 > Handled-By : Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> > Patch : http://patchwork.kernel.org/patch/33130/ Fixed in mainline: c277331d5fbaae5772ed19862feefa91f4e477d3 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13649] Bad page state in process with various applications @ 2009-07-27 22:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 22:06 UTC (permalink / raw) To: Johannes Weiner Cc: Linux Kernel Mailing List, Kernel Testers List, Maxim Levitsky, Mel Gorman On Monday 27 July 2009, Johannes Weiner wrote: > On Sun, Jul 26, 2009 at 10:45:33PM +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 > > Subject : Bad page state in process with various applications > > Submitter : Maxim Levitsky <maximlevitsky@gmail.com> > > Date : 2009-06-20 15:27 (37 days old) > > References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 > > Handled-By : Mel Gorman <mel@csn.ul.ie> > > Patch : http://patchwork.kernel.org/patch/33130/ > > Fixed in mainline: c277331d5fbaae5772ed19862feefa91f4e477d3 Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13649] Bad page state in process with various applications @ 2009-07-27 22:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-27 22:06 UTC (permalink / raw) To: Johannes Weiner Cc: Linux Kernel Mailing List, Kernel Testers List, Maxim Levitsky, Mel Gorman On Monday 27 July 2009, Johannes Weiner wrote: > On Sun, Jul 26, 2009 at 10:45:33PM +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 > > Subject : Bad page state in process with various applications > > Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Date : 2009-06-20 15:27 (37 days old) > > References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 > > Handled-By : Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> > > Patch : http://patchwork.kernel.org/patch/33130/ > > Fixed in mainline: c277331d5fbaae5772ed19862feefa91f4e477d3 Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13669] Kernel bug with dock driver 2009-07-26 20:41 ` Rafael J. Wysocki ` (39 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Henrique de Moraes Holschuh, Joerg Platte This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte@naasa.net> Date : 2009-06-14 21:00 (43 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13694] i915 phantom TV 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciek Józiewicz This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (25 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13694] i915 phantom TV @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciek Józiewicz This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (25 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13681] A number of usb Devices causes Oops messages and kernel panics. 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexander Kaltsas, Andrew Morton, Hugh Dickins, Linus Torvalds, Mel Gorman This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 Subject : A number of usb Devices causes Oops messages and kernel panics. Submitter : Alexander Kaltsas <alexkaltsas@gmail.com> Date : 2009-06-30 13:06 (27 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13681] A number of usb Devices causes Oops messages and kernel panics. @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexander Kaltsas, Andrew Morton, Hugh Dickins, Linus Torvalds, Mel Gorman This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 Subject : A number of usb Devices causes Oops messages and kernel panics. Submitter : Alexander Kaltsas <alexkaltsas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-30 13:06 (27 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13681] A number of usb Devices causes Oops messages and kernel panics. 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-29 13:29 ` Greg KH -1 siblings, 0 replies; 467+ messages in thread From: Greg KH @ 2009-07-29 13:29 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Alexander Kaltsas, Andrew Morton, Hugh Dickins, Linus Torvalds, Mel Gorman On Sun, Jul 26, 2009 at 10:45:34PM +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 > Subject : A number of usb Devices causes Oops messages and kernel panics. > Submitter : Alexander Kaltsas <alexkaltsas@gmail.com> > Date : 2009-06-30 13:06 (27 days old) This can no longer be reproduced by the original reporter, so it should be closed. thanks, greg k-h ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13681] A number of usb Devices causes Oops messages and kernel panics. @ 2009-07-29 13:29 ` Greg KH 0 siblings, 0 replies; 467+ messages in thread From: Greg KH @ 2009-07-29 13:29 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Alexander Kaltsas, Andrew Morton, Hugh Dickins, Linus Torvalds, Mel Gorman On Sun, Jul 26, 2009 at 10:45:34PM +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 > Subject : A number of usb Devices causes Oops messages and kernel panics. > Submitter : Alexander Kaltsas <alexkaltsas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2009-06-30 13:06 (27 days old) This can no longer be reproduced by the original reporter, so it should be closed. thanks, greg k-h ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13681] A number of usb Devices causes Oops messages and kernel panics. @ 2009-07-29 21:09 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-29 21:09 UTC (permalink / raw) To: Greg KH Cc: Linux Kernel Mailing List, Kernel Testers List, Alexander Kaltsas, Andrew Morton, Hugh Dickins, Linus Torvalds, Mel Gorman On Wednesday 29 July 2009, Greg KH wrote: > On Sun, Jul 26, 2009 at 10:45:34PM +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 > > Subject : A number of usb Devices causes Oops messages and kernel panics. > > Submitter : Alexander Kaltsas <alexkaltsas@gmail.com> > > Date : 2009-06-30 13:06 (27 days old) > > This can no longer be reproduced by the original reporter, so it should > be closed. Done. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13681] A number of usb Devices causes Oops messages and kernel panics. @ 2009-07-29 21:09 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-29 21:09 UTC (permalink / raw) To: Greg KH Cc: Linux Kernel Mailing List, Kernel Testers List, Alexander Kaltsas, Andrew Morton, Hugh Dickins, Linus Torvalds, Mel Gorman On Wednesday 29 July 2009, Greg KH wrote: > On Sun, Jul 26, 2009 at 10:45:34PM +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 > > Subject : A number of usb Devices causes Oops messages and kernel panics. > > Submitter : Alexander Kaltsas <alexkaltsas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Date : 2009-06-30 13:06 (27 days old) > > This can no longer be reproduced by the original reporter, so it should > be closed. Done. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 2009-07-26 20:41 ` Rafael J. Wysocki ` (42 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Nathanael Schaeffer This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (27 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13795] abnormal boot and no suspend due to 'async' (fastboot) 2009-07-26 20:41 ` Rafael J. Wysocki ` (43 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Arjan van de Ven, Rafal Kaczynski This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795 Subject : abnormal boot and no suspend due to 'async' (fastboot) Submitter : Rafal Kaczynski <fscnoboot@wp.pl> Date : 2009-07-18 17:19 (9 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13780] NULL pointer dereference loading powernowk8 2009-07-26 20:41 ` Rafael J. Wysocki ` (44 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-30 22:16 ` David Rientjes -1 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Kurt Roeckx This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 Subject : NULL pointer dereference loading powernowk8 Submitter : Kurt Roeckx <kurt@roeckx.be> Date : 2009-07-15 18:00 (12 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13780] NULL pointer dereference loading powernowk8 2009-07-26 20:45 ` [Bug #13780] NULL pointer dereference loading powernowk8 Rafael J. Wysocki @ 2009-07-30 22:16 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-30 22:16 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Kurt Roeckx, Rusty Russell On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 > Subject : NULL pointer dereference loading powernowk8 > Submitter : Kurt Roeckx <kurt@roeckx.be> > Date : 2009-07-15 18:00 (12 days old) > powernowk8_cpu_init() has since been largely modified for cpumask changes commit 1ff6e97f1d993dff2f9b6f4a9173687370660232. Kurt, could you try 2.6.31-rc4? If it still hits a bug, please post the dmesg and your .config. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13780] NULL pointer dereference loading powernowk8 @ 2009-07-30 22:16 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-30 22:16 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Kurt Roeckx, Rusty Russell On Sun, 26 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 > Subject : NULL pointer dereference loading powernowk8 > Submitter : Kurt Roeckx <kurt-burXGKnpAKGzQB+pC5nmwQ@public.gmane.org> > Date : 2009-07-15 18:00 (12 days old) > powernowk8_cpu_init() has since been largely modified for cpumask changes commit 1ff6e97f1d993dff2f9b6f4a9173687370660232. Kurt, could you try 2.6.31-rc4? If it still hits a bug, please post the dmesg and your .config. ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13739] 2.6.30 leaking keys on console switch 2009-07-26 20:41 ` Rafael J. Wysocki ` (45 preceding siblings ...) (?) @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andi Kleen, Jiri Kosina This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739 Subject : 2.6.30 leaking keys on console switch Submitter : Andi Kleen <andi@firstfloor.org> Date : 2009-07-07 8:44 (20 days old) References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4 Handled-By : Jiri Kosina <jkosina@suse.cz> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13751] oops on HP/Compaq 6910p lid closure 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Bjorn Helgaas, Matthew Garrett This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13751 Subject : oops on HP/Compaq 6910p lid closure Submitter : Bjorn Helgaas <bjorn.helgaas@hp.com> Date : 2009-07-09 15:17 (18 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13751] oops on HP/Compaq 6910p lid closure @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Bjorn Helgaas, Matthew Garrett This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13751 Subject : oops on HP/Compaq 6910p lid closure Submitter : Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org> Date : 2009-07-09 15:17 (18 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8 2009-07-26 20:41 ` Rafael J. Wysocki @ 2009-07-26 20:45 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jörg Sommer, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797 Subject : iBook G4 doesn't suspend since 2ed8d2b3a8 Submitter : Jörg Sommer <joerg@alea.gnuu.de> Date : 2009-07-18 20:18 (9 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8 @ 2009-07-26 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-26 20:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jörg Sommer, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797 Subject : iBook G4 doesn't suspend since 2ed8d2b3a8 Submitter : Jörg Sommer <joerg@alea.gnuu.de> Date : 2009-07-18 20:18 (9 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8 2009-07-26 20:45 ` Rafael J. Wysocki @ 2009-07-27 22:23 ` Jörg Sommer -1 siblings, 0 replies; 467+ messages in thread From: Jörg Sommer @ 2009-07-27 22:23 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 706 bytes --] Hi Rafael, Rafael J. Wysocki hat am Sun 26. Jul, 22:45 (+0200) geschrieben: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). Yes, the bug still exists. I can't put my iBook asleep using 2.6.30-rc4. Regards, Jörg. -- Da würde ich auch lieber den Panzerführerschein machen als den MCSE. Bringt mehr, dürfte das gleiche kosten und macht sicher mehr Spaß. Jens Dittmar in de.comp.security [-- Attachment #2: Digital signature http://en.wikipedia.org/wiki/OpenPGP --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8 @ 2009-07-27 22:23 ` Jörg Sommer 0 siblings, 0 replies; 467+ messages in thread From: Jörg Sommer @ 2009-07-27 22:23 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 706 bytes --] Hi Rafael, Rafael J. Wysocki hat am Sun 26. Jul, 22:45 (+0200) geschrieben: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). Yes, the bug still exists. I can't put my iBook asleep using 2.6.30-rc4. Regards, Jörg. -- Da würde ich auch lieber den Panzerführerschein machen als den MCSE. Bringt mehr, dürfte das gleiche kosten und macht sicher mehr Spaß. Jens Dittmar in de.comp.security [-- Attachment #2: Digital signature http://en.wikipedia.org/wiki/OpenPGP --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules 2009-07-26 20:41 ` Rafael J. Wysocki ` (48 preceding siblings ...) (?) @ 2009-07-28 14:40 ` Jan Scholz 2009-07-28 15:26 ` Johannes Berg -1 siblings, 1 reply; 467+ messages in thread From: Jan Scholz @ 2009-07-28 14:40 UTC (permalink / raw) To: Johannes Berg Cc: Jan Scholz, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville Johannes Berg <johannes@sipsolutions.net> writes: > On Sat, 2009-07-11 at 19:20 +0200, Jan Scholz wrote: >> Johannes Berg <johannes@sipsolutions.net> writes: >> >> > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote: >> > >> >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael >> >> > will correct me if I'm wrong) that should work on your platform, and put >> >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to >> >> > see where in there it's hanging? >> >> >> >> Did that, seems like it hangs in >> >> drv_remove_interface(local, &conf); >> > >> > Ok, thanks! I was going to suggest doing the same in >> > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think >> > the problem is just that we have an ordering problem and call drv_stop >> > before drv_remove_interface. I'll try to come up with a fix soon -- >> > might not be able to today though, in the meantime I guess you can just >> > move the drv_stop call to the end of the function and tell me if that >> > works -- that would be racy but should be ok most of the time. >> >> I moved drv_stop to the end of the function (see patch below) and now >> suspend works fine. > > Thanks, that's what I suspected -- I'll take a closer look into what is > required to make it race-free against RX. > Hi, The bug is still present in v2.6.31-rc4, it's still fixed by the patch (see below) suggested as a test by Johannes. Regards, Jan >> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c >> index 7a549f9..0ac15fb 100644 >> --- a/net/mac80211/pm.c >> +++ b/net/mac80211/pm.c >> @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) >> /* flush again, in case driver queued work */ >> flush_workqueue(local->hw.workqueue); >> >> - /* stop hardware - this must stop RX */ >> - if (local->open_count) { >> - ieee80211_led_radio(local, false); >> - drv_stop(local); >> - } >> - >> /* remove STAs */ >> spin_lock_irqsave(&local->sta_lock, flags); >> list_for_each_entry(sta, &local->sta_list, list) { >> @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw) >> drv_remove_interface(local, &conf); >> } >> >> + /* stop hardware - this must stop RX */ >> + if (local->open_count) { >> + ieee80211_led_radio(local, false); >> + drv_stop(local); >> + } >> + >> local->suspended = true; >> local->quiescing = false; >> -- Jan Scholz ____ ____ __ ___ ( ___)(_ _) /__\ / __) Frankfurt Institute for Advanced Studies )__) _)(_ /(__)\ \__ \ (__) (____)(__)(__)(___/ Goethe Universitaet Frankfurt Ruth-Moufang-Str. 1 Tel. 069-798-47534 60438 Frankfurt am Main ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-28 15:26 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-28 15:26 UTC (permalink / raw) To: Jan Scholz Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville [-- Attachment #1: Type: text/plain, Size: 288 bytes --] On Tue, 2009-07-28 at 16:40 +0200, Jan Scholz wrote: > The bug is still present in v2.6.31-rc4, it's still fixed by the patch > (see below) suggested as a test by Johannes. Sorry, this completely dropped off my radar, I'll take a look today. Thanks for reminding me. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules @ 2009-07-28 15:26 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-28 15:26 UTC (permalink / raw) To: Jan Scholz Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville [-- Attachment #1: Type: text/plain, Size: 288 bytes --] On Tue, 2009-07-28 at 16:40 +0200, Jan Scholz wrote: > The bug is still present in v2.6.31-rc4, it's still fixed by the patch > (see below) suggested as a test by Johannes. Sorry, this completely dropped off my radar, I'll take a look today. Thanks for reminding me. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules 2009-07-28 15:26 ` Johannes Berg (?) @ 2009-07-28 21:15 ` Rafael J. Wysocki 2009-07-28 23:51 ` [PATCH 2.6.31] mac80211: fix suspend Jan Scholz -1 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-28 21:15 UTC (permalink / raw) To: Johannes Berg Cc: Jan Scholz, Linux Kernel Mailing List, Kernel Testers List, Tomas Janousek, John W. Linville On Tuesday 28 July 2009, Johannes Berg wrote: > On Tue, 2009-07-28 at 16:40 +0200, Jan Scholz wrote: > > > The bug is still present in v2.6.31-rc4, it's still fixed by the patch > > (see below) suggested as a test by Johannes. > > Sorry, this completely dropped off my radar, I'll take a look today. > Thanks for reminding me. Thanks for the patch Johannes! Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [PATCH 2.6.31] mac80211: fix suspend 2009-07-28 21:15 ` Rafael J. Wysocki @ 2009-07-28 23:51 ` Jan Scholz 0 siblings, 0 replies; 467+ messages in thread From: Jan Scholz @ 2009-07-28 23:51 UTC (permalink / raw) To: Johannes Berg Cc: John Linville, Jan Scholz, linux-wireless, Bob Copeland, Rafael J. Wysocki, Tomas Janousek, linux-kernel I applied the patch to v2.6.31-rc4 and suspend works just fine. Thanks, Jan Johannes Berg <johannes@sipsolutions.net> writes: > Jan reported that his b43-based laptop hangs during suspend. > The problem turned out to be mac80211 asking the driver to > stop the hardware before removing interfaces, and interface > removal caused b43 to touch the hardware (while down, which > causes the hang). > > This patch fixes mac80211 to do reorder these operations to > have them in the correct order -- first remove interfaces > and then stop the hardware. Some more code is necessary to > be able to do so in a race-free manner, in particular it is > necessary to not process frames received during quiescing. > > Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13337. > > Reported-by: Jan Scholz <scholz@fias.uni-frankfurt.de> > Signed-off-by: Johannes Berg <johannes@sipsolutions.net> > --- > net/mac80211/pm.c | 24 +++++++++++++++--------- > net/mac80211/rx.c | 12 ++++++++++++ > 2 files changed, 27 insertions(+), 9 deletions(-) > > --- wireless-testing.orig/net/mac80211/pm.c 2009-07-28 17:58:11.000000000 +0200 > +++ wireless-testing/net/mac80211/pm.c 2009-07-28 18:06:25.000000000 +0200 > @@ -54,15 +54,6 @@ int __ieee80211_suspend(struct ieee80211 > > rcu_read_unlock(); > > - /* flush again, in case driver queued work */ > - flush_workqueue(local->hw.workqueue); > - > - /* stop hardware - this must stop RX */ > - if (local->open_count) { > - ieee80211_led_radio(local, false); > - drv_stop(local); > - } > - > /* remove STAs */ > spin_lock_bh(&local->sta_lock); > list_for_each_entry(sta, &local->sta_list, list) { > @@ -110,7 +101,22 @@ int __ieee80211_suspend(struct ieee80211 > drv_remove_interface(local, &conf); > } > > + /* stop hardware - this must stop RX */ > + if (local->open_count) { > + ieee80211_led_radio(local, false); > + drv_stop(local); > + } > + > + /* > + * flush again, in case driver queued work -- it > + * shouldn't be doing (or cancel everything in the > + * stop callback) that but better safe than sorry. > + */ > + flush_workqueue(local->hw.workqueue); > + > local->suspended = true; > + /* need suspended to be visible before quiescing is false */ > + barrier(); > local->quiescing = false; > > return 0; > --- wireless-testing.orig/net/mac80211/rx.c 2009-07-28 17:58:52.000000000 +0200 > +++ wireless-testing/net/mac80211/rx.c 2009-07-28 18:04:24.000000000 +0200 > @@ -2441,6 +2441,18 @@ void __ieee80211_rx(struct ieee80211_hw > return; > } > > + /* > + * If we're suspending, it is possible although not too likely > + * that we'd be receiving frames after having already partially > + * quiesced the stack. We can't process such frames then since > + * that might, for example, cause stations to be added or other > + * driver callbacks be invoked. > + */ > + if (unlikely(local->quiescing || local->suspended)) { > + kfree_skb(skb); > + return; > + } > + > if (status->flag & RX_FLAG_HT) { > /* rate_idx is MCS index */ > if (WARN_ON(status->rate_idx < 0 || > ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13341] Random Oops at boot at loading ip6tables rules 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, patrick, Rusty Russell This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (49 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13341] Random Oops at boot at loading ip6tables rules @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, patrick-nxAOmsU53hB6lmGzAMPh1A, Rusty Russell This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick-nxAOmsU53hB6lmGzAMPh1A@public.gmane.org> Date : 2009-05-19 09:08 (49 days old) Handled-By : Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Ingo Molnar, unggnu, Yinghai Lu This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (48 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Ingo Molnar, unggnu-gM/Ye1E23mwN+BqQ9rBEUg, Yinghai Lu This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> Date : 2009-05-20 14:09 (48 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alejandro Riveira, Chris Wright, Johannes Berg, John W. Linville This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (46 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alejandro Riveira, Chris Wright, Johannes Berg, John W. Linville This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-05-22 13:32 (46 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-07 10:06 ` Alejandro Riveira Fernández -1 siblings, 0 replies; 467+ messages in thread From: Alejandro Riveira Fernández @ 2009-07-07 10:06 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright, Johannes Berg, John W. Linville El Tue, 7 Jul 2009 02:00:38 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> escribió: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > It should be still listed 2.6.30.1 does not fix it. still not tried 2.6.31-rc* though. > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 > Subject : rt2x00: slow wifi with correct basic rate bitmap > Submitter : Alejandro Riveira <ariveira@gmail.com> > Date : 2009-05-22 13:32 (46 days old) > > ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap @ 2009-07-07 10:06 ` Alejandro Riveira Fernández 0 siblings, 0 replies; 467+ messages in thread From: Alejandro Riveira Fernández @ 2009-07-07 10:06 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright, Johannes Berg, John W. Linville El Tue, 7 Jul 2009 02:00:38 +0200 (CEST) "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> escribió: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > It should be still listed 2.6.30.1 does not fix it. still not tried 2.6.31-rc* though. > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 > Subject : rt2x00: slow wifi with correct basic rate bitmap > Submitter : Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2009-05-22 13:32 (46 days old) > > ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap 2009-07-07 10:06 ` Alejandro Riveira Fernández @ 2009-07-07 11:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 11:01 UTC (permalink / raw) To: Alejandro Riveira Fernández Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright, Johannes Berg, John W. Linville On Tuesday 07 July 2009, Alejandro Riveira Fernández wrote: > El Tue, 7 Jul 2009 02:00:38 +0200 (CEST) > "Rafael J. Wysocki" <rjw@sisk.pl> escribió: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > It should be still listed 2.6.30.1 does not fix it. still not tried > 2.6.31-rc* though. Thanks for the update. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap @ 2009-07-07 11:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 11:01 UTC (permalink / raw) To: Alejandro Riveira Fernández Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright, Johannes Berg, John W. Linville On Tuesday 07 July 2009, Alejandro Riveira Fernández wrote: > El Tue, 7 Jul 2009 02:00:38 +0200 (CEST) > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> escribió: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > It should be still listed 2.6.30.1 does not fix it. still not tried > 2.6.31-rc* though. Thanks for the update. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13374] reiserfs blocked for more than 120secs 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Harald Dunkel This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (45 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13374] reiserfs blocked for more than 120secs @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Harald Dunkel This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org> Date : 2009-05-23 8:52 (45 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Miles Lane This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (45 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Miles Lane This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-05-23 5:08 (45 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Frans Pop This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (42 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Frans Pop This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> Date : 2009-05-26 15:24 (42 days old) Handled-By : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-07 19:19 ` Frans Pop -1 siblings, 0 replies; 467+ messages in thread From: Frans Pop @ 2009-07-07 19:19 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Len Brown, rui.zhang On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > Subject : Warning 'Invalid throttling state, reset' gets displayed when > it should not be > Submitter : Frans Pop <elendil@planet.nl> > Date : 2009-05-26 15:24 (42 days old) > Handled-By : Frans Pop <elendil@planet.nl> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > http://bugzilla.kernel.org/attachment.cgi?id=21672 I still have not received any reaction from the ACPI maintainers to the bug or the proposed patches. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-07 19:19 ` Frans Pop 0 siblings, 0 replies; 467+ messages in thread From: Frans Pop @ 2009-07-07 19:19 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Len Brown, rui.zhang-ral2JQCrhuEAvxtiuMwx3w On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > Subject : Warning 'Invalid throttling state, reset' gets displayed when > it should not be > Submitter : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> > Date : 2009-05-26 15:24 (42 days old) > Handled-By : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > http://bugzilla.kernel.org/attachment.cgi?id=21672 I still have not received any reaction from the ACPI maintainers to the bug or the proposed patches. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-07 20:11 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 20:11 UTC (permalink / raw) To: Frans Pop, Len Brown Cc: Linux Kernel Mailing List, Kernel Testers List, rui.zhang On Tuesday 07 July 2009, Frans Pop wrote: > On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > > Subject : Warning 'Invalid throttling state, reset' gets displayed when > > it should not be > > Submitter : Frans Pop <elendil@planet.nl> > > Date : 2009-05-26 15:24 (42 days old) > > Handled-By : Frans Pop <elendil@planet.nl> > > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > > http://bugzilla.kernel.org/attachment.cgi?id=21672 > > I still have not received any reaction from the ACPI maintainers to the > bug or the proposed patches. Sorry for that. Len, what do you think of the patches listed above? Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-07 20:11 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 20:11 UTC (permalink / raw) To: Frans Pop, Len Brown Cc: Linux Kernel Mailing List, Kernel Testers List, rui.zhang-ral2JQCrhuEAvxtiuMwx3w On Tuesday 07 July 2009, Frans Pop wrote: > On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > > Subject : Warning 'Invalid throttling state, reset' gets displayed when > > it should not be > > Submitter : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> > > Date : 2009-05-26 15:24 (42 days old) > > Handled-By : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> > > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > > http://bugzilla.kernel.org/attachment.cgi?id=21672 > > I still have not received any reaction from the ACPI maintainers to the > bug or the proposed patches. Sorry for that. Len, what do you think of the patches listed above? Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-08 0:56 ` Zhang Rui 0 siblings, 0 replies; 467+ messages in thread From: Zhang Rui @ 2009-07-08 0:56 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Len Brown, Linux Kernel Mailing List, Kernel Testers List On Wed, 2009-07-08 at 04:11 +0800, Rafael J. Wysocki wrote: > On Tuesday 07 July 2009, Frans Pop wrote: > > On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > > > The following bug entry is on the current list of known regressions > > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > > > Subject : Warning 'Invalid throttling state, reset' gets displayed when > > > it should not be > > > Submitter : Frans Pop <elendil@planet.nl> > > > Date : 2009-05-26 15:24 (42 days old) > > > Handled-By : Frans Pop <elendil@planet.nl> > > > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > > > http://bugzilla.kernel.org/attachment.cgi?id=21672 > > both Acked-by: Zhang Rui <rui.zhang@intel.com> thanks, rui > > I still have not received any reaction from the ACPI maintainers to the > > bug or the proposed patches. > > Sorry for that. > > Len, what do you think of the patches listed above? > > Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be @ 2009-07-08 0:56 ` Zhang Rui 0 siblings, 0 replies; 467+ messages in thread From: Zhang Rui @ 2009-07-08 0:56 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Len Brown, Linux Kernel Mailing List, Kernel Testers List On Wed, 2009-07-08 at 04:11 +0800, Rafael J. Wysocki wrote: > On Tuesday 07 July 2009, Frans Pop wrote: > > On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > > > The following bug entry is on the current list of known regressions > > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 > > > Subject : Warning 'Invalid throttling state, reset' gets displayed when > > > it should not be > > > Submitter : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> > > > Date : 2009-05-26 15:24 (42 days old) > > > Handled-By : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> > > > Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 > > > http://bugzilla.kernel.org/attachment.cgi?id=21672 > > both Acked-by: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> thanks, rui > > I still have not received any reaction from the ACPI maintainers to the > > bug or the proposed patches. > > Sorry for that. > > Len, what do you think of the patches listed above? > > Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected) 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jens Axboe, Laurent Riffard This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (40 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected) @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jens Axboe, Laurent Riffard This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard-GANU6spQydw@public.gmane.org> Date : 2009-05-28 18:43 (40 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13407] adb trackpad disappears after suspend to ram 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Benjamin Herrenschmidt, Jan Scholz, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (40 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13407] adb trackpad disappears after suspend to ram @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Benjamin Herrenschmidt, Jan Scholz, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org> Date : 2009-05-28 7:59 (40 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13424] possible deadlock when doing governor switching 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Mathieu Desnoyers, Shaohua Li This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-05-31 16:36 (37 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html http://lkml.org/lkml/2009/6/28/405 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13424] possible deadlock when doing governor switching @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Mathieu Desnoyers, Shaohua Li This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Date : 2009-05-31 16:36 (37 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html http://lkml.org/lkml/2009/6/28/405 Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13408] Performance regression in 2.6.30-rc7 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrew Morton, Diego Calleja This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (38 days old) References : http://lkml.org/lkml/2009/5/30/146 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13408] Performance regression in 2.6.30-rc7 @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrew Morton, Diego Calleja This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-05-30 18:51 (38 days old) References : http://lkml.org/lkml/2009/5/30/146 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, ACPI Devel Maling List, Ozan Çağlayan This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (33 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, ACPI Devel Maling List, Ozan Çağlayan This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (33 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13475] suspend/hibernate lockdep warning 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Young, Mathieu Desnoyers This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar@gmail.com> Date : 2009-06-02 10:00 (35 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Patch : http://patchwork.kernel.org/patch/28660/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13475] suspend/hibernate lockdep warning @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Young, Mathieu Desnoyers This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-02 10:00 (35 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org> Patch : http://patchwork.kernel.org/patch/28660/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, sveina This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (27 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, sveina-Re5JQEeQqe8AvxtiuMwx3w This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-10 20:04 (27 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13472] Oops with minicom and USB serial 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Stern, Peter Chubb This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> Date : 2009-06-05 1:37 (32 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13472] Oops with minicom and USB serial @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Stern, Peter Chubb This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc-M3ycANVxPotyL3EAZA59ERCuuivNXqWP@public.gmane.org> Date : 2009-06-05 1:37 (32 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13512] D43 on 2.6.30 doesn't suspend anymore 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Daniel Smolik, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (26 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13512] D43 on 2.6.30 doesn't suspend anymore @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Daniel Smolik, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin-0pWKB23IDFjrBKCeMvbIDA@public.gmane.org> Date : 2009-06-11 20:12 (26 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13518] slab grows with NFS write activity. 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrew Randrianasulu, Linus Torvalds This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik@mail.ru> Date : 2009-06-12 09:51 (25 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13518] slab grows with NFS write activity. @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrew Randrianasulu, Linus Torvalds This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik-JGs/UdohzUI@public.gmane.org> Date : 2009-06-12 09:51 (25 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13514] acer_wmi causes stack corruption 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Rus This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (25 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13514] acer_wmi causes stack corruption @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Rus This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour-K87ZgELTUEPsG83rWm+8vg@public.gmane.org> Date : 2009-06-12 08:13 (25 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jos van Wolput This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> Date : 2009-06-17 06:28 (20 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jos van Wolput This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org> Date : 2009-06-17 06:28 (20 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-20 21:35 ` Andrew Morton -1 siblings, 0 replies; 467+ messages in thread From: Andrew Morton @ 2009-07-20 21:35 UTC (permalink / raw) To: Rafael J. Wysocki Cc: linux-kernel, kernel-testers, wolput, Nico Schottelius, Jesse Barnes, dri-devel On Tue, 7 Jul 2009 02:00:46 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 > Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window > Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> > Date : 2009-06-17 06:28 (20 days old) Nico reported a black-screen regression too. Subject: 2.6.31-r2: Xorg: Black screen Compared to the other normal brightness problems, with 2.6.31-r2 xorg starts, but there is no image displayed (neither on internal nor external monitor). Switching back to console does not change the status, though hitting ctrlaltdel reboots the system (i.e. still up and running fine). It works with 2.6.30-rc7 (besides sometimes the brightness is broken there). This looks like it might be a post-2.6.30 regression, in which case it might have a separate cause. We're having a lot of problems in this area. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window @ 2009-07-20 21:35 ` Andrew Morton 0 siblings, 0 replies; 467+ messages in thread From: Andrew Morton @ 2009-07-20 21:35 UTC (permalink / raw) To: Rafael J. Wysocki Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-testers-u79uwXL29TY76Z2rM5mHXA, wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh, Nico Schottelius, Jesse Barnes, dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Tue, 7 Jul 2009 02:00:46 +0200 (CEST) "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 > Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window > Submitter : Jos van Wolput <wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org> > Date : 2009-06-17 06:28 (20 days old) Nico reported a black-screen regression too. Subject: 2.6.31-r2: Xorg: Black screen Compared to the other normal brightness problems, with 2.6.31-r2 xorg starts, but there is no image displayed (neither on internal nor external monitor). Switching back to console does not change the status, though hitting ctrlaltdel reboots the system (i.e. still up and running fine). It works with 2.6.30-rc7 (besides sometimes the brightness is broken there). This looks like it might be a post-2.6.30 regression, in which case it might have a separate cause. We're having a lot of problems in this area. ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13558] Tracelog during resume 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (20 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13558] Tracelog during resume @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org> Date : 2009-06-17 11:32 (20 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Jenkins, Bob Moore This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (12 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Jenkins, Bob Moore This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org> Date : 2009-06-25 08:31 (12 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13564] random general protection fault at boot time caused by khubd. 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pauli This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (19 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13564] random general protection fault at boot time caused by khubd. @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pauli This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-18 12:44 (19 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13581] ath9k doesn't work with newer kernels 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Matteo This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (18 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13581] ath9k doesn't work with newer kernels @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Matteo This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85-whZMOeQn8C0@public.gmane.org> Date : 2009-06-19 12:04 (18 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13583] pdflush uses 5% CPU on otherwise idle system 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Paul Martin This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (18 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13583] pdflush uses 5% CPU on otherwise idle system @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Paul Martin This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> Date : 2009-06-19 13:33 (18 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13621] xfs hangs with assertion failed 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ 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 Engel This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (12 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13621] xfs hangs with assertion failed @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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 Engel This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> Date : 2009-06-25 10:07 (12 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13624] usb: wrong autosuspend initialization 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alan Stern, list This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list@phuk.ath.cx> Date : 2009-06-25 18:18 (12 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13624] usb: wrong autosuspend initialization @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alan Stern, list-2tUql6aCh3Vfq8cQ1yknNg This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org> Date : 2009-06-25 18:18 (12 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13624] usb: wrong autosuspend initialization 2009-07-07 0:00 ` Rafael J. Wysocki (?) @ 2009-07-07 0:22 ` list -1 siblings, 0 replies; 467+ messages in thread From: list @ 2009-07-07 0:22 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Alan Stern I think this should be considered a regression, at least until laptop_mode has been fixed to deal with it. I've reported it to their mailing list, but it seems somebody has to come up with a patch (I won't be able to look into it before mid-August). Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 > Subject : usb: wrong autosuspend initialization > Submitter : <list@phuk.ath.cx> > Date : 2009-06-25 18:18 (12 days old) > > ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (10 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Cijoml Cijomlovic Cijomlov This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org> Date : 2009-06-27 07:02 (10 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13638] rt2870 driver is broken for (some) cards 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, jakob gruber This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber@kabelnet.at> Date : 2009-06-27 17:33 (10 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13638] rt2870 driver is broken for (some) cards @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, jakob gruber This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber-1wqg/2C4znHk7+2FdBfRIA@public.gmane.org> Date : 2009-06-27 17:33 (10 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ 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 Stezenbach, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js@sig21.net> Date : 2009-06-16 01:27 (21 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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 Stezenbach, Rafael J. Wysocki This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org> Date : 2009-06-16 01:27 (21 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13646] warn_on tty_io.c, broken bluetooth 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pavel Machek This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (18 days old) References : http://lkml.org/lkml/2009/6/19/187 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13646] warn_on tty_io.c, broken bluetooth @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pavel Machek This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> Date : 2009-06-19 17:05 (18 days old) References : http://lkml.org/lkml/2009/6/19/187 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13647] fb/mmap lockdep report. 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrea Righi, Dave Jones, Jarek Poplawski This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 Subject : fb/mmap lockdep report. Submitter : Dave Jones <davej@redhat.com> Date : 2009-06-21 13:33 (16 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 References : http://lkml.org/lkml/2009/6/21/90 http://lkml.org/lkml/2009/6/21/122 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13647] fb/mmap lockdep report. @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Andrea Righi, Dave Jones, Jarek Poplawski This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 Subject : fb/mmap lockdep report. Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Date : 2009-06-21 13:33 (16 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 References : http://lkml.org/lkml/2009/6/21/90 http://lkml.org/lkml/2009/6/21/122 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13647] fb/mmap lockdep report. 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-07 5:57 ` Jarek Poplawski -1 siblings, 0 replies; 467+ messages in thread From: Jarek Poplawski @ 2009-07-07 5:57 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Andrea Righi, Dave Jones On Tue, Jul 07, 2009 at 02:00:51AM +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 > Subject : fb/mmap lockdep report. > Submitter : Dave Jones <davej@redhat.com> > Date : 2009-06-21 13:33 (16 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 > References : http://lkml.org/lkml/2009/6/21/90 > http://lkml.org/lkml/2009/6/21/122 This lockdep report isn't triggered by 2.6.31-rc2 anymore. Thanks, Jarek P. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13647] fb/mmap lockdep report. @ 2009-07-07 5:57 ` Jarek Poplawski 0 siblings, 0 replies; 467+ messages in thread From: Jarek Poplawski @ 2009-07-07 5:57 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Andrea Righi, Dave Jones On Tue, Jul 07, 2009 at 02:00:51AM +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 > Subject : fb/mmap lockdep report. > Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > Date : 2009-06-21 13:33 (16 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 > References : http://lkml.org/lkml/2009/6/21/90 > http://lkml.org/lkml/2009/6/21/122 This lockdep report isn't triggered by 2.6.31-rc2 anymore. Thanks, Jarek P. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13647] fb/mmap lockdep report. @ 2009-07-07 11:04 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 11:04 UTC (permalink / raw) To: Jarek Poplawski Cc: Linux Kernel Mailing List, Kernel Testers List, Andrea Righi, Dave Jones On Tuesday 07 July 2009, Jarek Poplawski wrote: > On Tue, Jul 07, 2009 at 02:00:51AM +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 > > Subject : fb/mmap lockdep report. > > Submitter : Dave Jones <davej@redhat.com> > > Date : 2009-06-21 13:33 (16 days old) > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 > > References : http://lkml.org/lkml/2009/6/21/90 > > http://lkml.org/lkml/2009/6/21/122 > > This lockdep report isn't triggered by 2.6.31-rc2 anymore. Thanks, I've closed the bug. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13647] fb/mmap lockdep report. @ 2009-07-07 11:04 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 11:04 UTC (permalink / raw) To: Jarek Poplawski Cc: Linux Kernel Mailing List, Kernel Testers List, Andrea Righi, Dave Jones On Tuesday 07 July 2009, Jarek Poplawski wrote: > On Tue, Jul 07, 2009 at 02:00:51AM +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 > > Subject : fb/mmap lockdep report. > > Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > Date : 2009-06-21 13:33 (16 days old) > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 > > References : http://lkml.org/lkml/2009/6/21/90 > > http://lkml.org/lkml/2009/6/21/122 > > This lockdep report isn't triggered by 2.6.31-rc2 anymore. Thanks, I've closed the bug. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13648] nfsd: page allocation failure 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Justin Piszcz This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-06-22 12:08 (15 days old) References : http://lkml.org/lkml/2009/6/22/309 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13648] nfsd: page allocation failure @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Justin Piszcz This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org> Date : 2009-06-22 12:08 (15 days old) References : http://lkml.org/lkml/2009/6/22/309 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-07 3:55 ` David Rientjes -1 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-07 3:55 UTC (permalink / raw) To: Justin Piszcz Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki On Tue, 7 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 > Subject : nfsd: page allocation failure > Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> > Date : 2009-06-22 12:08 (15 days old) > References : http://lkml.org/lkml/2009/6/22/309 > Here's the last page allocation failure in the bug report: [415964.311165] nfsd: page allocation failure. order:0, mode:0x20 [415964.311168] Pid: 2680, comm: nfsd Not tainted 2.6.30 #2 [415964.311170] Call Trace: [415964.311171] <IRQ> [<ffffffff802849ed>] ? __alloc_pages_internal+0x3dd/0x4e0 [415964.311179] [<ffffffff802a6c77>] ? cache_alloc_refill+0x2d7/0x570 [415964.311182] [<ffffffff802a707d>] ? kmem_cache_alloc+0x8d/0xa0 [415964.311185] [<ffffffff805a6109>] ? __alloc_skb+0x49/0x160 [415964.311188] [<ffffffff805ea846>] ? tcp_send_ack+0x26/0x120 [415964.311191] [<ffffffff805e867d>] ? tcp_rcv_established+0x7bd/0x940 [415964.311193] [<ffffffff805efb1d>] ? tcp_v4_do_rcv+0xdd/0x210 [415964.311195] [<ffffffff805f02d6>] ? tcp_v4_rcv+0x686/0x750 ... [415964.311319] Active_anon:154810 active_file:131162 inactive_anon:33447 [415964.311320] inactive_file:690987 unevictable:0 dirty:112116 writeback:0 unstable:0 [415964.311321] free:8662 slab:965366 mapped:9316 pagetables:4618 bounce:0 [415964.311325] DMA free:9692kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:8668kB pages_scanned:0 all_unreclaimable? yes [415964.311328] lowmem_reserve[]: 0 3246 7980 7980 [415964.311333] DMA32 free:21312kB min:6656kB low:8320kB high:9984kB active_anon:118464kB inactive_anon:23908kB active_file:174708kB inactive_file:1206812kB unevictable:0kB present:3324312kB pages_scanned:0 all_unreclaimable? no [415964.311336] lowmem_reserve[]: 0 0 4734 4734 [415964.311341] Normal free:3644kB min:9708kB low:12132kB high:14560kB active_anon:500776kB inactive_anon:109880kB active_file:349940kB inactive_file:1557136kB unevictable:0kB present:4848000kB pages_scanned:0 all_unreclaimable? no [415964.311344] lowmem_reserve[]: 0 0 0 0 ... There's simply no memory available in ZONE_NORMAL to satisfy the atomic allocation; you've been able to allocate beyond the 9708K minimum watermark because it's GFP_ATOMIC (and then only to 3641K because of ALLOC_HIGH and ALLOC_HARDER). 112116 pages, or 438M of memory, is dirty. [415964.311369] 827035 total pagecache pages [415964.311371] 4728 pages in swap cache [415964.311373] Swap cache stats: add 12746, delete 8018, find 16878/17480 [415964.311374] Free swap = 16756356kB [415964.311375] Total swap = 16787768kB [415964.312141] 2277376 pages RAM [415964.312141] 252254 pages reserved [415964.312141] 546309 pages shared [415964.312141] 1520221 pages non-shared And since you have an 8G machine, that value is only about half of the default dirty_background_ratio setting of 10 to start pdflush from writing it out. What is suspect is almost half of your system's memory is consumed by slab. Have you been able to collect slabtop -o when these failures happen to determine whether this is a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=13518 ? ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure @ 2009-07-07 3:55 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-07 3:55 UTC (permalink / raw) To: Justin Piszcz Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki On Tue, 7 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 > Subject : nfsd: page allocation failure > Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org> > Date : 2009-06-22 12:08 (15 days old) > References : http://lkml.org/lkml/2009/6/22/309 > Here's the last page allocation failure in the bug report: [415964.311165] nfsd: page allocation failure. order:0, mode:0x20 [415964.311168] Pid: 2680, comm: nfsd Not tainted 2.6.30 #2 [415964.311170] Call Trace: [415964.311171] <IRQ> [<ffffffff802849ed>] ? __alloc_pages_internal+0x3dd/0x4e0 [415964.311179] [<ffffffff802a6c77>] ? cache_alloc_refill+0x2d7/0x570 [415964.311182] [<ffffffff802a707d>] ? kmem_cache_alloc+0x8d/0xa0 [415964.311185] [<ffffffff805a6109>] ? __alloc_skb+0x49/0x160 [415964.311188] [<ffffffff805ea846>] ? tcp_send_ack+0x26/0x120 [415964.311191] [<ffffffff805e867d>] ? tcp_rcv_established+0x7bd/0x940 [415964.311193] [<ffffffff805efb1d>] ? tcp_v4_do_rcv+0xdd/0x210 [415964.311195] [<ffffffff805f02d6>] ? tcp_v4_rcv+0x686/0x750 ... [415964.311319] Active_anon:154810 active_file:131162 inactive_anon:33447 [415964.311320] inactive_file:690987 unevictable:0 dirty:112116 writeback:0 unstable:0 [415964.311321] free:8662 slab:965366 mapped:9316 pagetables:4618 bounce:0 [415964.311325] DMA free:9692kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:8668kB pages_scanned:0 all_unreclaimable? yes [415964.311328] lowmem_reserve[]: 0 3246 7980 7980 [415964.311333] DMA32 free:21312kB min:6656kB low:8320kB high:9984kB active_anon:118464kB inactive_anon:23908kB active_file:174708kB inactive_file:1206812kB unevictable:0kB present:3324312kB pages_scanned:0 all_unreclaimable? no [415964.311336] lowmem_reserve[]: 0 0 4734 4734 [415964.311341] Normal free:3644kB min:9708kB low:12132kB high:14560kB active_anon:500776kB inactive_anon:109880kB active_file:349940kB inactive_file:1557136kB unevictable:0kB present:4848000kB pages_scanned:0 all_unreclaimable? no [415964.311344] lowmem_reserve[]: 0 0 0 0 ... There's simply no memory available in ZONE_NORMAL to satisfy the atomic allocation; you've been able to allocate beyond the 9708K minimum watermark because it's GFP_ATOMIC (and then only to 3641K because of ALLOC_HIGH and ALLOC_HARDER). 112116 pages, or 438M of memory, is dirty. [415964.311369] 827035 total pagecache pages [415964.311371] 4728 pages in swap cache [415964.311373] Swap cache stats: add 12746, delete 8018, find 16878/17480 [415964.311374] Free swap = 16756356kB [415964.311375] Total swap = 16787768kB [415964.312141] 2277376 pages RAM [415964.312141] 252254 pages reserved [415964.312141] 546309 pages shared [415964.312141] 1520221 pages non-shared And since you have an 8G machine, that value is only about half of the default dirty_background_ratio setting of 10 to start pdflush from writing it out. What is suspect is almost half of your system's memory is consumed by slab. Have you been able to collect slabtop -o when these failures happen to determine whether this is a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=13518 ? ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure 2009-07-07 3:55 ` David Rientjes (?) @ 2009-07-07 8:01 ` Justin Piszcz -1 siblings, 0 replies; 467+ messages in thread From: Justin Piszcz @ 2009-07-07 8:01 UTC (permalink / raw) To: David Rientjes Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki On Mon, 6 Jul 2009, David Rientjes wrote: > On Tue, 7 Jul 2009, Rafael J. Wysocki wrote: > >> This message has been generated automatically as a part of a report >> of regressions introduced between 2.6.29 and 2.6.30. >> >> The following bug entry is on the current list of known regressions >> introduced between 2.6.29 and 2.6.30. Please verify if it still should >> be listed and let me know (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 >> Subject : nfsd: page allocation failure >> Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> >> Date : 2009-06-22 12:08 (15 days old) >> References : http://lkml.org/lkml/2009/6/22/309 >> > > Here's the last page allocation failure in the bug report: > > [415964.311165] nfsd: page allocation failure. order:0, mode:0x20 > [415964.311168] Pid: 2680, comm: nfsd Not tainted 2.6.30 #2 > [415964.311170] Call Trace: > [415964.311171] <IRQ> [<ffffffff802849ed>] ? __alloc_pages_internal+0x3dd/0x4e0 > [415964.311179] [<ffffffff802a6c77>] ? cache_alloc_refill+0x2d7/0x570 > [415964.311182] [<ffffffff802a707d>] ? kmem_cache_alloc+0x8d/0xa0 > [415964.311185] [<ffffffff805a6109>] ? __alloc_skb+0x49/0x160 > [415964.311188] [<ffffffff805ea846>] ? tcp_send_ack+0x26/0x120 > [415964.311191] [<ffffffff805e867d>] ? tcp_rcv_established+0x7bd/0x940 > [415964.311193] [<ffffffff805efb1d>] ? tcp_v4_do_rcv+0xdd/0x210 > [415964.311195] [<ffffffff805f02d6>] ? tcp_v4_rcv+0x686/0x750 > ... > [415964.311319] Active_anon:154810 active_file:131162 inactive_anon:33447 > [415964.311320] inactive_file:690987 unevictable:0 dirty:112116 writeback:0 unstable:0 > [415964.311321] free:8662 slab:965366 mapped:9316 pagetables:4618 bounce:0 > [415964.311325] DMA free:9692kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:8668kB pages_scanned:0 all_unreclaimable? yes > [415964.311328] lowmem_reserve[]: 0 3246 7980 7980 > [415964.311333] DMA32 free:21312kB min:6656kB low:8320kB high:9984kB active_anon:118464kB inactive_anon:23908kB active_file:174708kB inactive_file:1206812kB unevictable:0kB present:3324312kB pages_scanned:0 all_unreclaimable? no > [415964.311336] lowmem_reserve[]: 0 0 4734 4734 > [415964.311341] Normal free:3644kB min:9708kB low:12132kB high:14560kB active_anon:500776kB inactive_anon:109880kB active_file:349940kB inactive_file:1557136kB unevictable:0kB present:4848000kB pages_scanned:0 all_unreclaimable? no > [415964.311344] lowmem_reserve[]: 0 0 0 0 > ... > > There's simply no memory available in ZONE_NORMAL to satisfy the atomic > allocation; you've been able to allocate beyond the 9708K minimum > watermark because it's GFP_ATOMIC (and then only to 3641K because of > ALLOC_HIGH and ALLOC_HARDER). > > 112116 pages, or 438M of memory, is dirty. > > [415964.311369] 827035 total pagecache pages > [415964.311371] 4728 pages in swap cache > [415964.311373] Swap cache stats: add 12746, delete 8018, find 16878/17480 > [415964.311374] Free swap = 16756356kB > [415964.311375] Total swap = 16787768kB > [415964.312141] 2277376 pages RAM > [415964.312141] 252254 pages reserved > [415964.312141] 546309 pages shared > [415964.312141] 1520221 pages non-shared > > And since you have an 8G machine, that value is only about half of the > default dirty_background_ratio setting of 10 to start pdflush from writing > it out. > > What is suspect is almost half of your system's memory is consumed by > slab. Have you been able to collect slabtop -o when these failures happen > to determine whether this is a duplicate of > http://bugzilla.kernel.org/show_bug.cgi?id=13518 ? > As of yet, the problem has not recurred, when it does, will pull slabtop -o output. Justin. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure 2009-07-07 0:00 ` Rafael J. Wysocki @ 2009-07-19 21:36 ` David Rientjes -1 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-19 21:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Justin Piszcz, Stephan von Krawcynski On Tue, 7 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 > Subject : nfsd: page allocation failure > Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> > Date : 2009-06-22 12:08 (15 days old) > References : http://lkml.org/lkml/2009/6/22/309 > Stephan von Krawczynski has this problem with e1000e (but not e1000 or tg3) at least as far back as 2.6.28, so this doesn't appear to be a regression introduced in 2.6.30. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure @ 2009-07-19 21:36 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-07-19 21:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Justin Piszcz, Stephan von Krawcynski On Tue, 7 Jul 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 > Subject : nfsd: page allocation failure > Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org> > Date : 2009-06-22 12:08 (15 days old) > References : http://lkml.org/lkml/2009/6/22/309 > Stephan von Krawczynski has this problem with e1000e (but not e1000 or tg3) at least as far back as 2.6.28, so this doesn't appear to be a regression introduced in 2.6.30. ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13649] Bad page state in process with various applications 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maxim Levitsky, Mel Gorman This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-06-20 15:27 (17 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel@csn.ul.ie> Patch : http://patchwork.kernel.org/patch/33130/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13649] Bad page state in process with various applications @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maxim Levitsky, Mel Gorman This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-20 15:27 (17 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> Patch : http://patchwork.kernel.org/patch/33130/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13651] Anyone know what happened with PC speaker in 2.6.30? 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Frans Pop, Ken Witherow, Michael Tokarev, Takashi Iwai This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13651 Subject : Anyone know what happened with PC speaker in 2.6.30? Submitter : Michael Tokarev <mjt@tls.msk.ru> Date : 2009-06-15 14:41 (22 days old) References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13651] Anyone know what happened with PC speaker in 2.6.30? @ 2009-07-07 0:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:00 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Frans Pop, Ken Witherow, Michael Tokarev, Takashi Iwai This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13651 Subject : Anyone know what happened with PC speaker in 2.6.30? Submitter : Michael Tokarev <mjt-XAri/EZa3C4vJsYlp49lxw@public.gmane.org> Date : 2009-06-15 14:41 (22 days old) References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13651] Anyone know what happened with PC speaker in 2.6.30? 2009-07-07 0:00 ` Rafael J. Wysocki (?) @ 2009-07-07 19:13 ` Frans Pop 2009-07-07 20:24 ` Rafael J. Wysocki -1 siblings, 1 reply; 467+ messages in thread From: Frans Pop @ 2009-07-07 19:13 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Ken Witherow, Michael Tokarev, Takashi Iwai On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13651 > Subject : Anyone know what happened with PC speaker in 2.6.30? > Submitter : Michael Tokarev <mjt@tls.msk.ru> > Date : 2009-06-15 14:41 (22 days old) > References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4 Given the last comments from Michael I think this should be closed as "not a bug". The observed behavior is intended. See: http://lkml.org/lkml/2009/6/29/232. Cheers, FJP ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13651] Anyone know what happened with PC speaker in 2.6.30? @ 2009-07-07 20:24 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 20:24 UTC (permalink / raw) To: Frans Pop, Michael Tokarev Cc: Linux Kernel Mailing List, Kernel Testers List, Ken Witherow, Takashi Iwai On Tuesday 07 July 2009, Frans Pop wrote: > On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13651 > > Subject : Anyone know what happened with PC speaker in 2.6.30? > > Submitter : Michael Tokarev <mjt@tls.msk.ru> > > Date : 2009-06-15 14:41 (22 days old) > > References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4 > > Given the last comments from Michael I think this should be closed as "not > a bug". The observed behavior is intended. > See: http://lkml.org/lkml/2009/6/29/232. Well, I guess the regression here is the apparent lack of documentation, but now that the problem has been discussed, I guess this is not a problem any more. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13651] Anyone know what happened with PC speaker in 2.6.30? @ 2009-07-07 20:24 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 20:24 UTC (permalink / raw) To: Frans Pop, Michael Tokarev Cc: Linux Kernel Mailing List, Kernel Testers List, Ken Witherow, Takashi Iwai On Tuesday 07 July 2009, Frans Pop wrote: > On Tuesday 07 July 2009, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13651 > > Subject : Anyone know what happened with PC speaker in 2.6.30? > > Submitter : Michael Tokarev <mjt-XAri/EZa3C4vJsYlp49lxw@public.gmane.org> > > Date : 2009-06-15 14:41 (22 days old) > > References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4 > > Given the last comments from Michael I think this should be closed as "not > a bug". The observed behavior is intended. > See: http://lkml.org/lkml/2009/6/29/232. Well, I guess the regression here is the apparent lack of documentation, but now that the problem has been discussed, I guess this is not a problem any more. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Joao Correia This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (10 days old) References : http://lkml.org/lkml/2009/6/27/95 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs @ 2009-07-07 0:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Joao Correia This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-27 16:07 (10 days old) References : http://lkml.org/lkml/2009/6/27/95 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13663] suspend to ram regression (IDE related) 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Bartlomiej Zolnierkiewicz, Etienne Basset, Jeff Chua This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13663 Subject : suspend to ram regression (IDE related) Submitter : Etienne Basset <etienne.basset@numericable.fr> Date : 2009-06-26 17:40 (11 days old) References : http://lkml.org/lkml/2009/6/26/242 http://lkml.org/lkml/2009/6/29/126 Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Patch : http://patchwork.kernel.org/patch/32719/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13663] suspend to ram regression (IDE related) @ 2009-07-07 0:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Bartlomiej Zolnierkiewicz, Etienne Basset, Jeff Chua This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13663 Subject : suspend to ram regression (IDE related) Submitter : Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> Date : 2009-06-26 17:40 (11 days old) References : http://lkml.org/lkml/2009/6/26/242 http://lkml.org/lkml/2009/6/29/126 Handled-By : Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Patch : http://patchwork.kernel.org/patch/32719/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related) 2009-07-07 0:01 ` Rafael J. Wysocki @ 2009-07-07 18:02 ` Etienne Basset -1 siblings, 0 replies; 467+ messages in thread From: Etienne Basset @ 2009-07-07 18:02 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Bartlomiej Zolnierkiewicz, Jeff Chua Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13663 > Subject : suspend to ram regression (IDE related) > Submitter : Etienne Basset <etienne.basset@numericable.fr> > Date : 2009-06-26 17:40 (11 days old) > References : http://lkml.org/lkml/2009/6/26/242 > http://lkml.org/lkml/2009/6/29/126 > Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> > Patch : http://patchwork.kernel.org/patch/32719/ > > > hello, current git is OK, patch is not yet in 2.6.30-stable regards Etienne ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related) @ 2009-07-07 18:02 ` Etienne Basset 0 siblings, 0 replies; 467+ messages in thread From: Etienne Basset @ 2009-07-07 18:02 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Bartlomiej Zolnierkiewicz, Jeff Chua Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13663 > Subject : suspend to ram regression (IDE related) > Submitter : Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> > Date : 2009-06-26 17:40 (11 days old) > References : http://lkml.org/lkml/2009/6/26/242 > http://lkml.org/lkml/2009/6/29/126 > Handled-By : Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Patch : http://patchwork.kernel.org/patch/32719/ > > > hello, current git is OK, patch is not yet in 2.6.30-stable regards Etienne ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13669] Kernel bug with dock driver 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Henrique de Moraes Holschuh, Joerg Platte This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte@naasa.net> Date : 2009-06-14 21:00 (23 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13669] Kernel bug with dock driver @ 2009-07-07 0:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Henrique de Moraes Holschuh, Joerg Platte This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte-v18Uk5sXZWJeoWH0uzbU5w@public.gmane.org> Date : 2009-06-14 21:00 (23 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu. 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Benjamin Herrenschmidt, Jeremy Kerr, Rob Landley This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13668 Subject : Can't boot 2.6.30 powerpc kernel under qemu. Submitter : Rob Landley <rob@landley.net> Date : 2009-06-27 18:08 (10 days old) References : http://lkml.org/lkml/2009/6/27/159 ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu. @ 2009-07-07 0:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Benjamin Herrenschmidt, Jeremy Kerr, Rob Landley This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13668 Subject : Can't boot 2.6.30 powerpc kernel under qemu. Submitter : Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> Date : 2009-06-27 18:08 (10 days old) References : http://lkml.org/lkml/2009/6/27/159 ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu. 2009-07-07 0:01 ` Rafael J. Wysocki (?) @ 2009-07-07 2:49 ` Rob Landley 2009-07-07 11:08 ` Rafael J. Wysocki -1 siblings, 1 reply; 467+ messages in thread From: Rob Landley @ 2009-07-07 2:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Benjamin Herrenschmidt, Jeremy Kerr On Monday 06 July 2009 19:01:05 Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13668 > Subject : Can't boot 2.6.30 powerpc kernel under qemu. > Submitter : Rob Landley <rob@landley.net> > Date : 2009-06-27 18:08 (10 days old) > References : http://lkml.org/lkml/2009/6/27/159 Resolved, it just required a configuration change. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu. @ 2009-07-07 11:08 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 11:08 UTC (permalink / raw) To: Rob Landley Cc: Linux Kernel Mailing List, Kernel Testers List, Benjamin Herrenschmidt, Jeremy Kerr On Tuesday 07 July 2009, Rob Landley wrote: > On Monday 06 July 2009 19:01:05 Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13668 > > Subject : Can't boot 2.6.30 powerpc kernel under qemu. > > Submitter : Rob Landley <rob@landley.net> > > Date : 2009-06-27 18:08 (10 days old) > > References : http://lkml.org/lkml/2009/6/27/159 > > Resolved, it just required a configuration change. Thanks, closed. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu. @ 2009-07-07 11:08 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 11:08 UTC (permalink / raw) To: Rob Landley Cc: Linux Kernel Mailing List, Kernel Testers List, Benjamin Herrenschmidt, Jeremy Kerr On Tuesday 07 July 2009, Rob Landley wrote: > On Monday 06 July 2009 19:01:05 Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13668 > > Subject : Can't boot 2.6.30 powerpc kernel under qemu. > > Submitter : Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> > > Date : 2009-06-27 18:08 (10 days old) > > References : http://lkml.org/lkml/2009/6/27/159 > > Resolved, it just required a configuration change. Thanks, closed. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13681] A number of usb Devices causes Oops messages and kernel panics. 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alexander Kaltsas This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 Subject : A number of usb Devices causes Oops messages and kernel panics. Submitter : Alexander Kaltsas <alexkaltsas@gmail.com> Date : 2009-06-30 13:06 (7 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13681] A number of usb Devices causes Oops messages and kernel panics. @ 2009-07-07 0:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alexander Kaltsas This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13681 Subject : A number of usb Devices causes Oops messages and kernel panics. Submitter : Alexander Kaltsas <alexkaltsas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-30 13:06 (7 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Nathanael Schaeffer This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (7 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 @ 2009-07-07 0:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Nathanael Schaeffer This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-06-30 13:34 (7 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 2009-07-07 0:01 ` Rafael J. Wysocki @ 2009-07-07 7:32 ` Oliver Neukum -1 siblings, 0 replies; 467+ messages in thread From: Oliver Neukum @ 2009-07-07 7:32 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Nathanael Schaeffer Am Dienstag, 7. Juli 2009 02:01:07 schrieb Rafael J. Wysocki: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 > Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 > Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> > Date : 2009-06-30 13:34 (7 days old) This is caused by selecting a format (no longer / not) supported. Please make an strace of the failing programm so we know what it requests. Regards Oliver ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 @ 2009-07-07 7:32 ` Oliver Neukum 0 siblings, 0 replies; 467+ messages in thread From: Oliver Neukum @ 2009-07-07 7:32 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Nathanael Schaeffer Am Dienstag, 7. Juli 2009 02:01:07 schrieb Rafael J. Wysocki: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 > Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 > Submitter : Nathanael Schaeffer <nathanael.schaeffer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2009-06-30 13:34 (7 days old) This is caused by selecting a format (no longer / not) supported. Please make an strace of the failing programm so we know what it requests. Regards Oliver ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13694] i915 phantom TV 2009-07-06 23:57 ` Rafael J. Wysocki @ 2009-07-07 0:01 ` Rafael J. Wysocki -1 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciek Józiewicz This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (5 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13694] i915 phantom TV @ 2009-07-07 0:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-07-07 0:01 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciek Józiewicz This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-07-02 12:26 (5 days old) ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.31-rc7-git2: Reported regressions 2.6.29 -> 2.6.30 @ 2009-08-25 20:37 Rafael J. Wysocki 2009-08-25 21:05 ` Rafael J. Wysocki 0 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-25 20:37 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-08-26 152 33 30 2009-08-20 150 35 32 2009-08-10 148 39 37 2009-08-02 145 44 39 2009-07-27 143 48 45 2009-07-07 138 50 46 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14049 Subject : joydev: blacklist digitizers avoids recognition of Saitek X52 joysticks Submitter : Janos Laube <janos.dev@gmail.com> Date : 2009-08-24 14:18 (2 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d07a9cba6be5c0e947afc1014b5a62182a86f1f1 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13958 Subject : ath5k Atheros AR5001 low signal Submitter : Marco Siviero <darker1985@slacky.it> Date : 2009-08-10 15:03 (16 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13949 Subject : XFS regression Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-08-08 8:39 (18 days old) References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898 Subject : Intel 3945ABG - problems on 2.6.30.X Submitter : dienet <dienet@poczta.fm> Date : 2009-07-31 15:17 (26 days old) References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797 Subject : iBook G4 doesn't suspend since 2ed8d2b3a8 Submitter : Jörg Sommer <joerg@alea.gnuu.de> Date : 2009-07-18 20:18 (39 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795 Subject : abnormal boot and no suspend due to 'async' (fastboot) Submitter : Rafal Kaczynski <fscnoboot@wp.pl> Date : 2009-07-18 17:19 (39 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 Subject : NULL pointer dereference loading powernowk8 Submitter : Kurt Roeckx <kurt@roeckx.be> Date : 2009-07-15 18:00 (42 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13770 Subject : System freeze on XFS filesystem recovery on an external disk Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com> Date : 2009-07-14 10:31 (43 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739 Subject : 2.6.30 leaking keys on console switch Submitter : Andi Kleen <andi@firstfloor.org> Date : 2009-07-07 8:44 (50 days old) References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4 Handled-By : Jiri Kosina <jkosina@suse.cz> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (55 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (57 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (68 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (68 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (68 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (69 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (70 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (75 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (76 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (77 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (88 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (90 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (90 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (96 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 - 2.6.31 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (98 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (99 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (115 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (118 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 (104 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (117 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180 Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Submitter : Niel Lambrechts <niel.lambrechts@gmail.com> Date : 2009-04-21 21:35 (127 days old) References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4 http://lkml.org/lkml/2009/4/27/290 Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14059 Subject : DomU crashes during xenfb initialization Submitter : Michal Schmidt <mschmidt@redhat.com> Date : 2009-08-21 10:40 (5 days old) References : http://marc.info/?l=linux-kernel&m=125085108431360&w=4 Handled-By : Michal Schmidt <mschmidt@redhat.com> Patch : http://patchwork.kernel.org/patch/43107/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (92 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=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/ For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ 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 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-08-25 21:05 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-25 21:05 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (119 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 http://lkml.org/lkml/2009/7/26/213 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Patch : http://patchwork.kernel.org/patch/37655/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-08-25 21:05 ` Rafael J. Wysocki @ 2009-08-26 6:25 ` Pekka Enberg -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-08-26 6:25 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-08-26 6:25 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger Hi Rafael, On Wed, Aug 26, 2009 at 12:05 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > Subject : Page allocation failures with b43 and p54usb > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > Date : 2009-04-29 21:01 (119 days old) > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > http://lkml.org/lkml/2009/6/7/136 > http://lkml.org/lkml/2009/7/26/213 > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > David Rientjes <rientjes-hpIqsD4AKldhl2p70BpVqQ@public.gmane.orgm> > Patch : http://patchwork.kernel.org/patch/37655/ FYI, the fix (a new slub debugging option) is queued for 2.6.32 and we don't have plans to backport it to -stable because it depends on SLUB out-of-memory diagnostic patches and the problem doesn't affect production configs. Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-08-26 20:53 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-08-26 20:53 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-26 20:53 UTC (permalink / raw) To: Pekka Enberg Cc: Linux Kernel Mailing List, Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger On Wednesday 26 August 2009, Pekka Enberg wrote: > Hi Rafael, > > On Wed, Aug 26, 2009 at 12:05 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > > Subject : Page allocation failures with b43 and p54usb > > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > > Date : 2009-04-29 21:01 (119 days old) > > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > > http://lkml.org/lkml/2009/6/7/136 > > http://lkml.org/lkml/2009/7/26/213 > > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > > David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> > > Patch : http://patchwork.kernel.org/patch/37655/ > > FYI, the fix (a new slub debugging option) is queued for 2.6.32 and we > don't have plans to backport it to -stable because it depends on SLUB > out-of-memory diagnostic patches and the problem doesn't affect > production configs. Thanks for the info, I've closed the bug as "will fix later". Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.31-rc6-git5: Reported regressions 2.6.29 -> 2.6.30 @ 2009-08-19 20:36 Rafael J. Wysocki 2009-08-19 20:40 ` Rafael J. Wysocki 0 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-19 20:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-08-20 150 35 32 2009-08-10 148 39 37 2009-08-02 145 44 39 2009-07-27 143 48 45 2009-07-07 138 50 46 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13958 Subject : ath5k Atheros AR5001 low signal Submitter : Marco Siviero <darker1985@slacky.it> Date : 2009-08-10 15:03 (10 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13949 Subject : XFS regression Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-08-08 8:39 (12 days old) References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13933 Subject : System lockup on dual Pentium-3 with kernel 2.6.30 Submitter : Martin Rogge <marogge@onlinehome.de> Date : 2009-08-08 13:16 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898 Subject : Intel 3945ABG - problems on 2.6.30.X Submitter : dienet <dienet@poczta.fm> Date : 2009-07-31 15:17 (20 days old) References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797 Subject : iBook G4 doesn't suspend since 2ed8d2b3a8 Submitter : Jörg Sommer <joerg@alea.gnuu.de> Date : 2009-07-18 20:18 (33 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795 Subject : abnormal boot and no suspend due to 'async' (fastboot) Submitter : Rafal Kaczynski <fscnoboot@wp.pl> Date : 2009-07-18 17:19 (33 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 Subject : NULL pointer dereference loading powernowk8 Submitter : Kurt Roeckx <kurt@roeckx.be> Date : 2009-07-15 18:00 (36 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13770 Subject : System freeze on XFS filesystem recovery on an external disk Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com> Date : 2009-07-14 10:31 (37 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739 Subject : 2.6.30 leaking keys on console switch Submitter : Andi Kleen <andi@firstfloor.org> Date : 2009-07-07 8:44 (44 days old) References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4 Handled-By : Jiri Kosina <jkosina@suse.cz> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (49 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (51 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (62 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (54 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (62 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (62 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (63 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (64 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (69 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (70 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (71 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (82 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (84 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (84 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (89 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (90 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 - 2.6.31 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (92 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (93 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (109 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (112 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 (98 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (111 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180 Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Submitter : Niel Lambrechts <niel.lambrechts@gmail.com> Date : 2009-04-21 21:35 (121 days old) References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4 http://lkml.org/lkml/2009/4/27/290 Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (56 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> Handled-By : Lin Ming <ming.m.lin@intel.com> Patch : http://patchwork.kernel.org/patch/33626/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (86 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=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/ For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ 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; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-08-19 20:40 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-19 20:40 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (113 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 http://lkml.org/lkml/2009/7/26/213 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Patch : http://patchwork.kernel.org/patch/37655/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.31-rc5-git5: Reported regressions 2.6.29 -> 2.6.30 @ 2009-08-09 21:07 Rafael J. Wysocki 2009-08-09 21:10 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 0 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-09 21:07 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-08-10 148 39 37 2009-08-02 145 44 39 2009-07-27 143 48 45 2009-07-07 138 50 46 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13949 Subject : XFS regression Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-08-08 8:39 (2 days old) References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13945 Subject : Kernel freezes dual pentium-3 system Submitter : Martin Rogge <marogge@onlinehome.de> Date : 2009-08-03 16:25 (7 days old) References : http://marc.info/?l=linux-kernel&m=124931667320530&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898 Subject : Intel 3945ABG - problems on 2.6.30.X Submitter : dienet <dienet@poczta.fm> Date : 2009-07-31 15:17 (10 days old) References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797 Subject : iBook G4 doesn't suspend since 2ed8d2b3a8 Submitter : Jörg Sommer <joerg@alea.gnuu.de> Date : 2009-07-18 20:18 (23 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795 Subject : abnormal boot and no suspend due to 'async' (fastboot) Submitter : Rafal Kaczynski <fscnoboot@wp.pl> Date : 2009-07-18 17:19 (23 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 Subject : NULL pointer dereference loading powernowk8 Submitter : Kurt Roeckx <kurt@roeckx.be> Date : 2009-07-15 18:00 (26 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13770 Subject : System freeze on XFS filesystem recovery on an external disk Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com> Date : 2009-07-14 10:31 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739 Subject : 2.6.30 leaking keys on console switch Submitter : Andi Kleen <andi@firstfloor.org> Date : 2009-07-07 8:44 (34 days old) References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4 Handled-By : Jiri Kosina <jkosina@suse.cz> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (39 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (41 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (44 days old) References : http://lkml.org/lkml/2009/6/27/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (52 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber@kabelnet.at> Date : 2009-06-27 17:33 (44 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (44 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (46 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (46 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (52 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (52 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (53 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (54 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (59 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (60 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (61 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (72 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (74 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (74 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (79 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (79 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (80 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (82 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (83 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (99 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (102 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 (88 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (101 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180 Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Submitter : Niel Lambrechts <niel.lambrechts@gmail.com> Date : 2009-04-21 21:35 (111 days old) References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4 http://lkml.org/lkml/2009/4/27/290 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (121 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (76 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=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/ For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ 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; 467+ 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] 467+ messages in thread
* 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30 @ 2009-08-02 19:06 Rafael J. Wysocki 2009-08-02 19:09 ` Rafael J. Wysocki 0 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-02 19:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-08-02 145 44 39 2009-07-27 143 48 45 2009-07-07 138 50 46 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898 Subject : Intel 3945ABG - problems on 2.6.30.X Submitter : dienet <dienet@poczta.fm> Date : 2009-07-31 15:17 (3 days old) References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13886 Subject : Suspend to disk no longer works in 2.6.30.2 with an EIDE drive Submitter : <akwatts@ymail.com> Date : 2009-08-01 10:12 (2 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13865 Subject : Can only resume with HP_WMI selected on compaq nc6000 when 4c395bdd3f2ca8f7e8efad881e16071182c3b8ca is reverted Submitter : cedric <cedric@belbone.be> Date : 2009-07-29 12:47 (5 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797 Subject : iBook G4 doesn't suspend since 2ed8d2b3a8 Submitter : Jörg Sommer <joerg@alea.gnuu.de> Date : 2009-07-18 20:18 (16 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795 Subject : abnormal boot and no suspend due to 'async' (fastboot) Submitter : Rafal Kaczynski <fscnoboot@wp.pl> Date : 2009-07-18 17:19 (16 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780 Subject : NULL pointer dereference loading powernowk8 Submitter : Kurt Roeckx <kurt@roeckx.be> Date : 2009-07-15 18:00 (19 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739 Subject : 2.6.30 leaking keys on console switch Submitter : Andi Kleen <andi@firstfloor.org> Date : 2009-07-07 8:44 (27 days old) References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4 Handled-By : Jiri Kosina <jkosina@suse.cz> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694 Subject : i915 phantom TV Submitter : Maciek Józiewicz <mjoziew@gmail.com> Date : 2009-07-02 12:26 (32 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682 Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com> Date : 2009-06-30 13:34 (34 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte@naasa.net> Date : 2009-06-14 21:00 (50 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (37 days old) References : http://lkml.org/lkml/2009/6/27/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (45 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js@sig21.net> Date : 2009-06-16 01:27 (48 days old) References : http://lkml.org/lkml/2009/6/15/630 http://lkml.org/lkml/2009/6/29/504 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638 Subject : rt2870 driver is broken for (some) cards Submitter : jakob gruber <jakob.gruber@kabelnet.at> Date : 2009-06-27 17:33 (37 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (37 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (39 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (39 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583 Subject : pdflush uses 5% CPU on otherwise idle system Submitter : Paul Martin <pm@debian.org> Date : 2009-06-19 13:33 (45 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (45 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564 Subject : random general protection fault at boot time caused by khubd. Submitter : Pauli <suokkos@gmail.com> Date : 2009-06-18 12:44 (46 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (47 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> Date : 2009-06-17 06:28 (47 days old) References : http://marc.info/?l=linux-kernel&m=124686965407853&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (52 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (53 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (54 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (65 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (67 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (67 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (72 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (72 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (73 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (75 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (76 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (92 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318 Subject : AGP doesn't work anymore on nforce2 Submitter : Karsten Mehrhoff <kawime@gmx.de> Date : 2009-04-30 8:51 (95 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4 Handled-By : Shaohua Li <shaohua.li@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306 Subject : hibernate slow on _second_ run Submitter : Johannes Berg <johannes@sipsolutions.net> Date : 2009-05-14 09:34 (81 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (94 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180 Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Submitter : Niel Lambrechts <niel.lambrechts@gmail.com> Date : 2009-04-21 21:35 (104 days old) References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4 http://lkml.org/lkml/2009/4/27/290 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (114 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13897 Subject : PAT wc & vmap mapping count issue Submitter : Jerome Glisse <glisse@freedesktop.org> Date : 2009-07-30 13:11 (4 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3869c4aa18835c8c61b44bd0f3ace36e9d3b5bd0 References : http://marc.info/?l=linux-kernel&m=124895237114605&w=4 Handled-By : Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> Patch : http://patchwork.kernel.org/patch/38436/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13884 Subject : x86 CPA incorrect memtype reserving using set_pages_array_xx Submitter : Thomas Hellstrom <thellstrom@vmware.com> Date : 2009-07-31 13:39 (3 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9ae2847591c857bed44bc094b908b412bfa1b244 Handled-By : Thomas Hellstrom <thellstrom@vmware.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=22552 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (69 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (77 days old) Handled-By : Johannes Berg <johannes@sipsolutions.net> Patch : http://patchwork.kernel.org/patch/37837/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (96 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 http://lkml.org/lkml/2009/7/26/213 Handled-By : Johannes Berg <johannes@sipsolutions.net> David Rientjes <rientjes@google.com> Patch : http://patchwork.kernel.org/patch/37655/ For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ 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; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-08-02 19:09 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-08-02 19:09 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, David Rientjes, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (96 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 http://lkml.org/lkml/2009/7/26/213 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Patch : http://patchwork.kernel.org/patch/37655/ ^ permalink raw reply [flat|nested] 467+ messages in thread
* [PATCH 2.6.31] mac80211: fix suspend @ 2009-07-28 16:10 Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-07-28 16:10 UTC (permalink / raw) To: John Linville Cc: Jan Scholz, linux-wireless, Bob Copeland, Rafael J. Wysocki, Tomas Janousek Jan reported that his b43-based laptop hangs during suspend. The problem turned out to be mac80211 asking the driver to stop the hardware before removing interfaces, and interface removal caused b43 to touch the hardware (while down, which causes the hang). This patch fixes mac80211 to do reorder these operations to have them in the correct order -- first remove interfaces and then stop the hardware. Some more code is necessary to be able to do so in a race-free manner, in particular it is necessary to not process frames received during quiescing. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13337. Reported-by: Jan Scholz <scholz@fias.uni-frankfurt.de> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> --- net/mac80211/pm.c | 24 +++++++++++++++--------- net/mac80211/rx.c | 12 ++++++++++++ 2 files changed, 27 insertions(+), 9 deletions(-) --- wireless-testing.orig/net/mac80211/pm.c 2009-07-28 17:58:11.000000000 +0200 +++ wireless-testing/net/mac80211/pm.c 2009-07-28 18:06:25.000000000 +0200 @@ -54,15 +54,6 @@ int __ieee80211_suspend(struct ieee80211 rcu_read_unlock(); - /* flush again, in case driver queued work */ - flush_workqueue(local->hw.workqueue); - - /* stop hardware - this must stop RX */ - if (local->open_count) { - ieee80211_led_radio(local, false); - drv_stop(local); - } - /* remove STAs */ spin_lock_bh(&local->sta_lock); list_for_each_entry(sta, &local->sta_list, list) { @@ -110,7 +101,22 @@ int __ieee80211_suspend(struct ieee80211 drv_remove_interface(local, &conf); } + /* stop hardware - this must stop RX */ + if (local->open_count) { + ieee80211_led_radio(local, false); + drv_stop(local); + } + + /* + * flush again, in case driver queued work -- it + * shouldn't be doing (or cancel everything in the + * stop callback) that but better safe than sorry. + */ + flush_workqueue(local->hw.workqueue); + local->suspended = true; + /* need suspended to be visible before quiescing is false */ + barrier(); local->quiescing = false; return 0; --- wireless-testing.orig/net/mac80211/rx.c 2009-07-28 17:58:52.000000000 +0200 +++ wireless-testing/net/mac80211/rx.c 2009-07-28 18:04:24.000000000 +0200 @@ -2441,6 +2441,18 @@ void __ieee80211_rx(struct ieee80211_hw return; } + /* + * If we're suspending, it is possible although not too likely + * that we'd be receiving frames after having already partially + * quiesced the stack. We can't process such frames then since + * that might, for example, cause stations to be added or other + * driver callbacks be invoked. + */ + if (unlikely(local->quiescing || local->suspended)) { + kfree_skb(skb); + return; + } + if (status->flag & RX_FLAG_HT) { /* rate_idx is MCS index */ if (WARN_ON(status->rate_idx < 0 || ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30 @ 2009-06-29 0:26 Rafael J. Wysocki 2009-06-29 0:30 ` Rafael J. Wysocki 0 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-06-29 0:26 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI [NOTES: * I hope you notice the jump of the number of reported regressions after 2.6.30 was released. * Please let me know which of these bugs have been fixed already (ideally please also provide the name of the fix commit). * The post-2.6.30 reports were flooded by the megre window noise that made them very difficult to track.] This message contains a list of some regressions introduced between 2.6.29 and 2.6.30, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.29 and 2.6.30, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2009-06-29 133 46 43 2009-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13669 Subject : Kernel bug with dock driver Submitter : Joerg Platte <jplatte@naasa.net> Date : 2009-06-14 21:00 (15 days old) References : http://lkml.org/lkml/2009/6/14/216 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13668 Subject : Can't boot 2.6.30 powerpc kernel under qemu. Submitter : Rob Landley <rob@landley.net> Date : 2009-06-27 18:08 (2 days old) References : http://lkml.org/lkml/2009/6/27/159 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660 Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Submitter : Joao Correia <joaomiguelcorreia@gmail.com> Date : 2009-06-27 16:07 (2 days old) References : http://lkml.org/lkml/2009/6/27/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13651 Subject : Anyone know what happened with PC speaker in 2.6.30? Submitter : Michael Tokarev <mjt@tls.msk.ru> Date : 2009-06-15 14:41 (14 days old) References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13649 Subject : Bad page state in process with various applications Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-06-20 15:27 (9 days old) References : http://marc.info/?l=linux-mm&m=124551168828090&w=4 Handled-By : Mel Gorman <mel@csn.ul.ie> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 Subject : nfsd: page allocation failure Submitter : Justin Piszcz <jpiszcz@lucidpixels.com> Date : 2009-06-22 12:08 (7 days old) References : http://lkml.org/lkml/2009/6/22/309 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13647 Subject : fb/mmap lockdep report. Submitter : Dave Jones <davej@redhat.com> Date : 2009-06-21 13:33 (8 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=513adb58685615b0b1d47a3f0d40f5352beff189 References : http://lkml.org/lkml/2009/6/21/90 http://lkml.org/lkml/2009/6/21/122 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646 Subject : warn_on tty_io.c, broken bluetooth Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-06-19 17:05 (10 days old) References : http://lkml.org/lkml/2009/6/19/187 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644 Subject : hibernation/swsusp lockup due to acpi-cpufreq Submitter : Johannes Stezenbach <js@sig21.net> Date : 2009-06-16 01:27 (13 days old) References : http://lkml.org/lkml/2009/6/15/630 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634 Subject : [drm:drm_wait_vblank] failed to acquire vblank counter Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-27 07:02 (2 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13624 Subject : usb: wrong autosuspend initialization Submitter : <list@phuk.ath.cx> Date : 2009-06-25 18:18 (4 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621 Subject : xfs hangs with assertion failed Submitter : Johannes Engel <jcnengel@googlemail.com> Date : 2009-06-25 10:07 (4 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620 Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2009-06-25 08:31 (4 days old) References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13613 Subject : lockups with JFS (inconsistent lock state) Submitter : Jan "Yenya" Kasprzak <kas@fi.muni.cz> Date : 2009-06-24 09:35 (5 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581 Subject : ath9k doesn't work with newer kernels Submitter : Matteo <rootkit85@yahoo.it> Date : 2009-06-19 12:04 (10 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558 Subject : Tracelog during resume Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Date : 2009-06-17 11:32 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput <wolput@onsneteindhoven.nl> Date : 2009-06-17 06:28 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13528 Subject : au0828: major drop in reception quality between 2.6.29.4 and 2.6.30 on HVR-950q Submitter : Jim Faulkner <jfaulkne@ccs.neu.edu> Date : 2009-06-13 19:34 (16 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13518 Subject : slab grows with NFS write activity. Submitter : Andrew Randrianasulu <randrik@mail.ru> Date : 2009-06-12 09:51 (17 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject : acer_wmi causes stack corruption Submitter : Rus <harbour@sfinx.od.ua> Date : 2009-06-12 08:13 (17 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512 Subject : D43 on 2.6.30 doesn't suspend anymore Submitter : Daniel Smolik <marvin@mydatex.cz> Date : 2009-06-11 20:12 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502 Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Submitter : <sveina@gmail.com> Date : 2009-06-10 20:04 (19 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> Date : 2009-06-05 1:37 (24 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (25 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-05-31 16:36 (29 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (30 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (32 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (32 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (37 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (37 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (38 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (40 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (41 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (42 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (57 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (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> 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 (60 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 (46 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13277 Subject : 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 Submitter : Daniel Vetter <daniel@ffwll.ch> Date : 2009-05-11 10:08 (49 days old) Handled-By : Len Brown <len.brown@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (59 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13179 Subject : CD-R: wodim intermittent failures Submitter : Andy Isaacson <adi@hexapodia.org> Date : 2009-04-21 1:52 (69 days old) References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13119 Subject : Trouble with make-install from a NFS mount Submitter : Gregory Haskins <ghaskins@novell.com> Date : 2009-04-14 21:32 (76 days old) References : http://marc.info/?l=linux-kernel&m=123974482327044&w=4 Handled-By : H. Peter Anvin <hpa@zytor.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (79 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13663 Subject : suspend to ram regression (IDE related) Submitter : Etienne Basset <etienne.basset@numericable.fr> Date : 2009-06-26 17:40 (3 days old) References : http://lkml.org/lkml/2009/6/26/242 Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Patch : http://patchwork.kernel.org/patch/32719/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar@gmail.com> Date : 2009-06-02 10:00 (27 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Patch : http://patchwork.kernel.org/patch/28660/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (34 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions introduced between 2.6.29 and 2.6.30, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=13070 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-29 0:26 2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki @ 2009-06-29 0:30 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-29 0:30 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-06-29 0:30 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (61 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 http://lkml.org/lkml/2009/6/7/136 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-29 0:30 ` Rafael J. Wysocki @ 2009-06-29 16:51 ` Larry Finger -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-29 16:51 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-06-29 16:51 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > Subject : Page allocation failures with b43 and p54usb > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > Date : 2009-04-29 21:01 (61 days old) > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > http://lkml.org/lkml/2009/6/7/136 > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> The cause of these failures has been determined. The wireless subsystem frequently requests buffers of size 4096, but when SLUB debugging is enabled and the debug info is added, the request becomes of order 1 and memory becomes fragmented. A controversial "fix" in which SLUB debugging was disabled for allocations where adding such debugging info would increase the order was discussed and tried. With a quick look at the commit list for Linus's tree, I don't see that such a patch is available, but I will be corrected if I missed it. Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-29 23:15 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-29 23:15 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-06-29 23:15 UTC (permalink / raw) To: Larry Finger Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg On Monday 29 June 2009, Larry Finger wrote: > Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.29 and 2.6.30. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.29 and 2.6.30. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > > Subject : Page allocation failures with b43 and p54usb > > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > > Date : 2009-04-29 21:01 (61 days old) > > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > > http://lkml.org/lkml/2009/6/7/136 > > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > > The cause of these failures has been determined. The wireless > subsystem frequently requests buffers of size 4096, but when SLUB > debugging is enabled and the debug info is added, the request becomes > of order 1 and memory becomes fragmented. > > A controversial "fix" in which SLUB debugging was disabled for > allocations where adding such debugging info would increase the order > was discussed and tried. With a quick look at the commit list for > Linus's tree, I don't see that such a patch is available, but I will > be corrected if I missed it. Thanks for the update. Hmm, isn't it suboptimal to use a slab allocator for allocations taking up an entire page? That's the case on some architectures and seems to be the root cause of the issue at hand. Best, Rafael ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-29 23:47 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-29 23:47 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-06-29 23:47 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Pekka Enberg, Christoph Lameter On Mon, 29 Jun 2009, Larry Finger wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > > Subject : Page allocation failures with b43 and p54usb > > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > > Date : 2009-04-29 21:01 (61 days old) > > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > > http://lkml.org/lkml/2009/6/7/136 > > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > > The cause of these failures has been determined. The wireless > subsystem frequently requests buffers of size 4096, but when SLUB > debugging is enabled and the debug info is added, the request becomes > of order 1 and memory becomes fragmented. > > A controversial "fix" in which SLUB debugging was disabled for > allocations where adding such debugging info would increase the order > was discussed and tried. With a quick look at the commit list for > Linus's tree, I don't see that such a patch is available, but I will > be corrected if I missed it. > I'd disagree with disabling slub debugging by default for caches where oo_order(s->min) increases as the result of using it. This particular page allocation failure is happening for, presumably, kmalloc-4096, and the system has 4K pages. Disabling debugging for that cache (and any of its aliases) implicitly will lead to errors going undiagnosed as a result. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 2:06 ` Larry Finger 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 2:06 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-06-30 2:06 UTC (permalink / raw) To: David Rientjes Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Pekka Enberg, Christoph Lameter David Rientjes wrote: > On Mon, 29 Jun 2009, Larry Finger wrote: > >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 >>> Subject : Page allocation failures with b43 and p54usb >>> Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> >>> Date : 2009-04-29 21:01 (61 days old) >>> References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 >>> http://lkml.org/lkml/2009/6/7/136 >>> Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> >> The cause of these failures has been determined. The wireless >> subsystem frequently requests buffers of size 4096, but when SLUB >> debugging is enabled and the debug info is added, the request becomes >> of order 1 and memory becomes fragmented. >> >> A controversial "fix" in which SLUB debugging was disabled for >> allocations where adding such debugging info would increase the order >> was discussed and tried. With a quick look at the commit list for >> Linus's tree, I don't see that such a patch is available, but I will >> be corrected if I missed it. >> > > I'd disagree with disabling slub debugging by default for caches where > oo_order(s->min) increases as the result of using it. This particular > page allocation failure is happening for, presumably, kmalloc-4096, and > the system has 4K pages. Disabling debugging for that cache (and any of > its aliases) implicitly will lead to errors going undiagnosed as a result. If the current behavior is not changed, I will be forced to disable SLUB debugging, which will explicitly lead to errors that are undiagnosed. It seems better to me to debug when you can, but turn off debugging in cases like this. Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-30 2:06 ` Larry Finger (?) @ 2009-06-30 5:47 ` David Rientjes -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 6:55 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 6:55 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-30 6:55 UTC (permalink / raw) To: David Rientjes Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Christoph Lameter Hi David, On Tue, Jun 30, 2009 at 2:47 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > On Mon, 29 Jun 2009, Larry Finger wrote: > >> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 >> > Subject : Page allocation failures with b43 and p54usb >> > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> >> > Date : 2009-04-29 21:01 (61 days old) >> > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 >> > http://lkml.org/lkml/2009/6/7/136 >> > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> >> >> The cause of these failures has been determined. The wireless >> subsystem frequently requests buffers of size 4096, but when SLUB >> debugging is enabled and the debug info is added, the request becomes >> of order 1 and memory becomes fragmented. >> >> A controversial "fix" in which SLUB debugging was disabled for >> allocations where adding such debugging info would increase the order >> was discussed and tried. With a quick look at the commit list for >> Linus's tree, I don't see that such a patch is available, but I will >> be corrected if I missed it. >> > > I'd disagree with disabling slub debugging by default for caches where > oo_order(s->min) increases as the result of using it. This particular > page allocation failure is happening for, presumably, kmalloc-4096, and > the system has 4K pages. Disabling debugging for that cache (and any of > its aliases) implicitly will lead to errors going undiagnosed as a result. Well, I obviously don't agree here because kmalloc-4096 debugging causes problems in the real world. Furthermore, SLUB never supported debugging for objects that big historically because of page allocator passthrough. And with Mel Gorman's page allocator optimizations, we might be going back to that. So we should fix SLUB debugging as outlined by Mel Gorman and Christoph Lameter. I simply haven't had the time to do it. Patches are welcome! Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 7:47 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 7:47 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-06-30 7:47 UTC (permalink / raw) To: Pekka Enberg Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Christoph Lameter [-- Attachment #1: Type: TEXT/PLAIN, Size: 2316 bytes --] On Tue, 30 Jun 2009, Pekka Enberg wrote: > > I'd disagree with disabling slub debugging by default for caches where > > oo_order(s->min) increases as the result of using it. This particular > > page allocation failure is happening for, presumably, kmalloc-4096, and > > the system has 4K pages. Disabling debugging for that cache (and any of > > its aliases) implicitly will lead to errors going undiagnosed as a result. > > Well, I obviously don't agree here because kmalloc-4096 debugging > causes problems in the real world. I don't think CONFIG_SLUB_DEBUG_ON is generally the configuration used in the real world. The option has a clear and well-defined purpose and that is to enable debugging on all slab caches. If you modify its definition, users will generally ignore the warning about debugging being disabled when "the minimum possible order at which slab may be allocated is higher than without." And unless they check the kernel log for such a warning to boot with `slab_debug=,kmalloc-4096', we lose testing coverage because we cannot enable redzoning or tracing after boot. > Furthermore, SLUB never supported > debugging for objects that big historically because of page allocator > passthrough. And with Mel Gorman's page allocator optimizations, we > might be going back to that. > Even when page allocation is fast enough, it would still be helpful to configure slub to not do passthrough purely for the lightweight debugging opportunities. > So we should fix SLUB debugging as outlined by Mel Gorman and > Christoph Lameter. I simply haven't had the time to do it. Patches are > welcome! > You're referring to `slub_debug=A'? I think CONFIG_SLUB_DEBUG_ON should continue to enable debugging on all slab caches and in instances where it causes page allocation failures such in Larry's case because oo_order(s->min) with debugging on is greater than oo_order(s->min) with debugging off, you can emit a friendly warning in your recently added slab_out_of_memory() about using `slab_debug=-,<cache>'. We have a disagreement about which is the default behavior, but I would opt on the side of adding exemptions to a debug configuration option as opposed to requiring additional command line parameters to be fully enabled. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 8:24 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 8:24 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-30 8:24 UTC (permalink / raw) To: David Rientjes Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Christoph Lameter Hi David, On Tue, 30 Jun 2009, Pekka Enberg wrote: >> > I'd disagree with disabling slub debugging by default for caches where >> > oo_order(s->min) increases as the result of using it. This particular >> > page allocation failure is happening for, presumably, kmalloc-4096, and >> > the system has 4K pages. Disabling debugging for that cache (and any of >> > its aliases) implicitly will lead to errors going undiagnosed as a result. >> >> Well, I obviously don't agree here because kmalloc-4096 debugging >> causes problems in the real world. On Tue, Jun 30, 2009 at 10:47 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > I don't think CONFIG_SLUB_DEBUG_ON is generally the configuration used in > the real world. It is, hence the epic bug report that's eaten too many man hours already! Look, we encourage _testers_ to turn all as much as debugging options as possible so we catch bugs early. That why the only sane defaults are the ones that don't cause other problems! I don't know why you want to argue this. It's simply not an option to say "stupid user, fix your config" in core code like the slab allocator. Enabling CONFIG_SLUB_DEBUG_ON is a very reasonable thing to do when you are a tester looking for bugs. On Tue, 30 Jun 2009, Pekka Enberg wrote: >> So we should fix SLUB debugging as outlined by Mel Gorman and >> Christoph Lameter. I simply haven't had the time to do it. Patches are >> welcome! On Tue, Jun 30, 2009 at 10:47 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > You're referring to `slub_debug=A'? I think CONFIG_SLUB_DEBUG_ON should > continue to enable debugging on all slab caches and in instances where it > causes page allocation failures such in Larry's case because > oo_order(s->min) with debugging on is greater than oo_order(s->min) with > debugging off, you can emit a friendly warning in your recently added > slab_out_of_memory() about using `slab_debug=-,<cache>'. > > We have a disagreement about which is the default behavior, but I would > opt on the side of adding exemptions to a debug configuration option as > opposed to requiring additional command line parameters to be fully > enabled. Yup, I was referring to slub_debug=A and no, I don't agree with you that it should be on by default. Only people who know what they're doing should enable the option and a random tester by definition doesn't (no offence to Mr. Random Tester). Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-30 8:24 ` Pekka Enberg (?) @ 2009-06-30 14:38 ` Larry Finger -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 20:25 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 20:25 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-06-30 20:25 UTC (permalink / raw) To: Pekka Enberg Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Christoph Lameter On Tue, 30 Jun 2009, Pekka Enberg wrote: > On Tue, Jun 30, 2009 at 10:47 AM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > > I don't think CONFIG_SLUB_DEBUG_ON is generally the configuration used in > > the real world. > > It is, hence the epic bug report that's eaten too many man hours > already! Look, we encourage _testers_ to turn all as much as debugging > options as possible so we catch bugs early. That why the only sane > defaults are the ones that don't cause other problems! > I feel that asking a user to add a command line parameter such as `slub_debug=A' in addition to CONFIG_SLUB_DEBUG_ON will likely lead to less testing coverage and bugs going unreported. CONFIG_SLUB_DEBUG_ON is not something that a distro is going to enable or would be used in a production environment, it's something that's used to debug slub and/or slab allocations either during the development of new kernel code or when an underlying problem is realized. > I don't know why you want to argue this. It's simply not an option to > say "stupid user, fix your config" in core code like the slab > allocator. Enabling CONFIG_SLUB_DEBUG_ON is a very reasonable thing to > do when you are a tester looking for bugs. > Quite the contrary, I agree completely with the above, and that's why I'm arguing for full debugging to be enabled when a well-defined configuration option is enabled. I simply don't believe that such debugging should be coupled with a command line option to be fully activated for all caches. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 14:32 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 14:32 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-30 14:32 ` Christoph Lameter (?) @ 2009-06-30 15:01 ` Pekka Enberg 2009-06-30 15:14 ` Christoph Lameter -1 siblings, 1 reply; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-30 15:01 ` Pekka Enberg @ 2009-06-30 15:14 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 15:14 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 20:04 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 20:04 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 21:05 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 21:05 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 21:15 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 21:15 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 21:23 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 21:23 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 21:52 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 21:52 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 22:18 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-30 22:18 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-30 21:52 ` David Rientjes (?) (?) @ 2009-07-01 5:53 ` Pekka Enberg 2009-07-02 17:18 ` David Rientjes -1 siblings, 1 reply; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-02 17:18 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-02 17:18 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-03 7:23 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-07-03 7:23 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-07-03 7:23 UTC (permalink / raw) To: David Rientjes Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Hi David, On Wed, 1 Jul 2009, Pekka Enberg wrote: >> Lets go with the slab_out_of_memory() patch you outlined in a previous >> post and implement the slub_debug=p thing Christoph suggested. I think >> it's the best compromise at this point. When you guys finally see the >> light, we can always change it to a reasonable default. ;) >> >> So can you send a patch, please? On Thu, Jul 2, 2009 at 8:18 PM, David Rientjes<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > Sure, let me know if you think this is -rc material; otherwise, the bug > will have to be deferred until 2.6.32 with the temporary workaround of > disabling CONFIG_SLUB_DEBUG_ON. We're at -rc2 so yes, I do think we should fix 2.6.31. ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.30-rc8-git4: Reported regressions from 2.6.29 @ 2009-06-07 9:47 Rafael J. Wysocki 2009-06-07 9:52 ` Rafael J. Wysocki 0 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 9:47 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-06-07 110 35 31 2009-05-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13475 Subject : suspend/hibernate lockdep warning Submitter : Dave Young <hidave.darkstar@gmail.com> Date : 2009-06-02 10:00 (6 days old) References : http://marc.info/?l=linux-kernel&m=124393723321241&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13474 Subject : Oops whilst booting Submitter : Chris Clayton <chris2553@googlemail.com> Date : 2009-06-06 18:59 (2 days old) References : http://marc.info/?l=linux-kernel&m=124431487924254&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13473 Subject : Bug while trying to launch a KVM guest Submitter : Sachin Sant <sachinp@in.ibm.com> Date : 2009-06-05 17:20 (3 days old) References : http://marc.info/?l=linux-kernel&m=124422173129047&w=4 Handled-By : Mimi Zohar <zohar@us.ibm.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13472 Subject : Oops with minicom and USB serial Submitter : Peter Chubb <peterc@gelato.unsw.edu.au> Date : 2009-06-05 1:37 (3 days old) References : http://marc.info/?l=linux-kernel&m=124416901026700&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 Subject : Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 (4 days old) References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13446 Subject : resume after suspend-to-ram broken on Toshiba Satellite A100 with 2.6.30-rc8 (works in 2.6.28) Submitter : Andrea Iob <andrea_iob@yahoo.it> Date : 2009-06-03 21:42 (5 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13424 Subject : possible deadlock when doing governor switching Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-05-31 16:36 (8 days old) References : http://www.spinics.net/lists/cpufreq/msg00711.html Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (9 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (11 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (11 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13391 Subject : Kernel boot hangs at about every second start when kms is activated Submitter : Martin Bammer <mrb74@gmx.at> Date : 2009-05-26 21:47 (13 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (16 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 http://lkml.org/lkml/2009/5/29/389 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (16 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13366 Subject : About 80% of shutdowns fail (blocking) Submitter : Martin Bammer <mrb74@gmx.at> Date : 2009-05-23 00:58 (16 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : rt2x00: slow wifi with correct basic rate bitmap Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (17 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (19 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (20 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (21 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13330 Subject : nfs4 NULL pointer dereference in _nfs4_do_setlk Submitter : Rich Ercolani <rercola@acm.jhu.edu> Date : 2009-05-17 04:44 (22 days old) Handled-By : Trond Myklebust <trond.myklebust@fys.uio.no> 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 (36 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (40 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 (39 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=13313 Subject : vm86old oops Submitter : Sergey Senozhatsky <sergey.senozhatsky@mail.by> Date : 2009-05-14 21:53 (25 days old) 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 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13277 Subject : 2.6.30 regression - unreliable resume - bisected - Thinkpad X40 Submitter : Daniel Vetter <daniel@ffwll.ch> Date : 2009-05-11 10:08 (28 days old) Handled-By : Len Brown <len.brown@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Since kernel 2.6.30-rc1, computers hangs randomly .. Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (38 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180 Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Submitter : Niel Lambrechts <niel.lambrechts@gmail.com> Date : 2009-04-21 21:35 (48 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 (48 days old) References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13119 Subject : Trouble with make-install from a NFS mount Submitter : Gregory Haskins <ghaskins@novell.com> Date : 2009-04-14 21:32 (55 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=13116 Subject : Can't boot with nosmp Submitter : Stephen Hemminger <shemminger@vyatta.com> Date : 2009-04-15 4:18 (54 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=13109 Subject : High latency on /sys/class/thermal Submitter : Tiago Simões Batista <tiagosbatista@gmail.com> Date : 2009-04-11 14:56 (58 days old) References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Alexey Starikovskiy <astarikovskiy@suse.de> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13470 Subject : Machine doesn't boot due to mmconfig detection problem Submitter : Pascal Terjan <pterjan@mandriva.com> Date : 2009-05-29 19:35 (10 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=044cd80942e47b9de0915b627902adf05c52377f References : http://marc.info/?l=linux-kernel&m=124388792118481&w=4 Handled-By : Yinghai Lu <yinghai@kernel.org> Patch : http://patchwork.kernel.org/patch/27613/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13462 Subject : Unused bands in intefb console and smaller 180x56 -> 128x48 Submitter : Santi <santi@agolina.net> Date : 2009-06-05 16:30 (3 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c9fb15f60eb517c958dec64dca9357bf62bf2201 Handled-By : Keith Packard <keithp@keithp.com> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=13462#c2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13423 Subject : JMicron SATA controller not available Submitter : Marc Dionne <marc.c.dionne@gmail.com> Date : 2009-05-26 22:56 (13 days old) References : http://lkml.org/lkml/2009/5/26/687 Handled-By : Yu Zhao <yu.zhao@intel.com> Patch : http://lkml.org/lkml/2009/5/27/402 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (13 days old) Handled-By : Frans Pop <elendil@planet.nl> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671 http://bugzilla.kernel.org/attachment.cgi?id=21672 For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-07 9:47 2.6.30-rc8-git4: Reported regressions from 2.6.29 Rafael J. Wysocki @ 2009-06-07 9:52 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 9:52 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 9:52 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.29. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (40 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-07 9:52 ` Rafael J. Wysocki @ 2009-06-07 13:10 ` Larry Finger -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 13:10 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-06-07 13:10 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.29. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > Subject : Page allocation failures with b43 and p54usb > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > Date : 2009-04-29 21:01 (40 days old) > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> This bug is extremely difficult to pin down. I cannot reproduce it at will. The system has to be up for a long time, which is difficult with testing the late RC's of 2.6.30 and the code in wireless-testing so that new bugs don't end up in 2.6.31-RCX. That said, it still was in 2.6.30-RC6 and I'm not aware of any changes since that would fix it. My operating kernel is patched with additional diagnostics to help me understand why a kmalloc request for a buffer of 1390 bytes suddenly ends up as an O(1) request. Unfortunately, I don't have any answers. Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 13:40 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 13:40 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-07 13:40 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, Rik van Riel, KOSAKI Motohiro, KAMEZAWA Hiroyuki, hugh-DTz5qymZ9yRBDgjK7y7TUQ Hi Larry, On Sun, Jun 7, 2009 at 4:10 PM, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote: > Rafael J. Wysocki wrote: >> This message has been generated automatically as a part of a report >> of recent regressions. >> >> The following bug entry is on the current list of known regressions >> from 2.6.29. Please verify if it still should be listed and let me know >> (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 >> Subject : Page allocation failures with b43 and p54usb >> Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> >> Date : 2009-04-29 21:01 (40 days old) >> References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 >> Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > > This bug is extremely difficult to pin down. I cannot reproduce it at > will. The system has to be up for a long time, which is difficult with > testing the late RC's of 2.6.30 and the code in wireless-testing so > that new bugs don't end up in 2.6.31-RCX. That said, it still was in > 2.6.30-RC6 and I'm not aware of any changes since that would fix it. > > My operating kernel is patched with additional diagnostics to help me > understand why a kmalloc request for a buffer of 1390 bytes suddenly > ends up as an O(1) request. Unfortunately, I don't have any answers. Looking at the out-of-memory trace, there's still memory available but the pskb_expand_head() allocation is GFP_ATOMIC so there's not much the page allocator can do here. The amount of memory consumed by inactive_file is pretty high so maybe the problem is related to the recent mm/vmscan.c changes. Lets copy some more mm developers and see if they can help out. Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 14:19 ` Rik van Riel 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 14:19 ` Rik van Riel 0 siblings, 0 replies; 467+ messages in thread From: Rik van Riel @ 2009-06-07 14:19 UTC (permalink / raw) To: Pekka Enberg Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, hugh-DTz5qymZ9yRBDgjK7y7TUQ Pekka Enberg wrote: > Hi Larry, > > On Sun, Jun 7, 2009 at 4:10 PM, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote: >> Rafael J. Wysocki wrote: >>> This message has been generated automatically as a part of a report >>> of recent regressions. >>> >>> The following bug entry is on the current list of known regressions >>> from 2.6.29. Please verify if it still should be listed and let me know >>> (either way). >>> >>> >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 >>> Subject : Page allocation failures with b43 and p54usb >>> Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> >>> Date : 2009-04-29 21:01 (40 days old) >>> References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 >>> Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> >> This bug is extremely difficult to pin down. I cannot reproduce it at >> will. The system has to be up for a long time, which is difficult with >> testing the late RC's of 2.6.30 and the code in wireless-testing so >> that new bugs don't end up in 2.6.31-RCX. That said, it still was in >> 2.6.30-RC6 and I'm not aware of any changes since that would fix it. >> >> My operating kernel is patched with additional diagnostics to help me >> understand why a kmalloc request for a buffer of 1390 bytes suddenly >> ends up as an O(1) request. Unfortunately, I don't have any answers. > > Looking at the out-of-memory trace, there's still memory available but > the pskb_expand_head() allocation is GFP_ATOMIC so there's not much > the page allocator can do here. The amount of memory consumed by > inactive_file is pretty high so maybe the problem is related to the > recent mm/vmscan.c changes. Lets copy some more mm developers and see > if they can help out. That is a very strange trace. The Mem-Info indicates that the system has more than enough memory free, and also enough memory in higher-order free blocks. This would indicate a bug somewhere in the page allocator - this memory should have been given to this allocation request. -- All rights reversed. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 14:32 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 14:32 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-07 14:32 UTC (permalink / raw) To: Rik van Riel Cc: Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Mel Gorman On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > Pekka Enberg wrote: >> >> Hi Larry, >> >> On Sun, Jun 7, 2009 at 4:10 PM, Larry Finger <Larry.Finger@lwfinger.net> >> wrote: >>> >>> Rafael J. Wysocki wrote: >>>> >>>> This message has been generated automatically as a part of a report >>>> of recent regressions. >>>> >>>> The following bug entry is on the current list of known regressions >>>> from 2.6.29. Please verify if it still should be listed and let me know >>>> (either way). >>>> >>>> >>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 >>>> Subject : Page allocation failures with b43 and p54usb >>>> Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> >>>> Date : 2009-04-29 21:01 (40 days old) >>>> References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 >>>> Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> >>> >>> This bug is extremely difficult to pin down. I cannot reproduce it at >>> will. The system has to be up for a long time, which is difficult with >>> testing the late RC's of 2.6.30 and the code in wireless-testing so >>> that new bugs don't end up in 2.6.31-RCX. That said, it still was in >>> 2.6.30-RC6 and I'm not aware of any changes since that would fix it. >>> >>> My operating kernel is patched with additional diagnostics to help me >>> understand why a kmalloc request for a buffer of 1390 bytes suddenly >>> ends up as an O(1) request. Unfortunately, I don't have any answers. >> >> Looking at the out-of-memory trace, there's still memory available but >> the pskb_expand_head() allocation is GFP_ATOMIC so there's not much >> the page allocator can do here. The amount of memory consumed by >> inactive_file is pretty high so maybe the problem is related to the >> recent mm/vmscan.c changes. Lets copy some more mm developers and see >> if they can help out. > > That is a very strange trace. The Mem-Info indicates > that the system has more than enough memory free, and > also enough memory in higher-order free blocks. > > This would indicate a bug somewhere in the page > allocator - this memory should have been given to this > allocation request. Aha, I always have difficulties deciphering the traces. But lets invite Mel to the party then! Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 16:35 ` Larry Finger 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-07 16:35 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-06-07 16:35 UTC (permalink / raw) To: Pekka Enberg Cc: Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Mel Gorman Pekka Enberg wrote: > On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: >> That is a very strange trace. The Mem-Info indicates >> that the system has more than enough memory free, and >> also enough memory in higher-order free blocks. >> >> This would indicate a bug somewhere in the page >> allocator - this memory should have been given to this >> allocation request. > > Aha, I always have difficulties deciphering the traces. But lets > invite Mel to the party then! I'm happy to see some action on this problem. As usual, I'm happy to test patches and/or provide diagnostic output. Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 8:32 ` KAMEZAWA Hiroyuki 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 8:32 ` KAMEZAWA Hiroyuki 0 siblings, 0 replies; 467+ messages in thread From: KAMEZAWA Hiroyuki @ 2009-06-08 8:32 UTC (permalink / raw) To: Larry Finger Cc: Pekka Enberg, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, Mel Gorman On Sun, 07 Jun 2009 11:35:27 -0500 Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote: > Pekka Enberg wrote: > > On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > >> That is a very strange trace. The Mem-Info indicates > >> that the system has more than enough memory free, and > >> also enough memory in higher-order free blocks. > >> > >> This would indicate a bug somewhere in the page > >> allocator - this memory should have been given to this > >> allocation request. > > > > Aha, I always have difficulties deciphering the traces. But lets > > invite Mel to the party then! > > I'm happy to see some action on this problem. As usual, I'm happy to > test patches and/or provide diagnostic output. > One question. Did your system fragmented in same way as to this (see DMA32, 10052 of order-0 pages) in older kernel ? I think you can check fragmentation status via /proc/buddyinfo. = kernel: Node 0 DMA: 3*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 2100kB kernel: Node 0 DMA32: 10062*4kB 1*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 40976kB == Thanks, -Kame ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 17:20 ` Larry Finger 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 17:20 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-06-08 17:20 UTC (permalink / raw) To: KAMEZAWA Hiroyuki Cc: Pekka Enberg, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, Mel Gorman KAMEZAWA Hiroyuki wrote: > On Sun, 07 Jun 2009 11:35:27 -0500 > Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote: > >> Pekka Enberg wrote: >>> On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: >>>> That is a very strange trace. The Mem-Info indicates >>>> that the system has more than enough memory free, and >>>> also enough memory in higher-order free blocks. >>>> >>>> This would indicate a bug somewhere in the page >>>> allocator - this memory should have been given to this >>>> allocation request. >>> Aha, I always have difficulties deciphering the traces. But lets >>> invite Mel to the party then! >> I'm happy to see some action on this problem. As usual, I'm happy to >> test patches and/or provide diagnostic output. >> > One question. > > Did your system fragmented in same way as to this > (see DMA32, 10052 of order-0 pages) in older kernel ? I think you can check > fragmentation status via /proc/buddyinfo. > = > kernel: Node 0 DMA: 3*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB > 1*1024kB 0*2048kB 0*4096kB = 2100kB > kernel: Node 0 DMA32: 10062*4kB 1*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB > 1*512kB 0*1024kB 0*2048kB 0*4096kB = 40976kB > == The current system has not been up very long and does not show the fragmentation: finger@larrylap:~/wireless-testing> cat /proc/buddyinfo Node 0, zone DMA 4 5 4 2 4 1 2 0 1 0 0 Node 0, zone DMA32 261 78 46 55 61 54 37 17 14 12 262 After I did a git pull and a kernel build with the sources on an NFS-mounted volume, the fragmentation increased: Node 0, zone DMA 4 5 4 2 4 1 2 0 1 0 0 Node 0, zone DMA32 2213 1924 1292 705 285 81 25 8 5 4 141 After a git pull and a kernel build on a second NFS-mounted tree: Node 0, zone DMA 4 5 4 2 4 1 2 0 1 0 0 Node 0, zone DMA32 3127 3058 1989 756 401 142 56 14 5 3 12 Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 10:17 ` Mel Gorman 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 10:17 ` Mel Gorman 0 siblings, 0 replies; 467+ messages in thread From: Mel Gorman @ 2009-06-08 10:17 UTC (permalink / raw) To: Pekka Enberg Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki On Sun, Jun 07, 2009 at 05:32:52PM +0300, Pekka Enberg wrote: > On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > > Pekka Enberg wrote: > >> > >> Hi Larry, > >> > >> On Sun, Jun 7, 2009 at 4:10 PM, Larry Finger <Larry.Finger@lwfinger.net> > >> wrote: > >>> > >>> Rafael J. Wysocki wrote: > >>>> > >>>> This message has been generated automatically as a part of a report > >>>> of recent regressions. > >>>> > >>>> The following bug entry is on the current list of known regressions > >>>> from 2.6.29. Please verify if it still should be listed and let me know > >>>> (either way). > >>>> > >>>> > >>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > >>>> Subject : Page allocation failures with b43 and p54usb > >>>> Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > >>>> Date : 2009-04-29 21:01 (40 days old) > >>>> References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > >>>> Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > >>> > >>> This bug is extremely difficult to pin down. I cannot reproduce it at > >>> will. The system has to be up for a long time, which is difficult with > >>> testing the late RC's of 2.6.30 and the code in wireless-testing so > >>> that new bugs don't end up in 2.6.31-RCX. That said, it still was in > >>> 2.6.30-RC6 and I'm not aware of any changes since that would fix it. > >>> > >>> My operating kernel is patched with additional diagnostics to help me > >>> understand why a kmalloc request for a buffer of 1390 bytes suddenly > >>> ends up as an O(1) request. Unfortunately, I don't have any answers. > >> > >> Looking at the out-of-memory trace, there's still memory available but > >> the pskb_expand_head() allocation is GFP_ATOMIC so there's not much > >> the page allocator can do here. The amount of memory consumed by > >> inactive_file is pretty high so maybe the problem is related to the > >> recent mm/vmscan.c changes. Lets copy some more mm developers and see > >> if they can help out. > > > > That is a very strange trace. The Mem-Info indicates > > that the system has more than enough memory free, and > > also enough memory in higher-order free blocks. > > > > This would indicate a bug somewhere in the page > > allocator - this memory should have been given to this > > allocation request. > > Aha, I always have difficulties deciphering the traces. But lets > invite Mel to the party then! > Nothing like a party on Monday morning to get the week started! What we appear to have is o Allocation failure is high-order, high-priority, compound and atomic. o swap is mostly unused, but we cannot enter direct reclaim. o ZONE_DMA32 can be used o The allocation path is in the slub allocator o Are way above the order-0 watermarks so kswapd is probably not awake o The minimum watermark for an order-0 page was about 647 pages in ZONE_DMA32 o The minimum watermark for an order-1 page was about 323 pages in ZONE_DMA32 o There are 10244 pages free at the time of the failure o With the order-0 pages taken out for watermark calculation, there are 182 free pages which is below the watermark of 323 pages for an order-1 allocation While there is enough free memory overall, the zone watermark calculation takes into account the order of the request. As this is an order-1 allocation, the free order-0 pages are taken out of consideration and so the allocation fails. We've encountered this before and the conclusion was that the current adjustments for watermark calculations of high-order allocations is right, or at least there is no better alternative. In other words, the page allocator in this instance is behaving as expected. Do we want to revisit that discussion as to whether the watermark calculations for high-order allocation should change? I think we'll reach the same conclusion or at least decide that allowing the order-1 atomic allocation to succeed here would just postpone the problem. So the question is why are we doing a high-order atomic allocation in this path? According to an earlier discussion on this problemn > I think something happened to change the allocation as I never saw these > O(1) failures before with these particular drivers. I put in a few test > printk's and the buffers were 700-800 bytes long, and I would not expect > them to require more than an O(0) allocation. So, SLUB is deciding to use order-1 pages for the slab allocation. Ordinarily, it'll get away with that because order-1 pages will be allocated from a path that can direct reclaim. However, if a slab is being used for atomic allocations, there is a chance that it's the atomic request that allocates a new page for the slab. Larry, can you post the contents of /proc/slabinfo so we can see what size pages are being used for the kmalloc() buckets please? Larry, you say the buffer is 700-800 bytes. Can you confirm that 800 bytes is roughly the request size being made by ieee80211_skb_resize()? Pekka, assuming the request size is 800 bytes, and SLUB is using order-1 pages for allocations of that size, what happened order-1 allocations falling back to order-0 allocations as necessary. That logic exists, right? If so, could it be broken? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 10:52 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 10:52 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-08 10:52 UTC (permalink / raw) To: Mel Gorman Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter On Mon, Jun 8, 2009 at 1:17 PM, Mel Gorman<mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote: > Pekka, assuming the request size is 800 bytes, and SLUB is using order-1 > pages for allocations of that size, what happened order-1 allocations > falling back to order-0 allocations as necessary. That logic exists, > right? If so, could it be broken? That logic is in allocate_slab() and if the higher order allocation fails, we fall-back to struct kmem_cache ->min order. That in turn is set up in calculate_sizes() to get_order(size) so it seems pretty unlikely to me the allocation is 800 bytes. Of course, I could be missing something here and there's a bug in oo_make() or oo_order(). Hmm. Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 11:03 ` Mel Gorman 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 11:03 ` Mel Gorman 0 siblings, 0 replies; 467+ messages in thread From: Mel Gorman @ 2009-06-08 11:03 UTC (permalink / raw) To: Pekka Enberg Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter On Mon, Jun 08, 2009 at 01:52:05PM +0300, Pekka Enberg wrote: > On Mon, Jun 8, 2009 at 1:17 PM, Mel Gorman<mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote: > > Pekka, assuming the request size is 800 bytes, and SLUB is using order-1 > > pages for allocations of that size, what happened order-1 allocations > > falling back to order-0 allocations as necessary. That logic exists, > > right? If so, could it be broken? > > That logic is in allocate_slab() and if the higher order allocation > fails, we fall-back to struct kmem_cache ->min order. That in turn is > set up in calculate_sizes() to get_order(size) so it seems pretty > unlikely to me the allocation is 800 bytes. Of course, I could be > missing something here and there's a bug in oo_make() or oo_order(). > Hmm. Is there any chance you could hatchet together a patch slab-allocation-failure that reports on slab allocation failures similar to what the page allocator does? Minimally, it should tell us what the size of the allocation was but any other information such as the same of the slab, the size of pages it normally uses are, etc. would also be useful. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 13:58 ` Pekka J Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 13:58 ` Pekka J Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 14:12 ` Mel Gorman 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 14:12 ` Mel Gorman 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 14:42 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 14:42 ` Christoph Lameter 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-09 7:06 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-09 7:06 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-09 7:06 UTC (permalink / raw) To: Mel Gorman Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM Hi Mel, On Mon, 2009-06-08 at 15:12 +0100, Mel Gorman wrote: > > diff --git a/mm/slub.c b/mm/slub.c > > index 65ffda5..b5acf18 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -1565,6 +1565,8 @@ new_slab: > > c->page = new; > > goto load_freelist; > > } > > + printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n", > > + s->name, s->size, node, gfpflags); > > size could be almost anything here for a casual reader. You are > outputting the size of the object plus its metadata so the name should > reflect that. I think it would be better to output objsize= and the > object size without the metadata overhead. What do you think? > > In addition, include how many objects there are per-slab and include what > the order is being passed to the page allocator when allocating new slabs. > Would that be enough to determine if fallback-to-smaller orders occured? So how about something like this then? Pekka diff --git a/mm/slub.c b/mm/slub.c index 65ffda5..a03dbe8 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1484,6 +1484,58 @@ static inline int node_match(struct kmem_cache_cpu *c, int node) return 1; } +static int count_free(struct page *page) +{ + return page->objects - page->inuse; +} + +static unsigned long count_partial(struct kmem_cache_node *n, + int (*get_count)(struct page *)) +{ + unsigned long flags; + unsigned long x = 0; + struct page *page; + + spin_lock_irqsave(&n->list_lock, flags); + list_for_each_entry(page, &n->partial, lru) + x += get_count(page); + spin_unlock_irqrestore(&n->list_lock, flags); + return x; +} + +static noinline void +slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid) +{ + int node; + + printk(KERN_WARNING + "SLUB: Unable to allocate memory on node %d (gfp=%x)\n", + nid, gfpflags); + printk(KERN_WARNING " cache: %s, object size: %d, buffer size: %d, " + "default order: %d, min order: %d\n", s->name, s->objsize, + s->size, oo_order(s->oo), oo_order(s->min)); + + for_each_online_node(node) { + struct kmem_cache_node *n = get_node(s, node); + unsigned long nr_partials; + unsigned long nr_slabs; + unsigned long nr_objs; + unsigned long nr_free; + + if (!n) + continue; + + nr_partials = n->nr_partial; + nr_slabs = atomic_long_read(&n->nr_slabs); + nr_objs = atomic_long_read(&n->total_objects); + nr_free = count_partial(n, count_free); + + printk(KERN_WARNING + " node %d: partials: %ld, slabs: %ld, objs: %ld, free: %ld\n", + node, nr_partials, nr_slabs, nr_objs, nr_free); + } +} + /* * Slow path. The lockless freelist is empty or we need to perform * debugging duties. @@ -1565,6 +1617,7 @@ new_slab: c->page = new; goto load_freelist; } + slab_out_of_memory(s, gfpflags, node); return NULL; debug: if (!alloc_debug_processing(s, c->page, object, addr)) @@ -3318,20 +3371,6 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags, } #ifdef CONFIG_SLUB_DEBUG -static unsigned long count_partial(struct kmem_cache_node *n, - int (*get_count)(struct page *)) -{ - unsigned long flags; - unsigned long x = 0; - struct page *page; - - spin_lock_irqsave(&n->list_lock, flags); - list_for_each_entry(page, &n->partial, lru) - x += get_count(page); - spin_unlock_irqrestore(&n->list_lock, flags); - return x; -} - static int count_inuse(struct page *page) { return page->inuse; @@ -3342,11 +3381,6 @@ static int count_total(struct page *page) return page->objects; } -static int count_free(struct page *page) -{ - return page->objects - page->inuse; -} - static int validate_slab(struct kmem_cache *s, struct page *page, unsigned long *map) { ^ permalink raw reply related [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-09 7:06 ` Pekka Enberg @ 2009-06-09 7:54 ` David Rientjes -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-09 7:54 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-06-09 7:54 UTC (permalink / raw) To: Pekka Enberg Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM On Tue, 9 Jun 2009, Pekka Enberg wrote: > Hi Mel, > > On Mon, 2009-06-08 at 15:12 +0100, Mel Gorman wrote: > > > diff --git a/mm/slub.c b/mm/slub.c > > > index 65ffda5..b5acf18 100644 > > > --- a/mm/slub.c > > > +++ b/mm/slub.c > > > @@ -1565,6 +1565,8 @@ new_slab: > > > c->page = new; > > > goto load_freelist; > > > } > > > + printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n", > > > + s->name, s->size, node, gfpflags); > > > > size could be almost anything here for a casual reader. You are > > outputting the size of the object plus its metadata so the name should > > reflect that. I think it would be better to output objsize= and the > > object size without the metadata overhead. What do you think? > > > > In addition, include how many objects there are per-slab and include what > > the order is being passed to the page allocator when allocating new slabs. > > Would that be enough to determine if fallback-to-smaller orders occured? > > So how about something like this then? > Larry reported this stack trace: kernel: git: page allocation failure. order:1, mode:0x4020 kernel: Pid: 3707, comm: git Not tainted 2.6.30-rc1-wl #115 kernel: Call Trace: kernel: [<ffffffff80292f84>] __alloc_pages_internal+0x43d/0x45d kernel: [<ffffffff802b2383>] alloc_pages_current+0xbe/0xc6 kernel: [<ffffffff802b66a4>] new_slab+0xcf/0x28b That's in the order fallback for new slab allocations; so this cache must have oo_order(s->min) of 1. To diagnose whether its object size dictates a >0 slab order, you could enable CONFIG_SLUB_STATS (it's disabled in his .config) and check which /sys/kernel/slab/cache/order_fallback increased. Once you have identified the cache, you can get this information via /sys/kernel/slab/cache/{objsize,order,size}. I think this is what Christoph was getting at. You could even boot with `slub_nomerge' to determine whether cache merging was the issue where the cache under consideration was unnecessarily merged with one that requires larger higher order minimums. I don't quite understand how its necessary to print the partial lists for each node, they should be exhausted if we're allocating a new slab if the node doesn't matter (and can't in Larry's case, he only has one). ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-09 7:54 ` David Rientjes (?) @ 2009-06-09 7:58 ` Pekka Enberg 2009-06-09 8:14 ` David Rientjes -1 siblings, 1 reply; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-09 7:58 ` Pekka Enberg @ 2009-06-09 8:14 ` David Rientjes 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-09 8:14 ` David Rientjes 0 siblings, 0 replies; 467+ messages in thread From: David Rientjes @ 2009-06-09 8:14 UTC (permalink / raw) To: Pekka Enberg Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM On Tue, 9 Jun 2009, Pekka Enberg wrote: > > To diagnose whether its object size dictates a >0 slab order, you could > > enable CONFIG_SLUB_STATS (it's disabled in his .config) and check which > > /sys/kernel/slab/cache/order_fallback increased. Once you have identified > > the cache, you can get this information via > > /sys/kernel/slab/cache/{objsize,order,size}. I think this is what > > Christoph was getting at. > > > > You could even boot with `slub_nomerge' to determine whether cache merging > > was the issue where the cache under consideration was unnecessarily merged > > with one that requires larger higher order minimums. > > Sure. Applying my diagnostic patch will probably shed some light on the > subject too. > I wasn't sure whether you were proposing the patch as an addition to slub or just to help with this issue. I agree it would help in a hopefully ratelimited manner for general slab allocation failures and would have avoided some of the confusion for this issue from lack of diagnostics. > > I don't quite understand how its necessary to print the partial lists for > > each node, they should be exhausted if we're allocating a new slab if the > > node doesn't matter (and can't in Larry's case, he only has one). > > It doesn't hurt either, does it? Yes, we expect the partial lists to be > exhausted but it's better to print that out just in case we have a bug > some day somewhere and that condition is not true. This is very > infrequent slow patch code here anyway. > It will lead to false postiives since you can get a free to a full slab which moves it back to an allowed node's partial list before count_free() is printed. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-09 8:28 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-09 8:28 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-09 8:28 UTC (permalink / raw) To: David Rientjes Cc: Mel Gorman, Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM Hi David, On Tue, 2009-06-09 at 01:14 -0700, David Rientjes wrote: > I wasn't sure whether you were proposing the patch as an addition to slub > or just to help with this issue. I agree it would help in a hopefully > ratelimited manner for general slab allocation failures and would have > avoided some of the confusion for this issue from lack of diagnostics. I am proposing it as a generic addition to SLUB. On Tue, 2009-06-09 at 01:14 -0700, David Rientjes wrote: > > It doesn't hurt either, does it? Yes, we expect the partial lists to be > > exhausted but it's better to print that out just in case we have a bug > > some day somewhere and that condition is not true. This is very > > infrequent slow patch code here anyway. > > It will lead to false postiives since you can get a free to a full slab > which moves it back to an allowed node's partial list before count_free() > is printed. Fair enough, lets drop it then! Pekka diff --git a/mm/slub.c b/mm/slub.c index 65ffda5..2bbacfc 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1484,6 +1484,56 @@ static inline int node_match(struct kmem_cache_cpu *c, int node) return 1; } +static int count_free(struct page *page) +{ + return page->objects - page->inuse; +} + +static unsigned long count_partial(struct kmem_cache_node *n, + int (*get_count)(struct page *)) +{ + unsigned long flags; + unsigned long x = 0; + struct page *page; + + spin_lock_irqsave(&n->list_lock, flags); + list_for_each_entry(page, &n->partial, lru) + x += get_count(page); + spin_unlock_irqrestore(&n->list_lock, flags); + return x; +} + +static noinline void +slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid) +{ + int node; + + printk(KERN_WARNING + "SLUB: Unable to allocate memory on node %d (gfp=%x)\n", + nid, gfpflags); + printk(KERN_WARNING " cache: %s, object size: %d, buffer size: %d, " + "default order: %d, min order: %d\n", s->name, s->objsize, + s->size, oo_order(s->oo), oo_order(s->min)); + + for_each_online_node(node) { + struct kmem_cache_node *n = get_node(s, node); + unsigned long nr_slabs; + unsigned long nr_objs; + unsigned long nr_free; + + if (!n) + continue; + + nr_slabs = atomic_long_read(&n->nr_slabs); + nr_objs = atomic_long_read(&n->total_objects); + nr_free = count_partial(n, count_free); + + printk(KERN_WARNING + " node %d: slabs: %ld, objs: %ld, free: %ld\n", + node, nr_slabs, nr_objs, nr_free); + } +} + /* * Slow path. The lockless freelist is empty or we need to perform * debugging duties. @@ -1565,6 +1615,7 @@ new_slab: c->page = new; goto load_freelist; } + slab_out_of_memory(s, gfpflags, node); return NULL; debug: if (!alloc_debug_processing(s, c->page, object, addr)) @@ -3318,20 +3369,6 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags, } #ifdef CONFIG_SLUB_DEBUG -static unsigned long count_partial(struct kmem_cache_node *n, - int (*get_count)(struct page *)) -{ - unsigned long flags; - unsigned long x = 0; - struct page *page; - - spin_lock_irqsave(&n->list_lock, flags); - list_for_each_entry(page, &n->partial, lru) - x += get_count(page); - spin_unlock_irqrestore(&n->list_lock, flags); - return x; -} - static int count_inuse(struct page *page) { return page->inuse; @@ -3342,11 +3379,6 @@ static int count_total(struct page *page) return page->objects; } -static int count_free(struct page *page) -{ - return page->objects - page->inuse; -} - static int validate_slab(struct kmem_cache *s, struct page *page, unsigned long *map) { ^ permalink raw reply related [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-09 8:28 ` Pekka Enberg (?) @ 2009-06-10 14:41 ` Larry Finger 2009-06-10 15:44 ` Pekka Enberg -1 siblings, 1 reply; 467+ 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] 467+ 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; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-10 15:44 ` Pekka Enberg @ 2009-06-10 15:49 ` Pekka Enberg 2009-06-11 14:41 ` Christoph Lameter 1 sibling, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 15:49 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-10 15:49 UTC (permalink / raw) To: Larry Finger Cc: David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM, yanmin.zhang-VuQAYsv1563Yd54FQh9/CA On Wed, 2009-06-10 at 18:44 +0300, Pekka Enberg wrote: > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should > help. Christoph, are you okay with this patch? > > Pekka > > diff --git a/mm/slub.c b/mm/slub.c > index 65ffda5..2c93c30 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -2334,6 +2334,8 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order) > > } > > +#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track)) > + > static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, > const char *name, size_t size, > size_t align, unsigned long flags, > @@ -2346,6 +2348,9 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, > s->align = align; > s->flags = kmem_cache_flags(size, flags, name, ctor); > > + if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE) > + flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER); > + > if (!calculate_sizes(s, -1)) > goto error; > > Argh, that patch has a typo. Please try this one instead. Pekka diff --git a/mm/slub.c b/mm/slub.c index 65ffda5..cb0473c 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2334,6 +2334,8 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order) } +#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track)) + static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, const char *name, size_t size, size_t align, unsigned long flags, @@ -2346,6 +2348,9 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, s->align = align; s->flags = kmem_cache_flags(size, flags, name, ctor); + if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE) + s->flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER); + if (!calculate_sizes(s, -1)) goto error; ^ permalink raw reply related [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-10 15:49 ` Pekka Enberg @ 2009-06-10 15:52 ` Johannes Berg -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 15:52 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-06-10 15:52 UTC (permalink / raw) To: Pekka Enberg Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM, yanmin.zhang-VuQAYsv1563Yd54FQh9/CA [-- Attachment #1: Type: text/plain, Size: 591 bytes --] On Wed, 2009-06-10 at 18:49 +0300, Pekka Enberg wrote: > On Wed, 2009-06-10 at 18:44 +0300, Pekka Enberg wrote: > > > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have > > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should > > help. Christoph, are you okay with this patch? > + if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE) && size <= PAGE_SIZE ? Or is this a path that only happens for small allocations? > + s->flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER); > + > if (!calculate_sizes(s, -1)) > goto error; johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 16:06 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 16:06 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-10 16:06 UTC (permalink / raw) To: Johannes Berg Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM, yanmin.zhang-VuQAYsv1563Yd54FQh9/CA On Wed, 2009-06-10 at 17:52 +0200, Johannes Berg wrote: > On Wed, 2009-06-10 at 18:49 +0300, Pekka Enberg wrote: > > On Wed, 2009-06-10 at 18:44 +0300, Pekka Enberg wrote: > > > > > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have > > > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should > > > help. Christoph, are you okay with this patch? > > > > + if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE) > > && size <= PAGE_SIZE > > ? Or is this a path that only happens for small allocations? Anything that's beyond PAGE_SIZE * 2 is passed straight to the page allocator and the intent of this patch is to disable debugging for all big caches like SLAB does. Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 16:16 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 16:16 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-10 16:16 UTC (permalink / raw) To: Johannes Berg Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM, yanmin.zhang-VuQAYsv1563Yd54FQh9/CA On Wed, 2009-06-10 at 18:49 +0300, Pekka Enberg wrote: > > On Wed, 2009-06-10 at 18:44 +0300, Pekka Enberg wrote: > > > > > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have > > > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should > > > help. Christoph, are you okay with this patch? On Wed, 2009-06-10 at 17:52 +0200, Johannes Berg wrote: > > + if ((size + MAX_DEBUG_SIZE) >= PAGE_SIZE) > > && size <= PAGE_SIZE > > ? Or is this a path that only happens for small allocations? > > > + s->flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER); > > + > > if (!calculate_sizes(s, -1)) > > goto error; Although something like this would probably be even nicer. Pekka diff --git a/mm/slub.c b/mm/slub.c index 65ffda5..a4206ef 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2334,6 +2334,16 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order) } +#define MAX_DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track)) + +static bool must_disable_debug(size_t size) +{ + /* + * Disable debugging if it increases the minimum page order. + */ + return get_order(size + MAX_DEBUG_SIZE) > get_order(size); +} + static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, const char *name, size_t size, size_t align, unsigned long flags, @@ -2346,6 +2356,9 @@ static int kmem_cache_open(struct kmem_cache *s, gfp_t gfpflags, s->align = align; s->flags = kmem_cache_flags(size, flags, name, ctor); + if (must_disable_debug(size)) + s->flags &= ~(SLAB_POISON|SLAB_RED_ZONE|SLAB_STORE_USER); + if (!calculate_sizes(s, -1)) goto error; ^ permalink raw reply related [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-10 15:49 ` Pekka Enberg @ 2009-06-10 16:10 ` Larry Finger -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 16:10 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-06-10 16:10 UTC (permalink / raw) To: Pekka Enberg Cc: David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM, yanmin.zhang-VuQAYsv1563Yd54FQh9/CA Pekka Enberg wrote: > Argh, that patch has a typo. Please try this one instead. > > Pekka I installed this patch on top of the other one and have started testing. It usually takes almost a day for it to occur. Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-10 15:44 ` Pekka Enberg @ 2009-06-11 14:41 ` Christoph Lameter 2009-06-11 14:41 ` Christoph Lameter 1 sibling, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-11 14:41 ` Christoph Lameter 0 siblings, 0 replies; 467+ messages in thread From: Christoph Lameter @ 2009-06-11 14:41 UTC (permalink / raw) To: Pekka Enberg Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, npiggin-l3A5Bk7waGM, yanmin.zhang-VuQAYsv1563Yd54FQh9/CA, Andrew Morton On Wed, 10 Jun 2009, Pekka Enberg wrote: > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should > help. Christoph, are you okay with this patch? He likely has CONFIG_SLUB_DEBUG_ON set which enables debugging and thus needs more than the payload for metadata. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-11 15:09 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-11 15:09 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-11 15:09 UTC (permalink / raw) To: Christoph Lameter Cc: Larry Finger, David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, npiggin-l3A5Bk7waGM, yanmin.zhang-VuQAYsv1563Yd54FQh9/CA On Wed, 10 Jun 2009, Pekka Enberg wrote: > > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have > > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should > > help. Christoph, are you okay with this patch? On Thu, 2009-06-11 at 10:41 -0400, Christoph Lameter wrote: > He likely has CONFIG_SLUB_DEBUG_ON set which enables debugging and thus > needs more than the payload for metadata. Yup. I suspect a lot of people who are doing _testing_ enable that. If you're unhappy with my patch (the get_order one which shouldn't affect that many caches anyway), any suggestions how to fix this up? It seems that the wireless stack at least does quite a few kmalloc(4096) allocations. We can probably switch back to page allocator pass-through in the near future (when Mel's patches are in) but we need a fix for -stable. Pekka ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-11 15:09 ` Pekka Enberg @ 2009-06-11 18:41 ` Johannes Berg -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-11 18:41 ` Johannes Berg 0 siblings, 0 replies; 467+ messages in thread From: Johannes Berg @ 2009-06-11 18:41 UTC (permalink / raw) To: Pekka Enberg Cc: Christoph Lameter, Larry Finger, David Rientjes, Mel Gorman, Rik van Riel, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, npiggin-l3A5Bk7waGM, yanmin.zhang-VuQAYsv1563Yd54FQh9/CA [-- Attachment #1: Type: text/plain, Size: 892 bytes --] On Thu, 2009-06-11 at 18:09 +0300, Pekka Enberg wrote: > On Wed, 10 Jun 2009, Pekka Enberg wrote: > > > Aha, SLUB thinks the minimum order for 4096 is 1. I guess you have > > > CONFIG_SLUB_DEBUG enabled? If yes, something like to following should > > > help. Christoph, are you okay with this patch? > > On Thu, 2009-06-11 at 10:41 -0400, Christoph Lameter wrote: > > He likely has CONFIG_SLUB_DEBUG_ON set which enables debugging and thus > > needs more than the payload for metadata. > > Yup. I suspect a lot of people who are doing _testing_ enable that. If > you're unhappy with my patch (the get_order one which shouldn't affect > that many caches anyway), any suggestions how to fix this up? It seems > that the wireless stack at least does quite a few kmalloc(4096) > allocations. I think networking rounds up allocations, but it's not wireless per se. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-09 7:06 ` Pekka Enberg @ 2009-06-10 15:56 ` Mel Gorman -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 15:56 ` Mel Gorman 0 siblings, 0 replies; 467+ messages in thread From: Mel Gorman @ 2009-06-10 15:56 UTC (permalink / raw) To: Pekka Enberg Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM On Tue, Jun 09, 2009 at 10:06:41AM +0300, Pekka Enberg wrote: > Hi Mel, > > On Mon, 2009-06-08 at 15:12 +0100, Mel Gorman wrote: > > > diff --git a/mm/slub.c b/mm/slub.c > > > index 65ffda5..b5acf18 100644 > > > --- a/mm/slub.c > > > +++ b/mm/slub.c > > > @@ -1565,6 +1565,8 @@ new_slab: > > > c->page = new; > > > goto load_freelist; > > > } > > > + printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n", > > > + s->name, s->size, node, gfpflags); > > > > size could be almost anything here for a casual reader. You are > > outputting the size of the object plus its metadata so the name should > > reflect that. I think it would be better to output objsize= and the > > object size without the metadata overhead. What do you think? > > > > In addition, include how many objects there are per-slab and include what > > the order is being passed to the page allocator when allocating new slabs. > > Would that be enough to determine if fallback-to-smaller orders occured? > > So how about something like this then? > > Pekka > > diff --git a/mm/slub.c b/mm/slub.c > index 65ffda5..a03dbe8 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -1484,6 +1484,58 @@ static inline int node_match(struct kmem_cache_cpu *c, int node) > return 1; > } > > +static int count_free(struct page *page) > +{ > + return page->objects - page->inuse; > +} > + > +static unsigned long count_partial(struct kmem_cache_node *n, > + int (*get_count)(struct page *)) > +{ > + unsigned long flags; > + unsigned long x = 0; > + struct page *page; > + > + spin_lock_irqsave(&n->list_lock, flags); > + list_for_each_entry(page, &n->partial, lru) > + x += get_count(page); > + spin_unlock_irqrestore(&n->list_lock, flags); > + return x; > +} > + > +static noinline void > +slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid) > +{ > + int node; > + > + printk(KERN_WARNING > + "SLUB: Unable to allocate memory on node %d (gfp=%x)\n", > + nid, gfpflags); > + printk(KERN_WARNING " cache: %s, object size: %d, buffer size: %d, " > + "default order: %d, min order: %d\n", s->name, s->objsize, > + s->size, oo_order(s->oo), oo_order(s->min)); > + Much nicer. There is a clear division between the object size and the size including the metadata. There is also now a good idea of what sort of request it was, we know what cache it was so we can guess the size passed to kmalloc() with reasonable accuracy. > + for_each_online_node(node) { > + struct kmem_cache_node *n = get_node(s, node); > + unsigned long nr_partials; > + unsigned long nr_slabs; > + unsigned long nr_objs; > + unsigned long nr_free; > + > + if (!n) > + continue; > + > + nr_partials = n->nr_partial; > + nr_slabs = atomic_long_read(&n->nr_slabs); > + nr_objs = atomic_long_read(&n->total_objects); > + nr_free = count_partial(n, count_free); > + > + printk(KERN_WARNING > + " node %d: partials: %ld, slabs: %ld, objs: %ld, free: %ld\n", > + node, nr_partials, nr_slabs, nr_objs, nr_free); > + } > +} That looks like it would generate easier-to-debug-with messages and to not-expert-at-slub eye, it looks correct. Slap a changelog on it with an example message and go with it. It should make page allocation failures messages that go through SLUB a lot easier to figure out. Thanks > + > /* > * Slow path. The lockless freelist is empty or we need to perform > * debugging duties. > @@ -1565,6 +1617,7 @@ new_slab: > c->page = new; > goto load_freelist; > } > + slab_out_of_memory(s, gfpflags, node); > return NULL; > debug: > if (!alloc_debug_processing(s, c->page, object, addr)) > @@ -3318,20 +3371,6 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags, > } > > #ifdef CONFIG_SLUB_DEBUG > -static unsigned long count_partial(struct kmem_cache_node *n, > - int (*get_count)(struct page *)) > -{ > - unsigned long flags; > - unsigned long x = 0; > - struct page *page; > - > - spin_lock_irqsave(&n->list_lock, flags); > - list_for_each_entry(page, &n->partial, lru) > - x += get_count(page); > - spin_unlock_irqrestore(&n->list_lock, flags); > - return x; > -} > - > static int count_inuse(struct page *page) > { > return page->inuse; > @@ -3342,11 +3381,6 @@ static int count_total(struct page *page) > return page->objects; > } > > -static int count_free(struct page *page) > -{ > - return page->objects - page->inuse; > -} > - > static int validate_slab(struct kmem_cache *s, struct page *page, > unsigned long *map) > { > > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 18:03 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-10 18:03 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-10 18:03 UTC (permalink / raw) To: Mel Gorman Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter, npiggin-l3A5Bk7waGM On Wed, Jun 10, 2009 at 6:56 PM, Mel Gorman<mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote: > That looks like it would generate easier-to-debug-with messages and to > not-expert-at-slub eye, it looks correct. Slap a changelog on it with an > example message and go with it. It should make page allocation failures > messages that go through SLUB a lot easier to figure out. Thanks Mel! The patch is here and will be part of next slab pull request to Linus: http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=4bc6e7858da5ea4ecc3e47538f7fabed331cc21b ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-09 7:50 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-09 7:50 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-06-09 7:50 UTC (permalink / raw) To: Mel Gorman Cc: Rik van Riel, Larry Finger, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Andrew Morton, KOSAKI Motohiro, KAMEZAWA Hiroyuki, Christoph Lameter On Mon, Jun 8, 2009 at 5:12 PM, Mel Gorman<mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote: > In addition, include how many objects there are per-slab and include what > the order is being passed to the page allocator when allocating new slabs. > Would that be enough to determine if fallback-to-smaller orders occured? Well, if the slab_out_of_memory() is called, we already know the higher order allocation failed _and_ the fallback allocation failed. So yes, it would be enough. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 13:20 ` Rik van Riel 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 13:20 ` Rik van Riel 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 13:35 ` Mel Gorman 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-06-08 13:35 ` Mel Gorman 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-06-08 10:17 ` Mel Gorman ` (2 preceding siblings ...) (?) @ 2009-06-08 13:34 ` Larry Finger -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* 2.6.30-rc7-git4: Reported regressions from 2.6.29 @ 2009-05-30 19:29 Rafael J. Wysocki 2009-05-30 19:37 ` Rafael J. Wysocki 0 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-05-30 19:29 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-31 100 32 27 2009-05-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408 Subject : Performance regression in 2.6.30-rc7 Submitter : Diego Calleja <diegocg@gmail.com> Date : 2009-05-30 18:51 (1 days old) References : http://lkml.org/lkml/2009/5/30/146 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407 Subject : adb trackpad disappears after suspend to ram Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de> Date : 2009-05-28 7:59 (3 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401 Subject : pktcdvd writing is really slow with CFQ scheduler (bisected) Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2009-05-28 18:43 (3 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13391 Subject : Kernel boot hangs at about every second start when kms is activated Submitter : Martin Bammer <mrb74@gmx.at> Date : 2009-05-26 21:47 (5 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389 Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be Submitter : Frans Pop <elendil@planet.nl> Date : 2009-05-26 15:24 (5 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13377 Subject : Microphone no longer works on Toshiba Satellite A100 Submitter : M. Vefa Bicakci <bicave@superonline.com> Date : 2009-05-24 15:49 (7 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=23f0c048ba59ad5c2f3fd85ed98360b631dbf6f8 References : http://marc.info/?l=linux-kernel&m=124318383910011&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (8 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (8 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13366 Subject : About 80% of shutdowns fail (blocking) Submitter : Martin Bammer <mrb74@gmx.at> Date : 2009-05-23 00:58 (8 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362 Subject : [mac80211 ] Wifi Network Slownes Bisected Submitter : Alejandro Riveira <ariveira@gmail.com> Date : 2009-05-22 13:32 (9 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351 Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Submitter : <unggnu@googlemail.com> Date : 2009-05-20 14:09 (11 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742 Handled-By : Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (12 days old) Handled-By : Rusty Russell <rusty@rustcorp.com.au> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (13 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13330 Subject : nfs4 NULL pointer dereference in _nfs4_do_setlk Submitter : Rich Ercolani <rercola@acm.jhu.edu> Date : 2009-05-17 04:44 (14 days old) Handled-By : Trond Myklebust <trond.myklebust@fys.uio.no> 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 (28 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&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 (17 days old) References : http://marc.info/?l=linux-kernel&m=124231630701394&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (32 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 (31 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=13313 Subject : vm86old oops Submitter : Sergey Senozhatsky <sergey.senozhatsky@mail.by> Date : 2009-05-14 21:53 (17 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13310 Subject : REGRESSION 2.6.30-rc1: oprofile panics system when started Submitter : Jesse Brandeburg <jesse.brandeburg@intel.com> Date : 2009-05-14 17:51 (17 days old) 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 (17 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13277 Subject : 2.6.30 regression - unreliable resume - bisected - Thinkpad X40 Submitter : Daniel Vetter <daniel@ffwll.ch> Date : 2009-05-11 10:08 (20 days old) Handled-By : Len Brown <len.brown@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Since kernel 2.6.30-rc1, computers hangs randomly .. Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180 Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Submitter : Niel Lambrechts <niel.lambrechts@gmail.com> Date : 2009-04-21 21:35 (40 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 (40 days old) References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13119 Subject : Trouble with make-install from a NFS mount Submitter : Gregory Haskins <ghaskins@novell.com> Date : 2009-04-14 21:32 (47 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=13116 Subject : Can't boot with nosmp Submitter : Stephen Hemminger <shemminger@vyatta.com> Date : 2009-04-15 4:18 (46 days old) References : http://marc.info/?l=linux-kernel&m=123976917817920&w=4 Handled-By : Dan Williams <dan.j.williams@intel.com> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13406 Subject : Kernel does not compile when set to use i915 kernel mode-setting per default Submitter : Woody Suwalski <woodys@xandros.com> Date : 2009-05-20 19:30 (11 days old) References : http://marc.info/?l=linux-acpi&m=124284975803785&w=4 Handled-By : Len Brown <lenb@kernel.org> Patch : http://patchwork.kernel.org/patch/27026/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13378 Subject : kernel/async.c broke pata_legacy.c Submitter : Mikael Pettersson <mikpe@it.uu.se> Date : 2009-05-24 16:13 (7 days old) References : http://marc.info/?l=linux-kernel&m=124318186507210&w=4 Handled-By : James Bottomley <James.Bottomley@hansenpartnership.com> Patch : http://patchwork.kernel.org/patch/25699/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13372 Subject : Oops in usb-serial with keyspan adapter Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org> Date : 2009-05-18 0:07 (13 days old) References : http://marc.info/?l=linux-kernel&m=124260532924736&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> Patch : http://patchwork.kernel.org/patch/26603/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13121 Subject : Buggy _BCM - acer aspire 5720G, 5710Z, 5315 Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-04-16 11:37 (45 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a7c618a3f7bef1a20ae740df512eeba21397fa5 References : http://marc.info/?l=linux-kernel&m=123988189401913&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Patch : http://patchwork.kernel.org/patch/19755/ http://bugzilla.kernel.org/attachment.cgi?id=21268 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 (50 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] 467+ 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; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-30 19:37 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-05-30 19:37 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.29. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (32 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.30-rc7: Reported regressions from 2.6.29 @ 2009-05-24 19:06 Rafael J. Wysocki 2009-05-24 19:11 ` Rafael J. Wysocki 0 siblings, 1 reply; 467+ messages in thread From: Rafael J. Wysocki @ 2009-05-24 19:06 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 [NOTE: Bug entries for which I know there are working patches get the RESOLVED / PATCH_ALREADY_AVAILABLE status in the Bugzilla, which makes it easier to check if the patches have been merged before sending out the list. For this reason, please let me know of working patches for any of the regression list items or (better) change the status of the bug entries in case you know of a working patch (in which case please also add a link to the patch to the appropriate bug entry).] 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-24 92 34 27 2009-05-16 81 36 33 2009-04-25 55 36 26 2009-04-17 37 35 28 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13377 Subject : Microphone no longer works on Toshiba Satellite A100 Submitter : M. Vefa Bicakci <bicave@superonline.com> Date : 2009-05-24 15:49 (1 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=23f0c048ba59ad5c2f3fd85ed98360b631dbf6f8 References : http://marc.info/?l=linux-kernel&m=124318383910011&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374 Subject : reiserfs blocked for more than 120secs Submitter : Harald Dunkel <harald.dunkel@t-online.de> Date : 2009-05-23 8:52 (2 days old) References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373 Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2009-05-23 5:08 (2 days old) References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13372 Subject : Oops in usb-serial with keyspan adapter Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org> Date : 2009-05-18 0:07 (7 days old) References : http://marc.info/?l=linux-kernel&m=124260532924736&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13366 Subject : About 80% of shutdowns fail (blocking) Submitter : Martin Bammer <mrb74@gmx.at> Date : 2009-05-23 00:58 (2 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341 Subject : Random Oops at boot at loading ip6tables rules Submitter : <patrick@ostenberg.de> Date : 2009-05-19 09:08 (6 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13339 Subject : rtable leak in ipv4/route.c Submitter : Alexander V. Lukyanov <lav@yar.ru> Date : 2009-05-18 14:10 (7 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337 Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules Submitter : Tomas Janousek <tomi@nomi.cz> Date : 2009-05-18 10:59 (7 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13331 Subject : FUTEX_LOCK_PI kills kernel Submitter : Andreas Schwab <schwab@linux-m68k.org> Date : 2009-05-17 09:51 (8 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13330 Subject : nfs4 NULL pointer dereference in _nfs4_do_setlk Submitter : Rich Ercolani <rercola@acm.jhu.edu> Date : 2009-05-17 04:44 (8 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328 Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear. Submitter : Francis Moreau <francis.moro@gmail.com> Date : 2009-05-03 16:22 (22 days old) References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13326 Subject : [PATCH]Null pointer dereference in rtc-cmos driver Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-05-14 16:16 (11 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 (11 days old) References : http://marc.info/?l=linux-kernel&m=124231630701394&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 (32 days old) References : http://marc.info/?l=linux-kernel&m=124049547915450&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2009-04-29 21:01 (26 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 (25 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 (11 days old) 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 (13 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 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219 Subject : Since kernel 2.6.30-rc1, computers hangs randomly .. Submitter : David Hill <hilld@binarystorm.net> Date : 2009-05-01 16:57 (24 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180 Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle Submitter : Niel Lambrechts <niel.lambrechts@gmail.com> Date : 2009-04-21 21:35 (34 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 (34 days old) References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4 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 (36 days old) References : http://marc.info/?l=linux-kernel&m=124022460014812&w=4 https://bugs.freedesktop.org/show_bug.cgi?id=21480 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 (33 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 (40 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 (41 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=13116 Subject : Can't boot with nosmp Submitter : Stephen Hemminger <shemminger@vyatta.com> Date : 2009-04-15 4:18 (40 days old) References : http://marc.info/?l=linux-kernel&m=123976917817920&w=4 Handled-By : Dan Williams <dan.j.williams@intel.com> Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13378 Subject : kernel/async.c broke pata_legacy.c Submitter : Mikael Pettersson <mikpe@it.uu.se> Date : 2009-05-24 16:13 (1 days old) References : http://marc.info/?l=linux-kernel&m=124318186507210&w=4 Handled-By : James Bottomley <James.Bottomley@hansenpartnership.com> Patch : http://patchwork.kernel.org/patch/25699/ 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 (22 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 Handled-By : Lennert Buytenhek <buytenh@wantstofly.org> Patch : http://patchwork.kernel.org/patch/25518/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13277 Subject : Thinkpad X40 no longer resumes reliable since ff69f2bba67bd45514923aaedbf40fe351787c59 Submitter : Daniel Vetter <daniel@ffwll.ch> Date : 2009-05-11 10:08 (14 days old) Handled-By : Len Brown <len.brown@intel.com> Patch : http://patchwork.kernel.org/patch/22499/ 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 (21 days old) Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Patch : http://patchwork.kernel.org/patch/25557/ 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 (40 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=13121 Subject : Buggy _BCM - acer aspire 5720G, 5710Z, 5315 Submitter : Maxim Levitsky <maximlevitsky@gmail.com> Date : 2009-04-16 11:37 (39 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a7c618a3f7bef1a20ae740df512eeba21397fa5 References : http://marc.info/?l=linux-kernel&m=123988189401913&w=4 Handled-By : Zhang Rui <rui.zhang@intel.com> Patch : http://patchwork.kernel.org/patch/19755/ http://bugzilla.kernel.org/attachment.cgi?id=21268 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 (44 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb 2009-05-24 19:06 2.6.30-rc7: Reported regressions from 2.6.29 Rafael J. Wysocki @ 2009-05-24 19:11 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-24 19:11 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-05-24 19:11 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.29. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (26 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* 2.6.30-rc6: Reported regressions from 2.6.29 @ 2009-05-16 19:14 Rafael J. Wysocki 2009-05-16 19:20 ` Rafael J. Wysocki 0 siblings, 1 reply; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb 2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki @ 2009-05-16 19:20 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-16 19:20 ` Rafael J. Wysocki 0 siblings, 0 replies; 467+ messages in thread From: Rafael J. Wysocki @ 2009-05-16 19:20 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Johannes Berg, Larry Finger This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.29. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 Subject : Page allocation failures with b43 and p54usb Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> Date : 2009-04-29 21:01 (18 days old) References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-05-16 19:20 ` Rafael J. Wysocki @ 2009-05-16 23:36 ` Andrew Morton -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-16 23:36 ` Andrew Morton 0 siblings, 0 replies; 467+ messages in thread From: Andrew Morton @ 2009-05-16 23:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Larry Finger, linux-wireless-u79uwXL29TY76Z2rM5mHXA On Sat, 16 May 2009 21:20:45 +0200 (CEST) "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.29. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > Subject : Page allocation failures with b43 and p54usb > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > Date : 2009-04-29 21:01 (18 days old) > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> > > Well.. order-1 GFP_ATOMIC allocations are unreliable. The networking code should hanlde the situation and recover. I assume that is happening in this case? Perhaps we did something in that code after 2.6.29 which increased the frequency of the order-1 allocation attempts? Maybe earlier kernels used order-0 all the time? Those are much more reliable. ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-17 23:16 ` Larry Finger 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-17 23:16 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-05-17 23:16 UTC (permalink / raw) To: Andrew Morton Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA Andrew Morton wrote: > > Well.. order-1 GFP_ATOMIC allocations are unreliable. The networking > code should hanlde the situation and recover. I assume that is > happening in this case? Yes, the driver has recovered in all cases so far. > Perhaps we did something in that code after 2.6.29 which increased the > frequency of the order-1 allocation attempts? Maybe earlier kernels > used order-0 all the time? Those are much more reliable. I think something happened to change the allocation as I never saw these O(1) failures before with these particular drivers. I put in a few test printk's and the buffers were 700-800 bytes long, and I would not expect them to require more than an O(0) allocation. I pushed 2.6.30-rc6 hard for ~12 hours without any recurrence of the problem. Given the relative infrequency of the error, this certainly does not indicate a fix in recent code. I will be trying to force it again. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-18 6:31 ` Pekka Enberg 0 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-18 6:31 ` Pekka Enberg 0 siblings, 0 replies; 467+ messages in thread From: Pekka Enberg @ 2009-05-18 6:31 UTC (permalink / raw) To: Andrew Morton Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Johannes Berg, Larry Finger, linux-wireless-u79uwXL29TY76Z2rM5mHXA, adrian-TSF8l6Tg6afpT6hvJLqO3U8SxdOydiOw Hi Andrew, On Sat, 16 May 2009 21:20:45 +0200 (CEST) "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote: >> This message has been generated automatically as a part of a report >> of recent regressions. >> >> The following bug entry is on the current list of known regressions >> from 2.6.29. Please verify if it still should be listed and let me know >> (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 >> Subject : Page allocation failures with b43 and p54usb >> Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> >> Date : 2009-04-29 21:01 (18 days old) >> References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 >> Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> On Sun, May 17, 2009 at 2:36 AM, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote: > Well.. order-1 GFP_ATOMIC allocations are unreliable. The networking > code should hanlde the situation and recover. I assume that is > happening in this case? > > Perhaps we did something in that code after 2.6.29 which increased the > frequency of the order-1 allocation attempts? Maybe earlier kernels > used order-0 all the time? Those are much more reliable. I wonder if this is related: http://bugzilla.kernel.org/show_bug.cgi?id=13069 Both point to post 2.6.29... Hmm. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb 2009-05-16 19:20 ` Rafael J. Wysocki @ 2009-05-21 13:21 ` Larry Finger -1 siblings, 0 replies; 467+ 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] 467+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb @ 2009-05-21 13:21 ` Larry Finger 0 siblings, 0 replies; 467+ messages in thread From: Larry Finger @ 2009-05-21 13:21 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.29. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319 > Subject : Page allocation failures with b43 and p54usb > Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> > Date : 2009-04-29 21:01 (18 days old) > References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 > Handled-By : Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> I have been unable to repeat the problem with recent kernels - I am now running 2.6.30-rc6. This regression should probably be dropped even though it may show up when 2.6.30 is released. Larry ^ permalink raw reply [flat|nested] 467+ messages in thread
end of thread, other threads:[~2009-08-26 20:53 UTC | newest] Thread overview: 467+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-06 23:57 2.6.31-rc2: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki 2009-07-06 23:57 ` Rafael J. Wysocki 2009-07-06 23:57 ` [Bug #13109] High latency on /sys/class/thermal Rafael J. Wysocki 2009-07-06 23:57 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13277] 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13119] Trouble with make-install from a NFS mount Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13179] CD-R: wodim intermittent failures Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13306] hibernate slow on _second_ run Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:12 ` Johannes Berg 2009-07-07 0:12 ` Johannes Berg 2009-07-07 10:58 ` Rafael J. Wysocki 2009-07-07 10:58 ` Rafael J. Wysocki 2009-07-07 11:27 ` Johannes Berg 2009-07-07 0:00 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 1:05 ` Larry Finger 2009-07-07 1:05 ` Larry Finger 2009-07-07 6:29 ` David Rientjes 2009-07-07 6:29 ` David Rientjes 2009-07-07 6:57 ` Pekka Enberg 2009-07-07 6:57 ` Pekka Enberg 2009-07-08 13:18 ` Larry Finger 2009-07-08 13:18 ` Larry Finger 2009-07-07 0:00 ` [Bug #13318] AGP doesn't work anymore on nforce2 Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 2:12 ` Shaohua Li 2009-07-07 2:12 ` Shaohua Li 2009-07-07 11:00 ` Rafael J. Wysocki 2009-07-07 11:00 ` Rafael J. Wysocki 2009-07-07 11:46 ` Bartlomiej Zolnierkiewicz 2009-07-07 0:00 ` [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-08 22:02 ` Jan Scholz 2009-07-08 22:02 ` Jan Scholz 2009-07-09 15:14 ` Jan Scholz 2009-07-09 15:14 ` Jan Scholz 2009-07-09 20:03 ` Rafael J. Wysocki 2009-07-09 20:03 ` Rafael J. Wysocki 2009-07-09 20:28 ` Johannes Berg 2009-07-09 20:28 ` Johannes Berg 2009-07-09 20:34 ` Rafael J. Wysocki 2009-07-09 20:34 ` Rafael J. Wysocki 2009-07-11 14:07 ` Jan Scholz 2009-07-11 14:07 ` Jan Scholz 2009-07-11 14:36 ` Johannes Berg 2009-07-11 14:36 ` Johannes Berg 2009-07-11 17:20 ` Jan Scholz 2009-07-11 17:20 ` Jan Scholz 2009-07-11 17:47 ` Johannes Berg 2009-07-11 17:47 ` Johannes Berg 2009-07-26 20:41 ` 2.6.31-rc4: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki 2009-07-26 20:41 ` Rafael J. Wysocki 2009-07-26 20:41 ` [Bug #13109] High latency on /sys/class/thermal Rafael J. Wysocki 2009-07-26 20:41 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-07-27 0:17 ` Larry Finger 2009-07-27 0:17 ` Larry Finger 2009-07-27 0:24 ` David Rientjes 2009-07-27 0:24 ` David Rientjes 2009-07-27 7:08 ` Pekka Enberg 2009-07-27 7:08 ` Pekka Enberg 2009-07-27 9:37 ` David Rientjes 2009-07-27 9:37 ` David Rientjes 2009-07-27 17:20 ` Christoph Lameter 2009-07-27 17:20 ` Christoph Lameter 2009-07-27 18:16 ` David Rientjes 2009-07-27 18:16 ` David Rientjes 2009-07-27 21:43 ` Christoph Lameter 2009-07-27 21:43 ` Christoph Lameter 2009-07-27 22:38 ` David Rientjes 2009-07-28 1:30 ` [patch] slub: use size and objsize orders to disable debug flags David Rientjes 2009-07-28 1:30 ` David Rientjes 2009-07-28 7:53 ` Pekka Enberg 2009-07-28 7:53 ` Pekka Enberg 2009-08-03 14:56 ` Christoph Lameter 2009-08-03 14:56 ` Christoph Lameter 2009-07-26 20:45 ` [Bug #13341] Random Oops at boot at loading ip6tables rules Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13318] AGP doesn't work anymore on nforce2 Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13219] Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.4 Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13306] hibernate slow on _second_ run Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 8:16 ` Johannes Berg 2009-07-27 8:16 ` Johannes Berg 2009-07-27 21:09 ` [Bug 13306] " Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 1:22 ` Frans Pop 2009-07-27 1:22 ` Frans Pop [not found] ` <200907270322.47523.elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> 2009-07-27 21:25 ` Rafael J. Wysocki 2009-07-27 21:25 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-08-02 13:45 ` Alejandro Riveira Fernández 2009-08-02 13:45 ` Alejandro Riveira Fernández 2009-08-02 20:30 ` Rafael J. Wysocki 2009-08-02 20:30 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected) Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13374] reiserfs blocked for more than 120secs Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13407] adb trackpad disappears after suspend to ram Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-28 14:49 ` Jan Scholz 2009-07-28 14:49 ` Jan Scholz 2009-07-26 20:45 ` [Bug #13424] possible deadlock when doing governor switching Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 16:48 ` Mathieu Desnoyers 2009-07-27 16:48 ` Mathieu Desnoyers 2009-07-27 21:38 ` Rafael J. Wysocki 2009-07-27 21:38 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13408] Performance regression in 2.6.30-rc7 Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-31 14:14 ` Alan Cox [not found] ` <20090731151417.568094e5-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> 2009-07-31 15:08 ` Ozan Çağlayan 2009-07-31 15:08 ` Ozan Çağlayan 2009-07-31 15:08 ` Ozan Çağlayan 2009-07-31 15:17 ` Alan Cox [not found] ` <20090731161735.6a94ad9c-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> 2009-08-04 11:33 ` Ozan Çağlayan 2009-08-04 11:33 ` Ozan Çağlayan 2009-07-26 20:45 ` [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13472] Oops with minicom and USB serial Rafael J. Wysocki 2009-07-27 14:40 ` Alan Stern 2009-07-27 14:40 ` Alan Stern 2009-07-27 21:55 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13514] acer_wmi causes stack corruption Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13518] slab grows with NFS write activity Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13475] suspend/hibernate lockdep warning Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 1:59 ` Dave Young 2009-07-27 1:59 ` Dave Young 2009-07-27 16:52 ` Mathieu Desnoyers 2009-07-27 16:52 ` Mathieu Desnoyers 2009-07-27 21:57 ` Rafael J. Wysocki 2009-07-27 21:57 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13512] D43 on 2.6.30 doesn't suspend anymore Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13564] random general protection fault at boot time caused by khubd Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13583] pdflush uses 5% CPU on otherwise idle system Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13558] Tracelog during resume Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13581] ath9k doesn't work with newer kernels Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13638] rt2870 driver is broken for (some) cards Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13624] usb: wrong autosuspend initialization Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 14:42 ` Alan Stern 2009-07-27 14:42 ` Alan Stern 2009-07-27 14:44 ` list 2009-07-27 14:44 ` list-2tUql6aCh3Vfq8cQ1yknNg 2009-07-27 15:09 ` Alan Stern 2009-07-27 15:09 ` Alan Stern 2009-07-27 21:59 ` Rafael J. Wysocki 2009-07-27 21:59 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13621] xfs hangs with assertion failed Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13646] warn_on tty_io.c, broken bluetooth Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13648] nfsd: page allocation failure Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 11:04 ` Stephan von Krawczynski 2009-07-27 22:04 ` Rafael J. Wysocki 2009-07-27 22:04 ` Rafael J. Wysocki 2009-07-30 21:30 ` David Rientjes 2009-07-31 11:48 ` Stephan von Krawczynski 2009-07-31 11:48 ` Stephan von Krawczynski 2009-07-26 20:45 ` [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13649] Bad page state in process with various applications Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 9:05 ` Johannes Weiner 2009-07-27 9:05 ` Johannes Weiner 2009-07-27 22:06 ` Rafael J. Wysocki 2009-07-27 22:06 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13669] Kernel bug with dock driver Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13694] i915 phantom TV Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13681] A number of usb Devices causes Oops messages and kernel panics Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-29 13:29 ` Greg KH 2009-07-29 13:29 ` Greg KH 2009-07-29 21:09 ` Rafael J. Wysocki 2009-07-29 21:09 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13795] abnormal boot and no suspend due to 'async' (fastboot) Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13780] NULL pointer dereference loading powernowk8 Rafael J. Wysocki 2009-07-30 22:16 ` David Rientjes 2009-07-30 22:16 ` David Rientjes 2009-07-26 20:45 ` [Bug #13739] 2.6.30 leaking keys on console switch Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13751] oops on HP/Compaq 6910p lid closure Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-26 20:45 ` [Bug #13797] iBook G4 doesn't suspend since 2ed8d2b3a8 Rafael J. Wysocki 2009-07-26 20:45 ` Rafael J. Wysocki 2009-07-27 22:23 ` Jörg Sommer 2009-07-27 22:23 ` Jörg Sommer 2009-07-28 14:40 ` [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules Jan Scholz 2009-07-28 15:26 ` Johannes Berg 2009-07-28 15:26 ` Johannes Berg 2009-07-28 21:15 ` Rafael J. Wysocki 2009-07-28 23:51 ` [PATCH 2.6.31] mac80211: fix suspend Jan Scholz 2009-07-07 0:00 ` [Bug #13341] Random Oops at boot at loading ip6tables rules Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 10:06 ` Alejandro Riveira Fernández 2009-07-07 10:06 ` Alejandro Riveira Fernández 2009-07-07 11:01 ` Rafael J. Wysocki 2009-07-07 11:01 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13374] reiserfs blocked for more than 120secs Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 19:19 ` Frans Pop 2009-07-07 19:19 ` Frans Pop 2009-07-07 20:11 ` Rafael J. Wysocki 2009-07-07 20:11 ` Rafael J. Wysocki 2009-07-08 0:56 ` Zhang Rui 2009-07-08 0:56 ` Zhang Rui 2009-07-07 0:00 ` [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected) Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13407] adb trackpad disappears after suspend to ram Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13424] possible deadlock when doing governor switching Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13408] Performance regression in 2.6.30-rc7 Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13475] suspend/hibernate lockdep warning Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13472] Oops with minicom and USB serial Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13512] D43 on 2.6.30 doesn't suspend anymore Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13518] slab grows with NFS write activity Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13514] acer_wmi causes stack corruption Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-20 21:35 ` Andrew Morton 2009-07-20 21:35 ` Andrew Morton 2009-07-07 0:00 ` [Bug #13558] Tracelog during resume Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13564] random general protection fault at boot time caused by khubd Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13581] ath9k doesn't work with newer kernels Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13583] pdflush uses 5% CPU on otherwise idle system Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13621] xfs hangs with assertion failed Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13624] usb: wrong autosuspend initialization Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:22 ` list 2009-07-07 0:00 ` [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13638] rt2870 driver is broken for (some) cards Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13646] warn_on tty_io.c, broken bluetooth Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13647] fb/mmap lockdep report Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 5:57 ` Jarek Poplawski 2009-07-07 5:57 ` Jarek Poplawski 2009-07-07 11:04 ` Rafael J. Wysocki 2009-07-07 11:04 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13648] nfsd: page allocation failure Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 3:55 ` David Rientjes 2009-07-07 3:55 ` David Rientjes 2009-07-07 8:01 ` Justin Piszcz 2009-07-19 21:36 ` David Rientjes 2009-07-19 21:36 ` David Rientjes 2009-07-07 0:00 ` [Bug #13649] Bad page state in process with various applications Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 0:00 ` [Bug #13651] Anyone know what happened with PC speaker in 2.6.30? Rafael J. Wysocki 2009-07-07 0:00 ` Rafael J. Wysocki 2009-07-07 19:13 ` Frans Pop 2009-07-07 20:24 ` Rafael J. Wysocki 2009-07-07 20:24 ` Rafael J. Wysocki 2009-07-07 0:01 ` [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Rafael J. Wysocki 2009-07-07 0:01 ` Rafael J. Wysocki 2009-07-07 0:01 ` [Bug #13663] suspend to ram regression (IDE related) Rafael J. Wysocki 2009-07-07 0:01 ` Rafael J. Wysocki 2009-07-07 18:02 ` Etienne Basset 2009-07-07 18:02 ` Etienne Basset 2009-07-07 0:01 ` [Bug #13669] Kernel bug with dock driver Rafael J. Wysocki 2009-07-07 0:01 ` Rafael J. Wysocki 2009-07-07 0:01 ` [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu Rafael J. Wysocki 2009-07-07 0:01 ` Rafael J. Wysocki 2009-07-07 2:49 ` Rob Landley 2009-07-07 11:08 ` Rafael J. Wysocki 2009-07-07 11:08 ` Rafael J. Wysocki 2009-07-07 0:01 ` [Bug #13681] A number of usb Devices causes Oops messages and kernel panics Rafael J. Wysocki 2009-07-07 0:01 ` Rafael J. Wysocki 2009-07-07 0:01 ` [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 Rafael J. Wysocki 2009-07-07 0:01 ` Rafael J. Wysocki 2009-07-07 7:32 ` Oliver Neukum 2009-07-07 7:32 ` Oliver Neukum 2009-07-07 0:01 ` [Bug #13694] i915 phantom TV Rafael J. Wysocki 2009-07-07 0:01 ` Rafael J. Wysocki -- strict thread matches above, loose matches on Subject: below -- 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-25 21:05 ` Rafael J. Wysocki 2009-08-26 6:25 ` Pekka Enberg 2009-08-26 6:25 ` Pekka Enberg 2009-08-26 20:53 ` Rafael J. Wysocki 2009-08-26 20:53 ` Rafael J. Wysocki 2009-08-19 20:36 2.6.31-rc6-git5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki 2009-08-19 20:40 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-08-19 20:40 ` Rafael J. Wysocki 2009-08-09 21:07 2.6.31-rc5-git5: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki 2009-08-09 21:10 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-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-02 19:09 ` Rafael J. Wysocki 2009-07-28 16:10 [PATCH 2.6.31] mac80211: fix suspend Johannes Berg 2009-06-29 0:26 2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30 Rafael J. Wysocki 2009-06-29 0:30 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-06-29 0:30 ` Rafael J. Wysocki 2009-06-29 16:51 ` Larry Finger 2009-06-29 16:51 ` Larry Finger 2009-06-29 23:15 ` Rafael J. Wysocki 2009-06-29 23:15 ` Rafael J. Wysocki 2009-06-29 23:47 ` David Rientjes 2009-06-29 23:47 ` David Rientjes 2009-06-30 2:06 ` Larry Finger 2009-06-30 2:06 ` Larry Finger 2009-06-30 5:47 ` David Rientjes 2009-06-30 6:55 ` Pekka Enberg 2009-06-30 6:55 ` Pekka Enberg 2009-06-30 7:47 ` David Rientjes 2009-06-30 7:47 ` David Rientjes 2009-06-30 8:24 ` Pekka Enberg 2009-06-30 8:24 ` Pekka Enberg 2009-06-30 14:38 ` Larry Finger 2009-06-30 20:25 ` David Rientjes 2009-06-30 20:25 ` David Rientjes 2009-06-30 14:32 ` Christoph Lameter 2009-06-30 14:32 ` Christoph Lameter 2009-06-30 15:01 ` Pekka Enberg 2009-06-30 15:14 ` Christoph Lameter 2009-06-30 15:14 ` Christoph Lameter 2009-06-30 20:04 ` David Rientjes 2009-06-30 20:04 ` David Rientjes 2009-06-30 21:05 ` Christoph Lameter 2009-06-30 21:05 ` Christoph Lameter 2009-06-30 21:15 ` David Rientjes 2009-06-30 21:15 ` David Rientjes 2009-06-30 21:23 ` Christoph Lameter 2009-06-30 21:23 ` Christoph Lameter 2009-06-30 21:52 ` David Rientjes 2009-06-30 21:52 ` David Rientjes 2009-06-30 22:18 ` Christoph Lameter 2009-06-30 22:18 ` Christoph Lameter 2009-07-01 5:53 ` Pekka Enberg 2009-07-02 17:18 ` David Rientjes 2009-07-02 17:18 ` David Rientjes 2009-07-03 7:23 ` Pekka Enberg 2009-07-03 7:23 ` Pekka Enberg 2009-06-07 9:47 2.6.30-rc8-git4: Reported regressions from 2.6.29 Rafael J. Wysocki 2009-06-07 9:52 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-06-07 9:52 ` Rafael J. Wysocki 2009-06-07 13:10 ` Larry Finger 2009-06-07 13:10 ` Larry Finger 2009-06-07 13:40 ` Pekka Enberg 2009-06-07 13:40 ` Pekka Enberg 2009-06-07 14:19 ` Rik van Riel 2009-06-07 14:19 ` Rik van Riel 2009-06-07 14:32 ` Pekka Enberg 2009-06-07 14:32 ` Pekka Enberg 2009-06-07 16:35 ` Larry Finger 2009-06-07 16:35 ` Larry Finger 2009-06-08 8:32 ` KAMEZAWA Hiroyuki 2009-06-08 8:32 ` KAMEZAWA Hiroyuki 2009-06-08 17:20 ` Larry Finger 2009-06-08 17:20 ` Larry Finger 2009-06-08 10:17 ` Mel Gorman 2009-06-08 10:17 ` Mel Gorman 2009-06-08 10:52 ` Pekka Enberg 2009-06-08 10:52 ` Pekka Enberg 2009-06-08 11:03 ` Mel Gorman 2009-06-08 11:03 ` Mel Gorman 2009-06-08 13:58 ` Pekka J Enberg 2009-06-08 13:58 ` Pekka J Enberg 2009-06-08 14:12 ` Mel Gorman 2009-06-08 14:12 ` Mel Gorman 2009-06-08 14:42 ` Christoph Lameter 2009-06-08 14:42 ` Christoph Lameter 2009-06-09 7:06 ` Pekka Enberg 2009-06-09 7:06 ` Pekka Enberg 2009-06-09 7:54 ` David Rientjes 2009-06-09 7:54 ` David Rientjes 2009-06-09 7:58 ` Pekka Enberg 2009-06-09 8:14 ` David Rientjes 2009-06-09 8:14 ` David Rientjes 2009-06-09 8:28 ` Pekka Enberg 2009-06-09 8:28 ` Pekka Enberg 2009-06-10 14:41 ` Larry Finger 2009-06-10 15:44 ` Pekka Enberg 2009-06-10 15:49 ` Pekka Enberg 2009-06-10 15:49 ` Pekka Enberg 2009-06-10 15:52 ` Johannes Berg 2009-06-10 15:52 ` Johannes Berg 2009-06-10 16:06 ` Pekka Enberg 2009-06-10 16:06 ` Pekka Enberg 2009-06-10 16:16 ` Pekka Enberg 2009-06-10 16:16 ` Pekka Enberg 2009-06-10 16:10 ` Larry Finger 2009-06-10 16:10 ` Larry Finger 2009-06-11 14:41 ` Christoph Lameter 2009-06-11 14:41 ` Christoph Lameter 2009-06-11 15:09 ` Pekka Enberg 2009-06-11 15:09 ` Pekka Enberg 2009-06-11 18:41 ` Johannes Berg 2009-06-11 18:41 ` Johannes Berg 2009-06-10 15:56 ` Mel Gorman 2009-06-10 15:56 ` Mel Gorman 2009-06-10 18:03 ` Pekka Enberg 2009-06-10 18:03 ` Pekka Enberg 2009-06-09 7:50 ` Pekka Enberg 2009-06-09 7:50 ` Pekka Enberg 2009-06-08 13:20 ` Rik van Riel 2009-06-08 13:20 ` Rik van Riel 2009-06-08 13:35 ` Mel Gorman 2009-06-08 13:35 ` Mel Gorman 2009-06-08 13:34 ` Larry Finger 2009-05-30 19:29 2.6.30-rc7-git4: Reported regressions from 2.6.29 Rafael J. Wysocki 2009-05-30 19:37 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-05-30 19:37 ` Rafael J. Wysocki 2009-05-24 19:06 2.6.30-rc7: Reported regressions from 2.6.29 Rafael J. Wysocki 2009-05-24 19:11 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-05-24 19:11 ` Rafael J. Wysocki 2009-05-16 19:14 2.6.30-rc6: Reported regressions from 2.6.29 Rafael J. Wysocki 2009-05-16 19:20 ` [Bug #13319] Page allocation failures with b43 and p54usb Rafael J. Wysocki 2009-05-16 19:20 ` Rafael J. Wysocki 2009-05-16 23:36 ` Andrew Morton 2009-05-16 23:36 ` Andrew Morton 2009-05-17 23:16 ` Larry Finger 2009-05-17 23:16 ` Larry Finger 2009-05-18 6:31 ` Pekka Enberg 2009-05-18 6:31 ` Pekka Enberg 2009-05-21 13:21 ` Larry Finger 2009-05-21 13:21 ` Larry Finger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.