* 2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30
@ 2009-06-29 0:26 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* 2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30
@ 2009-06-29 0:26 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ 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-v18Uk5sXZWJeoWH0uzbU5w@public.gmane.org>
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-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
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 (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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-XAri/EZa3C4vJsYlp49lxw@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
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 (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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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-+ZI9xUNit7I@public.gmane.org>
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-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
Date : 2009-06-16 01:27 (13 days old)
References : http://lkml.org/lkml/2009/6/15/630
Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
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-VIXq6x/3rUk@public.gmane.org>
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-2tUql6aCh3Vfq8cQ1yknNg@public.gmane.org>
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-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org>
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-0hYGf3jDe+XrBKCeMvbIDA@public.gmane.org>
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-whZMOeQn8C0@public.gmane.org>
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-VIXq6x/3rUk@public.gmane.org>
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-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org>
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-1vnkWVZi4QaVc3sceRu5cw@public.gmane.org>
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-JGs/UdohzUI@public.gmane.org>
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-K87ZgELTUEPsG83rWm+8vg@public.gmane.org>
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-0pWKB23IDFjrBKCeMvbIDA@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-M3ycANVxPotyL3EAZA59ERCuuivNXqWP@public.gmane.org>
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-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
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 (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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2009-05-31 16:36 (29 days old)
References : http://www.spinics.net/lists/cpufreq/msg00711.html
Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
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 (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-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
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-KKrjLPT3xs0@public.gmane.org>
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 (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-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
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 (41 days old)
Handled-By : Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
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 (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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-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>
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 (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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
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 (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-/w4YWyX8dFk@public.gmane.org>
Date : 2009-05-11 10:08 (49 days old)
Handled-By : Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
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 (59 days old)
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 (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-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
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-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
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 (79 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>
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-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
Date : 2009-06-26 17:40 (3 days old)
References : http://lkml.org/lkml/2009/6/26/242
Handled-By : Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
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-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date : 2009-05-26 15:24 (34 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
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] 211+ messages in thread
* [Bug #13109] High latency on /sys/class/thermal
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:26 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:26 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 (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>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13109] High latency on /sys/class/thermal
@ 2009-06-29 0:26 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:26 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 (79 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] 211+ 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-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (59 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13306] hibernate slow on _second_ run
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ 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
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. 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 (46 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13179] CD-R: wodim intermittent failures
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (69 days old)
References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13119] Trouble with make-install from a NFS mount
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (76 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] 211+ messages in thread
* [Bug #13277] 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (49 days old)
Handled-By : Len Brown <len.brown@intel.com>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13318] AGP doesn't work anymore on nforce2
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (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>
^ permalink raw reply [flat|nested] 211+ 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-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (59 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13119] Trouble with make-install from a NFS mount
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (76 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] 211+ messages in thread
* [Bug #13306] hibernate slow on _second_ run
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ 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
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. 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 (46 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13179] CD-R: wodim intermittent failures
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (69 days old)
References : http://marc.info/?l=linux-kernel&m=124027879214231&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13277] 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (49 days old)
Handled-By : Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13318] AGP doesn't work anymore on nforce2
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ 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] 211+ messages in thread
* [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (42 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
2009-06-29 0:26 ` Rafael J. Wysocki
` (8 preceding siblings ...)
(?)
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (57 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13341] Random Oops at boot at loading ip6tables rules
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (41 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (42 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13341] Random Oops at boot at loading ip6tables rules
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (41 days old)
Handled-By : Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (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>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (37 days old)
References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (38 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13374] reiserfs blocked for more than 120secs
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (37 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] 211+ messages in thread
* [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (38 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (37 days old)
References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13374] reiserfs blocked for more than 120secs
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (37 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] 211+ messages in thread
* [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (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
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected)
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (32 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13424] possible deadlock when doing governor switching
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (29 days old)
References : http://www.spinics.net/lists/cpufreq/msg00711.html
Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13407] adb trackpad disappears after suspend to ram
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (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>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13408] Performance regression in 2.6.30-rc7
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (30 days old)
References : http://lkml.org/lkml/2009/5/30/146
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (34 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] 211+ messages in thread
* [Bug #13424] possible deadlock when doing governor switching
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (29 days old)
References : http://www.spinics.net/lists/cpufreq/msg00711.html
Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected)
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (32 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13408] Performance regression in 2.6.30-rc7
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (30 days old)
References : http://lkml.org/lkml/2009/5/30/146
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13407] adb trackpad disappears after suspend to ram
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (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-KKrjLPT3xs0@public.gmane.org>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (25 days old)
References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13472] Oops with minicom and USB serial
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (24 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] 211+ messages in thread
* [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (25 days old)
References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13472] Oops with minicom and USB serial
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (24 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] 211+ messages in thread
* [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (19 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13512] D43 on 2.6.30 doesn't suspend anymore
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (18 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13475] suspend/hibernate lockdep warning
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (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/
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13512] D43 on 2.6.30 doesn't suspend anymore
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (18 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13475] suspend/hibernate lockdep warning
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (27 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] 211+ messages in thread
* [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (19 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (12 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13518] slab grows with NFS write activity.
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andrew Randrianasulu
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. 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 (17 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13528] au0828: major drop in reception quality between 2.6.29.4 and 2.6.30 on HVR-950q
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jim Faulkner
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. Please verify if it still should
be listed and let me know (either way).
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)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13514] acer_wmi causes stack corruption
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (17 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13514] acer_wmi causes stack corruption
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (17 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13518] slab grows with NFS write activity.
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andrew Randrianasulu
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. 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 (17 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13528] au0828: major drop in reception quality between 2.6.29.4 and 2.6.30 on HVR-950q
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jim Faulkner
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. Please verify if it still should
be listed and let me know (either way).
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-1vnkWVZi4QaVc3sceRu5cw@public.gmane.org>
Date : 2009-06-13 19:34 (16 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
@ 2009-06-29 0:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:30 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 (12 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13621] xfs hangs with assertion failed
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (4 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13558] Tracelog during resume
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (12 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (4 days old)
References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13613] lockups with JFS (inconsistent lock state)
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jan "Yenya" Kasprzak
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. Please verify if it still should
be listed and let me know (either way).
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)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13581] ath9k doesn't work with newer kernels
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (10 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13558] Tracelog during resume
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (12 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (4 days old)
References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13621] xfs hangs with assertion failed
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (4 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13613] lockups with JFS (inconsistent lock state)
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jan "Yenya" Kasprzak
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13613
Subject : lockups with JFS (inconsistent lock state)
Submitter : Jan "Yenya" Kasprzak <kas-0hYGf3jDe+XrBKCeMvbIDA@public.gmane.org>
Date : 2009-06-24 09:35 (5 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13581] ath9k doesn't work with newer kernels
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (10 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13624] usb: wrong autosuspend initialization
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (4 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (2 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13646] warn_on tty_io.c, broken bluetooth
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (10 days old)
References : http://lkml.org/lkml/2009/6/19/187
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (13 days old)
References : http://lkml.org/lkml/2009/6/15/630
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (2 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13624] usb: wrong autosuspend initialization
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (4 days old)
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13646] warn_on tty_io.c, broken bluetooth
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (10 days old)
References : http://lkml.org/lkml/2009/6/19/187
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (13 days old)
References : http://lkml.org/lkml/2009/6/15/630
Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13647] fb/mmap lockdep report.
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (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
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13648] nfsd: page allocation failure
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (7 days old)
References : http://lkml.org/lkml/2009/6/22/309
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13649] Bad page state in process with various applications
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (9 days old)
References : http://marc.info/?l=linux-mm&m=124551168828090&w=4
Handled-By : Mel Gorman <mel@csn.ul.ie>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13648] nfsd: page allocation failure
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (7 days old)
References : http://lkml.org/lkml/2009/6/22/309
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13647] fb/mmap lockdep report.
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (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
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13649] Bad page state in process with various applications
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (9 days old)
References : http://marc.info/?l=linux-mm&m=124551168828090&w=4
Handled-By : Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13651] Anyone know what happened with PC speaker in 2.6.30?
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (14 days old)
References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu.
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (2 days old)
References : http://lkml.org/lkml/2009/6/27/159
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (2 days old)
References : http://lkml.org/lkml/2009/6/27/95
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13663] suspend to ram regression (IDE related)
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (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/
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13651] Anyone know what happened with PC speaker in 2.6.30?
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (14 days old)
References : http://marc.info/?l=linux-kernel&m=124507695427817&w=4
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13663] suspend to ram regression (IDE related)
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (3 days old)
References : http://lkml.org/lkml/2009/6/26/242
Handled-By : Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/32719/
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (2 days old)
References : http://lkml.org/lkml/2009/6/27/95
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu.
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (2 days old)
References : http://lkml.org/lkml/2009/6/27/159
^ permalink raw reply [flat|nested] 211+ messages in thread
* [Bug #13669] Kernel bug with dock driver
2009-06-29 0:26 ` Rafael J. Wysocki
@ 2009-06-29 0:31 ` Rafael J. Wysocki
-1 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (15 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] 211+ messages in thread
* [Bug #13669] Kernel bug with dock driver
@ 2009-06-29 0:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 0:31 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 (15 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] 211+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching
2009-06-29 0:30 ` Rafael J. Wysocki
@ 2009-06-29 1:25 ` Mathieu Desnoyers
-1 siblings, 0 replies; 211+ messages in thread
From: Mathieu Desnoyers @ 2009-06-29 1:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Shaohua Li,
Venkatesh Pallipadi
* 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).
>
Yep, it still exists. Venkatesh Pallipadi from Intel is working on it.
We need to figure out a proper way to fix policy rwlock vs dbs_mutex vs
timer mutex dependency.
Mathieu
>
> 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>
>
>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching
@ 2009-06-29 1:25 ` Mathieu Desnoyers
0 siblings, 0 replies; 211+ messages in thread
From: Mathieu Desnoyers @ 2009-06-29 1:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Shaohua Li,
Venkatesh Pallipadi
* 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).
>
Yep, it still exists. Venkatesh Pallipadi from Intel is working on it.
We need to figure out a proper way to fix policy rwlock vs dbs_mutex vs
timer mutex dependency.
Mathieu
>
> 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 (29 days old)
> References : http://www.spinics.net/lists/cpufreq/msg00711.html
> 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] 211+ messages in thread
* Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
2009-06-29 0:30 ` Rafael J. Wysocki
@ 2009-06-29 3:27 ` Jos van Wolput
-1 siblings, 0 replies; 211+ messages in thread
From: Jos van Wolput @ 2009-06-29 3:27 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554
> Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
> Submitter : Jos van Wolput <wolput@onsneteindhoven.nl>
> Date : 2009-06-17 06:28 (12 days old)
>
>
>
>
Yes, it still should be listed, KMS doesn't work, at least on my system.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
@ 2009-06-29 3:27 ` Jos van Wolput
0 siblings, 0 replies; 211+ messages in thread
From: Jos van Wolput @ 2009-06-29 3:27 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554
> Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
> Submitter : Jos van Wolput <wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org>
> Date : 2009-06-17 06:28 (12 days old)
>
>
>
>
Yes, it still should be listed, KMS doesn't work, at least on my system.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13512] D43 on 2.6.30 doesn't suspend anymore
2009-06-29 0:30 ` Rafael J. Wysocki
@ 2009-06-29 6:21 ` Daniel Smolik
-1 siblings, 0 replies; 211+ messages in thread
From: Daniel Smolik @ 2009-06-29 6:21 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
Rafael J. affected napsal(a):
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30. 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 (18 days old)
>
>
>
Yes problem still exists. I now bitsecting and I am near to find
affected patch.
Regards
Dan
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13512] D43 on 2.6.30 doesn't suspend anymore
@ 2009-06-29 6:21 ` Daniel Smolik
0 siblings, 0 replies; 211+ messages in thread
From: Daniel Smolik @ 2009-06-29 6:21 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
Rafael J. affected napsal(a):
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30. 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 (18 days old)
>
>
>
Yes problem still exists. I now bitsecting and I am near to find
affected patch.
Regards
Dan
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-06-29 0:31 ` Rafael J. Wysocki
(?)
@ 2009-06-29 10:29 ` Etienne Basset
2009-06-29 10:37 ` David Miller
-1 siblings, 1 reply; 211+ messages in thread
From: Etienne Basset @ 2009-06-29 10:29 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 (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/
>
>
>
yes, patch is not yet upstream;
2.6.31-rc1 + bart patch resumes from STR
current git + bart patch resume from STR fails, STR seems to have been broken again
(i was confident that the post-rc1 MCE fixes would correct the fact that computer hangs
a few minutes after resume, but computer doesn't resume at all)
Etienne
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-06-29 10:29 ` Etienne Basset
@ 2009-06-29 10:37 ` David Miller
2009-06-29 15:51 ` Etienne Basset
0 siblings, 1 reply; 211+ messages in thread
From: David Miller @ 2009-06-29 10:37 UTC (permalink / raw)
To: etienne.basset
Cc: rjw, linux-kernel, kernel-testers, bzolnier, jeff.chua.linux
From: Etienne Basset <etienne.basset@numericable.fr>
Date: Mon, 29 Jun 2009 12:29:09 +0200
> yes, patch is not yet upstream;
I'll take care of pushing this around today.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-06-29 15:51 ` Etienne Basset
0 siblings, 0 replies; 211+ messages in thread
From: Etienne Basset @ 2009-06-29 15:51 UTC (permalink / raw)
To: David Miller; +Cc: rjw, linux-kernel, kernel-testers, bzolnier, jeff.chua.linux
David Miller wrote:
> From: Etienne Basset <etienne.basset@numericable.fr>
> Date: Mon, 29 Jun 2009 12:29:09 +0200
>
>> yes, patch is not yet upstream;
>
> I'll take care of pushing this around today.
>
Hi,
thank you ;
i ran a new bisection to identify the commit that cause pain after -rc1
etienne@etienne-desktop:~/linux-2.6$ git bisect good
a1317f714af7aed60ddc182d0122477cbe36ee9b is first bad commit
commit a1317f714af7aed60ddc182d0122477cbe36ee9b
Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Tue Jun 23 23:52:17 2009 -0700
ide: improve handling of Power Management requests
Make hwif->rq point to PM request during PM sequence and do not allow
any other types of requests to slip in (the old comment was never correct
as there should be no such requests generated during PM sequence).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
To have STR/resume work with current git, I have to :
1) apply Bart's patch
2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
thanks
Etienne
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-06-29 15:51 ` Etienne Basset
0 siblings, 0 replies; 211+ messages in thread
From: Etienne Basset @ 2009-06-29 15:51 UTC (permalink / raw)
To: David Miller
Cc: rjw-KKrjLPT3xs0, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
bzolnier-Re5JQEeQqe8AvxtiuMwx3w,
jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w
David Miller wrote:
> From: Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> Date: Mon, 29 Jun 2009 12:29:09 +0200
>
>> yes, patch is not yet upstream;
>
> I'll take care of pushing this around today.
>
Hi,
thank you ;
i ran a new bisection to identify the commit that cause pain after -rc1
etienne@etienne-desktop:~/linux-2.6$ git bisect good
a1317f714af7aed60ddc182d0122477cbe36ee9b is first bad commit
commit a1317f714af7aed60ddc182d0122477cbe36ee9b
Author: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue Jun 23 23:52:17 2009 -0700
ide: improve handling of Power Management requests
Make hwif->rq point to PM request during PM sequence and do not allow
any other types of requests to slip in (the old comment was never correct
as there should be no such requests generated during PM sequence).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
To have STR/resume work with current git, I have to :
1) apply Bart's patch
2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
thanks
Etienne
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-06-29 16:21 ` Jeff Chua
0 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-06-29 16:21 UTC (permalink / raw)
To: Etienne Basset; +Cc: David Miller, rjw, linux-kernel, kernel-testers, bzolnier
On Mon, Jun 29, 2009 at 11:51 PM, Etienne
Basset<etienne.basset@numericable.fr> wrote:
> i ran a new bisection to identify the commit that cause pain after -rc1
> commit a1317f714af7aed60ddc182d0122477cbe36ee9b
> To have STR/resume work with current git, I have to :
> 1) apply Bart's patch
> 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
I just tried, and it "seems" to work. Will try a few more cycles.
Thanks,
Jeff.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-06-29 16:21 ` Jeff Chua
0 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-06-29 16:21 UTC (permalink / raw)
To: Etienne Basset
Cc: David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
bzolnier-Re5JQEeQqe8AvxtiuMwx3w
On Mon, Jun 29, 2009 at 11:51 PM, Etienne
Basset<etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
> i ran a new bisection to identify the commit that cause pain after -rc1
> commit a1317f714af7aed60ddc182d0122477cbe36ee9b
> To have STR/resume work with current git, I have to :
> 1) apply Bart's patch
> 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
I just tried, and it "seems" to work. Will try a few more cycles.
Thanks,
Jeff.
^ permalink raw reply [flat|nested] 211+ 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; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 16:51 ` Larry Finger
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-06-29 17:45 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-06-29 17:45 UTC (permalink / raw)
To: Etienne Basset
Cc: David Miller, rjw, linux-kernel, kernel-testers, jeff.chua.linux
On Monday 29 June 2009 17:51:35 Etienne Basset wrote:
> David Miller wrote:
> > From: Etienne Basset <etienne.basset@numericable.fr>
> > Date: Mon, 29 Jun 2009 12:29:09 +0200
> >
> >> yes, patch is not yet upstream;
> >
> > I'll take care of pushing this around today.
> >
> Hi,
>
> thank you ;
> i ran a new bisection to identify the commit that cause pain after -rc1
>
> etienne@etienne-desktop:~/linux-2.6$ git bisect good
> a1317f714af7aed60ddc182d0122477cbe36ee9b is first bad commit
Thanks for finding it.
Dave, please just revert this patch (it wasn't meant for Linus' tree anyway).
> commit a1317f714af7aed60ddc182d0122477cbe36ee9b
> Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Tue Jun 23 23:52:17 2009 -0700
>
> ide: improve handling of Power Management requests
>
> Make hwif->rq point to PM request during PM sequence and do not allow
> any other types of requests to slip in (the old comment was never correct
> as there should be no such requests generated during PM sequence).
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> To have STR/resume work with current git, I have to :
> 1) apply Bart's patch
> 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
>
> thanks
> Etienne
>
>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-06-29 17:45 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-06-29 17:45 UTC (permalink / raw)
To: Etienne Basset
Cc: David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w
On Monday 29 June 2009 17:51:35 Etienne Basset wrote:
> David Miller wrote:
> > From: Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> > Date: Mon, 29 Jun 2009 12:29:09 +0200
> >
> >> yes, patch is not yet upstream;
> >
> > I'll take care of pushing this around today.
> >
> Hi,
>
> thank you ;
> i ran a new bisection to identify the commit that cause pain after -rc1
>
> etienne@etienne-desktop:~/linux-2.6$ git bisect good
> a1317f714af7aed60ddc182d0122477cbe36ee9b is first bad commit
Thanks for finding it.
Dave, please just revert this patch (it wasn't meant for Linus' tree anyway).
> commit a1317f714af7aed60ddc182d0122477cbe36ee9b
> Author: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Tue Jun 23 23:52:17 2009 -0700
>
> ide: improve handling of Power Management requests
>
> Make hwif->rq point to PM request during PM sequence and do not allow
> any other types of requests to slip in (the old comment was never correct
> as there should be no such requests generated during PM sequence).
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>
> To have STR/resume work with current git, I have to :
> 1) apply Bart's patch
> 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
>
> thanks
> Etienne
>
>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching
2009-06-29 1:25 ` Mathieu Desnoyers
@ 2009-06-29 18:37 ` Pallipadi, Venkatesh
-1 siblings, 0 replies; 211+ messages in thread
From: Pallipadi, Venkatesh @ 2009-06-29 18:37 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Li, Shaohua, davej
On Sun, 2009-06-28 at 18:25 -0700, Mathieu Desnoyers wrote:
> * 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).
> >
>
> Yep, it still exists. Venkatesh Pallipadi from Intel is working on it.
> We need to figure out a proper way to fix policy rwlock vs dbs_mutex vs
> timer mutex dependency.
>
Yes. Still working on it. I thought I had a fix for this. But, over the
weekend test run resulted in a WARN_ON with sysfs_remove_group as below.
Looks like I need a day or two more to work through the web of locks
here..
Thanks,
Venki
[10412.466195] ------------[ cut here ]------------
[10412.466201] WARNING:
at /home/venkip/src/linus/linux-2.6/fs/sysfs/group.c:138
sysfs_remove_group+0x3e/0xa3()
[10412.466204] Hardware name: Santa Rosa platform
[10412.466206] sysfs group c16df3b0 not found for kobject 'cpufreq'
[10412.466207] Modules linked in:
[10412.466210] Pid: 20609, comm: write_syscpufre Not tainted 2.6.31-rc1
#195
[10412.466212] Call Trace:
[10412.466217] [<c102a0a4>] warn_slowpath_common+0x60/0x90
[10412.466220] [<c102a108>] warn_slowpath_fmt+0x24/0x27
[10412.466223] [<c10e0422>] sysfs_remove_group+0x3e/0xa3
[10412.466227] [<c131b7fc>] cpufreq_governor_dbs+0x1f7/0x25b
[10412.466231] [<c1319469>] __cpufreq_governor+0x7c/0xb3
[10412.466234] [<c1319608>] __cpufreq_set_policy+0x13f/0x1c3
[10412.466238] [<c1319e74>] store_scaling_governor+0x18a/0x1b2
[10412.466241] [<c131aa50>] ? handle_update+0x0/0x28
[10412.466244] [<c131a2a5>] ? lock_policy_rwsem_write+0x33/0x5b
[10412.466247] [<c1319cea>] ? store_scaling_governor+0x0/0x1b2
[10412.466250] [<c131a942>] store+0x48/0x61
[10412.466254] [<c10de532>] sysfs_write_file+0xb4/0xdf
[10412.466265] [<c10de47e>] ? sysfs_write_file+0x0/0xdf
[10412.466269] [<c10a0172>] vfs_write+0x84/0xdf
[10412.466272] [<c10a0266>] sys_write+0x3b/0x60
[10412.466276] [<c1002a04>] sysenter_do_call+0x12/0x22
[10412.466278] ---[ end trace 31a730d96cbc1841 ]---
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching
@ 2009-06-29 18:37 ` Pallipadi, Venkatesh
0 siblings, 0 replies; 211+ messages in thread
From: Pallipadi, Venkatesh @ 2009-06-29 18:37 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Li, Shaohua, davej-H+wXaHxf7aLQT0dZR+AlfA
On Sun, 2009-06-28 at 18:25 -0700, Mathieu Desnoyers wrote:
> * 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).
> >
>
> Yep, it still exists. Venkatesh Pallipadi from Intel is working on it.
> We need to figure out a proper way to fix policy rwlock vs dbs_mutex vs
> timer mutex dependency.
>
Yes. Still working on it. I thought I had a fix for this. But, over the
weekend test run resulted in a WARN_ON with sysfs_remove_group as below.
Looks like I need a day or two more to work through the web of locks
here..
Thanks,
Venki
[10412.466195] ------------[ cut here ]------------
[10412.466201] WARNING:
at /home/venkip/src/linus/linux-2.6/fs/sysfs/group.c:138
sysfs_remove_group+0x3e/0xa3()
[10412.466204] Hardware name: Santa Rosa platform
[10412.466206] sysfs group c16df3b0 not found for kobject 'cpufreq'
[10412.466207] Modules linked in:
[10412.466210] Pid: 20609, comm: write_syscpufre Not tainted 2.6.31-rc1
#195
[10412.466212] Call Trace:
[10412.466217] [<c102a0a4>] warn_slowpath_common+0x60/0x90
[10412.466220] [<c102a108>] warn_slowpath_fmt+0x24/0x27
[10412.466223] [<c10e0422>] sysfs_remove_group+0x3e/0xa3
[10412.466227] [<c131b7fc>] cpufreq_governor_dbs+0x1f7/0x25b
[10412.466231] [<c1319469>] __cpufreq_governor+0x7c/0xb3
[10412.466234] [<c1319608>] __cpufreq_set_policy+0x13f/0x1c3
[10412.466238] [<c1319e74>] store_scaling_governor+0x18a/0x1b2
[10412.466241] [<c131aa50>] ? handle_update+0x0/0x28
[10412.466244] [<c131a2a5>] ? lock_policy_rwsem_write+0x33/0x5b
[10412.466247] [<c1319cea>] ? store_scaling_governor+0x0/0x1b2
[10412.466250] [<c131a942>] store+0x48/0x61
[10412.466254] [<c10de532>] sysfs_write_file+0xb4/0xdf
[10412.466265] [<c10de47e>] ? sysfs_write_file+0x0/0xdf
[10412.466269] [<c10a0172>] vfs_write+0x84/0xdf
[10412.466272] [<c10a0266>] sys_write+0x3b/0x60
[10412.466276] [<c1002a04>] sysenter_do_call+0x12/0x22
[10412.466278] ---[ end trace 31a730d96cbc1841 ]---
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching
@ 2009-06-29 19:05 ` Mathieu Desnoyers
0 siblings, 0 replies; 211+ messages in thread
From: Mathieu Desnoyers @ 2009-06-29 19:05 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Li, Shaohua, davej
* Pallipadi, Venkatesh (venkatesh.pallipadi@intel.com) wrote:
> On Sun, 2009-06-28 at 18:25 -0700, Mathieu Desnoyers wrote:
> > * 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).
> > >
> >
> > Yep, it still exists. Venkatesh Pallipadi from Intel is working on it.
> > We need to figure out a proper way to fix policy rwlock vs dbs_mutex vs
> > timer mutex dependency.
> >
>
> Yes. Still working on it. I thought I had a fix for this. But, over the
> weekend test run resulted in a WARN_ON with sysfs_remove_group as below.
> Looks like I need a day or two more to work through the web of locks
> here..
>
A quick fix I thought about is to add a mutex to cpufreq.c.
This mutex would be taken outside of the rwlock write lock each time
this lock is taken in cpufreq.c.
This mutex would also be taken from the ondemand and conservator module
sysfs operations.
We remove the dbs_mutexes, given they would now be replaced by this
new cpufreq.c mutex.
Note that the GOV_STOP call should be done while this new mutex is held,
but the rwlock is _not_ held.
I did not implement it because cpufreq.c:cpufreq_add_dev() first needs a
big cleanup for the error handling paths. They are currently completely
bogus and I don't want to add a lock into code that is not currently
correct.
If you find time to do this cleanup and lock implementation, I'll be
glad to review it and provide advice.
Thanks,
Mathieu
> Thanks,
> Venki
>
> [10412.466195] ------------[ cut here ]------------
> [10412.466201] WARNING:
> at /home/venkip/src/linus/linux-2.6/fs/sysfs/group.c:138
> sysfs_remove_group+0x3e/0xa3()
> [10412.466204] Hardware name: Santa Rosa platform
> [10412.466206] sysfs group c16df3b0 not found for kobject 'cpufreq'
> [10412.466207] Modules linked in:
> [10412.466210] Pid: 20609, comm: write_syscpufre Not tainted 2.6.31-rc1
> #195
> [10412.466212] Call Trace:
> [10412.466217] [<c102a0a4>] warn_slowpath_common+0x60/0x90
> [10412.466220] [<c102a108>] warn_slowpath_fmt+0x24/0x27
> [10412.466223] [<c10e0422>] sysfs_remove_group+0x3e/0xa3
> [10412.466227] [<c131b7fc>] cpufreq_governor_dbs+0x1f7/0x25b
> [10412.466231] [<c1319469>] __cpufreq_governor+0x7c/0xb3
> [10412.466234] [<c1319608>] __cpufreq_set_policy+0x13f/0x1c3
> [10412.466238] [<c1319e74>] store_scaling_governor+0x18a/0x1b2
> [10412.466241] [<c131aa50>] ? handle_update+0x0/0x28
> [10412.466244] [<c131a2a5>] ? lock_policy_rwsem_write+0x33/0x5b
> [10412.466247] [<c1319cea>] ? store_scaling_governor+0x0/0x1b2
> [10412.466250] [<c131a942>] store+0x48/0x61
> [10412.466254] [<c10de532>] sysfs_write_file+0xb4/0xdf
> [10412.466265] [<c10de47e>] ? sysfs_write_file+0x0/0xdf
> [10412.466269] [<c10a0172>] vfs_write+0x84/0xdf
> [10412.466272] [<c10a0266>] sys_write+0x3b/0x60
> [10412.466276] [<c1002a04>] sysenter_do_call+0x12/0x22
> [10412.466278] ---[ end trace 31a730d96cbc1841 ]---
>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13424] possible deadlock when doing governor switching
@ 2009-06-29 19:05 ` Mathieu Desnoyers
0 siblings, 0 replies; 211+ messages in thread
From: Mathieu Desnoyers @ 2009-06-29 19:05 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Li, Shaohua, davej-H+wXaHxf7aLQT0dZR+AlfA
* Pallipadi, Venkatesh (venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org) wrote:
> On Sun, 2009-06-28 at 18:25 -0700, Mathieu Desnoyers wrote:
> > * 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).
> > >
> >
> > Yep, it still exists. Venkatesh Pallipadi from Intel is working on it.
> > We need to figure out a proper way to fix policy rwlock vs dbs_mutex vs
> > timer mutex dependency.
> >
>
> Yes. Still working on it. I thought I had a fix for this. But, over the
> weekend test run resulted in a WARN_ON with sysfs_remove_group as below.
> Looks like I need a day or two more to work through the web of locks
> here..
>
A quick fix I thought about is to add a mutex to cpufreq.c.
This mutex would be taken outside of the rwlock write lock each time
this lock is taken in cpufreq.c.
This mutex would also be taken from the ondemand and conservator module
sysfs operations.
We remove the dbs_mutexes, given they would now be replaced by this
new cpufreq.c mutex.
Note that the GOV_STOP call should be done while this new mutex is held,
but the rwlock is _not_ held.
I did not implement it because cpufreq.c:cpufreq_add_dev() first needs a
big cleanup for the error handling paths. They are currently completely
bogus and I don't want to add a lock into code that is not currently
correct.
If you find time to do this cleanup and lock implementation, I'll be
glad to review it and provide advice.
Thanks,
Mathieu
> Thanks,
> Venki
>
> [10412.466195] ------------[ cut here ]------------
> [10412.466201] WARNING:
> at /home/venkip/src/linus/linux-2.6/fs/sysfs/group.c:138
> sysfs_remove_group+0x3e/0xa3()
> [10412.466204] Hardware name: Santa Rosa platform
> [10412.466206] sysfs group c16df3b0 not found for kobject 'cpufreq'
> [10412.466207] Modules linked in:
> [10412.466210] Pid: 20609, comm: write_syscpufre Not tainted 2.6.31-rc1
> #195
> [10412.466212] Call Trace:
> [10412.466217] [<c102a0a4>] warn_slowpath_common+0x60/0x90
> [10412.466220] [<c102a108>] warn_slowpath_fmt+0x24/0x27
> [10412.466223] [<c10e0422>] sysfs_remove_group+0x3e/0xa3
> [10412.466227] [<c131b7fc>] cpufreq_governor_dbs+0x1f7/0x25b
> [10412.466231] [<c1319469>] __cpufreq_governor+0x7c/0xb3
> [10412.466234] [<c1319608>] __cpufreq_set_policy+0x13f/0x1c3
> [10412.466238] [<c1319e74>] store_scaling_governor+0x18a/0x1b2
> [10412.466241] [<c131aa50>] ? handle_update+0x0/0x28
> [10412.466244] [<c131a2a5>] ? lock_policy_rwsem_write+0x33/0x5b
> [10412.466247] [<c1319cea>] ? store_scaling_governor+0x0/0x1b2
> [10412.466250] [<c131a942>] store+0x48/0x61
> [10412.466254] [<c10de532>] sysfs_write_file+0xb4/0xdf
> [10412.466265] [<c10de47e>] ? sysfs_write_file+0x0/0xdf
> [10412.466269] [<c10a0172>] vfs_write+0x84/0xdf
> [10412.466272] [<c10a0266>] sys_write+0x3b/0x60
> [10412.466276] [<c1002a04>] sysenter_do_call+0x12/0x22
> [10412.466278] ---[ end trace 31a730d96cbc1841 ]---
>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: [Bug #13512] D43 on 2.6.30 doesn't suspend anymore
@ 2009-06-29 23:20 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 23:20 UTC (permalink / raw)
To: Daniel Smolik; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Monday 29 June 2009, Daniel Smolik wrote:
> Rafael J. affected napsal(a):
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30. 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 (18 days old)
> >
> >
> >
> Yes problem still exists. I now bitsecting and I am near to find
> affected patch.
Thanks for the update.
Best,
Rafael
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13512] D43 on 2.6.30 doesn't suspend anymore
@ 2009-06-29 23:20 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 23:20 UTC (permalink / raw)
To: Daniel Smolik; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Monday 29 June 2009, Daniel Smolik wrote:
> Rafael J. affected napsal(a):
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30. 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 (18 days old)
> >
> >
> >
> Yes problem still exists. I now bitsecting and I am near to find
> affected patch.
Thanks for the update.
Best,
Rafael
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
@ 2009-06-29 23:24 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 23:24 UTC (permalink / raw)
To: wolput; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Monday 29 June 2009, Jos van Wolput wrote:
>
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30. Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554
> > Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
> > Submitter : Jos van Wolput <wolput@onsneteindhoven.nl>
> > Date : 2009-06-17 06:28 (12 days old)
> >
> >
> >
> >
> Yes, it still should be listed, KMS doesn't work, at least on my system.
Thanks for the update, but I'm afraid we won't have enough information to
debug this issue.
Best,
Rafael
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
@ 2009-06-29 23:24 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-29 23:24 UTC (permalink / raw)
To: wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh
Cc: Linux Kernel Mailing List, Kernel Testers List
On Monday 29 June 2009, Jos van Wolput wrote:
>
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30. Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554
> > Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
> > Submitter : Jos van Wolput <wolput-kN7GrHn7egj0B9fh5IxImPP6llvjuJOh@public.gmane.org>
> > Date : 2009-06-17 06:28 (12 days old)
> >
> >
> >
> >
> Yes, it still should be listed, KMS doesn't work, at least on my system.
Thanks for the update, but I'm afraid we won't have enough information to
debug this issue.
Best,
Rafael
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 23:47 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-29 23:47 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure
2009-06-29 0:31 ` Rafael J. Wysocki
(?)
@ 2009-06-30 0:02 ` David Rientjes
2009-06-30 8:05 ` Justin Piszcz
-1 siblings, 1 reply; 211+ messages in thread
From: David Rientjes @ 2009-06-30 0:02 UTC (permalink / raw)
To: Justin Piszcz
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Rik van Riel
On Mon, 29 Jun 2009, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648
> Subject : nfsd: page allocation failure
> Submitter : Justin Piszcz <jpiszcz@lucidpixels.com>
> Date : 2009-06-22 12:08 (7 days old)
> References : http://lkml.org/lkml/2009/6/22/309
>
I'd be interested to hear from Justin if reducing
/proc/sys/vm/dirty_background_ratio as I earlier suggested helps.
ZONE_NORMAL isn't much larger than ZONE_DMA32 on this machine and both
lowmem zones have an abundance of free memory which suggests pdflush's
ratio isn't being met to commence background writeout while at the same
time ZONE_NORMAL is being depleted as the result of constant nfs
GFP_ATOMIC allocations that cannot try direct reclaim.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
2009-06-29 0:31 ` Rafael J. Wysocki
(?)
@ 2009-06-30 0:40 ` Johannes Stezenbach
2009-06-30 12:48 ` Rafael J. Wysocki
-1 siblings, 1 reply; 211+ messages in thread
From: Johannes Stezenbach @ 2009-06-30 0:40 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
On Mon, Jun 29, 2009 at 02:31:01AM +0200, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644
> Subject : hibernation/swsusp lockup due to acpi-cpufreq
> Submitter : Johannes Stezenbach <js@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>
I tested v2.6.31-rc1-228-g2bfdd79 and the bug is still there.
It actually got worse, the local_irq_save/restore workaround
in kernel/up-c (http://lkml.org/lkml/2009/6/16/333) doesn't fix it
anymore, it hangs at suspend before writing out the image.
With the up.c workaround (including a
WARN_ON_ONCE(irqs_disabled() && !oops_in_progress);)
applied and no_console_suspend I captured the attached
output using a crappy webcam. (Without the workaround
there is a huge spew of warnings about irqs enabled
unexpectedly.) I guess the interesting part is
pm_op(): pci_pm_thaw returns -16
PM: Device 0000:00:00.0 failed to thaw: error -16
(PCI info is in http://lkml.org/lkml/2009/6/15/630)
Johannes
[-- Attachment #2: suspend-crash.jpg --]
[-- Type: image/jpeg, Size: 31083 bytes --]
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 2:06 ` Larry Finger
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 2:06 ` Larry Finger
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 6:55 ` Pekka Enberg
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 6:55 ` Pekka Enberg
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 7:47 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 7:47 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure
@ 2009-06-30 8:05 ` Justin Piszcz
0 siblings, 0 replies; 211+ messages in thread
From: Justin Piszcz @ 2009-06-30 8:05 UTC (permalink / raw)
To: David Rientjes
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Rik van Riel
On Mon, 29 Jun 2009, David Rientjes wrote:
> On Mon, 29 Jun 2009, Rafael J. Wysocki wrote:
>
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.29 and 2.6.30.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.29 and 2.6.30. Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648
>> Subject : nfsd: page allocation failure
>> Submitter : Justin Piszcz <jpiszcz@lucidpixels.com>
>> Date : 2009-06-22 12:08 (7 days old)
>> References : http://lkml.org/lkml/2009/6/22/309
>>
>
> I'd be interested to hear from Justin if reducing
> /proc/sys/vm/dirty_background_ratio as I earlier suggested helps.
>
> ZONE_NORMAL isn't much larger than ZONE_DMA32 on this machine and both
> lowmem zones have an abundance of free memory which suggests pdflush's
> ratio isn't being met to commence background writeout while at the same
> time ZONE_NORMAL is being depleted as the result of constant nfs
> GFP_ATOMIC allocations that cannot try direct reclaim.
>
Hello,
http://patchwork.kernel.org/patch/30960/
"It's funny, though, that the problem that originally started this thread
was quickly diagnosed because of these messages. As far as I know, my
suggestion to increase /proc/sys/vm/dirty_background_ratio to kick pdflush
earlier has prevented the slab allocation failures and not required
delayed acks for nfsd."
--
The current value is 10, what value do you suggest I try?
$ cat /proc/sys/vm/dirty_background_ratio
10
Justin.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure
@ 2009-06-30 8:05 ` Justin Piszcz
0 siblings, 0 replies; 211+ messages in thread
From: Justin Piszcz @ 2009-06-30 8:05 UTC (permalink / raw)
To: David Rientjes
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Rik van Riel
On Mon, 29 Jun 2009, David Rientjes wrote:
> On Mon, 29 Jun 2009, Rafael J. Wysocki wrote:
>
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.29 and 2.6.30.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.29 and 2.6.30. Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648
>> Subject : nfsd: page allocation failure
>> Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
>> Date : 2009-06-22 12:08 (7 days old)
>> References : http://lkml.org/lkml/2009/6/22/309
>>
>
> I'd be interested to hear from Justin if reducing
> /proc/sys/vm/dirty_background_ratio as I earlier suggested helps.
>
> ZONE_NORMAL isn't much larger than ZONE_DMA32 on this machine and both
> lowmem zones have an abundance of free memory which suggests pdflush's
> ratio isn't being met to commence background writeout while at the same
> time ZONE_NORMAL is being depleted as the result of constant nfs
> GFP_ATOMIC allocations that cannot try direct reclaim.
>
Hello,
http://patchwork.kernel.org/patch/30960/
"It's funny, though, that the problem that originally started this thread
was quickly diagnosed because of these messages. As far as I know, my
suggestion to increase /proc/sys/vm/dirty_background_ratio to kick pdflush
earlier has prevented the slab allocation failures and not required
delayed acks for nfsd."
--
The current value is 10, what value do you suggest I try?
$ cat /proc/sys/vm/dirty_background_ratio
10
Justin.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 8:24 ` Pekka Enberg
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 8:24 ` Pekka Enberg
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure
@ 2009-06-30 8:48 ` David Rientjes
0 siblings, 0 replies; 211+ messages in thread
From: David Rientjes @ 2009-06-30 8:48 UTC (permalink / raw)
To: Justin Piszcz
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Rik van Riel
On Tue, 30 Jun 2009, Justin Piszcz wrote:
> The current value is 10, what value do you suggest I try?
>
> $ cat /proc/sys/vm/dirty_background_ratio
> 10
>
Looking at your initial bug report, it doesn't look like a background
writeout issue:
[415964.022375] Active_anon:154810 active_file:131162 inactive_anon:33447
[415964.022375] inactive_file:690987 unevictable:0 dirty:112116 writeback:0 unstable:0
[415964.022375] free:8662 slab:965366 mapped:9316 pagetables:4618 bounce:0
[415964.022375] DMA free:9692kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:8668kB pages_scanned:0 all_unreclaimable? yes
[415964.022375] lowmem_reserve[]: 0 3246 7980 7980
[415964.022375] DMA32 free:21312kB min:6656kB low:8320kB high:9984kB active_anon:118464kB inactive_anon:23908kB active_file:174708kB inactive_file:1206812kB unevictable:0kB present:3324312kB pages_scanned:0 all_unreclaimable? no
[415964.022375] lowmem_reserve[]: 0 0 4734 4734
[415964.022375] Normal free:3644kB min:9708kB low:12132kB high:14560kB active_anon:500776kB inactive_anon:109880kB active_file:349940kB inactive_file:1557136kB unevictable:0kB present:4848000kB pages_scanned:0 all_unreclaimable? no
[415964.022375] lowmem_reserve[]: 0 0 0 0
...
[415964.022375] 2277376 pages RAM
Ignore the all_unreclaimable information, this is a GFP_ATOMIC allocation
so we can't reclaim.
You have an 8G machine and only 437K is dirty (which is why pdflush hasn't
kicked in yet). You do have over 3.5G of slab allocated, however.
This appears related to http://bugzilla.kernel.org/show_bug.cgi?id=13518,
but that could be confirmed with slabtop.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13648] nfsd: page allocation failure
@ 2009-06-30 8:48 ` David Rientjes
0 siblings, 0 replies; 211+ messages in thread
From: David Rientjes @ 2009-06-30 8:48 UTC (permalink / raw)
To: Justin Piszcz
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, Rik van Riel
On Tue, 30 Jun 2009, Justin Piszcz wrote:
> The current value is 10, what value do you suggest I try?
>
> $ cat /proc/sys/vm/dirty_background_ratio
> 10
>
Looking at your initial bug report, it doesn't look like a background
writeout issue:
[415964.022375] Active_anon:154810 active_file:131162 inactive_anon:33447
[415964.022375] inactive_file:690987 unevictable:0 dirty:112116 writeback:0 unstable:0
[415964.022375] free:8662 slab:965366 mapped:9316 pagetables:4618 bounce:0
[415964.022375] DMA free:9692kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:8668kB pages_scanned:0 all_unreclaimable? yes
[415964.022375] lowmem_reserve[]: 0 3246 7980 7980
[415964.022375] DMA32 free:21312kB min:6656kB low:8320kB high:9984kB active_anon:118464kB inactive_anon:23908kB active_file:174708kB inactive_file:1206812kB unevictable:0kB present:3324312kB pages_scanned:0 all_unreclaimable? no
[415964.022375] lowmem_reserve[]: 0 0 4734 4734
[415964.022375] Normal free:3644kB min:9708kB low:12132kB high:14560kB active_anon:500776kB inactive_anon:109880kB active_file:349940kB inactive_file:1557136kB unevictable:0kB present:4848000kB pages_scanned:0 all_unreclaimable? no
[415964.022375] lowmem_reserve[]: 0 0 0 0
...
[415964.022375] 2277376 pages RAM
Ignore the all_unreclaimable information, this is a GFP_ATOMIC allocation
so we can't reclaim.
You have an 8G machine and only 437K is dirty (which is why pdflush hasn't
kicked in yet). You do have over 3.5G of slab allocated, however.
This appears related to http://bugzilla.kernel.org/show_bug.cgi?id=13518,
but that could be confirmed with slabtop.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
@ 2009-06-30 12:48 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-30 12:48 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Tuesday 30 June 2009, Johannes Stezenbach wrote:
> On Mon, Jun 29, 2009 at 02:31:01AM +0200, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644
> > Subject : hibernation/swsusp lockup due to acpi-cpufreq
> > Submitter : Johannes Stezenbach <js@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>
>
> I tested v2.6.31-rc1-228-g2bfdd79 and the bug is still there.
> It actually got worse, the local_irq_save/restore workaround
> in kernel/up-c (http://lkml.org/lkml/2009/6/16/333) doesn't fix it
> anymore, it hangs at suspend before writing out the image.
>
> With the up.c workaround (including a
> WARN_ON_ONCE(irqs_disabled() && !oops_in_progress);)
> applied and no_console_suspend I captured the attached
> output using a crappy webcam. (Without the workaround
> there is a huge spew of warnings about irqs enabled
> unexpectedly.) I guess the interesting part is
>
> pm_op(): pci_pm_thaw returns -16
> PM: Device 0000:00:00.0 failed to thaw: error -16
Hmm, it looks like we fail to thaw the host bridge.
> (PCI info is in http://lkml.org/lkml/2009/6/15/630)
Well, thanks for the update. I'll do my best to fix the cpufreq suspend
before 2.6.31 final.
Best,
Rafael
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq
@ 2009-06-30 12:48 ` Rafael J. Wysocki
0 siblings, 0 replies; 211+ messages in thread
From: Rafael J. Wysocki @ 2009-06-30 12:48 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Tuesday 30 June 2009, Johannes Stezenbach wrote:
> On Mon, Jun 29, 2009 at 02:31:01AM +0200, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13644
> > Subject : hibernation/swsusp lockup due to acpi-cpufreq
> > Submitter : Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
> > Date : 2009-06-16 01:27 (13 days old)
> > References : http://lkml.org/lkml/2009/6/15/630
> > Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
>
> I tested v2.6.31-rc1-228-g2bfdd79 and the bug is still there.
> It actually got worse, the local_irq_save/restore workaround
> in kernel/up-c (http://lkml.org/lkml/2009/6/16/333) doesn't fix it
> anymore, it hangs at suspend before writing out the image.
>
> With the up.c workaround (including a
> WARN_ON_ONCE(irqs_disabled() && !oops_in_progress);)
> applied and no_console_suspend I captured the attached
> output using a crappy webcam. (Without the workaround
> there is a huge spew of warnings about irqs enabled
> unexpectedly.) I guess the interesting part is
>
> pm_op(): pci_pm_thaw returns -16
> PM: Device 0000:00:00.0 failed to thaw: error -16
Hmm, it looks like we fail to thaw the host bridge.
> (PCI info is in http://lkml.org/lkml/2009/6/15/630)
Well, thanks for the update. I'll do my best to fix the cpufreq suspend
before 2.6.31 final.
Best,
Rafael
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 14:32 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 14:32 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 15:14 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap
2009-06-29 0:30 ` Rafael J. Wysocki
@ 2009-06-30 18:37 ` Alejandro Riveira Fernández
-1 siblings, 0 replies; 211+ messages in thread
From: Alejandro Riveira Fernández @ 2009-06-30 18:37 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright,
Johannes Berg, John W. Linville
El Mon, 29 Jun 2009 02:30:55 +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).
There is no 2.6.30.1 to see if it has been fixed and i have not tested
2.6.31-rc1 (too early for me) so i think it should be still listed
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
> Subject : rt2x00: slow wifi with correct basic rate bitmap
> Submitter : Alejandro Riveira <ariveira@gmail.com>
> Date : 2009-05-22 13:32 (38 days old)
>
>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap
@ 2009-06-30 18:37 ` Alejandro Riveira Fernández
0 siblings, 0 replies; 211+ messages in thread
From: Alejandro Riveira Fernández @ 2009-06-30 18:37 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Chris Wright,
Johannes Berg, John W. Linville
El Mon, 29 Jun 2009 02:30:55 +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).
There is no 2.6.30.1 to see if it has been fixed and i have not tested
2.6.31-rc1 (too early for me) so i think it should be still listed
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
> Subject : rt2x00: slow wifi with correct basic rate bitmap
> Submitter : Alejandro Riveira <ariveira-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2009-05-22 13:32 (38 days old)
>
>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 20:04 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 20:04 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 20:25 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 20:25 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:05 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:05 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:15 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:15 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:23 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:23 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:52 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 21:52 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 22:18 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-06-30 22:18 ` Christoph Lameter
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-01 14:31 ` Jeff Chua
0 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-07-01 14:31 UTC (permalink / raw)
To: Etienne Basset; +Cc: David Miller, rjw, linux-kernel, kernel-testers, bzolnier
On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
> I just tried, and it "seems" to work. Will try a few more cycles.
STD/STR survived quite a few cycles now. Patch seems to be doing the
right thing.
On Mon, Jun 29, 2009 at 11:51 PM, Etienne
Basset<etienne.basset@numericable.fr> wrote:
> To have STR/resume work with current git, I have to :
> 1) apply Bart's patch
This is not yet in Linus's tree. And much needed to really fix the problem.
> 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
This is already in Linus's tree.
Thanks,
Jeff.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-01 14:31 ` Jeff Chua
0 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-07-01 14:31 UTC (permalink / raw)
To: Etienne Basset
Cc: David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
bzolnier-Re5JQEeQqe8AvxtiuMwx3w
On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I just tried, and it "seems" to work. Will try a few more cycles.
STD/STR survived quite a few cycles now. Patch seems to be doing the
right thing.
On Mon, Jun 29, 2009 at 11:51 PM, Etienne
Basset<etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
> To have STR/resume work with current git, I have to :
> 1) apply Bart's patch
This is not yet in Linus's tree. And much needed to really fix the problem.
> 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
This is already in Linus's tree.
Thanks,
Jeff.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-01 14:31 ` Jeff Chua
@ 2009-07-01 14:47 ` Wu Zhangjin
-1 siblings, 0 replies; 211+ messages in thread
From: Wu Zhangjin @ 2009-07-01 14:47 UTC (permalink / raw)
To: Jeff Chua
Cc: Etienne Basset, David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
bzolnier-Re5JQEeQqe8AvxtiuMwx3w, Ralf Baechle,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > I just tried, and it "seems" to work. Will try a few more cycles.
>
> STD/STR survived quite a few cycles now. Patch seems to be doing the
> right thing.
>
> On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> Basset<etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
>
> > To have STR/resume work with current git, I have to :
>
> > 1) apply Bart's patch
>
> This is not yet in Linus's tree. And much needed to really fix the problem.
>
> > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
>
Yes, This commit must be reverted, otherwise, STD/Hibernation will not
work either. I have tested it on two different loongson-based machines:
fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
Here is what i have traced:
hibernate(kernel/power/hibernate.c)
--> hibernation_snapshot
--> dpm_resume_end
--> dpm_resume
--> device_resume
--> dev->bus->resume(generic_ide_resume), dev_name(dev) = 0.0
--> blk_execute_rq
{
DECLARE_COMPLETION_ONSTACK(wait);
...
wait_for_completion(&wait); // stop here
...
}
and I have tried to revert this part of the above patch:
-
- WARN_ON_ONCE(hwif->rq);
repeat:
prev_port = hwif->host->cur_port;
+
+ if (drive->dev_flags & IDE_DFLAG_BLOCKED)
+ rq = hwif->rq;
+ else
+ WARN_ON_ONCE(hwif->rq);
+
it works! need more time to test!
thanks!
Wu Zhangjin
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-01 14:47 ` Wu Zhangjin
0 siblings, 0 replies; 211+ messages in thread
From: Wu Zhangjin @ 2009-07-01 14:47 UTC (permalink / raw)
To: Jeff Chua
Cc: Etienne Basset, David Miller, rjw, linux-kernel, kernel-testers,
bzolnier, Ralf Baechle, linux-mips, linux-ide
On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
>
> > I just tried, and it "seems" to work. Will try a few more cycles.
>
> STD/STR survived quite a few cycles now. Patch seems to be doing the
> right thing.
>
> On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> Basset<etienne.basset@numericable.fr> wrote:
>
> > To have STR/resume work with current git, I have to :
>
> > 1) apply Bart's patch
>
> This is not yet in Linus's tree. And much needed to really fix the problem.
>
> > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
>
Yes, This commit must be reverted, otherwise, STD/Hibernation will not
work either. I have tested it on two different loongson-based machines:
fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
Here is what i have traced:
hibernate(kernel/power/hibernate.c)
--> hibernation_snapshot
--> dpm_resume_end
--> dpm_resume
--> device_resume
--> dev->bus->resume(generic_ide_resume), dev_name(dev) = 0.0
--> blk_execute_rq
{
DECLARE_COMPLETION_ONSTACK(wait);
...
wait_for_completion(&wait); // stop here
...
}
and I have tried to revert this part of the above patch:
-
- WARN_ON_ONCE(hwif->rq);
repeat:
prev_port = hwif->host->cur_port;
+
+ if (drive->dev_flags & IDE_DFLAG_BLOCKED)
+ rq = hwif->rq;
+ else
+ WARN_ON_ONCE(hwif->rq);
+
it works! need more time to test!
thanks!
Wu Zhangjin
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-01 14:47 ` Wu Zhangjin
(?)
@ 2009-07-01 16:21 ` Bartlomiej Zolnierkiewicz
[not found] ` <200907011821.26091.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
-1 siblings, 1 reply; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-07-01 16:21 UTC (permalink / raw)
To: wuzhangjin
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
> >
> > > I just tried, and it "seems" to work. Will try a few more cycles.
> >
> > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > right thing.
> >
> > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > Basset<etienne.basset@numericable.fr> wrote:
> >
> > > To have STR/resume work with current git, I have to :
> >
> > > 1) apply Bart's patch
> >
> > This is not yet in Linus's tree. And much needed to really fix the problem.
> >
> > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> >
>
> Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> work either. I have tested it on two different loongson-based machines:
> fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
Since it seems like Dave is taking his sweet time with doing the revert
I stared at the code a bit more and I think that I finally found the bug
(thanks to your debugging work for giving me the right hint!).
The patch needs to take into the account a new code introduced by the recent
block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
@@ -555,8 +560,11 @@ repeat:
startstop = start_request(drive, rq);
spin_lock_irq(&hwif->lock);
- if (startstop == ide_stopped)
+ if (startstop == ide_stopped) {
+ rq = hwif->rq;
+ hwif->rq = NULL;
goto repeat;
+ }
} else
goto plug_device;
out:
and not zero hwif->rq if the device is blocked.
Could you try the attached patch and see if it fixes the issue?
[ Dave: while I appreciate fast handling of my patches I had strongly
suggested giving this particular one some extra testing (because there
were a lot of changes in between the time that it has been tested
against other kernel subsystems). Yet, it seems that its linux-next
exposure was minimal at best.. :( ]
---
drivers/ide/ide-io.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/drivers/ide/ide-io.c
===================================================================
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -532,7 +532,8 @@ repeat:
if (startstop == ide_stopped) {
rq = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
+ hwif->rq = NULL;
goto repeat;
}
} else
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-01 16:21 ` Bartlomiej Zolnierkiewicz
@ 2009-07-01 16:29 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-07-01 16:29 UTC (permalink / raw)
To: wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w
Cc: Jeff Chua, Etienne Basset, David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA, Ralf Baechle,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > >
> > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > right thing.
> > >
> > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > Basset<etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
> > >
> > > > To have STR/resume work with current git, I have to :
> > >
> > > > 1) apply Bart's patch
> > >
> > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > >
> > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > >
> >
> > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > work either. I have tested it on two different loongson-based machines:
> > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
>
> Since it seems like Dave is taking his sweet time with doing the revert
> I stared at the code a bit more and I think that I finally found the bug
> (thanks to your debugging work for giving me the right hint!).
>
> The patch needs to take into the account a new code introduced by the recent
> block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
>
> @@ -555,8 +560,11 @@ repeat:
> startstop = start_request(drive, rq);
> spin_lock_irq(&hwif->lock);
>
> - if (startstop == ide_stopped)
> + if (startstop == ide_stopped) {
> + rq = hwif->rq;
> + hwif->rq = NULL;
> goto repeat;
> + }
> } else
> goto plug_device;
> out:
>
> and not zero hwif->rq if the device is blocked.
>
> Could you try the attached patch and see if it fixes the issue?
Here is the more complete version, also taking into the account changes
in ide_intr() and ide_timer_expiry():
---
drivers/ide/ide-io.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
Index: b/drivers/ide/ide-io.c
===================================================================
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -532,7 +532,8 @@ repeat:
if (startstop == ide_stopped) {
rq = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
+ hwif->rq = NULL;
goto repeat;
}
} else
@@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
spin_lock_irq(&hwif->lock);
enable_irq(hwif->irq);
if (startstop == ide_stopped && hwif->polling == 0) {
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
@@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
*/
if (startstop == ide_stopped && hwif->polling == 0) {
BUG_ON(hwif->handler);
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-01 16:29 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-07-01 16:29 UTC (permalink / raw)
To: wuzhangjin
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
> > >
> > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > >
> > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > right thing.
> > >
> > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > Basset<etienne.basset@numericable.fr> wrote:
> > >
> > > > To have STR/resume work with current git, I have to :
> > >
> > > > 1) apply Bart's patch
> > >
> > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > >
> > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > >
> >
> > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > work either. I have tested it on two different loongson-based machines:
> > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
>
> Since it seems like Dave is taking his sweet time with doing the revert
> I stared at the code a bit more and I think that I finally found the bug
> (thanks to your debugging work for giving me the right hint!).
>
> The patch needs to take into the account a new code introduced by the recent
> block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
>
> @@ -555,8 +560,11 @@ repeat:
> startstop = start_request(drive, rq);
> spin_lock_irq(&hwif->lock);
>
> - if (startstop == ide_stopped)
> + if (startstop == ide_stopped) {
> + rq = hwif->rq;
> + hwif->rq = NULL;
> goto repeat;
> + }
> } else
> goto plug_device;
> out:
>
> and not zero hwif->rq if the device is blocked.
>
> Could you try the attached patch and see if it fixes the issue?
Here is the more complete version, also taking into the account changes
in ide_intr() and ide_timer_expiry():
---
drivers/ide/ide-io.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
Index: b/drivers/ide/ide-io.c
===================================================================
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -532,7 +532,8 @@ repeat:
if (startstop == ide_stopped) {
rq = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
+ hwif->rq = NULL;
goto repeat;
}
} else
@@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
spin_lock_irq(&hwif->lock);
enable_irq(hwif->irq);
if (startstop == ide_stopped && hwif->polling == 0) {
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
@@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
*/
if (startstop == ide_stopped && hwif->polling == 0) {
BUG_ON(hwif->handler);
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-01 16:29 ` Bartlomiej Zolnierkiewicz
(?)
@ 2009-07-01 17:28 ` Jeff Chua
-1 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-07-01 17:28 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w, Etienne Basset, David Miller,
rjw-KKrjLPT3xs0, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA, Ralf Baechle,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
On Thu, Jul 2, 2009 at 12:29 AM, Bartlomiej
Zolnierkiewicz<bzolnier@gmail.com> wrote:
> Here is the more complete version, also taking into the account changes
> in ide_intr() and ide_timer_expiry():
This works great for. Survived STR, STD. I just applied on top vanilla
latest Linus's git pull. Nothing else to revert.
Thanks,
Jeff.
> ---
> drivers/ide/ide-io.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> Index: b/drivers/ide/ide-io.c
> ===================================================================
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -532,7 +532,8 @@ repeat:
>
> if (startstop == ide_stopped) {
> rq = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
> + hwif->rq = NULL;
> goto repeat;
> }
> } else
> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
> spin_lock_irq(&hwif->lock);
> enable_irq(hwif->irq);
> if (startstop == ide_stopped && hwif->polling == 0) {
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
> */
> if (startstop == ide_stopped && hwif->polling == 0) {
> BUG_ON(hwif->handler);
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-01 17:28 ` Jeff Chua
0 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-07-01 17:28 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: wuzhangjin, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Thu, Jul 2, 2009 at 12:29 AM, BartlomiejZolnierkiewicz<bzolnier@gmail.com> wrote:> Here is the more complete version, also taking into the account changes> in ide_intr() and ide_timer_expiry():
This works great for. Survived STR, STD. I just applied on top vanillalatest Linus's git pull. Nothing else to revert.
Thanks,Jeff.
> ---> drivers/ide/ide-io.c | 15 ++++++++++-----> 1 file changed, 10 insertions(+), 5 deletions(-)>> Index: b/drivers/ide/ide-io.c> ===================================================================> --- a/drivers/ide/ide-io.c> +++ b/drivers/ide/ide-io.c> @@ -532,7 +532,8 @@ repeat:>> if (startstop == ide_stopped) {> rq = hwif->rq;> - hwif->rq = NULL;> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)> + hwif->rq = NULL;> goto repeat;> }> } else> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat> spin_lock_irq(&hwif->lock);> enable_irq(hwif->irq);> if (startstop == ide_stopped && hwif->polling == 0) {> - rq_in_flight = hwif->rq;> - hwif->rq = NULL;> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {> + rq_in_flight = hwif->rq;> + hwif->rq = NULL;> + }> ide_unlock_port(hwif);> plug_device = 1;> }> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev> */> if (startstop == ide_stopped && hwif->polling == 0) {> BUG_ON(hwif->handler);> - rq_in_flight = hwif->rq;> - hwif->rq = NULL;> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {> + rq_in_flight = hwif->rq;> + hwif->rq = NULL;> + }> ide_unlock_port(hwif);> plug_device = 1;> }>ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-01 17:28 ` Jeff Chua
0 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-07-01 17:28 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: wuzhangjin, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Thu, Jul 2, 2009 at 12:29 AM, Bartlomiej
Zolnierkiewicz<bzolnier@gmail.com> wrote:
> Here is the more complete version, also taking into the account changes
> in ide_intr() and ide_timer_expiry():
This works great for. Survived STR, STD. I just applied on top vanilla
latest Linus's git pull. Nothing else to revert.
Thanks,
Jeff.
> ---
> drivers/ide/ide-io.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> Index: b/drivers/ide/ide-io.c
> ===================================================================
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -532,7 +532,8 @@ repeat:
>
> if (startstop == ide_stopped) {
> rq = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
> + hwif->rq = NULL;
> goto repeat;
> }
> } else
> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
> spin_lock_irq(&hwif->lock);
> enable_irq(hwif->irq);
> if (startstop == ide_stopped && hwif->polling == 0) {
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
> */
> if (startstop == ide_stopped && hwif->polling == 0) {
> BUG_ON(hwif->handler);
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
2009-06-29 0:31 ` Rafael J. Wysocki
@ 2009-07-01 20:36 ` Joao Correia
-1 siblings, 0 replies; 211+ messages in thread
From: Joao Correia @ 2009-07-01 20:36 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-kernel, kernel-testers
No formal patch has been sent yet, that i am aware of. I have made
some changes following suggestion by Americo Wang advise, to the
following:
(patch by Ingo)
diff --git a/kernel/lockdep_internals.h b/kernel/lockdep_internals.h
index 699a2ac..031f4c6 100644
--- a/kernel/lockdep_internals.h
+++ b/kernel/lockdep_internals.h
@@ -65,7 +65,7 @@ enum {
* Stack-trace: tightly packed array of stack backtrace
* addresses. Protected by the hash_lock.
*/
-#define MAX_STACK_TRACE_ENTRIES 262144UL
+#define MAX_STACK_TRACE_ENTRIES 1048576UL
extern struct list_head all_lock_classes;
extern struct lock_chain lock_chains[];
and afterwards, a new bug popped up, solved by changing
include/linux/sched.h
# define MAX_LOCK_DEPTH 48UL
to
# define MAX_LOCK_DEPTH 96UL
I have now found a third limit bug, related to MAX_LOCKDEP_CHAINS,
which was hidden so far, which im trying to raise and replicate. This
is being discussed in detail in another message exchange on the lkml,
between me and Americo.
Thank you very much for your time,
Joao Correia
Centro de Informatica
Universidade da Beira Interior
Portugal
On Mon, Jun 29, 2009 at 1:31 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=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
>
>
>
^ permalink raw reply related [flat|nested] 211+ messages in thread
* Re: [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
@ 2009-07-01 20:36 ` Joao Correia
0 siblings, 0 replies; 211+ messages in thread
From: Joao Correia @ 2009-07-01 20:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA
No formal patch has been sent yet, that i am aware of. I have made
some changes following suggestion by Americo Wang advise, to the
following:
(patch by Ingo)
diff --git a/kernel/lockdep_internals.h b/kernel/lockdep_internals.h
index 699a2ac..031f4c6 100644
--- a/kernel/lockdep_internals.h
+++ b/kernel/lockdep_internals.h
@@ -65,7 +65,7 @@ enum {
* Stack-trace: tightly packed array of stack backtrace
* addresses. Protected by the hash_lock.
*/
-#define MAX_STACK_TRACE_ENTRIES 262144UL
+#define MAX_STACK_TRACE_ENTRIES 1048576UL
extern struct list_head all_lock_classes;
extern struct lock_chain lock_chains[];
and afterwards, a new bug popped up, solved by changing
include/linux/sched.h
# define MAX_LOCK_DEPTH 48UL
to
# define MAX_LOCK_DEPTH 96UL
I have now found a third limit bug, related to MAX_LOCKDEP_CHAINS,
which was hidden so far, which im trying to raise and replicate. This
is being discussed in detail in another message exchange on the lkml,
between me and Americo.
Thank you very much for your time,
Joao Correia
Centro de Informatica
Universidade da Beira Interior
Portugal
On Mon, Jun 29, 2009 at 1:31 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=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 (2 days old)
> References : http://lkml.org/lkml/2009/6/27/95
>
>
>
^ permalink raw reply related [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-01 17:28 ` Jeff Chua
@ 2009-07-01 21:30 ` Etienne Basset
-1 siblings, 0 replies; 211+ messages in thread
From: Etienne Basset @ 2009-07-01 21:30 UTC (permalink / raw)
To: Jeff Chua
Cc: Bartlomiej Zolnierkiewicz, wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w,
David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA, Ralf Baechle,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
Jeff Chua wrote:
> On Thu, Jul 2, 2009 at 12:29 AM, Bartlomiej
> Zolnierkiewicz<bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Here is the more complete version, also taking into the account changes
>> in ide_intr() and ide_timer_expiry():
>
> This works great for. Survived STR, STD. I just applied on top vanilla
> latest Linus's git pull. Nothing else to revert.
>
> Thanks,
> Jeff.
>
>
i confirm, this works for me too :)
thanks,
Etienne
>> ---
>> drivers/ide/ide-io.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> Index: b/drivers/ide/ide-io.c
>> ===================================================================
>> --- a/drivers/ide/ide-io.c
>> +++ b/drivers/ide/ide-io.c
>> @@ -532,7 +532,8 @@ repeat:
>>
>> if (startstop == ide_stopped) {
>> rq = hwif->rq;
>> - hwif->rq = NULL;
>> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
>> + hwif->rq = NULL;
>> goto repeat;
>> }
>> } else
>> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
>> spin_lock_irq(&hwif->lock);
>> enable_irq(hwif->irq);
>> if (startstop == ide_stopped && hwif->polling == 0) {
>> - rq_in_flight = hwif->rq;
>> - hwif->rq = NULL;
>> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
>> + rq_in_flight = hwif->rq;
>> + hwif->rq = NULL;
>> + }
>> ide_unlock_port(hwif);
>> plug_device = 1;
>> }
>> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
>> */
>> if (startstop == ide_stopped && hwif->polling == 0) {
>> BUG_ON(hwif->handler);
>> - rq_in_flight = hwif->rq;
>> - hwif->rq = NULL;
>> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
>> + rq_in_flight = hwif->rq;
>> + hwif->rq = NULL;
>> + }
>> ide_unlock_port(hwif);
>> plug_device = 1;
>> }
>>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-01 21:30 ` Etienne Basset
0 siblings, 0 replies; 211+ messages in thread
From: Etienne Basset @ 2009-07-01 21:30 UTC (permalink / raw)
To: Jeff Chua
Cc: Bartlomiej Zolnierkiewicz, wuzhangjin, David Miller, rjw,
linux-kernel, kernel-testers, Ralf Baechle, linux-mips,
linux-ide
Jeff Chua wrote:
> On Thu, Jul 2, 2009 at 12:29 AM, Bartlomiej
> Zolnierkiewicz<bzolnier@gmail.com> wrote:
>> Here is the more complete version, also taking into the account changes
>> in ide_intr() and ide_timer_expiry():
>
> This works great for. Survived STR, STD. I just applied on top vanilla
> latest Linus's git pull. Nothing else to revert.
>
> Thanks,
> Jeff.
>
>
i confirm, this works for me too :)
thanks,
Etienne
>> ---
>> drivers/ide/ide-io.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> Index: b/drivers/ide/ide-io.c
>> ===================================================================
>> --- a/drivers/ide/ide-io.c
>> +++ b/drivers/ide/ide-io.c
>> @@ -532,7 +532,8 @@ repeat:
>>
>> if (startstop == ide_stopped) {
>> rq = hwif->rq;
>> - hwif->rq = NULL;
>> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
>> + hwif->rq = NULL;
>> goto repeat;
>> }
>> } else
>> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
>> spin_lock_irq(&hwif->lock);
>> enable_irq(hwif->irq);
>> if (startstop == ide_stopped && hwif->polling == 0) {
>> - rq_in_flight = hwif->rq;
>> - hwif->rq = NULL;
>> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
>> + rq_in_flight = hwif->rq;
>> + hwif->rq = NULL;
>> + }
>> ide_unlock_port(hwif);
>> plug_device = 1;
>> }
>> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
>> */
>> if (startstop == ide_stopped && hwif->polling == 0) {
>> BUG_ON(hwif->handler);
>> - rq_in_flight = hwif->rq;
>> - hwif->rq = NULL;
>> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
>> + rq_in_flight = hwif->rq;
>> + hwif->rq = NULL;
>> + }
>> ide_unlock_port(hwif);
>> plug_device = 1;
>> }
>>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-01 16:29 ` Bartlomiej Zolnierkiewicz
@ 2009-07-02 1:46 ` Wu Zhangjin
-1 siblings, 0 replies; 211+ messages in thread
From: Wu Zhangjin @ 2009-07-02 1:46 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Jeff Chua, Etienne Basset, David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA, Ralf Baechle,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > > >
> > > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > > right thing.
> > > >
> > > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > > Basset<etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
> > > >
> > > > > To have STR/resume work with current git, I have to :
> > > >
> > > > > 1) apply Bart's patch
> > > >
> > > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > > >
> > > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > > >
> > >
> > > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > > work either. I have tested it on two different loongson-based machines:
> > > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
> >
> > Since it seems like Dave is taking his sweet time with doing the revert
> > I stared at the code a bit more and I think that I finally found the bug
> > (thanks to your debugging work for giving me the right hint!).
> >
> > The patch needs to take into the account a new code introduced by the recent
> > block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
> >
> > @@ -555,8 +560,11 @@ repeat:
> > startstop = start_request(drive, rq);
> > spin_lock_irq(&hwif->lock);
> >
> > - if (startstop == ide_stopped)
> > + if (startstop == ide_stopped) {
> > + rq = hwif->rq;
> > + hwif->rq = NULL;
> > goto repeat;
> > + }
> > } else
> > goto plug_device;
> > out:
> >
> > and not zero hwif->rq if the device is blocked.
> >
> > Could you try the attached patch and see if it fixes the issue?
>
> Here is the more complete version, also taking into the account changes
> in ide_intr() and ide_timer_expiry():
>
Sorry, I can not apply this patch directly, which original version did
you use? I used the one in the master branch of linux-mips development
git repository.
commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
Merge: ec9c45d e18ed14
Author: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date: Mon Jun 29 20:07:43 2009 -0700
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
ide: memory overrun in ide_get_identity_ioctl() on big endian
machines using ioctl HDIO_OBSOLETE_IDENTITY
ide: fix resume for CONFIG_BLK_DEV_IDEACPI=y
ide-cd: handle fragmented packet commands gracefully
ide: always kill the whole request on error
ide: fix ide_kill_rq() for special ide-{floppy,tape} driver
requests
it this too old? should i merge another git repository?
I have tried to apply it manually, but unfortunately, also not work. any
other patch needed?
Thanks!
Wu Zhangjin
> ---
> drivers/ide/ide-io.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> Index: b/drivers/ide/ide-io.c
> ===================================================================
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -532,7 +532,8 @@ repeat:
>
> if (startstop == ide_stopped) {
> rq = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
> + hwif->rq = NULL;
> goto repeat;
> }
> } else
> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
> spin_lock_irq(&hwif->lock);
> enable_irq(hwif->irq);
> if (startstop == ide_stopped && hwif->polling == 0) {
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
> */
> if (startstop == ide_stopped && hwif->polling == 0) {
> BUG_ON(hwif->handler);
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-02 1:46 ` Wu Zhangjin
0 siblings, 0 replies; 211+ messages in thread
From: Wu Zhangjin @ 2009-07-02 1:46 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
> > > >
> > > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > > >
> > > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > > right thing.
> > > >
> > > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > > Basset<etienne.basset@numericable.fr> wrote:
> > > >
> > > > > To have STR/resume work with current git, I have to :
> > > >
> > > > > 1) apply Bart's patch
> > > >
> > > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > > >
> > > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > > >
> > >
> > > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > > work either. I have tested it on two different loongson-based machines:
> > > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
> >
> > Since it seems like Dave is taking his sweet time with doing the revert
> > I stared at the code a bit more and I think that I finally found the bug
> > (thanks to your debugging work for giving me the right hint!).
> >
> > The patch needs to take into the account a new code introduced by the recent
> > block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
> >
> > @@ -555,8 +560,11 @@ repeat:
> > startstop = start_request(drive, rq);
> > spin_lock_irq(&hwif->lock);
> >
> > - if (startstop == ide_stopped)
> > + if (startstop == ide_stopped) {
> > + rq = hwif->rq;
> > + hwif->rq = NULL;
> > goto repeat;
> > + }
> > } else
> > goto plug_device;
> > out:
> >
> > and not zero hwif->rq if the device is blocked.
> >
> > Could you try the attached patch and see if it fixes the issue?
>
> Here is the more complete version, also taking into the account changes
> in ide_intr() and ide_timer_expiry():
>
Sorry, I can not apply this patch directly, which original version did
you use? I used the one in the master branch of linux-mips development
git repository.
commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
Merge: ec9c45d e18ed14
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon Jun 29 20:07:43 2009 -0700
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
ide: memory overrun in ide_get_identity_ioctl() on big endian
machines using ioctl HDIO_OBSOLETE_IDENTITY
ide: fix resume for CONFIG_BLK_DEV_IDEACPI=y
ide-cd: handle fragmented packet commands gracefully
ide: always kill the whole request on error
ide: fix ide_kill_rq() for special ide-{floppy,tape} driver
requests
it this too old? should i merge another git repository?
I have tried to apply it manually, but unfortunately, also not work. any
other patch needed?
Thanks!
Wu Zhangjin
> ---
> drivers/ide/ide-io.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> Index: b/drivers/ide/ide-io.c
> ===================================================================
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -532,7 +532,8 @@ repeat:
>
> if (startstop == ide_stopped) {
> rq = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
> + hwif->rq = NULL;
> goto repeat;
> }
> } else
> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
> spin_lock_irq(&hwif->lock);
> enable_irq(hwif->irq);
> if (startstop == ide_stopped && hwif->polling == 0) {
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
> */
> if (startstop == ide_stopped && hwif->polling == 0) {
> BUG_ON(hwif->handler);
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-02 1:46 ` Wu Zhangjin
@ 2009-07-02 2:09 ` Jeff Chua
-1 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-07-02 2:09 UTC (permalink / raw)
To: wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w
Cc: Bartlomiej Zolnierkiewicz, Etienne Basset, David Miller,
rjw-KKrjLPT3xs0, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA, Ralf Baechle,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
On Thu, Jul 2, 2009 at 9:46 AM, Wu Zhangjin<wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> it this too old? should i merge another git repository?
> I have tried to apply it manually, but unfortunately, also not work. any
> other patch needed?
You need to be undo those two patches below ...
> On Mon, Jun 29, 2009 at 11:51 PM, Etienne Basset<etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> To have STR/resume work with current git, I have to :
> 1) apply Bart's patch
> 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
or try to pull from Linus's tree and try again. Latest is now ...
commit d960eea974f5e500c0dcb95a934239cc1f481cfd
Author: Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date: Mon Jun 29 14:54:11 2009 -0700
kernel-doc: move ignoring kmemcheck
Jeff.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-02 2:09 ` Jeff Chua
0 siblings, 0 replies; 211+ messages in thread
From: Jeff Chua @ 2009-07-02 2:09 UTC (permalink / raw)
To: wuzhangjin
Cc: Bartlomiej Zolnierkiewicz, Etienne Basset, David Miller, rjw,
linux-kernel, kernel-testers, Ralf Baechle, linux-mips,
linux-ide
On Thu, Jul 2, 2009 at 9:46 AM, Wu Zhangjin<wuzhangjin@gmail.com> wrote:
> it this too old? should i merge another git repository?
> I have tried to apply it manually, but unfortunately, also not work. any
> other patch needed?
You need to be undo those two patches below ...
> On Mon, Jun 29, 2009 at 11:51 PM, Etienne Basset<etienne.basset@numericable.fr>
> To have STR/resume work with current git, I have to :
> 1) apply Bart's patch
> 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
or try to pull from Linus's tree and try again. Latest is now ...
commit d960eea974f5e500c0dcb95a934239cc1f481cfd
Author: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon Jun 29 14:54:11 2009 -0700
kernel-doc: move ignoring kmemcheck
Jeff.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-02 1:46 ` Wu Zhangjin
@ 2009-07-02 10:46 ` Ralf Baechle
-1 siblings, 0 replies; 211+ messages in thread
From: Ralf Baechle @ 2009-07-02 10:46 UTC (permalink / raw)
To: Wu Zhangjin
Cc: Bartlomiej Zolnierkiewicz, Jeff Chua, Etienne Basset,
David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
On Thu, Jul 02, 2009 at 09:46:43AM +0800, Wu Zhangjin wrote:
> Sorry, I can not apply this patch directly, which original version did
> you use? I used the one in the master branch of linux-mips development
> git repository.
The master branch of linux-mips.org has no IDE changes over Linus' tree.
Ralf
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-02 10:46 ` Ralf Baechle
0 siblings, 0 replies; 211+ messages in thread
From: Ralf Baechle @ 2009-07-02 10:46 UTC (permalink / raw)
To: Wu Zhangjin
Cc: Bartlomiej Zolnierkiewicz, Jeff Chua, Etienne Basset,
David Miller, rjw, linux-kernel, kernel-testers, linux-mips,
linux-ide
On Thu, Jul 02, 2009 at 09:46:43AM +0800, Wu Zhangjin wrote:
> Sorry, I can not apply this patch directly, which original version did
> you use? I used the one in the master branch of linux-mips development
> git repository.
The master branch of linux-mips.org has no IDE changes over Linus' tree.
Ralf
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-02 1:46 ` Wu Zhangjin
@ 2009-07-02 16:13 ` Bartlomiej Zolnierkiewicz
-1 siblings, 0 replies; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-07-02 16:13 UTC (permalink / raw)
To: wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w
Cc: Jeff Chua, Etienne Basset, David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA, Ralf Baechle,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
On Thursday 02 July 2009 03:46:43 Wu Zhangjin wrote:
> On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> > > On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > > > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > >
> > > > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > > > >
> > > > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > > > right thing.
> > > > >
> > > > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > > > Basset<etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
> > > > >
> > > > > > To have STR/resume work with current git, I have to :
> > > > >
> > > > > > 1) apply Bart's patch
> > > > >
> > > > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > > > >
> > > > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > > > >
> > > >
> > > > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > > > work either. I have tested it on two different loongson-based machines:
> > > > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
> > >
> > > Since it seems like Dave is taking his sweet time with doing the revert
> > > I stared at the code a bit more and I think that I finally found the bug
> > > (thanks to your debugging work for giving me the right hint!).
> > >
> > > The patch needs to take into the account a new code introduced by the recent
> > > block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
> > >
> > > @@ -555,8 +560,11 @@ repeat:
> > > startstop = start_request(drive, rq);
> > > spin_lock_irq(&hwif->lock);
> > >
> > > - if (startstop == ide_stopped)
> > > + if (startstop == ide_stopped) {
> > > + rq = hwif->rq;
> > > + hwif->rq = NULL;
> > > goto repeat;
> > > + }
> > > } else
> > > goto plug_device;
> > > out:
> > >
> > > and not zero hwif->rq if the device is blocked.
> > >
> > > Could you try the attached patch and see if it fixes the issue?
> >
> > Here is the more complete version, also taking into the account changes
> > in ide_intr() and ide_timer_expiry():
> >
>
> Sorry, I can not apply this patch directly, which original version did
> you use? I used the one in the master branch of linux-mips development
> git repository.
>
> commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
> Merge: ec9c45d e18ed14
> Author: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> Date: Mon Jun 29 20:07:43 2009 -0700
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6
>
> * git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
> ide: memory overrun in ide_get_identity_ioctl() on big endian
> machines using ioctl HDIO_OBSOLETE_IDENTITY
> ide: fix resume for CONFIG_BLK_DEV_IDEACPI=y
> ide-cd: handle fragmented packet commands gracefully
> ide: always kill the whole request on error
> ide: fix ide_kill_rq() for special ide-{floppy,tape} driver
> requests
>
> it this too old? should i merge another git repository?
Weird, I used linux-next but Linus' tree should also be fine
(as it matches linux-next w.r.t. ide currently).
Anyway since the patch was confirmed to fix the problem by
Jeff and Etienne here is the final version for Dave.
From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: [PATCH] ide: make resume work again
It turns out that commit a1317f714af7aed60ddc182d0122477cbe36ee9b
("ide: improve handling of Power Management requests") needs to take
into the account a new code added by the recent block layer changes
in commit 8f6205cd572fece673da0255d74843680f67f879 ("ide: dequeue
in-flight request") and prevent clearing of hwif->rq if the device
is blocked.
Thanks to Etienne, Wu and Jeff for help in fixing the issue.
Reported-and-tested-by: Jeff Chua <jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reported-and-tested-by: Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
Reported-by: Wu Zhangjin <wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Added patch description, no other changes.
drivers/ide/ide-io.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
Index: b/drivers/ide/ide-io.c
===================================================================
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -532,7 +532,8 @@ repeat:
if (startstop == ide_stopped) {
rq = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
+ hwif->rq = NULL;
goto repeat;
}
} else
@@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
spin_lock_irq(&hwif->lock);
enable_irq(hwif->irq);
if (startstop == ide_stopped && hwif->polling == 0) {
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
@@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
*/
if (startstop == ide_stopped && hwif->polling == 0) {
BUG_ON(hwif->handler);
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-02 16:13 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-07-02 16:13 UTC (permalink / raw)
To: wuzhangjin
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Thursday 02 July 2009 03:46:43 Wu Zhangjin wrote:
> On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> > > On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > > > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
> > > > >
> > > > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > > > >
> > > > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > > > right thing.
> > > > >
> > > > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > > > Basset<etienne.basset@numericable.fr> wrote:
> > > > >
> > > > > > To have STR/resume work with current git, I have to :
> > > > >
> > > > > > 1) apply Bart's patch
> > > > >
> > > > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > > > >
> > > > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > > > >
> > > >
> > > > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > > > work either. I have tested it on two different loongson-based machines:
> > > > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
> > >
> > > Since it seems like Dave is taking his sweet time with doing the revert
> > > I stared at the code a bit more and I think that I finally found the bug
> > > (thanks to your debugging work for giving me the right hint!).
> > >
> > > The patch needs to take into the account a new code introduced by the recent
> > > block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
> > >
> > > @@ -555,8 +560,11 @@ repeat:
> > > startstop = start_request(drive, rq);
> > > spin_lock_irq(&hwif->lock);
> > >
> > > - if (startstop == ide_stopped)
> > > + if (startstop == ide_stopped) {
> > > + rq = hwif->rq;
> > > + hwif->rq = NULL;
> > > goto repeat;
> > > + }
> > > } else
> > > goto plug_device;
> > > out:
> > >
> > > and not zero hwif->rq if the device is blocked.
> > >
> > > Could you try the attached patch and see if it fixes the issue?
> >
> > Here is the more complete version, also taking into the account changes
> > in ide_intr() and ide_timer_expiry():
> >
>
> Sorry, I can not apply this patch directly, which original version did
> you use? I used the one in the master branch of linux-mips development
> git repository.
>
> commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
> Merge: ec9c45d e18ed14
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Mon Jun 29 20:07:43 2009 -0700
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6
>
> * git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
> ide: memory overrun in ide_get_identity_ioctl() on big endian
> machines using ioctl HDIO_OBSOLETE_IDENTITY
> ide: fix resume for CONFIG_BLK_DEV_IDEACPI=y
> ide-cd: handle fragmented packet commands gracefully
> ide: always kill the whole request on error
> ide: fix ide_kill_rq() for special ide-{floppy,tape} driver
> requests
>
> it this too old? should i merge another git repository?
Weird, I used linux-next but Linus' tree should also be fine
(as it matches linux-next w.r.t. ide currently).
Anyway since the patch was confirmed to fix the problem by
Jeff and Etienne here is the final version for Dave.
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: make resume work again
It turns out that commit a1317f714af7aed60ddc182d0122477cbe36ee9b
("ide: improve handling of Power Management requests") needs to take
into the account a new code added by the recent block layer changes
in commit 8f6205cd572fece673da0255d74843680f67f879 ("ide: dequeue
in-flight request") and prevent clearing of hwif->rq if the device
is blocked.
Thanks to Etienne, Wu and Jeff for help in fixing the issue.
Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
Reported-and-tested-by: Etienne Basset <etienne.basset@numericable.fr>
Reported-by: Wu Zhangjin <wuzhangjin@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
Added patch description, no other changes.
drivers/ide/ide-io.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
Index: b/drivers/ide/ide-io.c
===================================================================
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -532,7 +532,8 @@ repeat:
if (startstop == ide_stopped) {
rq = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
+ hwif->rq = NULL;
goto repeat;
}
} else
@@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
spin_lock_irq(&hwif->lock);
enable_irq(hwif->irq);
if (startstop == ide_stopped && hwif->polling == 0) {
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
@@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
*/
if (startstop == ide_stopped && hwif->polling == 0) {
BUG_ON(hwif->handler);
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-02 17:18 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-02 17:18 ` David Rientjes
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-02 16:13 ` Bartlomiej Zolnierkiewicz
@ 2009-07-03 3:58 ` Wu Zhangjin
-1 siblings, 0 replies; 211+ messages in thread
From: Wu Zhangjin @ 2009-07-03 3:58 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Jeff Chua, Etienne Basset, David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA, Ralf Baechle,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-ide-u79uwXL29TY76Z2rM5mHXA
On Thu, 2009-07-02 at 18:13 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 02 July 2009 03:46:43 Wu Zhangjin wrote:
> > On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> > > > On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > > > > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > > > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > >
> > > > > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > > > > >
> > > > > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > > > > right thing.
> > > > > >
> > > > > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > > > > Basset<etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
> > > > > >
> > > > > > > To have STR/resume work with current git, I have to :
> > > > > >
> > > > > > > 1) apply Bart's patch
> > > > > >
> > > > > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > > > > >
> > > > > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > > > > >
> > > > >
> > > > > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > > > > work either. I have tested it on two different loongson-based machines:
> > > > > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
> > > >
> > > > Since it seems like Dave is taking his sweet time with doing the revert
> > > > I stared at the code a bit more and I think that I finally found the bug
> > > > (thanks to your debugging work for giving me the right hint!).
> > > >
> > > > The patch needs to take into the account a new code introduced by the recent
> > > > block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
> > > >
> > > > @@ -555,8 +560,11 @@ repeat:
> > > > startstop = start_request(drive, rq);
> > > > spin_lock_irq(&hwif->lock);
> > > >
> > > > - if (startstop == ide_stopped)
> > > > + if (startstop == ide_stopped) {
> > > > + rq = hwif->rq;
> > > > + hwif->rq = NULL;
> > > > goto repeat;
> > > > + }
> > > > } else
> > > > goto plug_device;
> > > > out:
> > > >
> > > > and not zero hwif->rq if the device is blocked.
> > > >
> > > > Could you try the attached patch and see if it fixes the issue?
> > >
> > > Here is the more complete version, also taking into the account changes
> > > in ide_intr() and ide_timer_expiry():
> > >
> >
> > Sorry, I can not apply this patch directly, which original version did
> > you use? I used the one in the master branch of linux-mips development
> > git repository.
> >
> > commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
> > Merge: ec9c45d e18ed14
> > Author: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> > Date: Mon Jun 29 20:07:43 2009 -0700
> >
> > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6
> >
> > * git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
> > ide: memory overrun in ide_get_identity_ioctl() on big endian
> > machines using ioctl HDIO_OBSOLETE_IDENTITY
> > ide: fix resume for CONFIG_BLK_DEV_IDEACPI=y
> > ide-cd: handle fragmented packet commands gracefully
> > ide: always kill the whole request on error
> > ide: fix ide_kill_rq() for special ide-{floppy,tape} driver
> > requests
> >
> > it this too old? should i merge another git repository?
>
> Weird, I used linux-next but Linus' tree should also be fine
> (as it matches linux-next w.r.t. ide currently).
I just cloned the linux-next git repo, and tested your patch with
STD/Hibernation, unfortunately, it also not work :-(
here is the Call Trace:
blk_delete_timer+0x0/0x20
blk_requeue_request+0x24/0xd0
ide_requeue_and_plug+0x38/0xb0
ide_intr+0x120/0x300 ---> ide_intr....
handle_IRQ_event+0x94/0x230
handle_level_irq+0x7c/0x120
mach_irq_dispatch+0xc8/0x158
ret_from_irq+0x0/0x4
cpu_idle+0x30/0x60
start_kernel+0x330/0x34c
If _NOT_ apply your patch and comment this part, it works:
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index d5f3c77..a45de2b 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -468,12 +468,12 @@ void do_ide_request(struct request_queue *q)
ide_hwif_t *prev_port;
repeat:
prev_port = hwif->host->cur_port;
-
+/*
if (drive->dev_flags & IDE_DFLAG_BLOCKED)
rq = hwif->rq;
else
WARN_ON_ONCE(hwif->rq);
-
+*/
if (drive->dev_flags & IDE_DFLAG_SLEEPING &&
time_after(drive->sleep, jiffies)) {
ide_unlock_port(hwif);
Regards,
Wu Zhangjin
>
> Anyway since the patch was confirmed to fix the problem by
> Jeff and Etienne here is the final version for Dave.
>
> From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Subject: [PATCH] ide: make resume work again
>
> It turns out that commit a1317f714af7aed60ddc182d0122477cbe36ee9b
> ("ide: improve handling of Power Management requests") needs to take
> into the account a new code added by the recent block layer changes
> in commit 8f6205cd572fece673da0255d74843680f67f879 ("ide: dequeue
> in-flight request") and prevent clearing of hwif->rq if the device
> is blocked.
>
> Thanks to Etienne, Wu and Jeff for help in fixing the issue.
>
> Reported-and-tested-by: Jeff Chua <jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Reported-and-tested-by: Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> Reported-by: Wu Zhangjin <wuzhangjin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Added patch description, no other changes.
>
> drivers/ide/ide-io.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> Index: b/drivers/ide/ide-io.c
> ===================================================================
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -532,7 +532,8 @@ repeat:
>
> if (startstop == ide_stopped) {
> rq = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
> + hwif->rq = NULL;
> goto repeat;
> }
> } else
> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
> spin_lock_irq(&hwif->lock);
> enable_irq(hwif->irq);
> if (startstop == ide_stopped && hwif->polling == 0) {
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
> */
> if (startstop == ide_stopped && hwif->polling == 0) {
> BUG_ON(hwif->handler);
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" 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 related [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
@ 2009-07-03 3:58 ` Wu Zhangjin
0 siblings, 0 replies; 211+ messages in thread
From: Wu Zhangjin @ 2009-07-03 3:58 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Thu, 2009-07-02 at 18:13 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 02 July 2009 03:46:43 Wu Zhangjin wrote:
> > On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> > > > On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > > > > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > > > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
> > > > > >
> > > > > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > > > > >
> > > > > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > > > > right thing.
> > > > > >
> > > > > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > > > > Basset<etienne.basset@numericable.fr> wrote:
> > > > > >
> > > > > > > To have STR/resume work with current git, I have to :
> > > > > >
> > > > > > > 1) apply Bart's patch
> > > > > >
> > > > > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > > > > >
> > > > > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > > > > >
> > > > >
> > > > > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > > > > work either. I have tested it on two different loongson-based machines:
> > > > > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
> > > >
> > > > Since it seems like Dave is taking his sweet time with doing the revert
> > > > I stared at the code a bit more and I think that I finally found the bug
> > > > (thanks to your debugging work for giving me the right hint!).
> > > >
> > > > The patch needs to take into the account a new code introduced by the recent
> > > > block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
> > > >
> > > > @@ -555,8 +560,11 @@ repeat:
> > > > startstop = start_request(drive, rq);
> > > > spin_lock_irq(&hwif->lock);
> > > >
> > > > - if (startstop == ide_stopped)
> > > > + if (startstop == ide_stopped) {
> > > > + rq = hwif->rq;
> > > > + hwif->rq = NULL;
> > > > goto repeat;
> > > > + }
> > > > } else
> > > > goto plug_device;
> > > > out:
> > > >
> > > > and not zero hwif->rq if the device is blocked.
> > > >
> > > > Could you try the attached patch and see if it fixes the issue?
> > >
> > > Here is the more complete version, also taking into the account changes
> > > in ide_intr() and ide_timer_expiry():
> > >
> >
> > Sorry, I can not apply this patch directly, which original version did
> > you use? I used the one in the master branch of linux-mips development
> > git repository.
> >
> > commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
> > Merge: ec9c45d e18ed14
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date: Mon Jun 29 20:07:43 2009 -0700
> >
> > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6
> >
> > * git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
> > ide: memory overrun in ide_get_identity_ioctl() on big endian
> > machines using ioctl HDIO_OBSOLETE_IDENTITY
> > ide: fix resume for CONFIG_BLK_DEV_IDEACPI=y
> > ide-cd: handle fragmented packet commands gracefully
> > ide: always kill the whole request on error
> > ide: fix ide_kill_rq() for special ide-{floppy,tape} driver
> > requests
> >
> > it this too old? should i merge another git repository?
>
> Weird, I used linux-next but Linus' tree should also be fine
> (as it matches linux-next w.r.t. ide currently).
I just cloned the linux-next git repo, and tested your patch with
STD/Hibernation, unfortunately, it also not work :-(
here is the Call Trace:
blk_delete_timer+0x0/0x20
blk_requeue_request+0x24/0xd0
ide_requeue_and_plug+0x38/0xb0
ide_intr+0x120/0x300 ---> ide_intr....
handle_IRQ_event+0x94/0x230
handle_level_irq+0x7c/0x120
mach_irq_dispatch+0xc8/0x158
ret_from_irq+0x0/0x4
cpu_idle+0x30/0x60
start_kernel+0x330/0x34c
If _NOT_ apply your patch and comment this part, it works:
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index d5f3c77..a45de2b 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -468,12 +468,12 @@ void do_ide_request(struct request_queue *q)
ide_hwif_t *prev_port;
repeat:
prev_port = hwif->host->cur_port;
-
+/*
if (drive->dev_flags & IDE_DFLAG_BLOCKED)
rq = hwif->rq;
else
WARN_ON_ONCE(hwif->rq);
-
+*/
if (drive->dev_flags & IDE_DFLAG_SLEEPING &&
time_after(drive->sleep, jiffies)) {
ide_unlock_port(hwif);
Regards,
Wu Zhangjin
>
> Anyway since the patch was confirmed to fix the problem by
> Jeff and Etienne here is the final version for Dave.
>
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] ide: make resume work again
>
> It turns out that commit a1317f714af7aed60ddc182d0122477cbe36ee9b
> ("ide: improve handling of Power Management requests") needs to take
> into the account a new code added by the recent block layer changes
> in commit 8f6205cd572fece673da0255d74843680f67f879 ("ide: dequeue
> in-flight request") and prevent clearing of hwif->rq if the device
> is blocked.
>
> Thanks to Etienne, Wu and Jeff for help in fixing the issue.
>
> Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
> Reported-and-tested-by: Etienne Basset <etienne.basset@numericable.fr>
> Reported-by: Wu Zhangjin <wuzhangjin@gmail.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> Added patch description, no other changes.
>
> drivers/ide/ide-io.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> Index: b/drivers/ide/ide-io.c
> ===================================================================
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -532,7 +532,8 @@ repeat:
>
> if (startstop == ide_stopped) {
> rq = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
> + hwif->rq = NULL;
> goto repeat;
> }
> } else
> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
> spin_lock_irq(&hwif->lock);
> enable_irq(hwif->irq);
> if (startstop == ide_stopped && hwif->polling == 0) {
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
> */
> if (startstop == ide_stopped && hwif->polling == 0) {
> BUG_ON(hwif->handler);
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" 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 related [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-03 3:58 ` Wu Zhangjin
(?)
@ 2009-07-03 4:06 ` Wu Zhangjin
-1 siblings, 0 replies; 211+ messages in thread
From: Wu Zhangjin @ 2009-07-03 4:06 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Fri, 2009-07-03 at 11:58 +0800, Wu Zhangjin wrote:
> On Thu, 2009-07-02 at 18:13 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 02 July 2009 03:46:43 Wu Zhangjin wrote:
> > > On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> > > > > On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > > > > > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > > > > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
> > > > > > >
> > > > > > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > > > > > >
> > > > > > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > > > > > right thing.
> > > > > > >
> > > > > > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > > > > > Basset<etienne.basset@numericable.fr> wrote:
> > > > > > >
> > > > > > > > To have STR/resume work with current git, I have to :
> > > > > > >
> > > > > > > > 1) apply Bart's patch
> > > > > > >
> > > > > > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > > > > > >
> > > > > > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > > > > > >
> > > > > >
> > > > > > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > > > > > work either. I have tested it on two different loongson-based machines:
> > > > > > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
> > > > >
> > > > > Since it seems like Dave is taking his sweet time with doing the revert
> > > > > I stared at the code a bit more and I think that I finally found the bug
> > > > > (thanks to your debugging work for giving me the right hint!).
> > > > >
> > > > > The patch needs to take into the account a new code introduced by the recent
> > > > > block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
> > > > >
> > > > > @@ -555,8 +560,11 @@ repeat:
> > > > > startstop = start_request(drive, rq);
> > > > > spin_lock_irq(&hwif->lock);
> > > > >
> > > > > - if (startstop == ide_stopped)
> > > > > + if (startstop == ide_stopped) {
> > > > > + rq = hwif->rq;
> > > > > + hwif->rq = NULL;
> > > > > goto repeat;
> > > > > + }
> > > > > } else
> > > > > goto plug_device;
> > > > > out:
> > > > >
> > > > > and not zero hwif->rq if the device is blocked.
> > > > >
> > > > > Could you try the attached patch and see if it fixes the issue?
> > > >
> > > > Here is the more complete version, also taking into the account changes
> > > > in ide_intr() and ide_timer_expiry():
> > > >
> > >
> > > Sorry, I can not apply this patch directly, which original version did
> > > you use? I used the one in the master branch of linux-mips development
> > > git repository.
> > >
> > > commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
> > > Merge: ec9c45d e18ed14
> > > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > > Date: Mon Jun 29 20:07:43 2009 -0700
> > >
> > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6
> > >
> > > * git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
> > > ide: memory overrun in ide_get_identity_ioctl() on big endian
> > > machines using ioctl HDIO_OBSOLETE_IDENTITY
> > > ide: fix resume for CONFIG_BLK_DEV_IDEACPI=y
> > > ide-cd: handle fragmented packet commands gracefully
> > > ide: always kill the whole request on error
> > > ide: fix ide_kill_rq() for special ide-{floppy,tape} driver
> > > requests
> > >
> > > it this too old? should i merge another git repository?
> >
> > Weird, I used linux-next but Linus' tree should also be fine
> > (as it matches linux-next w.r.t. ide currently).
>
> I just cloned the linux-next git repo, and tested your patch with
> STD/Hibernation, unfortunately, it also not work :-(
>
> here is the Call Trace:
>
> blk_delete_timer+0x0/0x20
> blk_requeue_request+0x24/0xd0
> ide_requeue_and_plug+0x38/0xb0
> ide_intr+0x120/0x300 ---> ide_intr....
> handle_IRQ_event+0x94/0x230
> handle_level_irq+0x7c/0x120
> mach_irq_dispatch+0xc8/0x158
> ret_from_irq+0x0/0x4
> cpu_idle+0x30/0x60
> start_kernel+0x330/0x34c
>
There are two more lines after the Call Trace:
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Fatal exception in interrupt.
> If _NOT_ apply your patch and comment this part, it works:
>
> diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> index d5f3c77..a45de2b 100644
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -468,12 +468,12 @@ void do_ide_request(struct request_queue *q)
> ide_hwif_t *prev_port;
> repeat:
> prev_port = hwif->host->cur_port;
> -
> +/*
> if (drive->dev_flags & IDE_DFLAG_BLOCKED)
> rq = hwif->rq;
> else
> WARN_ON_ONCE(hwif->rq);
> -
> +*/
> if (drive->dev_flags & IDE_DFLAG_SLEEPING &&
> time_after(drive->sleep, jiffies)) {
> ide_unlock_port(hwif);
>
>
> Regards,
> Wu Zhangjin
> >
> > Anyway since the patch was confirmed to fix the problem by
> > Jeff and Etienne here is the final version for Dave.
> >
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] ide: make resume work again
> >
> > It turns out that commit a1317f714af7aed60ddc182d0122477cbe36ee9b
> > ("ide: improve handling of Power Management requests") needs to take
> > into the account a new code added by the recent block layer changes
> > in commit 8f6205cd572fece673da0255d74843680f67f879 ("ide: dequeue
> > in-flight request") and prevent clearing of hwif->rq if the device
> > is blocked.
> >
> > Thanks to Etienne, Wu and Jeff for help in fixing the issue.
> >
> > Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
> > Reported-and-tested-by: Etienne Basset <etienne.basset@numericable.fr>
> > Reported-by: Wu Zhangjin <wuzhangjin@gmail.com>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > ---
> > Added patch description, no other changes.
> >
> > drivers/ide/ide-io.c | 15 ++++++++++-----
> > 1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > Index: b/drivers/ide/ide-io.c
> > ===================================================================
> > --- a/drivers/ide/ide-io.c
> > +++ b/drivers/ide/ide-io.c
> > @@ -532,7 +532,8 @@ repeat:
> >
> > if (startstop == ide_stopped) {
> > rq = hwif->rq;
> > - hwif->rq = NULL;
> > + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
> > + hwif->rq = NULL;
> > goto repeat;
> > }
> > } else
> > @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
> > spin_lock_irq(&hwif->lock);
> > enable_irq(hwif->irq);
> > if (startstop == ide_stopped && hwif->polling == 0) {
> > - rq_in_flight = hwif->rq;
> > - hwif->rq = NULL;
> > + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> > + rq_in_flight = hwif->rq;
> > + hwif->rq = NULL;
> > + }
> > ide_unlock_port(hwif);
> > plug_device = 1;
> > }
> > @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
> > */
> > if (startstop == ide_stopped && hwif->polling == 0) {
> > BUG_ON(hwif->handler);
> > - rq_in_flight = hwif->rq;
> > - hwif->rq = NULL;
> > + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> > + rq_in_flight = hwif->rq;
> > + hwif->rq = NULL;
> > + }
> > ide_unlock_port(hwif);
> > plug_device = 1;
> > }
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ide" 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-03 7:23 ` Pekka Enberg
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13319] Page allocation failures with b43 and p54usb
@ 2009-07-03 7:23 ` Pekka Enberg
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-03 3:58 ` Wu Zhangjin
(?)
(?)
@ 2009-07-03 13:08 ` Bartlomiej Zolnierkiewicz
2009-07-03 15:31 ` Wu Zhangjin
-1 siblings, 1 reply; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-07-03 13:08 UTC (permalink / raw)
To: wuzhangjin
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Friday 03 July 2009 05:58:25 Wu Zhangjin wrote:
> On Thu, 2009-07-02 at 18:13 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 02 July 2009 03:46:43 Wu Zhangjin wrote:
> > > On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Wednesday 01 July 2009 18:21:25 Bartlomiej Zolnierkiewicz wrote:
> > > > > On Wednesday 01 July 2009 16:47:41 Wu Zhangjin wrote:
> > > > > > On Wed, 2009-07-01 at 22:31 +0800, Jeff Chua wrote:
> > > > > > > On Tue, Jun 30, 2009 at 12:21 AM, Jeff Chua<jeff.chua.linux@gmail.com> wrote:
> > > > > > >
> > > > > > > > I just tried, and it "seems" to work. Will try a few more cycles.
> > > > > > >
> > > > > > > STD/STR survived quite a few cycles now. Patch seems to be doing the
> > > > > > > right thing.
> > > > > > >
> > > > > > > On Mon, Jun 29, 2009 at 11:51 PM, Etienne
> > > > > > > Basset<etienne.basset@numericable.fr> wrote:
> > > > > > >
> > > > > > > > To have STR/resume work with current git, I have to :
> > > > > > >
> > > > > > > > 1) apply Bart's patch
> > > > > > >
> > > > > > > This is not yet in Linus's tree. And much needed to really fix the problem.
> > > > > > >
> > > > > > > > 2) revert this commit : a1317f714af7aed60ddc182d0122477cbe36ee9b
> > > > > > >
> > > > > >
> > > > > > Yes, This commit must be reverted, otherwise, STD/Hibernation will not
> > > > > > work either. I have tested it on two different loongson-based machines:
> > > > > > fuloong2e box and yeeloong2f netbook.(loongson is mips compatiable)
> > > > >
> > > > > Since it seems like Dave is taking his sweet time with doing the revert
> > > > > I stared at the code a bit more and I think that I finally found the bug
> > > > > (thanks to your debugging work for giving me the right hint!).
> > > > >
> > > > > The patch needs to take into the account a new code introduced by the recent
> > > > > block layer changes (commit 8f6205cd572fece673da0255d74843680f67f879):
> > > > >
> > > > > @@ -555,8 +560,11 @@ repeat:
> > > > > startstop = start_request(drive, rq);
> > > > > spin_lock_irq(&hwif->lock);
> > > > >
> > > > > - if (startstop == ide_stopped)
> > > > > + if (startstop == ide_stopped) {
> > > > > + rq = hwif->rq;
> > > > > + hwif->rq = NULL;
> > > > > goto repeat;
> > > > > + }
> > > > > } else
> > > > > goto plug_device;
> > > > > out:
> > > > >
> > > > > and not zero hwif->rq if the device is blocked.
> > > > >
> > > > > Could you try the attached patch and see if it fixes the issue?
> > > >
> > > > Here is the more complete version, also taking into the account changes
> > > > in ide_intr() and ide_timer_expiry():
> > > >
> > >
> > > Sorry, I can not apply this patch directly, which original version did
> > > you use? I used the one in the master branch of linux-mips development
> > > git repository.
> > >
> > > commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
> > > Merge: ec9c45d e18ed14
> > > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > > Date: Mon Jun 29 20:07:43 2009 -0700
> > >
> > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6
> > >
> > > * git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6:
> > > ide: memory overrun in ide_get_identity_ioctl() on big endian
> > > machines using ioctl HDIO_OBSOLETE_IDENTITY
> > > ide: fix resume for CONFIG_BLK_DEV_IDEACPI=y
> > > ide-cd: handle fragmented packet commands gracefully
> > > ide: always kill the whole request on error
> > > ide: fix ide_kill_rq() for special ide-{floppy,tape} driver
> > > requests
> > >
> > > it this too old? should i merge another git repository?
> >
> > Weird, I used linux-next but Linus' tree should also be fine
> > (as it matches linux-next w.r.t. ide currently).
>
> I just cloned the linux-next git repo, and tested your patch with
> STD/Hibernation, unfortunately, it also not work :-(
>
> here is the Call Trace:
>
> blk_delete_timer+0x0/0x20
> blk_requeue_request+0x24/0xd0
> ide_requeue_and_plug+0x38/0xb0
> ide_intr+0x120/0x300 ---> ide_intr....
> handle_IRQ_event+0x94/0x230
> handle_level_irq+0x7c/0x120
> mach_irq_dispatch+0xc8/0x158
> ret_from_irq+0x0/0x4
> cpu_idle+0x30/0x60
> start_kernel+0x330/0x34c
>
> If _NOT_ apply your patch and comment this part, it works:
OK, I see another gotcha added by recent changes, we need to explicitly
initialize rq_in_flight variables now. Revised patch below..
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: make resume work again (for real)
It turns out that commit a1317f714af7aed60ddc182d0122477cbe36ee9b
("ide: improve handling of Power Management requests") needs to take
into the account a new code added by the recent block layer changes
in commit 8f6205cd572fece673da0255d74843680f67f879 ("ide: dequeue
in-flight request") and prevent clearing of hwif->rq if the device
is blocked.
Thanks to Etienne, Wu and Jeff for help in fixing the issue.
Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
Reported-and-tested-by: Etienne Basset <etienne.basset@numericable.fr>
Reported-by: Wu Zhangjin <wuzhangjin@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
Added patch description, no other changes.
drivers/ide/ide-io.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
Index: b/drivers/ide/ide-io.c
===================================================================
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -532,7 +532,8 @@ repeat:
if (startstop == ide_stopped) {
rq = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
+ hwif->rq = NULL;
goto repeat;
}
} else
@@ -616,7 +617,7 @@ void ide_timer_expiry (unsigned long dat
unsigned long flags;
int wait = -1;
int plug_device = 0;
- struct request *uninitialized_var(rq_in_flight);
+ struct request *rq_in_flight = NULL;
spin_lock_irqsave(&hwif->lock, flags);
@@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
spin_lock_irq(&hwif->lock);
enable_irq(hwif->irq);
if (startstop == ide_stopped && hwif->polling == 0) {
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
@@ -775,7 +778,7 @@ irqreturn_t ide_intr (int irq, void *dev
ide_startstop_t startstop;
irqreturn_t irq_ret = IRQ_NONE;
int plug_device = 0;
- struct request *uninitialized_var(rq_in_flight);
+ struct request *rq_in_flight = NULL;
if (host->host_flags & IDE_HFLAG_SERIALIZE) {
if (hwif != host->cur_port)
@@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
*/
if (startstop == ide_stopped && hwif->polling == 0) {
BUG_ON(hwif->handler);
- rq_in_flight = hwif->rq;
- hwif->rq = NULL;
+ if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
+ rq_in_flight = hwif->rq;
+ hwif->rq = NULL;
+ }
ide_unlock_port(hwif);
plug_device = 1;
}
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-03 13:08 ` Bartlomiej Zolnierkiewicz
@ 2009-07-03 15:31 ` Wu Zhangjin
2009-07-06 14:57 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 211+ messages in thread
From: Wu Zhangjin @ 2009-07-03 15:31 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
Hi,
> OK, I see another gotcha added by recent changes, we need to explicitly
> initialize rq_in_flight variables now. Revised patch below..
>
Sorry, STD also not work. if apply this patch, the same problem as not
apply it, it stopped at:
...
PM: Crete hibernation image:
PM: Need to copy ... pages
PM: Hibernation image created ...
I think it's better to revert this commit:
a1317f714af7aed60ddc182d0122477cbe36ee9b ("ide: improve handling of
Power Management requests")
Regards,
Wu Zhangjin
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] ide: make resume work again (for real)
>
> It turns out that commit a1317f714af7aed60ddc182d0122477cbe36ee9b
> ("ide: improve handling of Power Management requests") needs to take
> into the account a new code added by the recent block layer changes
> in commit 8f6205cd572fece673da0255d74843680f67f879 ("ide: dequeue
> in-flight request") and prevent clearing of hwif->rq if the device
> is blocked.
>
> Thanks to Etienne, Wu and Jeff for help in fixing the issue.
>
> Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
> Reported-and-tested-by: Etienne Basset <etienne.basset@numericable.fr>
> Reported-by: Wu Zhangjin <wuzhangjin@gmail.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> Added patch description, no other changes.
>
> drivers/ide/ide-io.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> Index: b/drivers/ide/ide-io.c
> ===================================================================
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -532,7 +532,8 @@ repeat:
>
> if (startstop == ide_stopped) {
> rq = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0)
> + hwif->rq = NULL;
> goto repeat;
> }
> } else
> @@ -616,7 +617,7 @@ void ide_timer_expiry (unsigned long dat
> unsigned long flags;
> int wait = -1;
> int plug_device = 0;
> - struct request *uninitialized_var(rq_in_flight);
> + struct request *rq_in_flight = NULL;
>
> spin_lock_irqsave(&hwif->lock, flags);
>
> @@ -679,8 +680,10 @@ void ide_timer_expiry (unsigned long dat
> spin_lock_irq(&hwif->lock);
> enable_irq(hwif->irq);
> if (startstop == ide_stopped && hwif->polling == 0) {
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
> @@ -775,7 +778,7 @@ irqreturn_t ide_intr (int irq, void *dev
> ide_startstop_t startstop;
> irqreturn_t irq_ret = IRQ_NONE;
> int plug_device = 0;
> - struct request *uninitialized_var(rq_in_flight);
> + struct request *rq_in_flight = NULL;
>
> if (host->host_flags & IDE_HFLAG_SERIALIZE) {
> if (hwif != host->cur_port)
> @@ -856,8 +859,10 @@ irqreturn_t ide_intr (int irq, void *dev
> */
> if (startstop == ide_stopped && hwif->polling == 0) {
> BUG_ON(hwif->handler);
> - rq_in_flight = hwif->rq;
> - hwif->rq = NULL;
> + if ((drive->dev_flags & IDE_DFLAG_BLOCKED) == 0) {
> + rq_in_flight = hwif->rq;
> + hwif->rq = NULL;
> + }
> ide_unlock_port(hwif);
> plug_device = 1;
> }
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-03 15:31 ` Wu Zhangjin
@ 2009-07-06 14:57 ` Bartlomiej Zolnierkiewicz
2009-07-06 19:22 ` David Miller
0 siblings, 1 reply; 211+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-07-06 14:57 UTC (permalink / raw)
To: wuzhangjin
Cc: Jeff Chua, Etienne Basset, David Miller, rjw, linux-kernel,
kernel-testers, Ralf Baechle, linux-mips, linux-ide
On Friday 03 July 2009 17:31:36 Wu Zhangjin wrote:
> Hi,
>
> > OK, I see another gotcha added by recent changes, we need to explicitly
> > initialize rq_in_flight variables now. Revised patch below..
> >
>
> Sorry, STD also not work. if apply this patch, the same problem as not
> apply it, it stopped at:
>
> ...
> PM: Crete hibernation image:
> PM: Need to copy ... pages
> PM: Hibernation image created ...
>
> I think it's better to revert this commit:
> a1317f714af7aed60ddc182d0122477cbe36ee9b ("ide: improve handling of
> Power Management requests")
I completely agree and I've already requested this a week ago
(this commit was not meant for going straight to -rc tree anyway).
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13663] suspend to ram regression (IDE related)
2009-07-06 14:57 ` Bartlomiej Zolnierkiewicz
@ 2009-07-06 19:22 ` David Miller
0 siblings, 0 replies; 211+ messages in thread
From: David Miller @ 2009-07-06 19:22 UTC (permalink / raw)
To: bzolnier
Cc: wuzhangjin, jeff.chua.linux, etienne.basset, rjw, linux-kernel,
kernel-testers, ralf, linux-mips, linux-ide
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Mon, 6 Jul 2009 16:57:59 +0200
>> I think it's better to revert this commit:
>> a1317f714af7aed60ddc182d0122477cbe36ee9b ("ide: improve handling of
>> Power Management requests")
>
> I completely agree and I've already requested this a week ago
> (this commit was not meant for going straight to -rc tree anyway).
I'll revert this today and push that to Linus.
^ permalink raw reply [flat|nested] 211+ messages in thread
* [patch] slub: add option to disable higher order debugging slabs
@ 2009-07-07 6:02 ` David Rientjes
0 siblings, 0 replies; 211+ messages in thread
From: David Rientjes @ 2009-07-07 6:02 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
When debugging is enabled, slub requires that additional metadata be
stored in slabs for certain options: SLAB_RED_ZONE, SLAB_POISON, and
SLAB_STORE_USER.
Consequently, it may require that the minimum possible slab order needed
to allocate a single object be greater when using these options. The
most notable example is for objects that are PAGE_SIZE bytes in size.
Higher minimum slab orders may cause page allocation failures when oom or
under heavy fragmentation.
This patch adds a new slub_debug option, which disables debugging by
default for caches that would have resulted in higher minimum orders:
slub_debug=O
When this option is used on systems with 4K pages, kmalloc-4096, for
example, will not have debugging enabled by default even if
CONFIG_SLUB_DEBUG_ON is defined because it would have resulted in a
order-1 minimum slab order.
Cc: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: David Rientjes <rientjes@google.com>
---
Documentation/vm/slub.txt | 10 ++++++++++
mm/slub.c | 42 +++++++++++++++++++++++++++++++++++++++---
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt
--- a/Documentation/vm/slub.txt
+++ b/Documentation/vm/slub.txt
@@ -41,6 +41,8 @@ Possible debug options are
P Poisoning (object and padding)
U User tracking (free and alloc)
T Trace (please only use on single slabs)
+ O Switch debugging off for caches that would have
+ caused higher minimum slab orders
- Switch all debugging off (useful if the kernel is
configured with CONFIG_SLUB_DEBUG_ON)
@@ -59,6 +61,14 @@ to the dentry cache with
slub_debug=F,dentry
+Debugging options may require the minimum possible slab order to increase as
+a result of storing the metadata (for example, caches with PAGE_SIZE object
+sizes). This has a higher liklihood of resulting in slab allocation errors
+in low memory situations or if there's high fragmentation of memory. To
+switch off debugging for such caches by default, use
+
+ slub_debug=O
+
In case you forgot to enable debugging on the kernel command line: It is
possible to enable debugging manually when the kernel is up. Look at the
contents of:
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -142,6 +142,13 @@
SLAB_POISON | SLAB_STORE_USER)
/*
+ * Debugging flags that require metadata to be stored in the slab, up to
+ * DEBUG_SIZE in size.
+ */
+#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
+#define 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 | \
@@ -326,6 +333,7 @@ static int slub_debug;
#endif
static char *slub_debug_slabs;
+static int disable_higher_order_debug;
/*
* Object debugging
@@ -977,6 +985,15 @@ static int __init setup_slub_debug(char *str)
*/
goto check_slabs;
+ if (tolower(*str) == 'o') {
+ /*
+ * Avoid enabling debugging on caches if its minimum order
+ * would increase as a result.
+ */
+ disable_higher_order_debug = 1;
+ goto out;
+ }
+
slub_debug = 0;
if (*str == '-')
/*
@@ -1023,13 +1040,28 @@ 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 (slub_debug && (!slub_debug_slabs ||
- strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs)) == 0))
- flags |= slub_debug;
+ 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;
+ goto out;
+ flags |= debug_flags;
+ }
+out:
return flags;
}
#else
@@ -1561,6 +1593,10 @@ 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 (oo_order(s->min) > get_order(s->objsize))
+ printk(KERN_WARNING " %s debugging increased min order, use "
+ "slub_debug=O to disable.\n", 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] 211+ messages in thread
* [patch] slub: add option to disable higher order debugging slabs
@ 2009-07-07 6:02 ` David Rientjes
0 siblings, 0 replies; 211+ messages in thread
From: David Rientjes @ 2009-07-07 6:02 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
When debugging is enabled, slub requires that additional metadata be
stored in slabs for certain options: SLAB_RED_ZONE, SLAB_POISON, and
SLAB_STORE_USER.
Consequently, it may require that the minimum possible slab order needed
to allocate a single object be greater when using these options. The
most notable example is for objects that are PAGE_SIZE bytes in size.
Higher minimum slab orders may cause page allocation failures when oom or
under heavy fragmentation.
This patch adds a new slub_debug option, which disables debugging by
default for caches that would have resulted in higher minimum orders:
slub_debug=O
When this option is used on systems with 4K pages, kmalloc-4096, for
example, will not have debugging enabled by default even if
CONFIG_SLUB_DEBUG_ON is defined because it would have resulted in a
order-1 minimum slab order.
Cc: Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
Documentation/vm/slub.txt | 10 ++++++++++
mm/slub.c | 42 +++++++++++++++++++++++++++++++++++++++---
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt
--- a/Documentation/vm/slub.txt
+++ b/Documentation/vm/slub.txt
@@ -41,6 +41,8 @@ Possible debug options are
P Poisoning (object and padding)
U User tracking (free and alloc)
T Trace (please only use on single slabs)
+ O Switch debugging off for caches that would have
+ caused higher minimum slab orders
- Switch all debugging off (useful if the kernel is
configured with CONFIG_SLUB_DEBUG_ON)
@@ -59,6 +61,14 @@ to the dentry cache with
slub_debug=F,dentry
+Debugging options may require the minimum possible slab order to increase as
+a result of storing the metadata (for example, caches with PAGE_SIZE object
+sizes). This has a higher liklihood of resulting in slab allocation errors
+in low memory situations or if there's high fragmentation of memory. To
+switch off debugging for such caches by default, use
+
+ slub_debug=O
+
In case you forgot to enable debugging on the kernel command line: It is
possible to enable debugging manually when the kernel is up. Look at the
contents of:
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -142,6 +142,13 @@
SLAB_POISON | SLAB_STORE_USER)
/*
+ * Debugging flags that require metadata to be stored in the slab, up to
+ * DEBUG_SIZE in size.
+ */
+#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
+#define 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 | \
@@ -326,6 +333,7 @@ static int slub_debug;
#endif
static char *slub_debug_slabs;
+static int disable_higher_order_debug;
/*
* Object debugging
@@ -977,6 +985,15 @@ static int __init setup_slub_debug(char *str)
*/
goto check_slabs;
+ if (tolower(*str) == 'o') {
+ /*
+ * Avoid enabling debugging on caches if its minimum order
+ * would increase as a result.
+ */
+ disable_higher_order_debug = 1;
+ goto out;
+ }
+
slub_debug = 0;
if (*str == '-')
/*
@@ -1023,13 +1040,28 @@ 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 (slub_debug && (!slub_debug_slabs ||
- strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs)) == 0))
- flags |= slub_debug;
+ 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;
+ goto out;
+ flags |= debug_flags;
+ }
+out:
return flags;
}
#else
@@ -1561,6 +1593,10 @@ 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 (oo_order(s->min) > get_order(s->objsize))
+ printk(KERN_WARNING " %s debugging increased min order, use "
+ "slub_debug=O to disable.\n", 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] 211+ messages in thread
* [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-07 7:14 ` David Rientjes
0 siblings, 0 replies; 211+ messages in thread
From: David Rientjes @ 2009-07-07 7:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
When debugging is enabled, slub requires that additional metadata be
stored in slabs for certain options: SLAB_RED_ZONE, SLAB_POISON, and
SLAB_STORE_USER.
Consequently, it may require that the minimum possible slab order needed
to allocate a single object be greater when using these options. The
most notable example is for objects that are PAGE_SIZE bytes in size.
Higher minimum slab orders may cause page allocation failures when oom or
under heavy fragmentation.
This patch adds a new slub_debug option, which disables debugging by
default for caches that would have resulted in higher minimum orders:
slub_debug=O
When this option is used on systems with 4K pages, kmalloc-4096, for
example, will not have debugging enabled by default even if
CONFIG_SLUB_DEBUG_ON is defined because it would have resulted in a
order-1 minimum slab order.
Cc: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: David Rientjes <rientjes@google.com>
---
V1 -> V2: Removed spurious `goto out'.
Documentation/vm/slub.txt | 10 ++++++++++
mm/slub.c | 41 ++++++++++++++++++++++++++++++++++++++---
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt
--- a/Documentation/vm/slub.txt
+++ b/Documentation/vm/slub.txt
@@ -41,6 +41,8 @@ Possible debug options are
P Poisoning (object and padding)
U User tracking (free and alloc)
T Trace (please only use on single slabs)
+ O Switch debugging off for caches that would have
+ caused higher minimum slab orders
- Switch all debugging off (useful if the kernel is
configured with CONFIG_SLUB_DEBUG_ON)
@@ -59,6 +61,14 @@ to the dentry cache with
slub_debug=F,dentry
+Debugging options may require the minimum possible slab order to increase as
+a result of storing the metadata (for example, caches with PAGE_SIZE object
+sizes). This has a higher liklihood of resulting in slab allocation errors
+in low memory situations or if there's high fragmentation of memory. To
+switch off debugging for such caches by default, use
+
+ slub_debug=O
+
In case you forgot to enable debugging on the kernel command line: It is
possible to enable debugging manually when the kernel is up. Look at the
contents of:
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -142,6 +142,13 @@
SLAB_POISON | SLAB_STORE_USER)
/*
+ * Debugging flags that require metadata to be stored in the slab, up to
+ * DEBUG_SIZE in size.
+ */
+#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
+#define 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 | \
@@ -326,6 +333,7 @@ static int slub_debug;
#endif
static char *slub_debug_slabs;
+static int disable_higher_order_debug;
/*
* Object debugging
@@ -977,6 +985,15 @@ static int __init setup_slub_debug(char *str)
*/
goto check_slabs;
+ if (tolower(*str) == 'o') {
+ /*
+ * Avoid enabling debugging on caches if its minimum order
+ * would increase as a result.
+ */
+ disable_higher_order_debug = 1;
+ goto out;
+ }
+
slub_debug = 0;
if (*str == '-')
/*
@@ -1023,13 +1040,27 @@ 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 (slub_debug && (!slub_debug_slabs ||
- strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs)) == 0))
- flags |= slub_debug;
+ 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;
+ flags |= debug_flags;
+ }
+out:
return flags;
}
#else
@@ -1561,6 +1592,10 @@ 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 (oo_order(s->min) > get_order(s->objsize))
+ printk(KERN_WARNING " %s debugging increased min order, use "
+ "slub_debug=O to disable.\n", 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] 211+ messages in thread
* [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-07 7:14 ` David Rientjes
0 siblings, 0 replies; 211+ messages in thread
From: David Rientjes @ 2009-07-07 7:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
When debugging is enabled, slub requires that additional metadata be
stored in slabs for certain options: SLAB_RED_ZONE, SLAB_POISON, and
SLAB_STORE_USER.
Consequently, it may require that the minimum possible slab order needed
to allocate a single object be greater when using these options. The
most notable example is for objects that are PAGE_SIZE bytes in size.
Higher minimum slab orders may cause page allocation failures when oom or
under heavy fragmentation.
This patch adds a new slub_debug option, which disables debugging by
default for caches that would have resulted in higher minimum orders:
slub_debug=O
When this option is used on systems with 4K pages, kmalloc-4096, for
example, will not have debugging enabled by default even if
CONFIG_SLUB_DEBUG_ON is defined because it would have resulted in a
order-1 minimum slab order.
Cc: Christoph Lameter <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
V1 -> V2: Removed spurious `goto out'.
Documentation/vm/slub.txt | 10 ++++++++++
mm/slub.c | 41 ++++++++++++++++++++++++++++++++++++++---
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt
--- a/Documentation/vm/slub.txt
+++ b/Documentation/vm/slub.txt
@@ -41,6 +41,8 @@ Possible debug options are
P Poisoning (object and padding)
U User tracking (free and alloc)
T Trace (please only use on single slabs)
+ O Switch debugging off for caches that would have
+ caused higher minimum slab orders
- Switch all debugging off (useful if the kernel is
configured with CONFIG_SLUB_DEBUG_ON)
@@ -59,6 +61,14 @@ to the dentry cache with
slub_debug=F,dentry
+Debugging options may require the minimum possible slab order to increase as
+a result of storing the metadata (for example, caches with PAGE_SIZE object
+sizes). This has a higher liklihood of resulting in slab allocation errors
+in low memory situations or if there's high fragmentation of memory. To
+switch off debugging for such caches by default, use
+
+ slub_debug=O
+
In case you forgot to enable debugging on the kernel command line: It is
possible to enable debugging manually when the kernel is up. Look at the
contents of:
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -142,6 +142,13 @@
SLAB_POISON | SLAB_STORE_USER)
/*
+ * Debugging flags that require metadata to be stored in the slab, up to
+ * DEBUG_SIZE in size.
+ */
+#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
+#define 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 | \
@@ -326,6 +333,7 @@ static int slub_debug;
#endif
static char *slub_debug_slabs;
+static int disable_higher_order_debug;
/*
* Object debugging
@@ -977,6 +985,15 @@ static int __init setup_slub_debug(char *str)
*/
goto check_slabs;
+ if (tolower(*str) == 'o') {
+ /*
+ * Avoid enabling debugging on caches if its minimum order
+ * would increase as a result.
+ */
+ disable_higher_order_debug = 1;
+ goto out;
+ }
+
slub_debug = 0;
if (*str == '-')
/*
@@ -1023,13 +1040,27 @@ 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 (slub_debug && (!slub_debug_slabs ||
- strncmp(slub_debug_slabs, name, strlen(slub_debug_slabs)) == 0))
- flags |= slub_debug;
+ 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;
+ flags |= debug_flags;
+ }
+out:
return flags;
}
#else
@@ -1561,6 +1592,10 @@ 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 (oo_order(s->min) > get_order(s->objsize))
+ printk(KERN_WARNING " %s debugging increased min order, use "
+ "slub_debug=O to disable.\n", 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] 211+ messages in thread
* Re: [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
@ 2009-07-07 14:05 ` Américo Wang
0 siblings, 0 replies; 211+ messages in thread
From: Américo Wang @ 2009-07-07 14:05 UTC (permalink / raw)
To: Joao Correia; +Cc: Rafael J. Wysocki, linux-kernel, kernel-testers
On Thu, Jul 2, 2009 at 4:36 AM, Joao Correia<joaomiguelcorreia@gmail.com> wrote:
> No formal patch has been sent yet, that i am aware of. I have made
> some changes following suggestion by Americo Wang advise, to the
> following:
>
> (patch by Ingo)
>
> diff --git a/kernel/lockdep_internals.h b/kernel/lockdep_internals.h
> index 699a2ac..031f4c6 100644
> --- a/kernel/lockdep_internals.h
> +++ b/kernel/lockdep_internals.h
> @@ -65,7 +65,7 @@ enum {
> * Stack-trace: tightly packed array of stack backtrace
> * addresses. Protected by the hash_lock.
> */
> -#define MAX_STACK_TRACE_ENTRIES 262144UL
> +#define MAX_STACK_TRACE_ENTRIES 1048576UL
>
> extern struct list_head all_lock_classes;
> extern struct lock_chain lock_chains[];
>
> and afterwards, a new bug popped up, solved by changing
>
> include/linux/sched.h
>
> # define MAX_LOCK_DEPTH 48UL
>
> to
>
> # define MAX_LOCK_DEPTH 96UL
>
>
> I have now found a third limit bug, related to MAX_LOCKDEP_CHAINS,
> which was hidden so far, which im trying to raise and replicate. This
> is being discussed in detail in another message exchange on the lkml,
> between me and Americo.
How about changing MAX_LOCKDEP_CHAINS_BITS to 16?
kernel/lockdep_internals.h:59:#define MAX_LOCKDEP_CHAINS_BITS 15
And can you make a complete patch and send it to lkml with Peter and me
Cc'ed?
Thank you!
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
@ 2009-07-07 14:05 ` Américo Wang
0 siblings, 0 replies; 211+ messages in thread
From: Américo Wang @ 2009-07-07 14:05 UTC (permalink / raw)
To: Joao Correia
Cc: Rafael J. Wysocki, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA
On Thu, Jul 2, 2009 at 4:36 AM, Joao Correia<joaomiguelcorreia-Re5JQEeQqe8@public.gmane.orgm> wrote:
> No formal patch has been sent yet, that i am aware of. I have made
> some changes following suggestion by Americo Wang advise, to the
> following:
>
> (patch by Ingo)
>
> diff --git a/kernel/lockdep_internals.h b/kernel/lockdep_internals.h
> index 699a2ac..031f4c6 100644
> --- a/kernel/lockdep_internals.h
> +++ b/kernel/lockdep_internals.h
> @@ -65,7 +65,7 @@ enum {
> * Stack-trace: tightly packed array of stack backtrace
> * addresses. Protected by the hash_lock.
> */
> -#define MAX_STACK_TRACE_ENTRIES 262144UL
> +#define MAX_STACK_TRACE_ENTRIES 1048576UL
>
> extern struct list_head all_lock_classes;
> extern struct lock_chain lock_chains[];
>
> and afterwards, a new bug popped up, solved by changing
>
> include/linux/sched.h
>
> # define MAX_LOCK_DEPTH 48UL
>
> to
>
> # define MAX_LOCK_DEPTH 96UL
>
>
> I have now found a third limit bug, related to MAX_LOCKDEP_CHAINS,
> which was hidden so far, which im trying to raise and replicate. This
> is being discussed in detail in another message exchange on the lkml,
> between me and Americo.
How about changing MAX_LOCKDEP_CHAINS_BITS to 16?
kernel/lockdep_internals.h:59:#define MAX_LOCKDEP_CHAINS_BITS 15
And can you make a complete patch and send it to lkml with Peter and me
Cc'ed?
Thank you!
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
@ 2009-07-07 14:22 ` Joao Correia
0 siblings, 0 replies; 211+ messages in thread
From: Joao Correia @ 2009-07-07 14:22 UTC (permalink / raw)
To: Américo Wang; +Cc: Rafael J. Wysocki, linux-kernel, kernel-testers
Already testing the changes, just to see if something else breaks.
Any special notes on the patch (a basic guideline info on patches
would be great, just so i dont mess it up)? Never submited one before.
Joao Correia
On Tue, Jul 7, 2009 at 3:05 PM, Américo Wang<xiyou.wangcong@gmail.com> wrote:
> On Thu, Jul 2, 2009 at 4:36 AM, Joao Correia<joaomiguelcorreia@gmail.com> wrote:
>> No formal patch has been sent yet, that i am aware of. I have made
>> some changes following suggestion by Americo Wang advise, to the
>> following:
>>
>> (patch by Ingo)
>>
>> diff --git a/kernel/lockdep_internals.h b/kernel/lockdep_internals.h
>> index 699a2ac..031f4c6 100644
>> --- a/kernel/lockdep_internals.h
>> +++ b/kernel/lockdep_internals.h
>> @@ -65,7 +65,7 @@ enum {
>> * Stack-trace: tightly packed array of stack backtrace
>> * addresses. Protected by the hash_lock.
>> */
>> -#define MAX_STACK_TRACE_ENTRIES 262144UL
>> +#define MAX_STACK_TRACE_ENTRIES 1048576UL
>>
>> extern struct list_head all_lock_classes;
>> extern struct lock_chain lock_chains[];
>>
>> and afterwards, a new bug popped up, solved by changing
>>
>> include/linux/sched.h
>>
>> # define MAX_LOCK_DEPTH 48UL
>>
>> to
>>
>> # define MAX_LOCK_DEPTH 96UL
>>
>>
>> I have now found a third limit bug, related to MAX_LOCKDEP_CHAINS,
>> which was hidden so far, which im trying to raise and replicate. This
>> is being discussed in detail in another message exchange on the lkml,
>> between me and Americo.
>
> How about changing MAX_LOCKDEP_CHAINS_BITS to 16?
>
> kernel/lockdep_internals.h:59:#define MAX_LOCKDEP_CHAINS_BITS 15
>
> And can you make a complete patch and send it to lkml with Peter and me
> Cc'ed?
>
> Thank you!
>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
@ 2009-07-07 14:22 ` Joao Correia
0 siblings, 0 replies; 211+ messages in thread
From: Joao Correia @ 2009-07-07 14:22 UTC (permalink / raw)
To: Américo Wang
Cc: Rafael J. Wysocki, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA
Already testing the changes, just to see if something else breaks.
Any special notes on the patch (a basic guideline info on patches
would be great, just so i dont mess it up)? Never submited one before.
Joao Correia
On Tue, Jul 7, 2009 at 3:05 PM, Américo Wang<xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jul 2, 2009 at 4:36 AM, Joao Correia<joaomiguelcorreia@gmail.com> wrote:
>> No formal patch has been sent yet, that i am aware of. I have made
>> some changes following suggestion by Americo Wang advise, to the
>> following:
>>
>> (patch by Ingo)
>>
>> diff --git a/kernel/lockdep_internals.h b/kernel/lockdep_internals.h
>> index 699a2ac..031f4c6 100644
>> --- a/kernel/lockdep_internals.h
>> +++ b/kernel/lockdep_internals.h
>> @@ -65,7 +65,7 @@ enum {
>> * Stack-trace: tightly packed array of stack backtrace
>> * addresses. Protected by the hash_lock.
>> */
>> -#define MAX_STACK_TRACE_ENTRIES 262144UL
>> +#define MAX_STACK_TRACE_ENTRIES 1048576UL
>>
>> extern struct list_head all_lock_classes;
>> extern struct lock_chain lock_chains[];
>>
>> and afterwards, a new bug popped up, solved by changing
>>
>> include/linux/sched.h
>>
>> # define MAX_LOCK_DEPTH 48UL
>>
>> to
>>
>> # define MAX_LOCK_DEPTH 96UL
>>
>>
>> I have now found a third limit bug, related to MAX_LOCKDEP_CHAINS,
>> which was hidden so far, which im trying to raise and replicate. This
>> is being discussed in detail in another message exchange on the lkml,
>> between me and Americo.
>
> How about changing MAX_LOCKDEP_CHAINS_BITS to 16?
>
> kernel/lockdep_internals.h:59:#define MAX_LOCKDEP_CHAINS_BITS 15
>
> And can you make a complete patch and send it to lkml with Peter and me
> Cc'ed?
>
> Thank you!
>
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
2009-07-07 14:22 ` Joao Correia
(?)
@ 2009-07-07 14:44 ` Américo Wang
-1 siblings, 0 replies; 211+ messages in thread
From: Américo Wang @ 2009-07-07 14:44 UTC (permalink / raw)
To: Joao Correia; +Cc: Rafael J. Wysocki, linux-kernel, kernel-testers
On Tue, Jul 7, 2009 at 10:22 PM, Joao
Correia<joaomiguelcorreia@gmail.com> wrote:
> Already testing the changes, just to see if something else breaks.
>
> Any special notes on the patch (a basic guideline info on patches
> would be great, just so i dont mess it up)? Never submited one before.
Yes, check Documentation/SubmittingPatches and Documentation/email-clients.txt.
I am not sure if Peter likes them, but it is a good idea to split them
and send one by one.
Good luck!
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-07 15:57 ` Christoph Lameter
0 siblings, 0 replies; 211+ messages in thread
From: Christoph Lameter @ 2009-07-07 15:57 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, 7 Jul 2009, David Rientjes wrote:
> + * Debugging flags that require metadata to be stored in the slab, up to
> + * DEBUG_SIZE in size.
> + */
> +#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
> +#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
There is no need for DEBUG_SIZE since slub keeps both the size of the
object kmem_cache->objsize and the size with the metadata kmem_cache->size
If the order of both is different then the order would increase.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-07 15:57 ` Christoph Lameter
0 siblings, 0 replies; 211+ messages in thread
From: Christoph Lameter @ 2009-07-07 15:57 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, 7 Jul 2009, David Rientjes wrote:
> + * Debugging flags that require metadata to be stored in the slab, up to
> + * DEBUG_SIZE in size.
> + */
> +#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
> +#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
There is no need for DEBUG_SIZE since slub keeps both the size of the
object kmem_cache->objsize and the size with the metadata kmem_cache->size
If the order of both is different then the order would increase.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-09 23:26 ` David Rientjes
0 siblings, 0 replies; 211+ messages in thread
From: David Rientjes @ 2009-07-09 23:26 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, 7 Jul 2009, Christoph Lameter wrote:
> > + * Debugging flags that require metadata to be stored in the slab, up to
> > + * DEBUG_SIZE in size.
> > + */
> > +#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
> > +#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
>
> There is no need for DEBUG_SIZE since slub keeps both the size of the
> object kmem_cache->objsize and the size with the metadata kmem_cache->size
>
> If the order of both is different then the order would increase.
>
Without DEBUG_SIZE_FLAGS, the only way to determine what flags have
increased the size is in calculate_sizes() and then disable them by
default if slub_debug=O is specified. calculate_sizes() is used by
the `store', `poison', and `red_zone' callbacks, so the admin still has
the ability to enable these options even though slub_debug=O was used.
So we can either mask off the size-increasing debug bits when the cache is
created in kmem_cache_flags() like I did, or we can move the logic to
calculate_sizes() with an added formal to determine whether this is from
kmem_cache_open() or one of the attribute callbacks.
I think my solution is the cleanest and provides a single entity,
DEBUG_SIZE_FLAGS, which specifies the flags that slub_debug=O clears if
the minimum order increases.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-09 23:26 ` David Rientjes
0 siblings, 0 replies; 211+ messages in thread
From: David Rientjes @ 2009-07-09 23:26 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, 7 Jul 2009, Christoph Lameter wrote:
> > + * Debugging flags that require metadata to be stored in the slab, up to
> > + * DEBUG_SIZE in size.
> > + */
> > +#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
> > +#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
>
> There is no need for DEBUG_SIZE since slub keeps both the size of the
> object kmem_cache->objsize and the size with the metadata kmem_cache->size
>
> If the order of both is different then the order would increase.
>
Without DEBUG_SIZE_FLAGS, the only way to determine what flags have
increased the size is in calculate_sizes() and then disable them by
default if slub_debug=O is specified. calculate_sizes() is used by
the `store', `poison', and `red_zone' callbacks, so the admin still has
the ability to enable these options even though slub_debug=O was used.
So we can either mask off the size-increasing debug bits when the cache is
created in kmem_cache_flags() like I did, or we can move the logic to
calculate_sizes() with an added formal to determine whether this is from
kmem_cache_open() or one of the attribute callbacks.
I think my solution is the cleanest and provides a single entity,
DEBUG_SIZE_FLAGS, which specifies the flags that slub_debug=O clears if
the minimum order increases.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-10 6:54 ` Pekka Enberg
0 siblings, 0 replies; 211+ messages in thread
From: Pekka Enberg @ 2009-07-10 6:54 UTC (permalink / raw)
To: David Rientjes
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
On Tue, 7 Jul 2009, Christoph Lameter wrote:
> > > + * Debugging flags that require metadata to be stored in the slab, up to
> > > + * DEBUG_SIZE in size.
> > > + */
> > > +#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
> > > +#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
> >
> > There is no need for DEBUG_SIZE since slub keeps both the size of the
> > object kmem_cache->objsize and the size with the metadata kmem_cache->size
> >
> > If the order of both is different then the order would increase.
On Thu, 2009-07-09 at 16:26 -0700, David Rientjes wrote:
> Without DEBUG_SIZE_FLAGS, the only way to determine what flags have
> increased the size is in calculate_sizes() and then disable them by
> default if slub_debug=O is specified. calculate_sizes() is used by
> the `store', `poison', and `red_zone' callbacks, so the admin still has
> the ability to enable these options even though slub_debug=O was used.
>
> So we can either mask off the size-increasing debug bits when the cache is
> created in kmem_cache_flags() like I did, or we can move the logic to
> calculate_sizes() with an added formal to determine whether this is from
> kmem_cache_open() or one of the attribute callbacks.
>
> I think my solution is the cleanest and provides a single entity,
> DEBUG_SIZE_FLAGS, which specifies the flags that slub_debug=O clears if
> the minimum order increases.
Yup, agreed. I applied the patch, thanks everyone!
Pekka
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-10 6:54 ` Pekka Enberg
0 siblings, 0 replies; 211+ messages in thread
From: Pekka Enberg @ 2009-07-10 6:54 UTC (permalink / raw)
To: David Rientjes
Cc: Christoph Lameter, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
On Tue, 7 Jul 2009, Christoph Lameter wrote:
> > > + * Debugging flags that require metadata to be stored in the slab, up to
> > > + * DEBUG_SIZE in size.
> > > + */
> > > +#define DEBUG_SIZE_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
> > > +#define DEBUG_SIZE (3 * sizeof(void *) + 2 * sizeof(struct track))
> >
> > There is no need for DEBUG_SIZE since slub keeps both the size of the
> > object kmem_cache->objsize and the size with the metadata kmem_cache->size
> >
> > If the order of both is different then the order would increase.
On Thu, 2009-07-09 at 16:26 -0700, David Rientjes wrote:
> Without DEBUG_SIZE_FLAGS, the only way to determine what flags have
> increased the size is in calculate_sizes() and then disable them by
> default if slub_debug=O is specified. calculate_sizes() is used by
> the `store', `poison', and `red_zone' callbacks, so the admin still has
> the ability to enable these options even though slub_debug=O was used.
>
> So we can either mask off the size-increasing debug bits when the cache is
> created in kmem_cache_flags() like I did, or we can move the logic to
> calculate_sizes() with an added formal to determine whether this is from
> kmem_cache_open() or one of the attribute callbacks.
>
> I think my solution is the cleanest and provides a single entity,
> DEBUG_SIZE_FLAGS, which specifies the flags that slub_debug=O clears if
> the minimum order increases.
Yup, agreed. I applied the patch, thanks everyone!
Pekka
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [patch v2] slub: add option to disable higher order debugging slabs
2009-07-10 6:54 ` Pekka Enberg
@ 2009-07-10 18:47 ` Christoph Lameter
-1 siblings, 0 replies; 211+ messages in thread
From: Christoph Lameter @ 2009-07-10 18:47 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
On Fri, 10 Jul 2009, Pekka Enberg wrote:
> On Thu, 2009-07-09 at 16:26 -0700, David Rientjes wrote:
> > Without DEBUG_SIZE_FLAGS, the only way to determine what flags have
> > increased the size is in calculate_sizes() and then disable them by
> > default if slub_debug=O is specified. calculate_sizes() is used by
> > the `store', `poison', and `red_zone' callbacks, so the admin still has
> > the ability to enable these options even though slub_debug=O was used.
> >
> > So we can either mask off the size-increasing debug bits when the cache is
> > created in kmem_cache_flags() like I did, or we can move the logic to
> > calculate_sizes() with an added formal to determine whether this is from
> > kmem_cache_open() or one of the attribute callbacks.
> >
> > I think my solution is the cleanest and provides a single entity,
> > DEBUG_SIZE_FLAGS, which specifies the flags that slub_debug=O clears if
> > the minimum order increases.
>
> Yup, agreed. I applied the patch, thanks everyone!
There is a simpler solution. Call calculate sizes again if the resulting
sizes increased the order. Something like this.
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2009-07-10 13:45:02.000000000 -0500
+++ linux-2.6/mm/slub.c 2009-07-10 13:46:07.000000000 -0500
@@ -2454,6 +2454,10 @@ static int kmem_cache_open(struct kmem_c
if (!calculate_sizes(s, -1))
goto error;
+ if (get_order(s->size) != get_order(s->objsize) && flag is set) {
+ switch off debug flags.
+ calculate_sizes(s, -1);
+ }
/*
* The larger the object size is, the more pages we want on the
partial
* list to avoid pounding the page allocator excessively.
^ permalink raw reply [flat|nested] 211+ messages in thread
* Re: [patch v2] slub: add option to disable higher order debugging slabs
@ 2009-07-10 18:47 ` Christoph Lameter
0 siblings, 0 replies; 211+ messages in thread
From: Christoph Lameter @ 2009-07-10 18:47 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Larry Finger, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Johannes Berg
On Fri, 10 Jul 2009, Pekka Enberg wrote:
> On Thu, 2009-07-09 at 16:26 -0700, David Rientjes wrote:
> > Without DEBUG_SIZE_FLAGS, the only way to determine what flags have
> > increased the size is in calculate_sizes() and then disable them by
> > default if slub_debug=O is specified. calculate_sizes() is used by
> > the `store', `poison', and `red_zone' callbacks, so the admin still has
> > the ability to enable these options even though slub_debug=O was used.
> >
> > So we can either mask off the size-increasing debug bits when the cache is
> > created in kmem_cache_flags() like I did, or we can move the logic to
> > calculate_sizes() with an added formal to determine whether this is from
> > kmem_cache_open() or one of the attribute callbacks.
> >
> > I think my solution is the cleanest and provides a single entity,
> > DEBUG_SIZE_FLAGS, which specifies the flags that slub_debug=O clears if
> > the minimum order increases.
>
> Yup, agreed. I applied the patch, thanks everyone!
There is a simpler solution. Call calculate sizes again if the resulting
sizes increased the order. Something like this.
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2009-07-10 13:45:02.000000000 -0500
+++ linux-2.6/mm/slub.c 2009-07-10 13:46:07.000000000 -0500
@@ -2454,6 +2454,10 @@ static int kmem_cache_open(struct kmem_c
if (!calculate_sizes(s, -1))
goto error;
+ if (get_order(s->size) != get_order(s->objsize) && flag is set) {
+ switch off debug flags.
+ calculate_sizes(s, -1);
+ }
/*
* The larger the object size is, the more pages we want on the
partial
* list to avoid pounding the page allocator excessively.
^ permalink raw reply [flat|nested] 211+ messages in thread
end of thread, other threads:[~2009-07-10 18:47 UTC | newest]
Thread overview: 211+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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:26 ` Rafael J. Wysocki
2009-06-29 0:26 ` [Bug #13109] High latency on /sys/class/thermal Rafael J. Wysocki
2009-06-29 0:26 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13119] Trouble with make-install from a NFS mount Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13277] 2.6.30 regression - hang on 2nd resume - bisected - Thinkpad X40 Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13318] AGP doesn't work anymore on nforce2 Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [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-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13179] CD-R: wodim intermittent failures Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13306] hibernate slow on _second_ run Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13341] Random Oops at boot at loading ip6tables rules Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear 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-07-07 6:02 ` [patch] slub: add option to disable higher order debugging slabs David Rientjes
2009-07-07 6:02 ` David Rientjes
2009-07-07 7:14 ` [patch v2] " David Rientjes
2009-07-07 7:14 ` David Rientjes
2009-07-07 15:57 ` Christoph Lameter
2009-07-07 15:57 ` Christoph Lameter
2009-07-09 23:26 ` David Rientjes
2009-07-09 23:26 ` David Rientjes
2009-07-10 6:54 ` Pekka Enberg
2009-07-10 6:54 ` Pekka Enberg
2009-07-10 18:47 ` Christoph Lameter
2009-07-10 18:47 ` Christoph Lameter
2009-06-29 0:30 ` [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13362] rt2x00: slow wifi with correct basic rate bitmap Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-30 18:37 ` Alejandro Riveira Fernández
2009-06-30 18:37 ` Alejandro Riveira Fernández
2009-06-29 0:30 ` [Bug #13374] reiserfs blocked for more than 120secs Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13351] 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13401] pktcdvd writing is really slow with CFQ scheduler (bisected) Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13424] possible deadlock when doing governor switching Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 1:25 ` Mathieu Desnoyers
2009-06-29 1:25 ` Mathieu Desnoyers
2009-06-29 18:37 ` Pallipadi, Venkatesh
2009-06-29 18:37 ` Pallipadi, Venkatesh
2009-06-29 19:05 ` Mathieu Desnoyers
2009-06-29 19:05 ` Mathieu Desnoyers
2009-06-29 0:30 ` [Bug #13408] Performance regression in 2.6.30-rc7 Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13389] Warning 'Invalid throttling state, reset' gets displayed when it should not be Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13407] adb trackpad disappears after suspend to ram Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13472] Oops with minicom and USB serial Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13471] Loading parport_pc kills the keyboard if ACPI is enabled Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13512] D43 on 2.6.30 doesn't suspend anymore Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 6:21 ` Daniel Smolik
2009-06-29 6:21 ` Daniel Smolik
2009-06-29 23:20 ` Rafael J. Wysocki
2009-06-29 23:20 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13502] GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13475] suspend/hibernate lockdep warning Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13528] au0828: major drop in reception quality between 2.6.29.4 and 2.6.30 on HVR-950q Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13514] acer_wmi causes stack corruption Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13518] slab grows with NFS write activity Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 0:30 ` [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Rafael J. Wysocki
2009-06-29 0:30 ` Rafael J. Wysocki
2009-06-29 3:27 ` Jos van Wolput
2009-06-29 3:27 ` Jos van Wolput
2009-06-29 23:24 ` Rafael J. Wysocki
2009-06-29 23:24 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13581] ath9k doesn't work with newer kernels Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13621] xfs hangs with assertion failed Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13613] lockups with JFS (inconsistent lock state) Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13558] Tracelog during resume Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13620] acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13634] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13646] warn_on tty_io.c, broken bluetooth Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13644] hibernation/swsusp lockup due to acpi-cpufreq Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-30 0:40 ` Johannes Stezenbach
2009-06-30 12:48 ` Rafael J. Wysocki
2009-06-30 12:48 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13624] usb: wrong autosuspend initialization Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13647] fb/mmap lockdep report Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13648] nfsd: page allocation failure Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-30 0:02 ` David Rientjes
2009-06-30 8:05 ` Justin Piszcz
2009-06-30 8:05 ` Justin Piszcz
2009-06-30 8:48 ` David Rientjes
2009-06-30 8:48 ` David Rientjes
2009-06-29 0:31 ` [Bug #13649] Bad page state in process with various applications Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13651] Anyone know what happened with PC speaker in 2.6.30? Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13660] Crashes during boot on 2.6.30 / 2.6.31-rc, random programs Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-07-01 20:36 ` Joao Correia
2009-07-01 20:36 ` Joao Correia
2009-07-07 14:05 ` Américo Wang
2009-07-07 14:05 ` Américo Wang
2009-07-07 14:22 ` Joao Correia
2009-07-07 14:22 ` Joao Correia
2009-07-07 14:44 ` Américo Wang
2009-06-29 0:31 ` [Bug #13663] suspend to ram regression (IDE related) Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 10:29 ` Etienne Basset
2009-06-29 10:37 ` David Miller
2009-06-29 15:51 ` Etienne Basset
2009-06-29 15:51 ` Etienne Basset
2009-06-29 16:21 ` Jeff Chua
2009-06-29 16:21 ` Jeff Chua
2009-07-01 14:31 ` Jeff Chua
2009-07-01 14:31 ` Jeff Chua
[not found] ` <b6a2187b0907010731k510150b5u1c7fce8cbed7c33b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-07-01 14:47 ` Wu Zhangjin
2009-07-01 14:47 ` Wu Zhangjin
2009-07-01 16:21 ` Bartlomiej Zolnierkiewicz
[not found] ` <200907011821.26091.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-07-01 16:29 ` Bartlomiej Zolnierkiewicz
2009-07-01 16:29 ` Bartlomiej Zolnierkiewicz
[not found] ` <200907011829.16850.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-07-01 17:28 ` Jeff Chua
2009-07-01 17:28 ` Jeff Chua
2009-07-01 17:28 ` Jeff Chua
[not found] ` <b6a2187b0907011028r27d35be4xc62c7ed4496dfb2f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-07-01 21:30 ` Etienne Basset
2009-07-01 21:30 ` Etienne Basset
2009-07-02 1:46 ` Wu Zhangjin
2009-07-02 1:46 ` Wu Zhangjin
2009-07-02 2:09 ` Jeff Chua
2009-07-02 2:09 ` Jeff Chua
2009-07-02 10:46 ` Ralf Baechle
2009-07-02 10:46 ` Ralf Baechle
2009-07-02 16:13 ` Bartlomiej Zolnierkiewicz
2009-07-02 16:13 ` Bartlomiej Zolnierkiewicz
[not found] ` <200907021813.57322.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-07-03 3:58 ` Wu Zhangjin
2009-07-03 3:58 ` Wu Zhangjin
2009-07-03 4:06 ` Wu Zhangjin
2009-07-03 13:08 ` Bartlomiej Zolnierkiewicz
2009-07-03 15:31 ` Wu Zhangjin
2009-07-06 14:57 ` Bartlomiej Zolnierkiewicz
2009-07-06 19:22 ` David Miller
2009-06-29 17:45 ` Bartlomiej Zolnierkiewicz
2009-06-29 17:45 ` Bartlomiej Zolnierkiewicz
2009-06-29 0:31 ` [Bug #13668] Can't boot 2.6.30 powerpc kernel under qemu Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
2009-06-29 0:31 ` [Bug #13669] Kernel bug with dock driver Rafael J. Wysocki
2009-06-29 0:31 ` Rafael J. Wysocki
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.