2.6.30-rc7: Reported regressions from 2.6.29

2.6.30-rc7: Reported regressions from 2.6.29

[Rafael J. Wysocki]

[NOTE:
 Bug entries for which I know there are working patches get the
 RESOLVED / PATCH_ALREADY_AVAILABLE status in the Bugzilla, which
 makes it easier to check if the patches have been merged before sending
 out the list.  For this reason, please let me know of working patches
 for any of the regression list items or (better) change the status of the bug
 entries in case you know of a working patch (in which case please also add
 a link to the patch to the appropriate bug entry).]

This message contains a list of some regressions from 2.6.29, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.29, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-05-24       92       34          27
  2009-05-16       81       36          33
  2009-04-25       55       36          26
  2009-04-17       37       35          28


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13377
Subject		: Microphone no longer works on Toshiba Satellite A100
Submitter	: M. Vefa Bicakci <bicave@superonline.com>
Date		: 2009-05-24 15:49 (1 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=23f0c048ba59ad5c2f3fd85ed98360b631dbf6f8
References	: http://marc.info/?l=linux-kernel&m=124318383910011&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject		: reiserfs blocked for more than 120secs
Submitter	: Harald Dunkel <harald.dunkel@t-online.de>
Date		: 2009-05-23 8:52 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124306880410811&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject		: fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2009-05-23 5:08 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124305538130702&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13372
Subject		: Oops in usb-serial with keyspan adapter
Submitter	: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date		: 2009-05-18 0:07 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124260532924736&w=4
Handled-By	: Alan Stern <stern@rowland.harvard.edu>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13366
Subject		: About 80% of shutdowns fail (blocking)
Submitter	: Martin Bammer <mrb74@gmx.at>
Date		: 2009-05-23 00:58 (2 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject		: Random Oops at boot at loading ip6tables rules
Submitter	:  <patrick@ostenberg.de>
Date		: 2009-05-19 09:08 (6 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject		: rtable leak in ipv4/route.c
Submitter	: Alexander V. Lukyanov <lav@yar.ru>
Date		: 2009-05-18 14:10 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13331
Subject		: FUTEX_LOCK_PI kills kernel
Submitter	: Andreas Schwab <schwab@linux-m68k.org>
Date		: 2009-05-17 09:51 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13330
Subject		: nfs4 NULL pointer dereference in _nfs4_do_setlk
Submitter	: Rich Ercolani <rercola@acm.jhu.edu>
Date		: 2009-05-17 04:44 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject		: b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter	: Francis Moreau <francis.moro@gmail.com>
Date		: 2009-05-03 16:22 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4


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


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


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject		: Page allocation failures with b43 and p54usb
Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
Date		: 2009-04-29 21:01 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
Handled-By	: Johannes Berg <johannes@sipsolutions.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject		: AGP doesn't work anymore on nforce2
Submitter	: Karsten Mehrhoff <kawime@gmx.de>
Date		: 2009-04-30 8:51 (25 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By	: Shaohua Li <shaohua.li@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject		: hibernate slow on _second_ run
Submitter	: Johannes Berg <johannes@sipsolutions.net>
Date		: 2009-05-14 09:34 (11 days old)


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


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject		: Since kernel 2.6.30-rc1, computers hangs randomly ..
Submitter	: David Hill <hilld@binarystorm.net>
Date		: 2009-05-01 16:57 (24 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject		: 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter	: Niel Lambrechts <niel.lambrechts@gmail.com>
Date		: 2009-04-21 21:35 (34 days old)
References	: http://marc.info/?l=linux-kernel&m=124034980819102&w=4
		  http://lkml.org/lkml/2009/4/27/290


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13179
Subject		: CD-R: wodim intermittent failures
Submitter	: Andy Isaacson <adi@hexapodia.org>
Date		: 2009-04-21 1:52 (34 days old)
References	: http://marc.info/?l=linux-kernel&m=124027879214231&w=4


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


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


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


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


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


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13378
Subject		: kernel/async.c broke pata_legacy.c
Submitter	: Mikael Pettersson <mikpe@it.uu.se>
Date		: 2009-05-24 16:13 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124318186507210&w=4
Handled-By	: James Bottomley <James.Bottomley@hansenpartnership.com>
Patch		: http://patchwork.kernel.org/patch/25699/


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13277
Subject		: Thinkpad X40 no longer resumes reliable since ff69f2bba67bd45514923aaedbf40fe351787c59
Submitter	: Daniel Vetter <daniel@ffwll.ch>
Date		: 2009-05-11 10:08 (14 days old)
Handled-By	: Len Brown <len.brown@intel.com>
Patch		: http://patchwork.kernel.org/patch/22499/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13245
Subject		: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2009-05-04 16:56 (21 days old)
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
Patch		: http://patchwork.kernel.org/patch/25557/


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13121
Subject		: Buggy _BCM - acer aspire 5720G, 5710Z, 5315
Submitter	: Maxim Levitsky <maximlevitsky@gmail.com>
Date		: 2009-04-16 11:37 (39 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a7c618a3f7bef1a20ae740df512eeba21397fa5
References	: http://marc.info/?l=linux-kernel&m=123988189401913&w=4
Handled-By	: Zhang Rui <rui.zhang@intel.com>
Patch		: http://patchwork.kernel.org/patch/19755/
		  http://bugzilla.kernel.org/attachment.cgi?id=21268


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject		: High latency on /sys/class/thermal
Submitter	: Tiago Simões Batista <tiagosbatista@gmail.com>
Date		: 2009-04-11 14:56 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By	: Zhang Rui <rui.zhang@intel.com>
		  Alexey Starikovskiy <astarikovskiy@suse.de>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21061
		  http://bugzilla.kernel.org/attachment.cgi?id=21282


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.29,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=13070

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael

[Bug #13109] High latency on /sys/class/thermal

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject		: High latency on /sys/class/thermal
Submitter	: Tiago Simões Batista <tiagosbatista@gmail.com>
Date		: 2009-04-11 14:56 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By	: Zhang Rui <rui.zhang@intel.com>
		  Alexey Starikovskiy <astarikovskiy@suse.de>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21061
		  http://bugzilla.kernel.org/attachment.cgi?id=21282

[Bug #13109] High latency on /sys/class/thermal

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject		: High latency on /sys/class/thermal
Submitter	: Tiago Simões Batista <tiagosbatista-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-11 14:56 (44 days old)
References	: http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By	: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
		  Alexey Starikovskiy <astarikovskiy-l3A5Bk7waGM@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=21061
		  http://bugzilla.kernel.org/attachment.cgi?id=21282

[Bug #13119] Trouble with make-install from a NFS mount

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13116] Can't boot with nosmp

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13125] active uvcvideo breaks over suspend

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13121] Buggy _BCM - acer aspire 5720G, 5710Z, 5315

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13121
Subject		: Buggy _BCM - acer aspire 5720G, 5710Z, 5315
Submitter	: Maxim Levitsky <maximlevitsky@gmail.com>
Date		: 2009-04-16 11:37 (39 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a7c618a3f7bef1a20ae740df512eeba21397fa5
References	: http://marc.info/?l=linux-kernel&m=123988189401913&w=4
Handled-By	: Zhang Rui <rui.zhang@intel.com>
Patch		: http://patchwork.kernel.org/patch/19755/
		  http://bugzilla.kernel.org/attachment.cgi?id=21268

[Bug #13119] Trouble with make-install from a NFS mount

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13116] Can't boot with nosmp

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13121] Buggy _BCM - acer aspire 5720G, 5710Z, 5315

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13121
Subject		: Buggy _BCM - acer aspire 5720G, 5710Z, 5315
Submitter	: Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-16 11:37 (39 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a7c618a3f7bef1a20ae740df512eeba21397fa5
References	: http://marc.info/?l=linux-kernel&m=123988189401913&w=4
Handled-By	: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/19755/
		  http://bugzilla.kernel.org/attachment.cgi?id=21268

[Bug #13125] active uvcvideo breaks over suspend

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13171] 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13179] CD-R: wodim intermittent failures

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13179
Subject		: CD-R: wodim intermittent failures
Submitter	: Andy Isaacson <adi@hexapodia.org>
Date		: 2009-04-21 1:52 (34 days old)
References	: http://marc.info/?l=linux-kernel&m=124027879214231&w=4

[Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13171] 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13179] CD-R: wodim intermittent failures

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13179
Subject		: CD-R: wodim intermittent failures
Submitter	: Andy Isaacson <adi-3HqRAUrWAWyGglJvpFV4uA@public.gmane.org>
Date		: 2009-04-21 1:52 (34 days old)
References	: http://marc.info/?l=linux-kernel&m=124027879214231&w=4

[Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13219] Since kernel 2.6.30-rc1, computers hangs randomly ..

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject		: Since kernel 2.6.30-rc1, computers hangs randomly ..
Submitter	: David Hill <hilld@binarystorm.net>
Date		: 2009-05-01 16:57 (24 days old)

[Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject		: 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter	: Niel Lambrechts <niel.lambrechts@gmail.com>
Date		: 2009-04-21 21:35 (34 days old)
References	: http://marc.info/?l=linux-kernel&m=124034980819102&w=4
		  http://lkml.org/lkml/2009/4/27/290

[Bug #13250] Side channel of Intel HDA chip doesn't work anymore, did work with 2.6.29

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13245] possible circular locking dependency detected

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13245
Subject		: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2009-05-04 16:56 (21 days old)
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
Patch		: http://patchwork.kernel.org/patch/25557/

[Bug #13180] 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject		: 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter	: Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-21 21:35 (34 days old)
References	: http://marc.info/?l=linux-kernel&m=124034980819102&w=4
		  http://lkml.org/lkml/2009/4/27/290

[Bug #13219] Since kernel 2.6.30-rc1, computers hangs randomly ..

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject		: Since kernel 2.6.30-rc1, computers hangs randomly ..
Submitter	: David Hill <hilld-HTiBYHdybX7UkGsOFmftXw@public.gmane.org>
Date		: 2009-05-01 16:57 (24 days old)

[Bug #13245] possible circular locking dependency detected

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13245
Subject		: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-04 16:56 (21 days old)
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/25557/

[Bug #13250] Side channel of Intel HDA chip doesn't work anymore, did work with 2.6.29

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13285] INTELFB: Colors display incorrectly

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13277] Thinkpad X40 no longer resumes reliable since ff69f2bba67bd45514923aaedbf40fe351787c59

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13277
Subject		: Thinkpad X40 no longer resumes reliable since ff69f2bba67bd45514923aaedbf40fe351787c59
Submitter	: Daniel Vetter <daniel@ffwll.ch>
Date		: 2009-05-11 10:08 (14 days old)
Handled-By	: Len Brown <len.brown@intel.com>
Patch		: http://patchwork.kernel.org/patch/22499/

[Bug #13293] Kernel BUG under network load with gianfar

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13293] Kernel BUG under network load with gianfar

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13293
Subject		: Kernel BUG under network load with gianfar
Submitter	: Michael Guntsche <mike-Z92qn3yYq0hWk0Htik3J/w@public.gmane.org>
Date		: 2009-05-03 13:36 (22 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0fd56bb5be6455d0d42241e65aed057244665e5e
References	: http://marc.info/?l=linux-kernel&m=124135824600924&w=4
Handled-By	: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/25518/

[Bug #13285] INTELFB: Colors display incorrectly

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13277] Thinkpad X40 no longer resumes reliable since ff69f2bba67bd45514923aaedbf40fe351787c59

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13277
Subject		: Thinkpad X40 no longer resumes reliable since ff69f2bba67bd45514923aaedbf40fe351787c59
Submitter	: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Date		: 2009-05-11 10:08 (14 days old)
Handled-By	: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/22499/

[Bug #13323] 2.6.30-rc deadline scheduler performance regression for iozone over NFS

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13306] hibernate slow on _second_ run

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject		: hibernate slow on _second_ run
Submitter	: Johannes Berg <johannes@sipsolutions.net>
Date		: 2009-05-14 09:34 (11 days old)

[Bug #13318] AGP doesn't work anymore on nforce2

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject		: AGP doesn't work anymore on nforce2
Submitter	: Karsten Mehrhoff <kawime@gmx.de>
Date		: 2009-04-30 8:51 (25 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By	: Shaohua Li <shaohua.li@intel.com>

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject		: Page allocation failures with b43 and p54usb
Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
Date		: 2009-04-29 21:01 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
Handled-By	: Johannes Berg <johannes@sipsolutions.net>

[Bug #13306] hibernate slow on _second_ run

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject		: hibernate slow on _second_ run
Submitter	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date		: 2009-05-14 09:34 (11 days old)

[Bug #13318] AGP doesn't work anymore on nforce2

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject		: AGP doesn't work anymore on nforce2
Submitter	: Karsten Mehrhoff <kawime-Mmb7MZpHnFY@public.gmane.org>
Date		: 2009-04-30 8:51 (25 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References	: http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By	: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

[Bug #13319] Page allocation failures with b43 and p54usb

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject		: Page allocation failures with b43 and p54usb
Submitter	: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-04-29 21:01 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124103897101088&w=4
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

[Bug #13323] 2.6.30-rc deadline scheduler performance regression for iozone over NFS

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13326] [PATCH]Null pointer dereference in rtc-cmos driver

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13325] 2.6.30-rc kills my box hard - and lockdep chains

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13325] 2.6.30-rc kills my box hard - and lockdep chains

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13326] [PATCH]Null pointer dereference in rtc-cmos driver

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


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

[Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject		: b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter	: Francis Moreau <francis.moro@gmail.com>
Date		: 2009-05-03 16:22 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4

[Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject		: b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter	: Francis Moreau <francis.moro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-03 16:22 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=124136778012280&w=4

[Bug #13330] nfs4 NULL pointer dereference in _nfs4_do_setlk

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13330
Subject		: nfs4 NULL pointer dereference in _nfs4_do_setlk
Submitter	: Rich Ercolani <rercola@acm.jhu.edu>
Date		: 2009-05-17 04:44 (8 days old)

[Bug #13331] FUTEX_LOCK_PI kills kernel

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13331
Subject		: FUTEX_LOCK_PI kills kernel
Submitter	: Andreas Schwab <schwab@linux-m68k.org>
Date		: 2009-05-17 09:51 (8 days old)

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (7 days old)

[Bug #13339] rtable leak in ipv4/route.c

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject		: rtable leak in ipv4/route.c
Submitter	: Alexander V. Lukyanov <lav@yar.ru>
Date		: 2009-05-18 14:10 (7 days old)

[Bug #13341] Random Oops at boot at loading ip6tables rules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject		: Random Oops at boot at loading ip6tables rules
Submitter	:  <patrick@ostenberg.de>
Date		: 2009-05-19 09:08 (6 days old)

[Bug #13331] FUTEX_LOCK_PI kills kernel

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13331
Subject		: FUTEX_LOCK_PI kills kernel
Submitter	: Andreas Schwab <schwab-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Date		: 2009-05-17 09:51 (8 days old)

[Bug #13339] rtable leak in ipv4/route.c

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject		: rtable leak in ipv4/route.c
Submitter	: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
Date		: 2009-05-18 14:10 (7 days old)

[Bug #13330] nfs4 NULL pointer dereference in _nfs4_do_setlk

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13330
Subject		: nfs4 NULL pointer dereference in _nfs4_do_setlk
Submitter	: Rich Ercolani <rercola-YxllIAoeIHiVc3sceRu5cw@public.gmane.org>
Date		: 2009-05-17 04:44 (8 days old)

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=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 (7 days old)

[Bug #13341] Random Oops at boot at loading ip6tables rules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject		: Random Oops at boot at loading ip6tables rules
Submitter	:  <patrick-nxAOmsU53hB6lmGzAMPh1A@public.gmane.org>
Date		: 2009-05-19 09:08 (6 days old)

[Bug #13377] Microphone no longer works on Toshiba Satellite A100

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13377
Subject		: Microphone no longer works on Toshiba Satellite A100
Submitter	: M. Vefa Bicakci <bicave@superonline.com>
Date		: 2009-05-24 15:49 (1 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=23f0c048ba59ad5c2f3fd85ed98360b631dbf6f8
References	: http://marc.info/?l=linux-kernel&m=124318383910011&w=4

[Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject		: fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2009-05-23 5:08 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124305538130702&w=4

[Bug #13366] About 80% of shutdowns fail (blocking)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13366
Subject		: About 80% of shutdowns fail (blocking)
Submitter	: Martin Bammer <mrb74@gmx.at>
Date		: 2009-05-23 00:58 (2 days old)

[Bug #13372] Oops in usb-serial with keyspan adapter

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13372
Subject		: Oops in usb-serial with keyspan adapter
Submitter	: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date		: 2009-05-18 0:07 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124260532924736&w=4
Handled-By	: Alan Stern <stern@rowland.harvard.edu>

[Bug #13374] reiserfs blocked for more than 120secs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject		: reiserfs blocked for more than 120secs
Submitter	: Harald Dunkel <harald.dunkel@t-online.de>
Date		: 2009-05-23 8:52 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124306880410811&w=4

[Bug #13373] fbcon, intelfb, i915: INFO: possible circular locking dependency detected

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=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 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124305538130702&w=4

[Bug #13372] Oops in usb-serial with keyspan adapter

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13372
Subject		: Oops in usb-serial with keyspan adapter
Submitter	: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date		: 2009-05-18 0:07 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124260532924736&w=4
Handled-By	: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>

[Bug #13366] About 80% of shutdowns fail (blocking)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13366
Subject		: About 80% of shutdowns fail (blocking)
Submitter	: Martin Bammer <mrb74-RbZlAiThDcE@public.gmane.org>
Date		: 2009-05-23 00:58 (2 days old)

[Bug #13377] Microphone no longer works on Toshiba Satellite A100

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13377
Subject		: Microphone no longer works on Toshiba Satellite A100
Submitter	: M. Vefa Bicakci <bicave-qUEp0r/b3FNfOZc0+OmrVg@public.gmane.org>
Date		: 2009-05-24 15:49 (1 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=23f0c048ba59ad5c2f3fd85ed98360b631dbf6f8
References	: http://marc.info/?l=linux-kernel&m=124318383910011&w=4

[Bug #13374] reiserfs blocked for more than 120secs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject		: reiserfs blocked for more than 120secs
Submitter	: Harald Dunkel <harald.dunkel-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Date		: 2009-05-23 8:52 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124306880410811&w=4

[Bug #13378] kernel/async.c broke pata_legacy.c

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13378
Subject		: kernel/async.c broke pata_legacy.c
Submitter	: Mikael Pettersson <mikpe@it.uu.se>
Date		: 2009-05-24 16:13 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124318186507210&w=4
Handled-By	: James Bottomley <James.Bottomley@hansenpartnership.com>
Patch		: http://patchwork.kernel.org/patch/25699/

[Bug #13378] kernel/async.c broke pata_legacy.c

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13378
Subject		: kernel/async.c broke pata_legacy.c
Submitter	: Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date		: 2009-05-24 16:13 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124318186507210&w=4
Handled-By	: James Bottomley <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/25699/

Re: 2.6.30-rc7: Reported regressions from 2.6.29

[Ozan Çağlayan]

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

Just to notice that the patch for this is at:

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core.current/driver-core-do-not-oops-when-driver_unregister-is-called-for-unregistered-drivers.patch

Can at least be marked as "has a patch".

Thanks,
Ozan Caglayan

Re: 2.6.30-rc7: Reported regressions from 2.6.29

[Ozan Çağlayan]

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

Just to notice that the patch for this is at:

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core.current/driver-core-do-not-oops-when-driver_unregister-is-called-for-unregistered-drivers.patch

Can at least be marked as "has a patch".

Thanks,
Ozan Caglayan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.30-rc7: Reported regressions from 2.6.29

[Ozan Çağlayan]

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

Just to notice that the patch for this is at:

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core.current/driver-core-do-not-oops-when-driver_unregister-is-called-for-unregistered-drivers.patch

Can at least be marked as "has a patch".

Thanks,
Ozan Caglayan
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: 2.6.30-rc7: Reported regressions from 2.6.29

[Rafael J. Wysocki]

On Monday 25 May 2009, Ozan Çağlayan wrote:
> Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13326
> > Subject		: [PATCH]Null pointer dereference in rtc-cmos driver
> > Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
> > Date		: 2009-05-14 16:16 (11 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124231783704696&w=4
> >   
> 
> Just to notice that the patch for this is at:
> 
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core.current/driver-core-do-not-oops-when-driver_unregister-is-called-for-unregistered-drivers.patch
> 
> Can at least be marked as "has a patch".

Thanks, I added the patch to the bug entry and changed its status.

Best,
Rafael

Re: 2.6.30-rc7: Reported regressions from 2.6.29

[Rafael J. Wysocki]

On Monday 25 May 2009, Ozan Çağlayan wrote:
> Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13326
> > Subject		: [PATCH]Null pointer dereference in rtc-cmos driver
> > Submitter	: Ozan Çağlayan <ozan-caicS1wCkhO6A22drWdTBw@public.gmane.org>
> > Date		: 2009-05-14 16:16 (11 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124231783704696&w=4
> >   
> 
> Just to notice that the patch for this is at:
> 
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core.current/driver-core-do-not-oops-when-driver_unregister-is-called-for-unregistered-drivers.patch
> 
> Can at least be marked as "has a patch".

Thanks, I added the patch to the bug entry and changed its status.

Best,
Rafael

Re: 2.6.30-rc7: Reported regressions from 2.6.29

[Rafael J. Wysocki]

On Monday 25 May 2009, Ozan Çağlayan wrote:
> Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13326
> > Subject		: [PATCH]Null pointer dereference in rtc-cmos driver
> > Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
> > Date		: 2009-05-14 16:16 (11 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124231783704696&w=4
> >   
> 
> Just to notice that the patch for this is at:
> 
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core.current/driver-core-do-not-oops-when-driver_unregister-is-called-for-unregistered-drivers.patch
> 
> Can at least be marked as "has a patch".

Thanks, I added the patch to the bug entry and changed its status.

Best,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [Bug #13339] rtable leak in ipv4/route.c

[Eric Dumazet]

Rafael J. Wysocki a écrit :
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
> Subject		: rtable leak in ipv4/route.c
> Submitter	: Alexander V. Lukyanov <lav@yar.ru>
> Date		: 2009-05-18 14:10 (7 days old)
> 

Bug was present in 2.6.29, so its a regression from 2.6.28

It is solved and available in David tree (net-2.6), and scheduled for stable submission

commit 1ddbcb005c395518c2cd0df504cff3d4b5c85853
net: fix rtable leak in net/ipv4/route.c

Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
Quoted here because its a perfect one :

begin_of_quotation
 2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
 patch has at least one critical flaw, and another problem.

 rt_intern_hash calculates rthi pointer, which is later used for new entry
 insertion. The same loop calculates cand pointer which is used to clean the
 list. If the pointers are the same, rtable leak occurs, as first the cand is
 removed then the new entry is appended to it.

 This leak leads to unregister_netdevice problem (usage count > 0).

 Another problem of the patch is that it tries to insert the entries in certain
 order, to facilitate counting of entries distinct by all but QoS parameters.
 Unfortunately, referencing an existing rtable entry moves it to list beginning,
 to speed up further lookups, so the carefully built order is destroyed.

 For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
 it will also destroy the ordering.
end_of_quotation

Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b
(net: implement emergency route cache rebulds when gc_elasticity is exceeded)

Trying to keep dst_entries ordered is too complex and breaks the fact that
order should depend on the frequency of use for garbage collection.

A possible fix is to make rt_intern_hash() simpler, and only makes
rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
entries order. The added loop is running on cache hot data, while cpu
is prefetching next object, so should be unnoticied.

Reported-and-analyzed-by: Alexander V. Lukyanov <lav@yar.ru>
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Thanks

Re: [Bug #13339] rtable leak in ipv4/route.c

[Eric Dumazet]

Rafael J. Wysocki a écrit :
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
> Subject		: rtable leak in ipv4/route.c
> Submitter	: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
> Date		: 2009-05-18 14:10 (7 days old)
> 

Bug was present in 2.6.29, so its a regression from 2.6.28

It is solved and available in David tree (net-2.6), and scheduled for stable submission

commit 1ddbcb005c395518c2cd0df504cff3d4b5c85853
net: fix rtable leak in net/ipv4/route.c

Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
Quoted here because its a perfect one :

begin_of_quotation
 2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
 patch has at least one critical flaw, and another problem.

 rt_intern_hash calculates rthi pointer, which is later used for new entry
 insertion. The same loop calculates cand pointer which is used to clean the
 list. If the pointers are the same, rtable leak occurs, as first the cand is
 removed then the new entry is appended to it.

 This leak leads to unregister_netdevice problem (usage count > 0).

 Another problem of the patch is that it tries to insert the entries in certain
 order, to facilitate counting of entries distinct by all but QoS parameters.
 Unfortunately, referencing an existing rtable entry moves it to list beginning,
 to speed up further lookups, so the carefully built order is destroyed.

 For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
 it will also destroy the ordering.
end_of_quotation

Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b
(net: implement emergency route cache rebulds when gc_elasticity is exceeded)

Trying to keep dst_entries ordered is too complex and breaks the fact that
order should depend on the frequency of use for garbage collection.

A possible fix is to make rt_intern_hash() simpler, and only makes
rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
entries order. The added loop is running on cache hot data, while cpu
is prefetching next object, so should be unnoticied.

Reported-and-analyzed-by: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
Signed-off-by: Eric Dumazet <dada1-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

Thanks

Re: [Bug #13339] rtable leak in ipv4/route.c

[Eric Dumazet]

Rafael J. Wysocki a écrit :
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
> Subject		: rtable leak in ipv4/route.c
> Submitter	: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
> Date		: 2009-05-18 14:10 (7 days old)
> 

Bug was present in 2.6.29, so its a regression from 2.6.28

It is solved and available in David tree (net-2.6), and scheduled for stable submission

commit 1ddbcb005c395518c2cd0df504cff3d4b5c85853
net: fix rtable leak in net/ipv4/route.c

Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
Quoted here because its a perfect one :

begin_of_quotation
 2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
 patch has at least one critical flaw, and another problem.

 rt_intern_hash calculates rthi pointer, which is later used for new entry
 insertion. The same loop calculates cand pointer which is used to clean the
 list. If the pointers are the same, rtable leak occurs, as first the cand is
 removed then the new entry is appended to it.

 This leak leads to unregister_netdevice problem (usage count > 0).

 Another problem of the patch is that it tries to insert the entries in certain
 order, to facilitate counting of entries distinct by all but QoS parameters.
 Unfortunately, referencing an existing rtable entry moves it to list beginning,
 to speed up further lookups, so the carefully built order is destroyed.

 For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
 it will also destroy the ordering.
end_of_quotation

Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b
(net: implement emergency route cache rebulds when gc_elasticity is exceeded)

Trying to keep dst_entries ordered is too complex and breaks the fact that
order should depend on the frequency of use for garbage collection.

A possible fix is to make rt_intern_hash() simpler, and only makes
rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
entries order. The added loop is running on cache hot data, while cpu
is prefetching next object, so should be unnoticied.

Reported-and-analyzed-by: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
Signed-off-by: Eric Dumazet <dada1-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

Thanks

Re: [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present

[Mattia Dongili]

On Sun, May 24, 2009 at 09:11:50PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
> Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
> Submitter	: fanderay <fanderay4@googlemail.com>
> Date		: 2009-04-22 14:39 (33 days old)

sorry for not mentioning this before, but it looks like this regression
was introduced between .28 and .29

cheers
-- 
mattia
:wq!

Re: [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present

[Mattia Dongili]

On Sun, May 24, 2009 at 09:11:50PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
> Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
> Submitter	: fanderay <fanderay4-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Date		: 2009-04-22 14:39 (33 days old)

sorry for not mentioning this before, but it looks like this regression
was introduced between .28 and .29

cheers
-- 
mattia
:wq!

Re: [Bug #13293] Kernel BUG under network load with gianfar

[Lennert Buytenhek]

On Sun, May 24, 2009 at 09:11:52PM +0200, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13293
> Subject		: Kernel BUG under network load with gianfar
> Submitter	: Michael Guntsche <mike@it-loops.com>
> Date		: 2009-05-03 13:36 (22 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0fd56bb5be6455d0d42241e65aed057244665e5e
> References	: http://marc.info/?l=linux-kernel&m=124135824600924&w=4
> Handled-By	: Lennert Buytenhek <buytenh@wantstofly.org>
> Patch		: http://patchwork.kernel.org/patch/25518/

The proposed patch has yet to be ACKed by the maintainer/merged, so
yes, this regression should still be listed.

Re: [Bug #13293] Kernel BUG under network load with gianfar

[Lennert Buytenhek]

On Sun, May 24, 2009 at 09:11:52PM +0200, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13293
> Subject		: Kernel BUG under network load with gianfar
> Submitter	: Michael Guntsche <mike-Z92qn3yYq0hWk0Htik3J/w@public.gmane.org>
> Date		: 2009-05-03 13:36 (22 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0fd56bb5be6455d0d42241e65aed057244665e5e
> References	: http://marc.info/?l=linux-kernel&m=124135824600924&w=4
> Handled-By	: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/25518/

The proposed patch has yet to be ACKed by the maintainer/merged, so
yes, this regression should still be listed.

Re: [Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs

[Peter Zijlstra]

On Sun, 2009-05-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13126
> Subject		: BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
> Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
> Date		: 2009-04-15 12:43 (40 days old)
> References	: http://marc.info/?l=linux-kernel&m=123979949820538&w=4

-rc7 includes:

Ingo Molnar (1):
      lockdep: increase MAX_LOCKDEP_ENTRIES and MAX_LOCKDEP_CHAINS

Which can be found with commit id: 
   d80c19df5fcceb8c741e96f09f275c2da719efef

Re: [Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs

[Peter Zijlstra]

On Sun, 2009-05-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13126
> Subject		: BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
> Submitter	: Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-04-15 12:43 (40 days old)
> References	: http://marc.info/?l=linux-kernel&m=123979949820538&w=4

-rc7 includes:

Ingo Molnar (1):
      lockdep: increase MAX_LOCKDEP_ENTRIES and MAX_LOCKDEP_CHAINS

Which can be found with commit id: 
   d80c19df5fcceb8c741e96f09f275c2da719efef

Re: [Bug #13331] FUTEX_LOCK_PI kills kernel

[Peter Zijlstra]

On Sun, 2009-05-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13331
> Subject		: FUTEX_LOCK_PI kills kernel
> Submitter	: Andreas Schwab <schwab@linux-m68k.org>
> Date		: 2009-05-17 09:51 (8 days old)

commit 64d1304a64477629cb16b75491a77bafe6f86963
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon May 18 21:20:10 2009 +0200

    futex: setup writeable mapping for futex ops which modify user space data

Re: [Bug #13331] FUTEX_LOCK_PI kills kernel

[Peter Zijlstra]

On Sun, 2009-05-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13331
> Subject		: FUTEX_LOCK_PI kills kernel
> Submitter	: Andreas Schwab <schwab-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> Date		: 2009-05-17 09:51 (8 days old)

commit 64d1304a64477629cb16b75491a77bafe6f86963
Author: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Date:   Mon May 18 21:20:10 2009 +0200

    futex: setup writeable mapping for futex ops which modify user space data

Re: [Bug #13171] 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption

[Alex Bennee]

2009/5/24 Rafael J. Wysocki <rjw@sisk.pl>:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13171
> Subject         : 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
> Submitter       : Alex Bennee <kernel-hacker@bennee.com>
> Date            : 2009-04-19 6:27 (36 days old)
> References      : http://marc.info/?l=linux-kernel&m=124022460014812&w=4
>                  https://bugs.freedesktop.org/show_bug.cgi?id=21480
>

I've tested on the latest rc7 kernel and can now boot into the X with
KMS enabled. I believe that's probably good enough for this regression
to be cleared.

I still have some issues with KMS enabled which means it shouldn't be
made a default for intel just yet however I'm not sure where the
problem lie between kernel, X and apps. Compared to a none KMS system
(same xorg.conf, same kernel):

1. GDM gets confused about screen sizes and comes up 1440x900 instead
of stretching the screen to 1680x1050. However the X session itself
gets the right size.

2. Full screen video freezes X. At this point I cannot switch to VT
and need to ssh in to kill and restore X. The logs/dmesg are fairly
mute as to why though.

3. Performance seems to be lower. The compiz benchmark happily report
120fps without KMS on my normal display and around 60FPS with it
enabled. Some displays (like the big wall plugin) the difference is
less marked (14FPS to 9FPS).

I've also seen some oopses occur while running:

[  406.818468] [drm] TMDS-8: set mode  2e
[  478.370123] [drm] DAC-6: set mode 1440x900 1b
[  478.475342] [drm] TMDS-8: set mode 1680x1050 2d
[  660.644103] [drm] TMDS-8: set mode  2f
[  960.272242] INFO: task events/0:9 blocked for more than 120 seconds.
[  960.272245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  960.272248] events/0      D ffff8800b70a58c0     0     9      2
[  960.272254]  ffff8800b70b5de0 0000000000000046 ffff8800b103dc41
ffff880001028980
[  960.272260]  0000000000004000 0000000000010dc0 000000000000ca38
ffff8800b0d31678
[  960.272265]  ffff8800b70b5d60 ffff8800b70a58c0 ffffffff80648350
ffff8800b70a5c48
[  960.272270] Call Trace:
[  960.272280]  [<ffffffff804bfce6>] ? thread_return+0x3e/0xaa
[  960.272285]  [<ffffffff804c0589>] __mutex_lock_slowpath+0xdf/0x129
[  960.272290]  [<ffffffff804c092d>] mutex_lock+0x23/0x3b
[  960.272295]  [<ffffffff803cecd3>] i915_gem_retire_work_handler+0x2d/0x6b
[  960.272301]  [<ffffffff80247666>] worker_thread+0x176/0x20f
[  960.272306]  [<ffffffff803ceca6>] ? i915_gem_retire_work_handler+0x0/0x6b
[  960.272311]  [<ffffffff8024b463>] ? autoremove_wake_function+0x0/0x3d
[  960.272315]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[  960.272319]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[  960.272323]  [<ffffffff8024b061>] kthread+0x5b/0x88
[  960.272329]  [<ffffffff8020c0ba>] child_rip+0xa/0x20
[  960.272333]  [<ffffffff8024b006>] ? kthread+0x0/0x88
[  960.272337]  [<ffffffff8020c0b0>] ? child_rip+0x0/0x20
[ 1200.272036] INFO: task events/0:9 blocked for more than 120 seconds.
[ 1200.272039] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 1200.272043] events/0      D ffff8800b70a58c0     0     9      2
[ 1200.272048]  ffff8800b70b5de0 0000000000000046 ffff8800b103dc41
ffff880001028980
[ 1200.272054]  0000000000004000 0000000000010dc0 000000000000ca38
ffff8800b0d31678
[ 1200.272059]  ffff8800b70b5d60 ffff8800b70a58c0 ffff8800a6c98000
ffff8800b70a5c48
[ 1200.272064] Call Trace:
[ 1200.272074]  [<ffffffff804bfce6>] ? thread_return+0x3e/0xaa
[ 1200.272079]  [<ffffffff804c0589>] __mutex_lock_slowpath+0xdf/0x129
[ 1200.272083]  [<ffffffff804c092d>] mutex_lock+0x23/0x3b
[ 1200.272089]  [<ffffffff803cecd3>] i915_gem_retire_work_handler+0x2d/0x6b
[ 1200.272095]  [<ffffffff80247666>] worker_thread+0x176/0x20f
[ 1200.272100]  [<ffffffff803ceca6>] ? i915_gem_retire_work_handler+0x0/0x6b
[ 1200.272105]  [<ffffffff8024b463>] ? autoremove_wake_function+0x0/0x3d
[ 1200.272109]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[ 1200.272114]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[ 1200.272117]  [<ffffffff8024b061>] kthread+0x5b/0x88
[ 1200.272123]  [<ffffffff8020c0ba>] child_rip+0xa/0x20
[ 1200.272127]  [<ffffffff8024b006>] ? kthread+0x0/0x88
[ 1200.272131]  [<ffffffff8020c0b0>] ? child_rip+0x0/0x20
[ 1200.272154] INFO: task bash:5541 blocked for more than 120 seconds.
[ 1200.272156] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 1200.272159] bash          D ffff88009cb01a90     0  5541      1
[ 1200.272163]  ffff88009cb01928 0000000000000046 ffff8800b6a03400
ffff88009cb01988
[ 1200.272168]  0000000000004000 0000000000010dc0 000000000000ca38
0000000000000000
[ 1200.272173]  ffff88009cb019e8 ffff88009e0058c0 ffff8800a9544290
ffff88009e005c48
[ 1200.272178] Call Trace:
[ 1200.272184]  [<ffffffff8027a5b8>] ? find_get_page+0x28/0x89
[ 1200.272189]  [<ffffffff8027e28e>] ? __rmqueue_smallest+0xb7/0x141
[ 1200.272193]  [<ffffffff804bfd60>] schedule+0xe/0x22
[ 1200.272197]  [<ffffffff804c007b>] schedule_timeout+0x29/0x162
[ 1200.272201]  [<ffffffff8027e552>] ? rmqueue_bulk+0x47/0x91
[ 1200.272205]  [<ffffffff804bff10>] wait_for_common+0xd4/0x13a
[ 1200.272210]  [<ffffffff80230c9f>] ? default_wake_function+0x0/0x14
[ 1200.272215]  [<ffffffff804c0019>] wait_for_completion+0x1d/0x1f
[ 1200.272219]  [<ffffffff8024794c>] flush_cpu_workqueue+0x72/0x7e
[ 1200.272223]  [<ffffffff802479bd>] ? wq_barrier_func+0x0/0x14
[ 1200.272228]  [<ffffffff80247f5d>] flush_workqueue+0x46/0x6c
[ 1200.272232]  [<ffffffff80247f98>] flush_scheduled_work+0x15/0x17
[ 1200.272237]  [<ffffffff8039fb26>] tty_ldisc_release+0x4f/0x1da
[ 1200.272242]  [<ffffffff8022a89a>] ? __wake_up+0x48/0x55
[ 1200.272253]  [<ffffffff8039b5d6>] tty_release_dev+0x4ae/0x4e3
[ 1200.272257]  [<ffffffff802a18cd>] ? discard_slab+0x43/0x45
[ 1200.272260]  [<ffffffff8039b629>] tty_release+0x1e/0x29
[ 1200.272263]  [<ffffffff802a87ed>] __fput+0xe4/0x19d
[ 1200.272266]  [<ffffffff802a88c3>] fput+0x1d/0x1f
[ 1200.272270]  [<ffffffff802a5b42>] filp_close+0x5e/0x68
[ 1200.272273]  [<ffffffff802392d7>] put_files_struct+0x70/0xc7
[ 1200.272276]  [<ffffffff8023937a>] exit_files+0x4c/0x55
[ 1200.272279]  [<ffffffff8023ac10>] do_exit+0x1c7/0x637
[ 1200.272282]  [<ffffffff80230cc3>] ? wake_up_state+0x10/0x12
[ 1200.272286]  [<ffffffff80242cc1>] ? signal_wake_up+0x3d/0x41
[ 1200.272289]  [<ffffffff8023b0f7>] do_group_exit+0x77/0xa4
[ 1200.272292]  [<ffffffff80244944>] get_signal_to_deliver+0x318/0x338
[ 1200.272296]  [<ffffffff8020a525>] do_notify_resume+0x90/0x6f9
[ 1200.272299]  [<ffffffff8024391c>] ? kill_pid_info+0x3f/0x4d
[ 1200.272302]  [<ffffffff80243b2e>] ? sys_kill+0x90/0x17b
[ 1200.272305]  [<ffffffff8024221a>] ? sys_rt_sigaction+0x7a/0x98
[ 1200.272308]  [<ffffffff8020b235>] sysret_signal+0x6d/0xb7
[ 1320.272017] INFO: task events/0:9 blocked for more than 120 seconds.
[ 1320.272020] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 1320.272023] events/0      D ffff8800b70a58c0     0     9      2
[ 1320.272029]  ffff8800b70b5de0 0000000000000046 ffff8800b103dc41
ffff880001028980
[ 1320.272034]  0000000000004000 0000000000010dc0 000000000000ca38
ffff8800b0d31678
[ 1320.272040]  ffff8800b70b5d60 ffff8800b70a58c0 ffff8800a6c98000
ffff8800b70a5c48
[ 1320.272045] Call Trace:
[ 1320.272053]  [<ffffffff804bfce6>] ? thread_return+0x3e/0xaa
[ 1320.272059]  [<ffffffff804c0589>] __mutex_lock_slowpath+0xdf/0x129
[ 1320.272063]  [<ffffffff804c092d>] mutex_lock+0x23/0x3b
[ 1320.272068]  [<ffffffff803cecd3>] i915_gem_retire_work_handler+0x2d/0x6b
[ 1320.272074]  [<ffffffff80247666>] worker_thread+0x176/0x20f
[ 1320.272078]  [<ffffffff803ceca6>] ? i915_gem_retire_work_handler+0x0/0x6b
[ 1320.272083]  [<ffffffff8024b463>] ? autoremove_wake_function+0x0/0x3d
[ 1320.272088]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[ 1320.272092]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[ 1320.272096]  [<ffffffff8024b061>] kthread+0x5b/0x88
[ 1320.272101]  [<ffffffff8020c0ba>] child_rip+0xa/0x20
[ 1320.272105]  [<ffffffff8024b006>] ? kthread+0x0/0x88
[ 1320.272110]  [<ffffffff8020c0b0>] ? child_rip+0x0/0x20

But I've been unable to replicate these reliably on a kernel with
mutex debugging enabled.

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

Re: [Bug #13171] 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption

[Alex Bennee]

2009/5/24 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13171
> Subject         : 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
> Submitter       : Alex Bennee <kernel-hacker-jriKODhXDevQT0dZR+AlfA@public.gmane.org>
> Date            : 2009-04-19 6:27 (36 days old)
> References      : http://marc.info/?l=linux-kernel&m=124022460014812&w=4
>                  https://bugs.freedesktop.org/show_bug.cgi?id=21480
>

I've tested on the latest rc7 kernel and can now boot into the X with
KMS enabled. I believe that's probably good enough for this regression
to be cleared.

I still have some issues with KMS enabled which means it shouldn't be
made a default for intel just yet however I'm not sure where the
problem lie between kernel, X and apps. Compared to a none KMS system
(same xorg.conf, same kernel):

1. GDM gets confused about screen sizes and comes up 1440x900 instead
of stretching the screen to 1680x1050. However the X session itself
gets the right size.

2. Full screen video freezes X. At this point I cannot switch to VT
and need to ssh in to kill and restore X. The logs/dmesg are fairly
mute as to why though.

3. Performance seems to be lower. The compiz benchmark happily report
120fps without KMS on my normal display and around 60FPS with it
enabled. Some displays (like the big wall plugin) the difference is
less marked (14FPS to 9FPS).

I've also seen some oopses occur while running:

[  406.818468] [drm] TMDS-8: set mode  2e
[  478.370123] [drm] DAC-6: set mode 1440x900 1b
[  478.475342] [drm] TMDS-8: set mode 1680x1050 2d
[  660.644103] [drm] TMDS-8: set mode  2f
[  960.272242] INFO: task events/0:9 blocked for more than 120 seconds.
[  960.272245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  960.272248] events/0      D ffff8800b70a58c0     0     9      2
[  960.272254]  ffff8800b70b5de0 0000000000000046 ffff8800b103dc41
ffff880001028980
[  960.272260]  0000000000004000 0000000000010dc0 000000000000ca38
ffff8800b0d31678
[  960.272265]  ffff8800b70b5d60 ffff8800b70a58c0 ffffffff80648350
ffff8800b70a5c48
[  960.272270] Call Trace:
[  960.272280]  [<ffffffff804bfce6>] ? thread_return+0x3e/0xaa
[  960.272285]  [<ffffffff804c0589>] __mutex_lock_slowpath+0xdf/0x129
[  960.272290]  [<ffffffff804c092d>] mutex_lock+0x23/0x3b
[  960.272295]  [<ffffffff803cecd3>] i915_gem_retire_work_handler+0x2d/0x6b
[  960.272301]  [<ffffffff80247666>] worker_thread+0x176/0x20f
[  960.272306]  [<ffffffff803ceca6>] ? i915_gem_retire_work_handler+0x0/0x6b
[  960.272311]  [<ffffffff8024b463>] ? autoremove_wake_function+0x0/0x3d
[  960.272315]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[  960.272319]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[  960.272323]  [<ffffffff8024b061>] kthread+0x5b/0x88
[  960.272329]  [<ffffffff8020c0ba>] child_rip+0xa/0x20
[  960.272333]  [<ffffffff8024b006>] ? kthread+0x0/0x88
[  960.272337]  [<ffffffff8020c0b0>] ? child_rip+0x0/0x20
[ 1200.272036] INFO: task events/0:9 blocked for more than 120 seconds.
[ 1200.272039] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 1200.272043] events/0      D ffff8800b70a58c0     0     9      2
[ 1200.272048]  ffff8800b70b5de0 0000000000000046 ffff8800b103dc41
ffff880001028980
[ 1200.272054]  0000000000004000 0000000000010dc0 000000000000ca38
ffff8800b0d31678
[ 1200.272059]  ffff8800b70b5d60 ffff8800b70a58c0 ffff8800a6c98000
ffff8800b70a5c48
[ 1200.272064] Call Trace:
[ 1200.272074]  [<ffffffff804bfce6>] ? thread_return+0x3e/0xaa
[ 1200.272079]  [<ffffffff804c0589>] __mutex_lock_slowpath+0xdf/0x129
[ 1200.272083]  [<ffffffff804c092d>] mutex_lock+0x23/0x3b
[ 1200.272089]  [<ffffffff803cecd3>] i915_gem_retire_work_handler+0x2d/0x6b
[ 1200.272095]  [<ffffffff80247666>] worker_thread+0x176/0x20f
[ 1200.272100]  [<ffffffff803ceca6>] ? i915_gem_retire_work_handler+0x0/0x6b
[ 1200.272105]  [<ffffffff8024b463>] ? autoremove_wake_function+0x0/0x3d
[ 1200.272109]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[ 1200.272114]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[ 1200.272117]  [<ffffffff8024b061>] kthread+0x5b/0x88
[ 1200.272123]  [<ffffffff8020c0ba>] child_rip+0xa/0x20
[ 1200.272127]  [<ffffffff8024b006>] ? kthread+0x0/0x88
[ 1200.272131]  [<ffffffff8020c0b0>] ? child_rip+0x0/0x20
[ 1200.272154] INFO: task bash:5541 blocked for more than 120 seconds.
[ 1200.272156] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 1200.272159] bash          D ffff88009cb01a90     0  5541      1
[ 1200.272163]  ffff88009cb01928 0000000000000046 ffff8800b6a03400
ffff88009cb01988
[ 1200.272168]  0000000000004000 0000000000010dc0 000000000000ca38
0000000000000000
[ 1200.272173]  ffff88009cb019e8 ffff88009e0058c0 ffff8800a9544290
ffff88009e005c48
[ 1200.272178] Call Trace:
[ 1200.272184]  [<ffffffff8027a5b8>] ? find_get_page+0x28/0x89
[ 1200.272189]  [<ffffffff8027e28e>] ? __rmqueue_smallest+0xb7/0x141
[ 1200.272193]  [<ffffffff804bfd60>] schedule+0xe/0x22
[ 1200.272197]  [<ffffffff804c007b>] schedule_timeout+0x29/0x162
[ 1200.272201]  [<ffffffff8027e552>] ? rmqueue_bulk+0x47/0x91
[ 1200.272205]  [<ffffffff804bff10>] wait_for_common+0xd4/0x13a
[ 1200.272210]  [<ffffffff80230c9f>] ? default_wake_function+0x0/0x14
[ 1200.272215]  [<ffffffff804c0019>] wait_for_completion+0x1d/0x1f
[ 1200.272219]  [<ffffffff8024794c>] flush_cpu_workqueue+0x72/0x7e
[ 1200.272223]  [<ffffffff802479bd>] ? wq_barrier_func+0x0/0x14
[ 1200.272228]  [<ffffffff80247f5d>] flush_workqueue+0x46/0x6c
[ 1200.272232]  [<ffffffff80247f98>] flush_scheduled_work+0x15/0x17
[ 1200.272237]  [<ffffffff8039fb26>] tty_ldisc_release+0x4f/0x1da
[ 1200.272242]  [<ffffffff8022a89a>] ? __wake_up+0x48/0x55
[ 1200.272253]  [<ffffffff8039b5d6>] tty_release_dev+0x4ae/0x4e3
[ 1200.272257]  [<ffffffff802a18cd>] ? discard_slab+0x43/0x45
[ 1200.272260]  [<ffffffff8039b629>] tty_release+0x1e/0x29
[ 1200.272263]  [<ffffffff802a87ed>] __fput+0xe4/0x19d
[ 1200.272266]  [<ffffffff802a88c3>] fput+0x1d/0x1f
[ 1200.272270]  [<ffffffff802a5b42>] filp_close+0x5e/0x68
[ 1200.272273]  [<ffffffff802392d7>] put_files_struct+0x70/0xc7
[ 1200.272276]  [<ffffffff8023937a>] exit_files+0x4c/0x55
[ 1200.272279]  [<ffffffff8023ac10>] do_exit+0x1c7/0x637
[ 1200.272282]  [<ffffffff80230cc3>] ? wake_up_state+0x10/0x12
[ 1200.272286]  [<ffffffff80242cc1>] ? signal_wake_up+0x3d/0x41
[ 1200.272289]  [<ffffffff8023b0f7>] do_group_exit+0x77/0xa4
[ 1200.272292]  [<ffffffff80244944>] get_signal_to_deliver+0x318/0x338
[ 1200.272296]  [<ffffffff8020a525>] do_notify_resume+0x90/0x6f9
[ 1200.272299]  [<ffffffff8024391c>] ? kill_pid_info+0x3f/0x4d
[ 1200.272302]  [<ffffffff80243b2e>] ? sys_kill+0x90/0x17b
[ 1200.272305]  [<ffffffff8024221a>] ? sys_rt_sigaction+0x7a/0x98
[ 1200.272308]  [<ffffffff8020b235>] sysret_signal+0x6d/0xb7
[ 1320.272017] INFO: task events/0:9 blocked for more than 120 seconds.
[ 1320.272020] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 1320.272023] events/0      D ffff8800b70a58c0     0     9      2
[ 1320.272029]  ffff8800b70b5de0 0000000000000046 ffff8800b103dc41
ffff880001028980
[ 1320.272034]  0000000000004000 0000000000010dc0 000000000000ca38
ffff8800b0d31678
[ 1320.272040]  ffff8800b70b5d60 ffff8800b70a58c0 ffff8800a6c98000
ffff8800b70a5c48
[ 1320.272045] Call Trace:
[ 1320.272053]  [<ffffffff804bfce6>] ? thread_return+0x3e/0xaa
[ 1320.272059]  [<ffffffff804c0589>] __mutex_lock_slowpath+0xdf/0x129
[ 1320.272063]  [<ffffffff804c092d>] mutex_lock+0x23/0x3b
[ 1320.272068]  [<ffffffff803cecd3>] i915_gem_retire_work_handler+0x2d/0x6b
[ 1320.272074]  [<ffffffff80247666>] worker_thread+0x176/0x20f
[ 1320.272078]  [<ffffffff803ceca6>] ? i915_gem_retire_work_handler+0x0/0x6b
[ 1320.272083]  [<ffffffff8024b463>] ? autoremove_wake_function+0x0/0x3d
[ 1320.272088]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[ 1320.272092]  [<ffffffff802474f0>] ? worker_thread+0x0/0x20f
[ 1320.272096]  [<ffffffff8024b061>] kthread+0x5b/0x88
[ 1320.272101]  [<ffffffff8020c0ba>] child_rip+0xa/0x20
[ 1320.272105]  [<ffffffff8024b006>] ? kthread+0x0/0x88
[ 1320.272110]  [<ffffffff8020c0b0>] ? child_rip+0x0/0x20

But I've been unable to replicate these reliably on a kernel with
mutex debugging enabled.

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

Re: [Bug #13125] active uvcvideo breaks over suspend

[Alan Jenkins]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13125
> Subject		: active uvcvideo breaks over suspend
> Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Date		: 2009-04-15 10:12 (40 days old)
> References	: http://marc.info/?l=linux-kernel&m=123979009508840&w=4
> Handled-By	: Ming Lei <tom.leiming@gmail.com>
> Patch		: http://lkml.org/lkml/2009/4/18/5
>   

Seems to be fixed in RC7, thanks.

Re: [Bug #13125] active uvcvideo breaks over suspend

[Alan Jenkins]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.29.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13125
> Subject		: active uvcvideo breaks over suspend
> Submitter	: Alan Jenkins <alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org>
> Date		: 2009-04-15 10:12 (40 days old)
> References	: http://marc.info/?l=linux-kernel&m=123979009508840&w=4
> Handled-By	: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Patch		: http://lkml.org/lkml/2009/4/18/5
>   

Seems to be fixed in RC7, thanks.

Re: [Bug #13125] active uvcvideo breaks over suspend

[Rafael J. Wysocki]

On Monday 25 May 2009, Alan Jenkins wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13125
> > Subject		: active uvcvideo breaks over suspend
> > Submitter	: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> > Date		: 2009-04-15 10:12 (40 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123979009508840&w=4
> > Handled-By	: Ming Lei <tom.leiming@gmail.com>
> > Patch		: http://lkml.org/lkml/2009/4/18/5
> >   
> 
> Seems to be fixed in RC7, thanks.

Thanks, closed.

Rafael

Re: [Bug #13125] active uvcvideo breaks over suspend

[Rafael J. Wysocki]

On Monday 25 May 2009, Alan Jenkins wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13125
> > Subject		: active uvcvideo breaks over suspend
> > Submitter	: Alan Jenkins <alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org>
> > Date		: 2009-04-15 10:12 (40 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123979009508840&w=4
> > Handled-By	: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Patch		: http://lkml.org/lkml/2009/4/18/5
> >   
> 
> Seems to be fixed in RC7, thanks.

Thanks, closed.

Rafael

Re: [Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs

[Rafael J. Wysocki]

On Monday 25 May 2009, Peter Zijlstra wrote:
> On Sun, 2009-05-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13126
> > Subject		: BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
> > Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
> > Date		: 2009-04-15 12:43 (40 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123979949820538&w=4
> 
> -rc7 includes:
> 
> Ingo Molnar (1):
>       lockdep: increase MAX_LOCKDEP_ENTRIES and MAX_LOCKDEP_CHAINS
> 
> Which can be found with commit id: 
>    d80c19df5fcceb8c741e96f09f275c2da719efef

Thanks, closed.

Rafael

Re: [Bug #13126] BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs

[Rafael J. Wysocki]

On Monday 25 May 2009, Peter Zijlstra wrote:
> On Sun, 2009-05-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13126
> > Subject		: BUG: MAX_LOCKDEP_ENTRIES too low! when mounting rootfs
> > Submitter	: Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-04-15 12:43 (40 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123979949820538&w=4
> 
> -rc7 includes:
> 
> Ingo Molnar (1):
>       lockdep: increase MAX_LOCKDEP_ENTRIES and MAX_LOCKDEP_CHAINS
> 
> Which can be found with commit id: 
>    d80c19df5fcceb8c741e96f09f275c2da719efef

Thanks, closed.

Rafael

Re: [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present

[Rafael J. Wysocki]

On Monday 25 May 2009, Mattia Dongili wrote:
> On Sun, May 24, 2009 at 09:11:50PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
> > Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
> > Submitter	: fanderay <fanderay4@googlemail.com>
> > Date		: 2009-04-22 14:39 (33 days old)
> 
> sorry for not mentioning this before, but it looks like this regression
> was introduced between .28 and .29

Thanks, moved to the other list.

Rafael

Re: [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present

[Rafael J. Wysocki]

On Monday 25 May 2009, Mattia Dongili wrote:
> On Sun, May 24, 2009 at 09:11:50PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
> > Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
> > Submitter	: fanderay <fanderay4-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > Date		: 2009-04-22 14:39 (33 days old)
> 
> sorry for not mentioning this before, but it looks like this regression
> was introduced between .28 and .29

Thanks, moved to the other list.

Rafael

Re: [Bug #13331] FUTEX_LOCK_PI kills kernel

[Rafael J. Wysocki]

On Monday 25 May 2009, Peter Zijlstra wrote:
> On Sun, 2009-05-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13331
> > Subject		: FUTEX_LOCK_PI kills kernel
> > Submitter	: Andreas Schwab <schwab@linux-m68k.org>
> > Date		: 2009-05-17 09:51 (8 days old)
> 
> commit 64d1304a64477629cb16b75491a77bafe6f86963
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Mon May 18 21:20:10 2009 +0200
> 
>     futex: setup writeable mapping for futex ops which modify user space data

Thanks, closed.

Rafael

Re: [Bug #13331] FUTEX_LOCK_PI kills kernel

[Rafael J. Wysocki]

On Monday 25 May 2009, Peter Zijlstra wrote:
> On Sun, 2009-05-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13331
> > Subject		: FUTEX_LOCK_PI kills kernel
> > Submitter	: Andreas Schwab <schwab-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> > Date		: 2009-05-17 09:51 (8 days old)
> 
> commit 64d1304a64477629cb16b75491a77bafe6f86963
> Author: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> Date:   Mon May 18 21:20:10 2009 +0200
> 
>     futex: setup writeable mapping for futex ops which modify user space data

Thanks, closed.

Rafael

Re: [Bug #13339] rtable leak in ipv4/route.c

[Rafael J. Wysocki]

On Monday 25 May 2009, Eric Dumazet wrote:
> Rafael J. Wysocki a écrit :
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
> > Subject		: rtable leak in ipv4/route.c
> > Submitter	: Alexander V. Lukyanov <lav@yar.ru>
> > Date		: 2009-05-18 14:10 (7 days old)
> > 
> 
> Bug was present in 2.6.29, so its a regression from 2.6.28
> 
> It is solved and available in David tree (net-2.6), and scheduled for stable submission
> 
> commit 1ddbcb005c395518c2cd0df504cff3d4b5c85853
> net: fix rtable leak in net/ipv4/route.c
> 
> Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
> analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
> Quoted here because its a perfect one :
> 
> begin_of_quotation
>  2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
>  patch has at least one critical flaw, and another problem.
> 
>  rt_intern_hash calculates rthi pointer, which is later used for new entry
>  insertion. The same loop calculates cand pointer which is used to clean the
>  list. If the pointers are the same, rtable leak occurs, as first the cand is
>  removed then the new entry is appended to it.
> 
>  This leak leads to unregister_netdevice problem (usage count > 0).
> 
>  Another problem of the patch is that it tries to insert the entries in certain
>  order, to facilitate counting of entries distinct by all but QoS parameters.
>  Unfortunately, referencing an existing rtable entry moves it to list beginning,
>  to speed up further lookups, so the carefully built order is destroyed.
> 
>  For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
>  it will also destroy the ordering.
> end_of_quotation
> 
> Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b
> (net: implement emergency route cache rebulds when gc_elasticity is exceeded)
> 
> Trying to keep dst_entries ordered is too complex and breaks the fact that
> order should depend on the frequency of use for garbage collection.
> 
> A possible fix is to make rt_intern_hash() simpler, and only makes
> rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
> entries order. The added loop is running on cache hot data, while cpu
> is prefetching next object, so should be unnoticied.
> 
> Reported-and-analyzed-by: Alexander V. Lukyanov <lav@yar.ru>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>

Thanks, updated.

Rafael

Re: [Bug #13339] rtable leak in ipv4/route.c

[Rafael J. Wysocki]

On Monday 25 May 2009, Eric Dumazet wrote:
> Rafael J. Wysocki a écrit :
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
> > Subject		: rtable leak in ipv4/route.c
> > Submitter	: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
> > Date		: 2009-05-18 14:10 (7 days old)
> > 
> 
> Bug was present in 2.6.29, so its a regression from 2.6.28
> 
> It is solved and available in David tree (net-2.6), and scheduled for stable submission
> 
> commit 1ddbcb005c395518c2cd0df504cff3d4b5c85853
> net: fix rtable leak in net/ipv4/route.c
> 
> Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
> analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
> Quoted here because its a perfect one :
> 
> begin_of_quotation
>  2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
>  patch has at least one critical flaw, and another problem.
> 
>  rt_intern_hash calculates rthi pointer, which is later used for new entry
>  insertion. The same loop calculates cand pointer which is used to clean the
>  list. If the pointers are the same, rtable leak occurs, as first the cand is
>  removed then the new entry is appended to it.
> 
>  This leak leads to unregister_netdevice problem (usage count > 0).
> 
>  Another problem of the patch is that it tries to insert the entries in certain
>  order, to facilitate counting of entries distinct by all but QoS parameters.
>  Unfortunately, referencing an existing rtable entry moves it to list beginning,
>  to speed up further lookups, so the carefully built order is destroyed.
> 
>  For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
>  it will also destroy the ordering.
> end_of_quotation
> 
> Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b
> (net: implement emergency route cache rebulds when gc_elasticity is exceeded)
> 
> Trying to keep dst_entries ordered is too complex and breaks the fact that
> order should depend on the frequency of use for garbage collection.
> 
> A possible fix is to make rt_intern_hash() simpler, and only makes
> rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
> entries order. The added loop is running on cache hot data, while cpu
> is prefetching next object, so should be unnoticied.
> 
> Reported-and-analyzed-by: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
> Signed-off-by: Eric Dumazet <dada1-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
> Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

Thanks, updated.

Rafael

Re: [Bug #13339] rtable leak in ipv4/route.c

[Rafael J. Wysocki]

On Monday 25 May 2009, Eric Dumazet wrote:
> Rafael J. Wysocki a écrit :
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
> > Subject		: rtable leak in ipv4/route.c
> > Submitter	: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
> > Date		: 2009-05-18 14:10 (7 days old)
> > 
> 
> Bug was present in 2.6.29, so its a regression from 2.6.28
> 
> It is solved and available in David tree (net-2.6), and scheduled for stable submission
> 
> commit 1ddbcb005c395518c2cd0df504cff3d4b5c85853
> net: fix rtable leak in net/ipv4/route.c
> 
> Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
> analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
> Quoted here because its a perfect one :
> 
> begin_of_quotation
>  2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
>  patch has at least one critical flaw, and another problem.
> 
>  rt_intern_hash calculates rthi pointer, which is later used for new entry
>  insertion. The same loop calculates cand pointer which is used to clean the
>  list. If the pointers are the same, rtable leak occurs, as first the cand is
>  removed then the new entry is appended to it.
> 
>  This leak leads to unregister_netdevice problem (usage count > 0).
> 
>  Another problem of the patch is that it tries to insert the entries in certain
>  order, to facilitate counting of entries distinct by all but QoS parameters.
>  Unfortunately, referencing an existing rtable entry moves it to list beginning,
>  to speed up further lookups, so the carefully built order is destroyed.
> 
>  For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
>  it will also destroy the ordering.
> end_of_quotation
> 
> Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b
> (net: implement emergency route cache rebulds when gc_elasticity is exceeded)
> 
> Trying to keep dst_entries ordered is too complex and breaks the fact that
> order should depend on the frequency of use for garbage collection.
> 
> A possible fix is to make rt_intern_hash() simpler, and only makes
> rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
> entries order. The added loop is running on cache hot data, while cpu
> is prefetching next object, so should be unnoticied.
> 
> Reported-and-analyzed-by: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
> Signed-off-by: Eric Dumazet <dada1-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
> Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

Thanks, updated.

Rafael

Re: 2.6.30-rc7: Reported regressions from 2.6.29

[Luis R. Rodriguez]

On Sun, May 24, 2009 at 12:06 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:

Should help with reading, we have only 2 left for wireless:

> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13337
> Subject         : [post 2.6.29 regression] hang during suspend of b44/b43 modules
> Submitter       : Tomas Janousek <tomi@nomi.cz>
> Date            : 2009-05-18 10:59 (7 days old)


> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13319
> Subject         : Page allocation failures with b43 and p54usb
> Submitter       : Larry Finger <Larry.Finger@lwfinger.net>
> Date            : 2009-04-29 21:01 (26 days old)
> References      : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> Handled-By      : Johannes Berg <johannes@sipsolutions.net>

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[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=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (77 days old)
Handled-By	: Johannes Berg <johannes@sipsolutions.net>
Patch		: http://patchwork.kernel.org/patch/37837/

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[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=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
Date		: 2009-05-18 10:59 (77 days old)
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/37837/

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

On Tuesday 28 July 2009, Johannes Berg wrote:
> On Tue, 2009-07-28 at 16:40 +0200, Jan Scholz wrote:
> 
> > The bug is still present in v2.6.31-rc4, it's still fixed by the patch
> > (see below) suggested as a test by Johannes.
> 
> Sorry, this completely dropped off my radar, I'll take a look today.
> Thanks for reminding me.

Thanks for the patch Johannes!

Best,
Rafael

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On Tue, 2009-07-28 at 16:40 +0200, Jan Scholz wrote:

> The bug is still present in v2.6.31-rc4, it's still fixed by the patch
> (see below) suggested as a test by Johannes.

Sorry, this completely dropped off my radar, I'll take a look today.
Thanks for reminding me.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On Tue, 2009-07-28 at 16:40 +0200, Jan Scholz wrote:

> The bug is still present in v2.6.31-rc4, it's still fixed by the patch
> (see below) suggested as a test by Johannes.

Sorry, this completely dropped off my radar, I'll take a look today.
Thanks for reminding me.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Sat, 2009-07-11 at 19:20 +0200, Jan Scholz wrote:
>> Johannes Berg <johannes@sipsolutions.net> writes:
>> 
>> > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:
>> >
>> >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
>> >> > will correct me if I'm wrong) that should work on your platform, and put
>> >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
>> >> > see where in there it's hanging?
>> >> 
>> >> Did that, seems like it hangs in
>> >>   drv_remove_interface(local, &conf);
>> >
>> > Ok, thanks! I was going to suggest doing the same in
>> > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
>> > the problem is just that we have an ordering problem and call drv_stop
>> > before drv_remove_interface. I'll try to come up with a fix soon --
>> > might not be able to today though, in the meantime I guess you can just
>> > move the drv_stop call to the end of the function and tell me if that
>> > works -- that would be racy but should be ok most of the time.
>> 
>> I moved drv_stop to the end of the function (see patch below) and now
>> suspend works fine.
>
> Thanks, that's what I suspected -- I'll take a closer look into what is
> required to make it race-free against RX.
>

Hi,

The bug is still present in v2.6.31-rc4, it's still fixed by the patch
(see below) suggested as a test by Johannes.

Regards,
   Jan

>> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
>> index 7a549f9..0ac15fb 100644
>> --- a/net/mac80211/pm.c
>> +++ b/net/mac80211/pm.c
>> @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>>  	/* flush again, in case driver queued work */
>>  	flush_workqueue(local->hw.workqueue);
>>  
>> -	/* stop hardware - this must stop RX */
>> -	if (local->open_count) {
>> -		ieee80211_led_radio(local, false);
>> -		drv_stop(local);
>> -	}
>> -
>>  	/* remove STAs */
>>  	spin_lock_irqsave(&local->sta_lock, flags);
>>  	list_for_each_entry(sta, &local->sta_list, list) {
>> @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>>  		drv_remove_interface(local, &conf);
>>  	}
>>  
>> +	/* stop hardware - this must stop RX */
>> +	if (local->open_count) {
>> +		ieee80211_led_radio(local, false);
>> +		drv_stop(local);
>> +	}
>> +
>>  	local->suspended = true;
>>  	local->quiescing = false;
>> 

-- 
 Jan Scholz                                ____  ____    __    ___ 
                                          ( ___)(_  _)  /__\  / __)
 Frankfurt Institute for Advanced Studies  )__)  _)(_  /(__)\ \__ \
                                          (__)  (____)(__)(__)(___/
 Goethe Universitaet Frankfurt
 Ruth-Moufang-Str. 1                             Tel. 069-798-47534
 60438 Frankfurt am Main

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[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=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (70 days old)

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[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=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
Date		: 2009-05-18 10:59 (70 days old)

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On Sat, 2009-07-11 at 19:20 +0200, Jan Scholz wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> 
> > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:
> >
> >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> >> > will correct me if I'm wrong) that should work on your platform, and put
> >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> >> > see where in there it's hanging?
> >> 
> >> Did that, seems like it hangs in
> >>   drv_remove_interface(local, &conf);
> >
> > Ok, thanks! I was going to suggest doing the same in
> > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
> > the problem is just that we have an ordering problem and call drv_stop
> > before drv_remove_interface. I'll try to come up with a fix soon --
> > might not be able to today though, in the meantime I guess you can just
> > move the drv_stop call to the end of the function and tell me if that
> > works -- that would be racy but should be ok most of the time.
> 
> I moved drv_stop to the end of the function (see patch below) and now
> suspend works fine.

Thanks, that's what I suspected -- I'll take a closer look into what is
required to make it race-free against RX.

johannes

> Jan
> 
> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
> index 7a549f9..0ac15fb 100644
> --- a/net/mac80211/pm.c
> +++ b/net/mac80211/pm.c
> @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>  	/* flush again, in case driver queued work */
>  	flush_workqueue(local->hw.workqueue);
>  
> -	/* stop hardware - this must stop RX */
> -	if (local->open_count) {
> -		ieee80211_led_radio(local, false);
> -		drv_stop(local);
> -	}
> -
>  	/* remove STAs */
>  	spin_lock_irqsave(&local->sta_lock, flags);
>  	list_for_each_entry(sta, &local->sta_list, list) {
> @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>  		drv_remove_interface(local, &conf);
>  	}
>  
> +	/* stop hardware - this must stop RX */
> +	if (local->open_count) {
> +		ieee80211_led_radio(local, false);
> +		drv_stop(local);
> +	}
> +
>  	local->suspended = true;
>  	local->quiescing = false;
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

On Sat, 2009-07-11 at 19:20 +0200, Jan Scholz wrote:
> Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:
> 
> > On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:
> >
> >> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> >> > will correct me if I'm wrong) that should work on your platform, and put
> >> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> >> > see where in there it's hanging?
> >> 
> >> Did that, seems like it hangs in
> >>   drv_remove_interface(local, &conf);
> >
> > Ok, thanks! I was going to suggest doing the same in
> > b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
> > the problem is just that we have an ordering problem and call drv_stop
> > before drv_remove_interface. I'll try to come up with a fix soon --
> > might not be able to today though, in the meantime I guess you can just
> > move the drv_stop call to the end of the function and tell me if that
> > works -- that would be racy but should be ok most of the time.
> 
> I moved drv_stop to the end of the function (see patch below) and now
> suspend works fine.

Thanks, that's what I suspected -- I'll take a closer look into what is
required to make it race-free against RX.

johannes

> Jan
> 
> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
> index 7a549f9..0ac15fb 100644
> --- a/net/mac80211/pm.c
> +++ b/net/mac80211/pm.c
> @@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>  	/* flush again, in case driver queued work */
>  	flush_workqueue(local->hw.workqueue);
>  
> -	/* stop hardware - this must stop RX */
> -	if (local->open_count) {
> -		ieee80211_led_radio(local, false);
> -		drv_stop(local);
> -	}
> -
>  	/* remove STAs */
>  	spin_lock_irqsave(&local->sta_lock, flags);
>  	list_for_each_entry(sta, &local->sta_list, list) {
> @@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
>  		drv_remove_interface(local, &conf);
>  	}
>  
> +	/* stop hardware - this must stop RX */
> +	if (local->open_count) {
> +		ieee80211_led_radio(local, false);
> +		drv_stop(local);
> +	}
> +
>  	local->suspended = true;
>  	local->quiescing = false;
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:
>
>> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
>> > will correct me if I'm wrong) that should work on your platform, and put
>> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
>> > see where in there it's hanging?
>> 
>> Did that, seems like it hangs in
>>   drv_remove_interface(local, &conf);
>
> Ok, thanks! I was going to suggest doing the same in
> b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
> the problem is just that we have an ordering problem and call drv_stop
> before drv_remove_interface. I'll try to come up with a fix soon --
> might not be able to today though, in the meantime I guess you can just
> move the drv_stop call to the end of the function and tell me if that
> works -- that would be racy but should be ok most of the time.

I moved drv_stop to the end of the function (see patch below) and now
suspend works fine.

Jan

diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index 7a549f9..0ac15fb 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
 	/* flush again, in case driver queued work */
 	flush_workqueue(local->hw.workqueue);
 
-	/* stop hardware - this must stop RX */
-	if (local->open_count) {
-		ieee80211_led_radio(local, false);
-		drv_stop(local);
-	}
-
 	/* remove STAs */
 	spin_lock_irqsave(&local->sta_lock, flags);
 	list_for_each_entry(sta, &local->sta_list, list) {
@@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
 		drv_remove_interface(local, &conf);
 	}
 
+	/* stop hardware - this must stop RX */
+	if (local->open_count) {
+		ieee80211_led_radio(local, false);
+		drv_stop(local);
+	}
+
 	local->suspended = true;
 	local->quiescing = false;

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:

> On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:
>
>> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
>> > will correct me if I'm wrong) that should work on your platform, and put
>> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
>> > see where in there it's hanging?
>> 
>> Did that, seems like it hangs in
>>   drv_remove_interface(local, &conf);
>
> Ok, thanks! I was going to suggest doing the same in
> b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
> the problem is just that we have an ordering problem and call drv_stop
> before drv_remove_interface. I'll try to come up with a fix soon --
> might not be able to today though, in the meantime I guess you can just
> move the drv_stop call to the end of the function and tell me if that
> works -- that would be racy but should be ok most of the time.

I moved drv_stop to the end of the function (see patch below) and now
suspend works fine.

Jan

diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index 7a549f9..0ac15fb 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -58,12 +58,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
 	/* flush again, in case driver queued work */
 	flush_workqueue(local->hw.workqueue);
 
-	/* stop hardware - this must stop RX */
-	if (local->open_count) {
-		ieee80211_led_radio(local, false);
-		drv_stop(local);
-	}
-
 	/* remove STAs */
 	spin_lock_irqsave(&local->sta_lock, flags);
 	list_for_each_entry(sta, &local->sta_list, list) {
@@ -111,6 +105,12 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
 		drv_remove_interface(local, &conf);
 	}
 
+	/* stop hardware - this must stop RX */
+	if (local->open_count) {
+		ieee80211_led_radio(local, false);
+		drv_stop(local);
+	}
+
 	local->suspended = true;
 	local->quiescing = false;

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:

> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> > will correct me if I'm wrong) that should work on your platform, and put
> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> > see where in there it's hanging?
> 
> Did that, seems like it hangs in
>   drv_remove_interface(local, &conf);

Ok, thanks! I was going to suggest doing the same in
b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
the problem is just that we have an ordering problem and call drv_stop
before drv_remove_interface. I'll try to come up with a fix soon --
might not be able to today though, in the meantime I guess you can just
move the drv_stop call to the end of the function and tell me if that
works -- that would be racy but should be ok most of the time.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Sat, 2009-07-11 at 16:07 +0200, Jan Scholz wrote:

> > Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> > will correct me if I'm wrong) that should work on your platform, and put
> > a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> > see where in there it's hanging?
> 
> Did that, seems like it hangs in
>   drv_remove_interface(local, &conf);

Ok, thanks! I was going to suggest doing the same in
b43_op_remove_interface in drivers/net/wireless/b43/main.c, but I think
the problem is just that we have an ordering problem and call drv_stop
before drv_remove_interface. I'll try to come up with a fix soon --
might not be able to today though, in the meantime I guess you can just
move the drv_stop call to the end of the function and tell me if that
works -- that would be racy but should be ok most of the time.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Johannes Berg <johannes@sipsolutions.net> writes:
> On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
>> On Thursday 09 July 2009, Jan Scholz wrote:
>> > Hi,
>> > 
>> > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
>> > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
>> > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
>> > 
>> > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
>> > with the test procedure described below, but it works fine when I revert
>> > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
>> >  "mac80211: cancel/restart all timers across suspend/resume"
>> 
>> Thanks for the update.
>> 
>> Johannes, do you have any idea what can go wrong here?
>
> Not really, no. __ieee80211_suspend isn't holding any locks that the
> cancel_work_sync() calls could require or so afaict...
>
> Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> will correct me if I'm wrong) that should work on your platform, and put
> a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> see where in there it's hanging?

Did that, seems like it hangs in
  drv_remove_interface(local, &conf);

Jan

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:
> On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
>> On Thursday 09 July 2009, Jan Scholz wrote:
>> > Hi,
>> > 
>> > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
>> > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
>> > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
>> > 
>> > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
>> > with the test procedure described below, but it works fine when I revert
>> > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
>> >  "mac80211: cancel/restart all timers across suspend/resume"
>> 
>> Thanks for the update.
>> 
>> Johannes, do you have any idea what can go wrong here?
>
> Not really, no. __ieee80211_suspend isn't holding any locks that the
> cancel_work_sync() calls could require or so afaict...
>
> Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> will correct me if I'm wrong) that should work on your platform, and put
> a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
> see where in there it's hanging?

Did that, seems like it hangs in
  drv_remove_interface(local, &conf);

Jan

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

On Thursday 09 July 2009, Johannes Berg wrote:
> On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
> > On Thursday 09 July 2009, Jan Scholz wrote:
> > > Hi,
> > > 
> > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> > > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> > > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> > > 
> > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> > > with the test procedure described below, but it works fine when I revert
> > > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> > >  "mac80211: cancel/restart all timers across suspend/resume"
> > 
> > Thanks for the update.
> > 
> > Johannes, do you have any idea what can go wrong here?
> 
> Not really, no. __ieee80211_suspend isn't holding any locks that the
> cancel_work_sync() calls could require or so afaict...
> 
> Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> will correct me if I'm wrong)

That's just 'no_console_suspend'.

Best,
Rafael

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

On Thursday 09 July 2009, Johannes Berg wrote:
> On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
> > On Thursday 09 July 2009, Jan Scholz wrote:
> > > Hi,
> > > 
> > > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> > > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> > > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> > > 
> > > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> > > with the test procedure described below, but it works fine when I revert
> > > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> > >  "mac80211: cancel/restart all timers across suspend/resume"
> > 
> > Thanks for the update.
> > 
> > Johannes, do you have any idea what can go wrong here?
> 
> Not really, no. __ieee80211_suspend isn't holding any locks that the
> cancel_work_sync() calls could require or so afaict...
> 
> Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
> will correct me if I'm wrong)

That's just 'no_console_suspend'.

Best,
Rafael

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
> On Thursday 09 July 2009, Jan Scholz wrote:
> > Hi,
> > 
> > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> > 
> > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> > with the test procedure described below, but it works fine when I revert
> > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> >  "mac80211: cancel/restart all timers across suspend/resume"
> 
> Thanks for the update.
> 
> Johannes, do you have any idea what can go wrong here?

Not really, no. __ieee80211_suspend isn't holding any locks that the
cancel_work_sync() calls could require or so afaict...

Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
will correct me if I'm wrong) that should work on your platform, and put
a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
see where in there it's hanging?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Thu, 2009-07-09 at 22:03 +0200, Rafael J. Wysocki wrote:
> On Thursday 09 July 2009, Jan Scholz wrote:
> > Hi,
> > 
> > I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> > (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> > suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> > 
> > For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> > with the test procedure described below, but it works fine when I revert
> > commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> >  "mac80211: cancel/restart all timers across suspend/resume"
> 
> Thanks for the update.
> 
> Johannes, do you have any idea what can go wrong here?

Not really, no. __ieee80211_suspend isn't holding any locks that the
cancel_work_sync() calls could require or so afaict...

Jan, can you run with console_suspend=0 (or whatever it is now, Rafael
will correct me if I'm wrong) that should work on your platform, and put
a bunch of printk calls into __ieee80211_suspend in net/mac80211/pm.c to
see where in there it's hanging?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

On Thursday 09 July 2009, Jan Scholz wrote:
> Hi,
> 
> I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> 
> For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> with the test procedure described below, but it works fine when I revert
> commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
>  "mac80211: cancel/restart all timers across suspend/resume"

Thanks for the update.

Johannes, do you have any idea what can go wrong here?

Rafael

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

On Thursday 09 July 2009, Jan Scholz wrote:
> Hi,
> 
> I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
> (I wanted to test this on v2.6.31-rc2 as well, but there I had other
> suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)
> 
> For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
> with the test procedure described below, but it works fine when I revert
> commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
>  "mac80211: cancel/restart all timers across suspend/resume"

Thanks for the update.

Johannes, do you have any idea what can go wrong here?

Rafael

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Hi,

I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
(I wanted to test this on v2.6.31-rc2 as well, but there I had other
suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)

For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
with the test procedure described below, but it works fine when I revert
commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
 "mac80211: cancel/restart all timers across suspend/resume"

Best regards,
   Jan

Jan Scholz <scholz@fias.uni-frankfurt.de> writes:

> Hi,
>
> I'm not sure if I experience the same bug on my apple iBook G4 (ppc
> 7447A, altivec supported PowerBook6,5) or just something very similar.
>
> With v2.6.30-rc1 I noticed, that suspending to ram does not work if my
> wireless card is 'up'. The wireless card is an apple airport extreme
> card, this is its lspci output:
>
> 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
>
> I tested suspend like this:
>
> # unload the wireless module
> modprobe -r b43
> echo mem > /sys/power/state
>
> # wake up works fine
>
> #loading b43
> modprobe b43
> echo mem > /sys/power/state
>
> # wake up still works fine
>
> ifconfig wlan0 up
> echo mem > /sys/power/state
>
> # the box does not wake up, I guess it's not really sleeping, because
> # the sleep led is not on
>
> I bisected this and got:
>
> 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit
> commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> Author: Johannes Berg <johannes@sipsolutions.net>
> Date:   Sun May 17 11:40:42 2009 +0200
>    
>     mac80211: cancel/restart all timers across suspend/resume
>
>
> Best regards,
>     Jan Scholz
>
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.29 and 2.6.30.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
>> Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
>> Submitter	: Tomas Janousek <tomi@nomi.cz>
>> Date		: 2009-05-18 10:59 (50 days old)
>>

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Hi,

I have just checked this on v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547
(I wanted to test this on v2.6.31-rc2 as well, but there I had other
suspend-issues that are fixed in todays v2.6.31-rc2-214-g34f2547)

For both v2.6.31-rc1 and v2.6.31-rc2-214-g34f2547 suspend to ram fails
with the test procedure described below, but it works fine when I revert
commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
 "mac80211: cancel/restart all timers across suspend/resume"

Best regards,
   Jan

Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org> writes:

> Hi,
>
> I'm not sure if I experience the same bug on my apple iBook G4 (ppc
> 7447A, altivec supported PowerBook6,5) or just something very similar.
>
> With v2.6.30-rc1 I noticed, that suspending to ram does not work if my
> wireless card is 'up'. The wireless card is an apple airport extreme
> card, this is its lspci output:
>
> 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
>
> I tested suspend like this:
>
> # unload the wireless module
> modprobe -r b43
> echo mem > /sys/power/state
>
> # wake up works fine
>
> #loading b43
> modprobe b43
> echo mem > /sys/power/state
>
> # wake up still works fine
>
> ifconfig wlan0 up
> echo mem > /sys/power/state
>
> # the box does not wake up, I guess it's not really sleeping, because
> # the sleep led is not on
>
> I bisected this and got:
>
> 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit
> commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
> Author: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> Date:   Sun May 17 11:40:42 2009 +0200
>    
>     mac80211: cancel/restart all timers across suspend/resume
>
>
> Best regards,
>     Jan Scholz
>
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
>
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.29 and 2.6.30.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
>> Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
>> Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
>> Date		: 2009-05-18 10:59 (50 days old)
>>

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Hi,

I'm not sure if I experience the same bug on my apple iBook G4 (ppc
7447A, altivec supported PowerBook6,5) or just something very similar.

With v2.6.30-rc1 I noticed, that suspending to ram does not work if my
wireless card is 'up'. The wireless card is an apple airport extreme
card, this is its lspci output:

0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

I tested suspend like this:

# unload the wireless module
modprobe -r b43
echo mem > /sys/power/state

# wake up works fine

#loading b43
modprobe b43
echo mem > /sys/power/state

# wake up still works fine

ifconfig wlan0 up
echo mem > /sys/power/state

# the box does not wake up, I guess it's not really sleeping, because
# the sleep led is not on

I bisected this and got:

5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit
commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Sun May 17 11:40:42 2009 +0200
   
    mac80211: cancel/restart all timers across suspend/resume


Best regards,
    Jan Scholz

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
> Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
> Submitter	: Tomas Janousek <tomi@nomi.cz>
> Date		: 2009-05-18 10:59 (50 days old)
>

Re: [Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Jan Scholz]

Hi,

I'm not sure if I experience the same bug on my apple iBook G4 (ppc
7447A, altivec supported PowerBook6,5) or just something very similar.

With v2.6.30-rc1 I noticed, that suspending to ram does not work if my
wireless card is 'up'. The wireless card is an apple airport extreme
card, this is its lspci output:

0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

I tested suspend like this:

# unload the wireless module
modprobe -r b43
echo mem > /sys/power/state

# wake up works fine

#loading b43
modprobe b43
echo mem > /sys/power/state

# wake up still works fine

ifconfig wlan0 up
echo mem > /sys/power/state

# the box does not wake up, I guess it's not really sleeping, because
# the sleep led is not on

I bisected this and got:

5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7 is first bad commit
commit 5bb644a0fd25a5e083ecbfaa92a211db99aa6ef7
Author: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date:   Sun May 17 11:40:42 2009 +0200
   
    mac80211: cancel/restart all timers across suspend/resume


Best regards,
    Jan Scholz

"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
> Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
> Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
> Date		: 2009-05-18 10:59 (50 days old)
>

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[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=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (50 days old)

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[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=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi-YoqI/XImC7s@public.gmane.org>
Date		: 2009-05-18 10:59 (50 days old)

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[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=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 #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[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=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 #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (21 days old)

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=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 (21 days old)

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13337
Subject		: [post 2.6.29 regression] hang during suspend of b44/b43 modules
Submitter	: Tomas Janousek <tomi@nomi.cz>
Date		: 2009-05-18 10:59 (13 days old)

[Bug #13337] [post 2.6.29 regression] hang during suspend of b44/b43 modules

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.29.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=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 (13 days old)