* 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29
@ 2009-05-16 19:58 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:58 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.28 and
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 introduced between 2.6.28
and 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-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13271
Subject : ath9k stop working since 2.6.29
Submitter : lyman <lymanrb@gmail.com>
Date : 2009-05-10 01:58 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric@belbone.be>
Date : 2009-05-08 08:48 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2009-05-02 21:41 (15 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13183
Subject : forcedeth: no link during initialization
Submitter : Harald Dunkel <harald.dunkel@t-online.de>
Date : 2009-04-23 13:02 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049180309233&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap@knobisoft.de>
Date : 2009-04-24 12:45 (23 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject : sata_nv incompatible with async scsi scan
Submitter : Benny Halevy <bhalevy@panasas.com>
Date : 2009-04-21 7:03 (26 days old)
References : http://marc.info/?l=linux-kernel&m=124029746431777&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13172
Subject : Spontaneous reboots since 2.6.29-rc*
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2009-04-17 17:03 (30 days old)
References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights@fastmail.fm>
Date : 2009-04-21 17:03 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-04-06 23:52 (41 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias@archlinux-br.org>
Date : 2009-04-12 14:10 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date : 2009-04-12 07:00 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date : 2009-04-06 19:47 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark@hell.ne.jp>
Date : 2009-04-06 19:12 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd@gmail.com>
Date : 2009-04-03 09:30 (44 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus@better.se>
Date : 2009-03-31 08:58 (47 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666@gmail.com>
Date : 2009-03-29 18:02 (49 days old)
Handled-By : Matt Carlson <mcarlson@broadcom.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph@xs4all.nl>
Date : 2009-03-26 16:14 (52 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat@zip.com.au>
Date : 2009-03-16 10:25 (62 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann@secunet.com>
Date : 2009-03-20 07:13 (58 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12861
Subject : Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter : Emil Karlson <jkarlson@cc.hut.fi>
Date : 2009-03-12 12:06 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab657db12d7020629f26f30d287558a8d0e32b41
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213@schottelius.org>
Date : 2009-02-13 9:33 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric@anholt.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj@bk.ru>
Date : 2009-02-09 13:01 (97 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2009-01-13 18:34 (124 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By : Marcel Holtmann <marcel@holtmann.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (125 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me@bobcopeland.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
Subject : cpufreq timer teardown problem
Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date : 2009-04-23 14:00 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Patch : http://patchwork.kernel.org/patch/19754/
http://patchwork.kernel.org/patch/19753/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
Date : 2009-02-21 15:38 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://patchwork.kernel.org/patch/20197/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29
@ 2009-05-16 19:58 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:58 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.28 and
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 introduced between 2.6.28
and 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-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13271
Subject : ath9k stop working since 2.6.29
Submitter : lyman <lymanrb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-05-10 01:58 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric-x1Cn44Nr1HaZIoH1IeqzKA@public.gmane.org>
Date : 2009-05-08 08:48 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date : 2009-05-03 19:46 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem-VInPYn6yXxRWk0Htik3J/w@public.gmane.org>
Date : 2009-05-02 21:41 (15 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13183
Subject : forcedeth: no link during initialization
Submitter : Harald Dunkel <harald.dunkel-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Date : 2009-04-23 13:02 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049180309233&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
Date : 2009-04-24 12:45 (23 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject : sata_nv incompatible with async scsi scan
Submitter : Benny Halevy <bhalevy-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
Date : 2009-04-21 7:03 (26 days old)
References : http://marc.info/?l=linux-kernel&m=124029746431777&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13172
Subject : Spontaneous reboots since 2.6.29-rc*
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-17 17:03 (30 days old)
References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights-97jfqw80gc6171pxa8y+qA@public.gmane.org>
Date : 2009-04-21 17:03 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-06 23:52 (41 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias-fd97jBR+K/6SGgWmA85PRw@public.gmane.org>
Date : 2009-04-12 14:10 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY@public.gmane.org>
Date : 2009-04-12 07:00 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-06 19:47 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark-pwcEARUeV57PDbFq/vQRIQ@public.gmane.org>
Date : 2009-04-06 19:12 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-03 09:30 (44 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
Date : 2009-03-31 08:58 (47 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-03-29 18:02 (49 days old)
Handled-By : Matt Carlson <mcarlson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Date : 2009-03-26 16:14 (52 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org>
Date : 2009-03-16 10:25 (62 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann-opNxpl+3fjRBDgjK7y7TUQ@public.gmane.org>
Date : 2009-03-20 07:13 (58 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12861
Subject : Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter : Emil Karlson <jkarlson-kf+aQKke1yb1KXRcyAk9cg@public.gmane.org>
Date : 2009-03-12 12:06 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab657db12d7020629f26f30d287558a8d0e32b41
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date : 2009-02-13 9:33 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj-5URONGGNgjI@public.gmane.org>
Date : 2009-02-09 13:01 (97 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy-l3A5Bk7waGM@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-13 18:34 (124 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By : Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-12 7:38 (125 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me-aXfl/3sk2vNUbtYUoyoikg@public.gmane.org>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
Subject : cpufreq timer teardown problem
Submitter : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Date : 2009-04-23 14:00 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/19754/
http://patchwork.kernel.org/patch/19753/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date : 2009-02-21 15:38 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/20197/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12490] ath5k related kernel panic in 2.6.29-rc1
2009-05-16 19:58 ` Rafael J. Wysocki
(?)
@ 2009-05-16 19:59 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Bob Copeland, Sergey S. Kostyliov
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (125 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me@bobcopeland.com>
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12499] Problem with using bluetooth adaper connected to usb port
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:04 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:04 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Marcel Holtmann
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2009-01-13 18:34 (124 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By : Marcel Holtmann <marcel@holtmann.org>
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12499] Problem with using bluetooth adaper connected to usb port
@ 2009-05-16 20:04 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:04 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Marcel Holtmann
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-13 18:34 (124 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By : Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12499] Problem with using bluetooth adaper connected to usb port
2009-05-16 20:04 ` Rafael J. Wysocki
@ 2009-05-17 7:58 ` Maciej Rutecki
-1 siblings, 0 replies; 142+ messages in thread
From: Maciej Rutecki @ 2009-05-17 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Marcel Holtmann
2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=12499
> Subject : Problem with using bluetooth adaper connected to usb port
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2009-01-13 18:34 (124 days old)
> References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By : Marcel Holtmann <marcel@holtmann.org>
>
2.6.30-rc6 works fine. Please, remove it.
Thanks
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12499] Problem with using bluetooth adaper connected to usb port
@ 2009-05-17 7:58 ` Maciej Rutecki
0 siblings, 0 replies; 142+ messages in thread
From: Maciej Rutecki @ 2009-05-17 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Marcel Holtmann
2009/5/16 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=12499
> Subject : Problem with using bluetooth adaper connected to usb port
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2009-01-13 18:34 (124 days old)
> References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By : Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
>
2.6.30-rc6 works fine. Please, remove it.
Thanks
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12499] Problem with using bluetooth adaper connected to usb port
@ 2009-05-17 10:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 10:21 UTC (permalink / raw)
To: Maciej Rutecki
Cc: Linux Kernel Mailing List, Kernel Testers List, Marcel Holtmann
On Sunday 17 May 2009, Maciej Rutecki wrote:
> 2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 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=12499
> > Subject : Problem with using bluetooth adaper connected to usb port
> > Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date : 2009-01-13 18:34 (124 days old)
> > References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> > Handled-By : Marcel Holtmann <marcel@holtmann.org>
> >
>
> 2.6.30-rc6 works fine. Please, remove it.
Removed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12499] Problem with using bluetooth adaper connected to usb port
@ 2009-05-17 10:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 10:21 UTC (permalink / raw)
To: Maciej Rutecki
Cc: Linux Kernel Mailing List, Kernel Testers List, Marcel Holtmann
On Sunday 17 May 2009, Maciej Rutecki wrote:
> 2009/5/16 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 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=12499
> > Subject : Problem with using bluetooth adaper connected to usb port
> > Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2009-01-13 18:34 (124 days old)
> > References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> > Handled-By : Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
> >
>
> 2.6.30-rc6 works fine. Please, remove it.
Removed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12861] Xorg fails to start "Failed to allocate space for kernel memory manager"
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, David Howells, DRI,
Emil Karlson, Eric Anholt, Linus Torvalds, Serge E. Hallyn
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12861
Subject : Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter : Emil Karlson <jkarlson@cc.hut.fi>
Date : 2009-03-12 12:06 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab657db12d7020629f26f30d287558a8d0e32b41
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12681] s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
2009-05-16 19:58 ` Rafael J. Wysocki
` (3 preceding siblings ...)
(?)
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alexey Starikovskiy, Len Brown, Linux ACPI,
Orivej Desh, Zhang Rui
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj@bk.ru>
Date : 2009-02-09 13:01 (97 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12705] X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Eric Anholt, Matthew Garrett,
Nico Schottelius
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213@schottelius.org>
Date : 2009-02-13 9:33 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric@anholt.net>
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12765] i915 VT switch with AIGLX causes X lock up
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, DRI, Jesse Barnes,
Michel Dänzer, Sitsofe Wheeler
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
Date : 2009-02-21 15:38 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://patchwork.kernel.org/patch/20197/
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12765] i915 VT switch with AIGLX causes X lock up
@ 2009-05-16 20:05 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, DRI, Jesse Barnes,
Michel Dänzer, Sitsofe Wheeler
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date : 2009-02-21 15:38 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/20197/
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up
2009-05-16 20:05 ` Rafael J. Wysocki
@ 2009-05-18 7:13 ` Sitsofe Wheeler
-1 siblings, 0 replies; 142+ messages in thread
From: Sitsofe Wheeler @ 2009-05-18 7:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, DRI,
Jesse Barnes, Michel Dänzer
On Sat, May 16, 2009 at 10:05:57PM +0200, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=12765
> Subject : i915 VT switch with AIGLX causes X lock up
> Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
> Date : 2009-02-21 15:38 (85 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> http://lkml.org/lkml/2009/4/27/317
> Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
> Patch : http://patchwork.kernel.org/patch/20197/
Yes, this problem is still here in 2.6.30-rc6-00026-g0f6f49a .
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up
@ 2009-05-18 7:13 ` Sitsofe Wheeler
0 siblings, 0 replies; 142+ messages in thread
From: Sitsofe Wheeler @ 2009-05-18 7:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, DRI,
Jesse Barnes, Michel Dänzer
On Sat, May 16, 2009 at 10:05:57PM +0200, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=12765
> Subject : i915 VT switch with AIGLX causes X lock up
> Submitter : Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
> Date : 2009-02-21 15:38 (85 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> http://lkml.org/lkml/2009/4/27/317
> Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
> Patch : http://patchwork.kernel.org/patch/20197/
Yes, this problem is still here in 2.6.30-rc6-00026-g0f6f49a .
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up
@ 2009-05-18 17:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-18 17:10 UTC (permalink / raw)
To: Sitsofe Wheeler
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, DRI,
Jesse Barnes, Michel Dänzer
On Monday 18 May 2009, Sitsofe Wheeler wrote:
> On Sat, May 16, 2009 at 10:05:57PM +0200, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 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=12765
> > Subject : i915 VT switch with AIGLX causes X lock up
> > Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
> > Date : 2009-02-21 15:38 (85 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> > References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> > http://lkml.org/lkml/2009/4/27/317
> > Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
> > Patch : http://patchwork.kernel.org/patch/20197/
>
> Yes, this problem is still here in 2.6.30-rc6-00026-g0f6f49a .
Thanks for the update.
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up
@ 2009-05-18 17:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-18 17:10 UTC (permalink / raw)
To: Sitsofe Wheeler
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, DRI,
Jesse Barnes, Michel Dänzer
On Monday 18 May 2009, Sitsofe Wheeler wrote:
> On Sat, May 16, 2009 at 10:05:57PM +0200, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 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=12765
> > Subject : i915 VT switch with AIGLX causes X lock up
> > Submitter : Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
> > Date : 2009-02-21 15:38 (85 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> > References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> > http://lkml.org/lkml/2009/4/27/317
> > Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
> > Patch : http://patchwork.kernel.org/patch/20197/
>
> Yes, this problem is still here in 2.6.30-rc6-00026-g0f6f49a .
Thanks for the update.
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12909] boot/kernel init duration regression from 2.6.28
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, CaT
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat@zip.com.au>
Date : 2009-03-16 10:25 (62 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12971] "tg3 transmit timed out" when transmitting at high bitrate
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Matt Carlson, Nikolay
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666@gmail.com>
Date : 2009-03-29 18:02 (49 days old)
Handled-By : Matt Carlson <mcarlson@broadcom.com>
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12971] "tg3 transmit timed out" when transmitting at high bitrate
@ 2009-05-16 20:05 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Matt Carlson, Nikolay
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-03-29 18:02 (49 days old)
Handled-By : Matt Carlson <mcarlson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12899] Crash in i915.ko: i915_driver_irq_handler
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, DRI, Helge Bahmann
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann@secunet.com>
Date : 2009-03-20 07:13 (58 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12899] Crash in i915.ko: i915_driver_irq_handler
@ 2009-05-16 20:05 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, DRI, Helge Bahmann
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann-opNxpl+3fjRBDgjK7y7TUQ@public.gmane.org>
Date : 2009-03-20 07:13 (58 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12947] r128: system hangs when X is started with DRI enabled
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, DRI, Jos van der Ende, venkatesh.pallipadi
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph@xs4all.nl>
Date : 2009-03-26 16:14 (52 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12947] r128: system hangs when X is started with DRI enabled
@ 2009-05-16 20:05 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, DRI, Jos van der Ende,
venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Date : 2009-03-26 16:14 (52 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12947] r128: system hangs when X is started with DRI enabled
2009-05-16 20:05 ` Rafael J. Wysocki
@ 2009-05-17 16:08 ` Jos van der Ende
-1 siblings, 0 replies; 142+ messages in thread
From: Jos van der Ende @ 2009-05-17 16:08 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, DRI,
Jos van der Ende, venkatesh.pallipadi
On Sat, 16 May 2009 22:05:58 +0200 (CEST)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
The bug is still present in 2.6.29.3, but we've found the likely cause and a potential fix. As soon as I have access to the system again, I will test this patch. Unfortunately I won't be anywhere near the system this week. I'll get back to it on Monday 25th.
--
Jos van der Ende <seraph@xs4all.nl>
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12947] r128: system hangs when X is started with DRI enabled
@ 2009-05-17 16:08 ` Jos van der Ende
0 siblings, 0 replies; 142+ messages in thread
From: Jos van der Ende @ 2009-05-17 16:08 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, DRI,
Jos van der Ende, venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w
On Sat, 16 May 2009 22:05:58 +0200 (CEST)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
The bug is still present in 2.6.29.3, but we've found the likely cause and a potential fix. As soon as I have access to the system again, I will test this patch. Unfortunately I won't be anywhere near the system this week. I'll get back to it on Monday 25th.
--
Jos van der Ende <seraph-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13001] PCI-DMA: Out of IOMMU space
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, FUJITA Tomonori, Grant Grundler, optimusgd
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd@gmail.com>
Date : 2009-04-03 09:30 (44 days old)
References : http://lkml.org/lkml/2009/4/28/133
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13024] nozomi: pppd fails on kernel 2.6.29
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Mark Karpeles
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark@hell.ne.jp>
Date : 2009-04-06 19:12 (41 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13024] nozomi: pppd fails on kernel 2.6.29
@ 2009-05-16 20:05 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Mark Karpeles
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark-pwcEARUeV57PDbFq/vQRIQ@public.gmane.org>
Date : 2009-04-06 19:12 (41 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12980] lockup in X.org
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:05 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Marcus Better
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus@better.se>
Date : 2009-03-31 08:58 (47 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #12980] lockup in X.org
@ 2009-05-16 20:05 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Marcus Better
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
Date : 2009-03-31 08:58 (47 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12980] lockup in X.org
2009-05-16 20:05 ` Rafael J. Wysocki
@ 2009-05-17 15:39 ` Marcus Better
-1 siblings, 0 replies; 142+ messages in thread
From: Marcus Better @ 2009-05-17 15:39 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
> Subject : lockup in X.org
> Submitter : Marcus Better <marcus@better.se>
> Date : 2009-03-31 08:58 (47 days old)
Bug went away for unknown reason, hasn't occurred in more than a month.
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoQL78ACgkQXjXn6TzcAQlQNQCcDH+GrasHNGT7UrrsvfNOH/iy
hlkAoMo9JJ+33MJLPrTF49HgfgcIdp/r
=ovke
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12980] lockup in X.org
@ 2009-05-17 15:39 ` Marcus Better
0 siblings, 0 replies; 142+ messages in thread
From: Marcus Better @ 2009-05-17 15:39 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
> Subject : lockup in X.org
> Submitter : Marcus Better <marcus-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
> Date : 2009-03-31 08:58 (47 days old)
Bug went away for unknown reason, hasn't occurred in more than a month.
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoQL78ACgkQXjXn6TzcAQlQNQCcDH+GrasHNGT7UrrsvfNOH/iy
hlkAoMo9JJ+33MJLPrTF49HgfgcIdp/r
=ovke
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #12980] lockup in X.org
@ 2009-05-17 17:27 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 17:27 UTC (permalink / raw)
To: Marcus Better; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Sunday 17 May 2009, Marcus Better wrote:
> Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
> > Subject : lockup in X.org
> > Submitter : Marcus Better <marcus@better.se>
> > Date : 2009-03-31 08:58 (47 days old)
>
> Bug went away for unknown reason, hasn't occurred in more than a month.
Thanks, bug closed.
Best,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13074] gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Paulo Matias
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias@archlinux-br.org>
Date : 2009-04-12 14:10 (35 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13074] gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Paulo Matias
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias-fd97jBR+K/6SGgWmA85PRw@public.gmane.org>
Date : 2009-04-12 14:10 (35 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Takashi Iwai, Yaroslav Isakov
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date : 2009-04-06 19:47 (41 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Takashi Iwai, Yaroslav Isakov
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-06 19:47 (41 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13072] forcedeth seems to switch off eth on shutdown
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Daniel Bierstedt
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date : 2009-04-12 07:00 (35 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13072] forcedeth seems to switch off eth on shutdown
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Daniel Bierstedt
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY@public.gmane.org>
Date : 2009-04-12 07:00 (35 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
[parent not found: <1242563611.15249.2.camel@laptop.workgroup>]
* Re: [Bug #13072] forcedeth seems to switch off eth on shutdown
@ 2009-05-17 12:56 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 12:56 UTC (permalink / raw)
To: Daniel Bierstedt; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Sunday 17 May 2009, Daniel Bierstedt wrote:
> Hello,
>
> as I wrote on 26'th of April:
>
> yes, this bug entry should be listed. This bug prevents people from
> using live-cd's or testing the 2.6.29 (if they know about this bug...).
>
> Meanwhile I did some tests with knoppix 6 (2.6.28.4) and the
> systemrescue-cd (2.6.27.somewhat). Both could deal with eth0, but the
> physical device remained dead...
Thanks for the update.
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13072] forcedeth seems to switch off eth on shutdown
@ 2009-05-17 12:56 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 12:56 UTC (permalink / raw)
To: Daniel Bierstedt; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Sunday 17 May 2009, Daniel Bierstedt wrote:
> Hello,
>
> as I wrote on 26'th of April:
>
> yes, this bug entry should be listed. This bug prevents people from
> using live-cd's or testing the 2.6.29 (if they know about this bug...).
>
> Meanwhile I did some tests with knoppix 6 (2.6.28.4) and the
> systemrescue-cd (2.6.27.somewhat). Both could deal with eth0, but the
> physical device remained dead...
Thanks for the update.
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alan Stern, Greg Kroah-Hartman,
Maxim Levitsky, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-04-06 23:52 (41 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13144] resume from suspend fails using video card i915
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, C Sights, Dave Airlie
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights@fastmail.fm>
Date : 2009-04-21 17:03 (26 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13144] resume from suspend fails using video card i915
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, C Sights, Dave Airlie
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights-97jfqw80gc6171pxa8y+qA@public.gmane.org>
Date : 2009-04-21 17:03 (26 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13175] sata_nv incompatible with async scsi scan
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Arjan van de Ven, Arjan van de Ven,
Benny Halevy, Jeff Garzik, Matthew Wilcox
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13175
Subject : sata_nv incompatible with async scsi scan
Submitter : Benny Halevy <bhalevy@panasas.com>
Date : 2009-04-21 7:03 (26 days old)
References : http://marc.info/?l=linux-kernel&m=124029746431777&w=4
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13172] Spontaneous reboots since 2.6.29-rc*
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki, Yinghai Lu
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13172
Subject : Spontaneous reboots since 2.6.29-rc*
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2009-04-17 17:03 (30 days old)
References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13172] Spontaneous reboots since 2.6.29-rc*
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki, Yinghai Lu
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13172
Subject : Spontaneous reboots since 2.6.29-rc*
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-17 17:03 (30 days old)
References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13172] Spontaneous reboots since 2.6.29-rc*
2009-05-16 20:06 ` Rafael J. Wysocki
@ 2009-05-17 7:53 ` Maciej Rutecki
-1 siblings, 0 replies; 142+ messages in thread
From: Maciej Rutecki @ 2009-05-17 7:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Yinghai Lu
2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13172
> Subject : Spontaneous reboots since 2.6.29-rc*
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2009-04-17 17:03 (30 days old)
> References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
>
>
I try:
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
from:
http://marc.info/?l=linux-kernel&m=124022460715035&w=4
Spontaneous reboots occur less often than in previous .config. From
last report it occur once or twice. I think, it's hardware/bios/mtrr
issue.
Because of this I think we should remove this regression from list,
until I find out, why it happen, or more people report this. What do
You think?
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13172] Spontaneous reboots since 2.6.29-rc*
@ 2009-05-17 7:53 ` Maciej Rutecki
0 siblings, 0 replies; 142+ messages in thread
From: Maciej Rutecki @ 2009-05-17 7:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Yinghai Lu
2009/5/16 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13172
> Subject : Spontaneous reboots since 2.6.29-rc*
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2009-04-17 17:03 (30 days old)
> References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
>
>
I try:
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
from:
http://marc.info/?l=linux-kernel&m=124022460715035&w=4
Spontaneous reboots occur less often than in previous .config. From
last report it occur once or twice. I think, it's hardware/bios/mtrr
issue.
Because of this I think we should remove this regression from list,
until I find out, why it happen, or more people report this. What do
You think?
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13172] Spontaneous reboots since 2.6.29-rc*
@ 2009-05-17 10:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 10:23 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: Linux Kernel Mailing List, Kernel Testers List, Yinghai Lu
On Sunday 17 May 2009, Maciej Rutecki wrote:
> 2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 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=13172
> > Subject : Spontaneous reboots since 2.6.29-rc*
> > Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date : 2009-04-17 17:03 (30 days old)
> > References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
> >
> >
>
> I try:
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>
> from:
> http://marc.info/?l=linux-kernel&m=124022460715035&w=4
>
> Spontaneous reboots occur less often than in previous .config. From
> last report it occur once or twice. I think, it's hardware/bios/mtrr
> issue.
>
> Because of this I think we should remove this regression from list,
> until I find out, why it happen, or more people report this. What do
> You think?
I've closed the bug. Pleaes reopen it once you've found the root cause.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13172] Spontaneous reboots since 2.6.29-rc*
@ 2009-05-17 10:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-17 10:23 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: Linux Kernel Mailing List, Kernel Testers List, Yinghai Lu
On Sunday 17 May 2009, Maciej Rutecki wrote:
> 2009/5/16 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 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=13172
> > Subject : Spontaneous reboots since 2.6.29-rc*
> > Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2009-04-17 17:03 (30 days old)
> > References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
> >
> >
>
> I try:
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
>
> from:
> http://marc.info/?l=linux-kernel&m=124022460715035&w=4
>
> Spontaneous reboots occur less often than in previous .config. From
> last report it occur once or twice. I think, it's hardware/bios/mtrr
> issue.
>
> Because of this I think we should remove this regression from list,
> until I find out, why it happen, or more people report this. What do
> You think?
I've closed the bug. Pleaes reopen it once you've found the root cause.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13178] Booting very slow
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Martin Knoblauch
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap@knobisoft.de>
Date : 2009-04-24 12:45 (23 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13178] Booting very slow
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Martin Knoblauch
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
Date : 2009-04-24 12:45 (23 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
2009-05-16 20:06 ` Rafael J. Wysocki
@ 2009-05-18 8:15 ` Martin Knoblauch
-1 siblings, 0 replies; 142+ messages in thread
From: Martin Knoblauch @ 2009-05-18 8:15 UTC (permalink / raw)
To: Rafael J. Wysocki, Linux Kernel Mailing List; +Cc: Kernel Testers List
----- Original Message ----
> From: Rafael J. Wysocki <rjw@sisk.pl>
> To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> Sent: Saturday, May 16, 2009 10:06:02 PM
> Subject: [Bug #13178] Booting very slow
>
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13178
> Subject : Booting very slow
> Submitter : Martin Knoblauch
> Date : 2009-04-24 12:45 (23 days old)
> References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.
Simple fix to user space is available. I do not know how important this issue is.
Anyway, I am in the process of bisecting the problem. It is just a bit tedious in the my customers and employers environment :-(
Cheers
Martin
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-18 8:15 ` Martin Knoblauch
0 siblings, 0 replies; 142+ messages in thread
From: Martin Knoblauch @ 2009-05-18 8:15 UTC (permalink / raw)
To: Rafael J. Wysocki, Linux Kernel Mailing List; +Cc: Kernel Testers List
----- Original Message ----
> From: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> To: Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Kernel Testers List <kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
> Sent: Saturday, May 16, 2009 10:06:02 PM
> Subject: [Bug #13178] Booting very slow
>
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13178
> Subject : Booting very slow
> Submitter : Martin Knoblauch
> Date : 2009-04-24 12:45 (23 days old)
> References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.
Simple fix to user space is available. I do not know how important this issue is.
Anyway, I am in the process of bisecting the problem. It is just a bit tedious in the my customers and employers environment :-(
Cheers
Martin
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-18 17:13 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-18 17:13 UTC (permalink / raw)
To: Martin Knoblauch; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Monday 18 May 2009, Martin Knoblauch wrote:
>
> ----- Original Message ----
>
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> > To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> > Sent: Saturday, May 16, 2009 10:06:02 PM
> > Subject: [Bug #13178] Booting very slow
> >
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 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=13178
> > Subject : Booting very slow
> > Submitter : Martin Knoblauch
> > Date : 2009-04-24 12:45 (23 days old)
> > References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
>
> The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.
>
> Simple fix to user space is available. I do not know how important this issue is.
>
> Anyway, I am in the process of bisecting the problem. It is just a bit tedious in the my customers and employers environment :-(
Thanks a lot for doing this.
Best,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-18 17:13 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-18 17:13 UTC (permalink / raw)
To: Martin Knoblauch; +Cc: Linux Kernel Mailing List, Kernel Testers List
On Monday 18 May 2009, Martin Knoblauch wrote:
>
> ----- Original Message ----
>
> > From: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> > To: Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> > Cc: Kernel Testers List <kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
> > Sent: Saturday, May 16, 2009 10:06:02 PM
> > Subject: [Bug #13178] Booting very slow
> >
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 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=13178
> > Subject : Booting very slow
> > Submitter : Martin Knoblauch
> > Date : 2009-04-24 12:45 (23 days old)
> > References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
>
> The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.
>
> Simple fix to user space is available. I do not know how important this issue is.
>
> Anyway, I am in the process of bisecting the problem. It is just a bit tedious in the my customers and employers environment :-(
Thanks a lot for doing this.
Best,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-19 0:26 ` Kay Sievers
0 siblings, 0 replies; 142+ messages in thread
From: Kay Sievers @ 2009-05-19 0:26 UTC (permalink / raw)
To: Martin Knoblauch
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Mon, May 18, 2009 at 10:15, Martin Knoblauch <spamtrap@knobisoft.de> wrote:
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
>> Subject : Booting very slow
>> Submitter : Martin Knoblauch
>> Date : 2009-04-24 12:45 (23 days old)
>> References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
>
> The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.
Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
leaves the sysfs entry in /proc/mounts behind, which then shows up as
a duplicate when running in the real rootfs?
Thanks,
Kay
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-19 0:26 ` Kay Sievers
0 siblings, 0 replies; 142+ messages in thread
From: Kay Sievers @ 2009-05-19 0:26 UTC (permalink / raw)
To: Martin Knoblauch
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Mon, May 18, 2009 at 10:15, Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org> wrote:
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
>> Subject : Booting very slow
>> Submitter : Martin Knoblauch
>> Date : 2009-04-24 12:45 (23 days old)
>> References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
>
> The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.
Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
leaves the sysfs entry in /proc/mounts behind, which then shows up as
a duplicate when running in the real rootfs?
Thanks,
Kay
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-19 7:22 ` Martin Knoblauch
0 siblings, 0 replies; 142+ messages in thread
From: Martin Knoblauch @ 2009-05-19 7:22 UTC (permalink / raw)
To: Kay Sievers
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
----- Original Message ----
> From: Kay Sievers <kay.sievers@vrfy.org>
> To: Martin Knoblauch <spamtrap@knobisoft.de>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Kernel Testers List <kernel-testers@vger.kernel.org>
> Sent: Tuesday, May 19, 2009 2:26:04 AM
> Subject: Re: [Bug #13178] Booting very slow
>
> On Mon, May 18, 2009 at 10:15, Martin Knoblauch wrote:
>
> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
> >> Subject : Booting very slow
> >> Submitter : Martin Knoblauch
> >> Date : 2009-04-24 12:45 (23 days old)
> >> References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> >
> > The issue is still open. It turns out that starting with 2.6.29-rc1
> /proc/mounts already has a "sysfs" line when entering the startup scripts from
> initrd. This breaks the RHEL4 firmware hotplug script.
>
> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
> leaves the sysfs entry in /proc/mounts behind, which then shows up as
> a duplicate when running in the real rootfs?
>
could be. Remains the question, why it never showed up before 2.6.29. I compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the module-binaries.
Cheers
Martin
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-19 7:22 ` Martin Knoblauch
0 siblings, 0 replies; 142+ messages in thread
From: Martin Knoblauch @ 2009-05-19 7:22 UTC (permalink / raw)
To: Kay Sievers
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
----- Original Message ----
> From: Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>
> To: Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
> Cc: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>; Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; Kernel Testers List <kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Sent: Tuesday, May 19, 2009 2:26:04 AM
> Subject: Re: [Bug #13178] Booting very slow
>
> On Mon, May 18, 2009 at 10:15, Martin Knoblauch wrote:
>
> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
> >> Subject : Booting very slow
> >> Submitter : Martin Knoblauch
> >> Date : 2009-04-24 12:45 (23 days old)
> >> References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> >
> > The issue is still open. It turns out that starting with 2.6.29-rc1
> /proc/mounts already has a "sysfs" line when entering the startup scripts from
> initrd. This breaks the RHEL4 firmware hotplug script.
>
> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
> leaves the sysfs entry in /proc/mounts behind, which then shows up as
> a duplicate when running in the real rootfs?
>
could be. Remains the question, why it never showed up before 2.6.29. I compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the module-binaries.
Cheers
Martin
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-19 8:58 ` Kay Sievers
0 siblings, 0 replies; 142+ messages in thread
From: Kay Sievers @ 2009-05-19 8:58 UTC (permalink / raw)
To: Martin Knoblauch
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Tue, May 19, 2009 at 09:22, Martin Knoblauch <spamtrap@knobisoft.de> wrote:
>> > The issue is still open. It turns out that starting with 2.6.29-rc1
>> /proc/mounts already has a "sysfs" line when entering the startup scripts from
>> initrd. This breaks the RHEL4 firmware hotplug script.
>>
>> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
>> leaves the sysfs entry in /proc/mounts behind, which then shows up as
>> a duplicate when running in the real rootfs?
>
> could be. Remains the question, why it never showed up before 2.6.29. I compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the module-binaries.
I wouldn't be surprised if we are just "too fast" again now with the
async stuff, for another piece of rather fragile userspace bootup
logic, making some wrong assumptions. Are you compiling-in the modules
for the root disk and the root filesystem?
Cheers,
Kay
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-19 8:58 ` Kay Sievers
0 siblings, 0 replies; 142+ messages in thread
From: Kay Sievers @ 2009-05-19 8:58 UTC (permalink / raw)
To: Martin Knoblauch
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Tue, May 19, 2009 at 09:22, Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org> wrote:
>> > The issue is still open. It turns out that starting with 2.6.29-rc1
>> /proc/mounts already has a "sysfs" line when entering the startup scripts from
>> initrd. This breaks the RHEL4 firmware hotplug script.
>>
>> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
>> leaves the sysfs entry in /proc/mounts behind, which then shows up as
>> a duplicate when running in the real rootfs?
>
> could be. Remains the question, why it never showed up before 2.6.29. I compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the module-binaries.
I wouldn't be surprised if we are just "too fast" again now with the
async stuff, for another piece of rather fragile userspace bootup
logic, making some wrong assumptions. Are you compiling-in the modules
for the root disk and the root filesystem?
Cheers,
Kay
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-20 10:14 ` Martin Knoblauch
0 siblings, 0 replies; 142+ messages in thread
From: Martin Knoblauch @ 2009-05-20 10:14 UTC (permalink / raw)
To: Kay Sievers
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
----- Original Message ----
> From: Kay Sievers <kay.sievers@vrfy.org>
> To: Martin Knoblauch <spamtrap@knobisoft.de>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Kernel Testers List <kernel-testers@vger.kernel.org>
> Sent: Tuesday, May 19, 2009 10:58:24 AM
> Subject: Re: [Bug #13178] Booting very slow
>
> On Tue, May 19, 2009 at 09:22, Martin Knoblauch wrote:
> >> > The issue is still open. It turns out that starting with 2.6.29-rc1
> >> /proc/mounts already has a "sysfs" line when entering the startup scripts
> from
> >> initrd. This breaks the RHEL4 firmware hotplug script.
> >>
> >> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
> >> leaves the sysfs entry in /proc/mounts behind, which then shows up as
> >> a duplicate when running in the real rootfs?
> >
> > could be. Remains the question, why it never showed up before 2.6.29. I
> compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the
> module-binaries.
>
> I wouldn't be surprised if we are just "too fast" again now with the
> async stuff, for another piece of rather fragile userspace bootup
> logic, making some wrong assumptions. Are you compiling-in the modules
> for the root disk and the root filesystem?
>
> Cheers,
> Kay
timing may actually be the answer. I finally manged to bisect the thing and the first bad commit is this one:
|commit 1120f8b8169fb2cb51219d326892d963e762edb6
|Author: Stephen Hemminger <shemminger@vyatta.com>
|Date: Thu Dec 18 09:17:16 2008 -0800
|
| PCI: handle long delays in VPD access
|
| Accessing the VPD area can take a long time. The existing
| VPD access code fails consistently on my hardware. There are comments
|
| Change the access routines to:
| * use a mutex rather than spinning with IRQ's disabled and lock held
| * have a much longer timeout
| * call cond_resched while spinning
|
| Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
| Reviewed-by: Matthew Wilcox <willy@linux.intel.com>
| Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
And no, the "cciss", "ext3" and "jbd" are modules in my intrd image.
I will continue the discussion under the original topic.
Cheers
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13178] Booting very slow
@ 2009-05-20 10:14 ` Martin Knoblauch
0 siblings, 0 replies; 142+ messages in thread
From: Martin Knoblauch @ 2009-05-20 10:14 UTC (permalink / raw)
To: Kay Sievers
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
----- Original Message ----
> From: Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>
> To: Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
> Cc: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>; Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; Kernel Testers List <kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Sent: Tuesday, May 19, 2009 10:58:24 AM
> Subject: Re: [Bug #13178] Booting very slow
>
> On Tue, May 19, 2009 at 09:22, Martin Knoblauch wrote:
> >> > The issue is still open. It turns out that starting with 2.6.29-rc1
> >> /proc/mounts already has a "sysfs" line when entering the startup scripts
> from
> >> initrd. This breaks the RHEL4 firmware hotplug script.
> >>
> >> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
> >> leaves the sysfs entry in /proc/mounts behind, which then shows up as
> >> a duplicate when running in the real rootfs?
> >
> > could be. Remains the question, why it never showed up before 2.6.29. I
> compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the
> module-binaries.
>
> I wouldn't be surprised if we are just "too fast" again now with the
> async stuff, for another piece of rather fragile userspace bootup
> logic, making some wrong assumptions. Are you compiling-in the modules
> for the root disk and the root filesystem?
>
> Cheers,
> Kay
timing may actually be the answer. I finally manged to bisect the thing and the first bad commit is this one:
|commit 1120f8b8169fb2cb51219d326892d963e762edb6
|Author: Stephen Hemminger <shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>
|Date: Thu Dec 18 09:17:16 2008 -0800
|
| PCI: handle long delays in VPD access
|
| Accessing the VPD area can take a long time. The existing
| VPD access code fails consistently on my hardware. There are comments
|
| Change the access routines to:
| * use a mutex rather than spinning with IRQ's disabled and lock held
| * have a much longer timeout
| * call cond_resched while spinning
|
| Signed-off-by: Stephen Hemminger <shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>
| Reviewed-by: Matthew Wilcox <willy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
| Signed-off-by: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
And no, the "cciss", "ext3" and "jbd" are modules in my intrd image.
I will continue the discussion under the original topic.
Cheers
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13186] cpufreq timer teardown problem
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Mathieu Desnoyers
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13186
Subject : cpufreq timer teardown problem
Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date : 2009-04-23 14:00 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Patch : http://patchwork.kernel.org/patch/19754/
http://patchwork.kernel.org/patch/19753/
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13186] cpufreq timer teardown problem
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Mathieu Desnoyers
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13186
Subject : cpufreq timer teardown problem
Submitter : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Date : 2009-04-23 14:00 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/19754/
http://patchwork.kernel.org/patch/19753/
^ permalink raw reply [flat|nested] 142+ messages in thread
* [PATCH] cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
2009-05-16 20:06 ` Rafael J. Wysocki
@ 2009-05-17 14:23 ` Mathieu Desnoyers
-1 siblings, 0 replies; 142+ messages in thread
From: Mathieu Desnoyers @ 2009-05-17 14:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Chris Wright, Dave Jones, Ben Slusky, Ingo Molnar, Greg KH,
KOSAKI Motohiro
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
The patches linked above depend on the following patch to remove
circular locking dependency :
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
(the following issue was faced when using cancel_delayed_work_sync() in the
timer teardown (which fixes a race).
* KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:
> Hi
>
> my box output following warnings.
> it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
>
> A: work -> do_dbs_timer() -> cpu_policy_rwsem
> B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
>
>
Hrm, I think it must be due to my attempt to fix the timer teardown race
in ondemand governor mixed with new locking behavior in 2.6.30-rc.
The rwlock seems to be taken around the whole call to
cpufreq_governor_dbs(), when it should be only taken around accesses to
the locked data, and especially *not* around the call to
dbs_timer_exit().
Reverting my fix attempt would put the teardown race back in place
(replacing the cancel_delayed_work_sync by cancel_delayed_work).
Instead, a proper fix would imply modifying this critical section :
cpufreq.c: __cpufreq_remove_dev()
...
if (cpufreq_driver->target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);
unlock_policy_rwsem_write(cpu);
To make sure the __cpufreq_governor() callback is not called with rwsem
held. This would allow execution of cancel_delayed_work_sync() without
being nested within the rwsem.
Applies on top of the 2.6.30-rc5 tree.
Required to remove circular dep in teardown of both conservative and
ondemande governors so they can use cancel_delayed_work_sync().
CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
unneeded.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Greg KH <greg@kroah.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
CC: Ben Slusky <sluskyb@paranoiacs.org>
CC: Dave Jones <davej@redhat.com>
CC: Chris Wright <chrisw@sous-sol.org>
CC: Andrew Morton <akpm@linux-foundation.org>
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-lttng/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq.c 2009-05-10 14:41:53.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq.c 2009-05-10 14:42:29.000000000 -0400
@@ -1070,11 +1070,11 @@ static int __cpufreq_remove_dev(struct s
spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
#endif
+ unlock_policy_rwsem_write(cpu);
+
if (cpufreq_driver->target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);
- unlock_policy_rwsem_write(cpu);
-
kobject_put(&data->kobj);
/* we need to make sure that the underlying kobj is actually
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 142+ messages in thread
* [PATCH] cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
@ 2009-05-17 14:23 ` Mathieu Desnoyers
0 siblings, 0 replies; 142+ messages in thread
From: Mathieu Desnoyers @ 2009-05-17 14:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Chris Wright, Dave Jones, Ben Slusky, Ingo Molnar, Greg KH,
KOSAKI Motohiro
* Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
The patches linked above depend on the following patch to remove
circular locking dependency :
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
(the following issue was faced when using cancel_delayed_work_sync() in the
timer teardown (which fixes a race).
* KOSAKI Motohiro (kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org) wrote:
> Hi
>
> my box output following warnings.
> it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
>
> A: work -> do_dbs_timer() -> cpu_policy_rwsem
> B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
>
>
Hrm, I think it must be due to my attempt to fix the timer teardown race
in ondemand governor mixed with new locking behavior in 2.6.30-rc.
The rwlock seems to be taken around the whole call to
cpufreq_governor_dbs(), when it should be only taken around accesses to
the locked data, and especially *not* around the call to
dbs_timer_exit().
Reverting my fix attempt would put the teardown race back in place
(replacing the cancel_delayed_work_sync by cancel_delayed_work).
Instead, a proper fix would imply modifying this critical section :
cpufreq.c: __cpufreq_remove_dev()
...
if (cpufreq_driver->target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);
unlock_policy_rwsem_write(cpu);
To make sure the __cpufreq_governor() callback is not called with rwsem
held. This would allow execution of cancel_delayed_work_sync() without
being nested within the rwsem.
Applies on top of the 2.6.30-rc5 tree.
Required to remove circular dep in teardown of both conservative and
ondemande governors so they can use cancel_delayed_work_sync().
CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
unneeded.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
CC: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
CC: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
CC: "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>
CC: Ben Slusky <sluskyb-k/7z6JowIC0cuXOPmUuyGA@public.gmane.org>
CC: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
CC: Chris Wright <chrisw-69jw2NvuJkxg9hUCZPvPmw@public.gmane.org>
CC: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-lttng/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq.c 2009-05-10 14:41:53.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq.c 2009-05-10 14:42:29.000000000 -0400
@@ -1070,11 +1070,11 @@ static int __cpufreq_remove_dev(struct s
spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
#endif
+ unlock_policy_rwsem_write(cpu);
+
if (cpufreq_driver->target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);
- unlock_policy_rwsem_write(cpu);
-
kobject_put(&data->kobj);
/* we need to make sure that the underlying kobj is actually
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 142+ messages in thread
* [PATCH] cpufreq fix timer teardown in conservative governor
2009-05-16 20:06 ` Rafael J. Wysocki
@ 2009-05-17 14:29 ` Mathieu Desnoyers
-1 siblings, 0 replies; 142+ messages in thread
From: Mathieu Desnoyers @ 2009-05-17 14:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
gregkh, stable, cpufreq, Ingo Molnar, rjw, Ben Slusky,
Dave Jones
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(re-send with updated changelog)
cpufreq fix timer teardown in conservative governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
The following patch applies to 2.6.30-rc2. Stable kernels have a similar
issue which should also be fixed, but the code changed between 2.6.29
and 2.6.30, so this patch only applies to 2.6.30-rc.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: gregkh@suse.de
CC: stable@kernel.org
CC: cpufreq@vger.kernel.org
CC: Ingo Molnar <mingo@elte.hu>
CC: rjw@sisk.pl
CC: Ben Slusky <sluskyb@paranoiacs.org>
CC: Dave Jones <davej@redhat.com>
---
drivers/cpufreq/cpufreq_conservative.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/drivers/cpufreq/cpufreq_conservative.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq_conservative.c 2009-04-23 23:22:15.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq_conservative.c 2009-04-23 23:24:38.000000000 -0400
@@ -91,6 +91,9 @@ static unsigned int dbs_enable; /* numbe
* (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
* cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
* is recursive for the same process. -Venki
+ * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
+ * would deadlock with cancel_delayed_work_sync(), which is needed for proper
+ * raceless workqueue teardown.
*/
static DEFINE_MUTEX(dbs_mutex);
@@ -542,7 +545,7 @@ static inline void dbs_timer_init(struct
static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
{
dbs_info->enable = 0;
- cancel_delayed_work(&dbs_info->work);
+ cancel_delayed_work_sync(&dbs_info->work);
}
static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 142+ messages in thread
* [PATCH] cpufreq fix timer teardown in conservative governor
@ 2009-05-17 14:29 ` Mathieu Desnoyers
0 siblings, 0 replies; 142+ messages in thread
From: Mathieu Desnoyers @ 2009-05-17 14:29 UTC (permalink / raw)
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
gregkh-l3A5Bk7waGM, stable-DgEjT+Ai2ygdnm+yROfE0A,
cpufreq-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, rjw-KKrjLPT3xs0,
Ben Slusky, Dave Jones
* Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(re-send with updated changelog)
cpufreq fix timer teardown in conservative governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
The following patch applies to 2.6.30-rc2. Stable kernels have a similar
issue which should also be fixed, but the code changed between 2.6.29
and 2.6.30, so this patch only applies to 2.6.30-rc.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
CC: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
CC: gregkh-l3A5Bk7waGM@public.gmane.org
CC: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
CC: cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
CC: rjw-KKrjLPT3xs0@public.gmane.org
CC: Ben Slusky <sluskyb-k/7z6JowIC0cuXOPmUuyGA@public.gmane.org>
CC: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/cpufreq/cpufreq_conservative.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/drivers/cpufreq/cpufreq_conservative.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq_conservative.c 2009-04-23 23:22:15.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq_conservative.c 2009-04-23 23:24:38.000000000 -0400
@@ -91,6 +91,9 @@ static unsigned int dbs_enable; /* numbe
* (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
* cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
* is recursive for the same process. -Venki
+ * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
+ * would deadlock with cancel_delayed_work_sync(), which is needed for proper
+ * raceless workqueue teardown.
*/
static DEFINE_MUTEX(dbs_mutex);
@@ -542,7 +545,7 @@ static inline void dbs_timer_init(struct
static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
{
dbs_info->enable = 0;
- cancel_delayed_work(&dbs_info->work);
+ cancel_delayed_work_sync(&dbs_info->work);
}
static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 142+ messages in thread
* [PATCH] cpufreq fix timer teardown in ondemand governor
2009-05-16 20:06 ` Rafael J. Wysocki
@ 2009-05-17 14:30 ` Mathieu Desnoyers
-1 siblings, 0 replies; 142+ messages in thread
From: Mathieu Desnoyers @ 2009-05-17 14:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
gregkh, stable, cpufreq, Ingo Molnar, rjw, Ben Slusky,
Dave Jones
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(updated changelog)
cpufreq fix timer teardown in ondemand governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: gregkh@suse.de
CC: stable@kernel.org
CC: cpufreq@vger.kernel.org
CC: Ingo Molnar <mingo@elte.hu>
CC: rjw@sisk.pl
CC: Ben Slusky <sluskyb@paranoiacs.org>
CC: Dave Jones <davej@redhat.com>
---
drivers/cpufreq/cpufreq_ondemand.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/drivers/cpufreq/cpufreq_ondemand.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq_ondemand.c 2009-04-23 23:25:00.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq_ondemand.c 2009-04-23 23:25:39.000000000 -0400
@@ -98,6 +98,9 @@ static unsigned int dbs_enable; /* numbe
* (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
* cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
* is recursive for the same process. -Venki
+ * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
+ * would deadlock with cancel_delayed_work_sync(), which is needed for proper
+ * raceless workqueue teardown.
*/
static DEFINE_MUTEX(dbs_mutex);
@@ -562,7 +565,7 @@ static inline void dbs_timer_init(struct
static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
{
dbs_info->enable = 0;
- cancel_delayed_work(&dbs_info->work);
+ cancel_delayed_work_sync(&dbs_info->work);
}
static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 142+ messages in thread
* [PATCH] cpufreq fix timer teardown in ondemand governor
@ 2009-05-17 14:30 ` Mathieu Desnoyers
0 siblings, 0 replies; 142+ messages in thread
From: Mathieu Desnoyers @ 2009-05-17 14:30 UTC (permalink / raw)
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
gregkh-l3A5Bk7waGM, stable-DgEjT+Ai2ygdnm+yROfE0A,
cpufreq-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, rjw-KKrjLPT3xs0,
Ben Slusky, Dave Jones
* Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(updated changelog)
cpufreq fix timer teardown in ondemand governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
CC: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
CC: gregkh-l3A5Bk7waGM@public.gmane.org
CC: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
CC: cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
CC: rjw-KKrjLPT3xs0@public.gmane.org
CC: Ben Slusky <sluskyb-k/7z6JowIC0cuXOPmUuyGA@public.gmane.org>
CC: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/cpufreq/cpufreq_ondemand.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/drivers/cpufreq/cpufreq_ondemand.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq_ondemand.c 2009-04-23 23:25:00.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq_ondemand.c 2009-04-23 23:25:39.000000000 -0400
@@ -98,6 +98,9 @@ static unsigned int dbs_enable; /* numbe
* (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
* cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
* is recursive for the same process. -Venki
+ * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
+ * would deadlock with cancel_delayed_work_sync(), which is needed for proper
+ * raceless workqueue teardown.
*/
static DEFINE_MUTEX(dbs_mutex);
@@ -562,7 +565,7 @@ static inline void dbs_timer_init(struct
static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
{
dbs_info->enable = 0;
- cancel_delayed_work(&dbs_info->work);
+ cancel_delayed_work_sync(&dbs_info->work);
}
static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13225] [2.6.29 regression] Software suspend no longer works
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Artem S. Tashkinov
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2009-05-02 21:41 (15 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13225] [2.6.29 regression] Software suspend no longer works
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Artem S. Tashkinov
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem-VInPYn6yXxRWk0Htik3J/w@public.gmane.org>
Date : 2009-05-02 21:41 (15 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13183] forcedeth: no link during initialization
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Harald Dunkel
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13183
Subject : forcedeth: no link during initialization
Submitter : Harald Dunkel <harald.dunkel@t-online.de>
Date : 2009-04-23 13:02 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049180309233&w=4
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, cedric, Peter Zijlstra
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric@belbone.be>
Date : 2009-05-08 08:48 (9 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, cedric, Peter Zijlstra
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric-x1Cn44Nr1HaZIoH1IeqzKA@public.gmane.org>
Date : 2009-05-08 08:48 (9 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (14 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date : 2009-05-03 19:46 (14 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-16 20:06 ` Rafael J. Wysocki
@ 2009-05-18 13:25 ` Theodore Tso
-1 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-05-18 13:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Watson
On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13232
> Subject : ext3/4 with synchronous writes gets wedged by Postfix
> Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> Date : 2009-05-03 19:46 (14 days old)
This turned out to be caused by change in the VFS, as documented in
the bug report. Al Viro has a patch, which I've reviewed.
David, would you be able to try testing Al's proposed patch, since you
have an easy reproduction case? Thanks,
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-18 13:25 ` Theodore Tso
0 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-05-18 13:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Watson
On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 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=13232
> Subject : ext3/4 with synchronous writes gets wedged by Postfix
> Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> Date : 2009-05-03 19:46 (14 days old)
This turned out to be caused by change in the VFS, as documented in
the bug report. Al Viro has a patch, which I've reviewed.
David, would you be able to try testing Al's proposed patch, since you
have an easy reproduction case? Thanks,
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-19 17:17 ` David Watson
0 siblings, 0 replies; 142+ messages in thread
From: David Watson @ 2009-05-19 17:17 UTC (permalink / raw)
To: Theodore Tso, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Mon 18 May 2009, Theodore Tso wrote:
> On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > Date : 2009-05-03 19:46 (14 days old)
>
> This turned out to be caused by change in the VFS, as documented in
> the bug report. Al Viro has a patch, which I've reviewed.
>
> David, would you be able to try testing Al's proposed patch, since you
> have an easy reproduction case? Thanks,
Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-19 17:17 ` David Watson
0 siblings, 0 replies; 142+ messages in thread
From: David Watson @ 2009-05-19 17:17 UTC (permalink / raw)
To: Theodore Tso, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Mon 18 May 2009, Theodore Tso wrote:
> On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > Date : 2009-05-03 19:46 (14 days old)
>
> This turned out to be caused by change in the VFS, as documented in
> the bug report. Al Viro has a patch, which I've reviewed.
>
> David, would you be able to try testing Al's proposed patch, since you
> have an easy reproduction case? Thanks,
Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-19 17:53 ` Theodore Tso
0 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-05-19 17:53 UTC (permalink / raw)
To: David Watson, Al Viro
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
> On Mon 18 May 2009, Theodore Tso wrote:
> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > > Date : 2009-05-03 19:46 (14 days old)
> >
> > This turned out to be caused by change in the VFS, as documented in
> > the bug report. Al Viro has a patch, which I've reviewed.
> >
> > David, would you be able to try testing Al's proposed patch, since you
> > have an easy reproduction case? Thanks,
>
> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
Thanks, David.
Al, Jan Kara and I have reviewed your patch, and we can add a
Tested-by: from David Watson (assuming David, you don't mind your name
or e-mail address showing up in the Kernel commit logs --- if you want
us to suppress one or both, please let us know). Given this is a
2.6.28 regression, and this can certainly affect real-life users, I
think we should push your patch to Linus for 2.6.30. Do you agree?
Regards,
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-19 17:53 ` Theodore Tso
0 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-05-19 17:53 UTC (permalink / raw)
To: David Watson, Al Viro
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
> On Mon 18 May 2009, Theodore Tso wrote:
> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > > Date : 2009-05-03 19:46 (14 days old)
> >
> > This turned out to be caused by change in the VFS, as documented in
> > the bug report. Al Viro has a patch, which I've reviewed.
> >
> > David, would you be able to try testing Al's proposed patch, since you
> > have an easy reproduction case? Thanks,
>
> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
Thanks, David.
Al, Jan Kara and I have reviewed your patch, and we can add a
Tested-by: from David Watson (assuming David, you don't mind your name
or e-mail address showing up in the Kernel commit logs --- if you want
us to suppress one or both, please let us know). Given this is a
2.6.28 regression, and this can certainly affect real-life users, I
think we should push your patch to Linus for 2.6.30. Do you agree?
Regards,
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-19 17:53 ` Theodore Tso
(?)
@ 2009-05-19 18:27 ` John Stoffel
2009-05-19 20:41 ` Theodore Tso
-1 siblings, 1 reply; 142+ messages in thread
From: John Stoffel @ 2009-05-19 18:27 UTC (permalink / raw)
To: Theodore Tso
Cc: David Watson, Al Viro, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
>>>>> "Theodore" == Theodore Tso <tytso@mit.edu> writes:
Theodore> On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
>> On Mon 18 May 2009, Theodore Tso wrote:
>> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
>> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
>> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
>> > > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
>> > > Date : 2009-05-03 19:46 (14 days old)
>> >
>> > This turned out to be caused by change in the VFS, as documented in
>> > the bug report. Al Viro has a patch, which I've reviewed.
>> >
>> > David, would you be able to try testing Al's proposed patch, since you
>> > have an easy reproduction case? Thanks,
>>
>> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
Theodore> Al, Jan Kara and I have reviewed your patch, and we can add
Theodore> a Tested-by: from David Watson (assuming David, you don't
Theodore> mind your name or e-mail address showing up in the Kernel
Theodore> commit logs --- if you want us to suppress one or both,
Theodore> please let us know). Given this is a 2.6.28 regression, and
Theodore> this can certainly affect real-life users, I think we should
Theodore> push your patch to Linus for 2.6.30. Do you agree?
I wonder if this is the reason my main file server has been locking up
solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
Since it's my main file server at home, and with my home dir NFS
mounted from it onto another system, it's been hard to catch. I spent
some time fiddling around getting netconsole setup, but then I ran out
of time.
My system is a Debian, pretty upto date, PIII, 550Mhz Dual CPU, 3Gb
RAM, lots of SCSI, SATA and IDE busses, with various types of devices
on all the busses, from DLT tape drive and library, to a mix of disks.
I'm also running ext4 on a mirrored pair disks I use for spooling
backups to tape from. Ext3 on the rest of my mirrored filesystems as
well.
If someone could send me the patch, I'll apply it and see how well
2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
Reproducing the problem was pretty easy for me.
Thanks,
John
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-19 20:41 ` Theodore Tso
0 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-05-19 20:41 UTC (permalink / raw)
To: John Stoffel
Cc: David Watson, Al Viro, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Tue, May 19, 2009 at 02:27:14PM -0400, John Stoffel wrote:
> I wonder if this is the reason my main file server has been locking up
> solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
> Since it's my main file server at home, and with my home dir NFS
> mounted from it onto another system, it's been hard to catch. I spent
> some time fiddling around getting netconsole setup, but then I ran out
> of time.
Unless you have your partition mounted with the "sync" mount option
(which has negative performance implifications; it makes sense for a
mail queue directory, but not necessarily for a general purpose file
server) or you have a directory chattr'ed with the sync flag, probably
not...
If you want to try it, though, the patch is available here:
http://bugzilla.kernel.org/attachment.cgi?id=21436
> If someone could send me the patch, I'll apply it and see how well
> 2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
> Reproducing the problem was pretty easy for me.
Anything on the console? Any oops messages, or soft lockup warnings?
What filesystem(s) are you using?
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-19 20:41 ` Theodore Tso
0 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-05-19 20:41 UTC (permalink / raw)
To: John Stoffel
Cc: David Watson, Al Viro, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Tue, May 19, 2009 at 02:27:14PM -0400, John Stoffel wrote:
> I wonder if this is the reason my main file server has been locking up
> solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
> Since it's my main file server at home, and with my home dir NFS
> mounted from it onto another system, it's been hard to catch. I spent
> some time fiddling around getting netconsole setup, but then I ran out
> of time.
Unless you have your partition mounted with the "sync" mount option
(which has negative performance implifications; it makes sense for a
mail queue directory, but not necessarily for a general purpose file
server) or you have a directory chattr'ed with the sync flag, probably
not...
If you want to try it, though, the patch is available here:
http://bugzilla.kernel.org/attachment.cgi?id=21436
> If someone could send me the patch, I'll apply it and see how well
> 2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
> Reproducing the problem was pretty easy for me.
Anything on the console? Any oops messages, or soft lockup warnings?
What filesystem(s) are you using?
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-20 16:53 ` John Stoffel
0 siblings, 0 replies; 142+ messages in thread
From: John Stoffel @ 2009-05-20 16:53 UTC (permalink / raw)
To: Theodore Tso
Cc: John Stoffel, David Watson, Al Viro, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
>>>>> "Theodore" == Theodore Tso <tytso@mit.edu> writes:
Oops. It looks like 2.6.29.3 is actually quite solid. My fault, I
must have gotten confused. I know that 2.6.30-rc* was unstable on
there and locked up easily.
Theodore> On Tue, May 19, 2009 at 02:27:14PM -0400, John Stoffel wrote:
>> I wonder if this is the reason my main file server has been locking up
>> solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
>> Since it's my main file server at home, and with my home dir NFS
>> mounted from it onto another system, it's been hard to catch. I spent
>> some time fiddling around getting netconsole setup, but then I ran out
>> of time.
Theodore> Unless you have your partition mounted with the "sync" mount
Theodore> option (which has negative performance implifications; it
Theodore> makes sense for a mail queue directory, but not necessarily
Theodore> for a general purpose file server) or you have a directory
Theodore> chattr'ed with the sync flag, probably not...
Theodore> If you want to try it, though, the patch is available here:
Theodore> http://bugzilla.kernel.org/attachment.cgi?id=21436
Ok, then it's probably not something I need to test, since I'm only
mounting stuff noatime.
>> If someone could send me the patch, I'll apply it and see how well
>> 2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
>> Reproducing the problem was pretty easy for me.
Theodore> Anything on the console? Any oops messages, or soft lockup warnings?
Nothing. I've not had the time lately to reboot the system to try
2.6.29 or newer with all the lockup debugging stuff yet. Maybe
tonight I'll get a chance.
Theodore> What filesystem(s) are you using?
ext3 for everything, except one staging area running ext4 which is
only used for bacula to stage data before writing to tape. It's solid
under 2.6.29.3 (dammit, I must have mis-remembered) and it's been up
now for six days running backups and serving NFS files.
Here's my filesystems:
> mount
/dev/sda2 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
/udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sda5 on /var type ext3 (rw,noatime)
/dev/sda1 on /boot type ext3 (rw,noatime)
/dev/sda6 on /usr type ext3 (rw,noatime)
/dev/dm-1 on /home type ext3 (rw,noatime)
/dev/dm-2 on /local type ext3 (rw,noatime)
overflow on /tmp type tmpfs (rw,size=1048576,mode=1777,size=50%)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw,noexec,nosuid,nodev)
/dev/mapper/onetwenty-staging on /staging type ext4 (rw,noatime)
When the system locks up, there's nothing in the logs, nothing on the
screen, even when I leave it turned to VT1 (Ctl-Alt-F1) and then wait
for a lockup, the screen is completely blank.
I'll see about finding some more time to beat on this and get better
results back to people.
John
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-20 16:53 ` John Stoffel
0 siblings, 0 replies; 142+ messages in thread
From: John Stoffel @ 2009-05-20 16:53 UTC (permalink / raw)
To: Theodore Tso
Cc: John Stoffel, David Watson, Al Viro, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
>>>>> "Theodore" == Theodore Tso <tytso-3s7WtUTddSA@public.gmane.org> writes:
Oops. It looks like 2.6.29.3 is actually quite solid. My fault, I
must have gotten confused. I know that 2.6.30-rc* was unstable on
there and locked up easily.
Theodore> On Tue, May 19, 2009 at 02:27:14PM -0400, John Stoffel wrote:
>> I wonder if this is the reason my main file server has been locking up
>> solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
>> Since it's my main file server at home, and with my home dir NFS
>> mounted from it onto another system, it's been hard to catch. I spent
>> some time fiddling around getting netconsole setup, but then I ran out
>> of time.
Theodore> Unless you have your partition mounted with the "sync" mount
Theodore> option (which has negative performance implifications; it
Theodore> makes sense for a mail queue directory, but not necessarily
Theodore> for a general purpose file server) or you have a directory
Theodore> chattr'ed with the sync flag, probably not...
Theodore> If you want to try it, though, the patch is available here:
Theodore> http://bugzilla.kernel.org/attachment.cgi?id=21436
Ok, then it's probably not something I need to test, since I'm only
mounting stuff noatime.
>> If someone could send me the patch, I'll apply it and see how well
>> 2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
>> Reproducing the problem was pretty easy for me.
Theodore> Anything on the console? Any oops messages, or soft lockup warnings?
Nothing. I've not had the time lately to reboot the system to try
2.6.29 or newer with all the lockup debugging stuff yet. Maybe
tonight I'll get a chance.
Theodore> What filesystem(s) are you using?
ext3 for everything, except one staging area running ext4 which is
only used for bacula to stage data before writing to tape. It's solid
under 2.6.29.3 (dammit, I must have mis-remembered) and it's been up
now for six days running backups and serving NFS files.
Here's my filesystems:
> mount
/dev/sda2 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
/udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sda5 on /var type ext3 (rw,noatime)
/dev/sda1 on /boot type ext3 (rw,noatime)
/dev/sda6 on /usr type ext3 (rw,noatime)
/dev/dm-1 on /home type ext3 (rw,noatime)
/dev/dm-2 on /local type ext3 (rw,noatime)
overflow on /tmp type tmpfs (rw,size=1048576,mode=1777,size=50%)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw,noexec,nosuid,nodev)
/dev/mapper/onetwenty-staging on /staging type ext4 (rw,noatime)
When the system locks up, there's nothing in the logs, nothing on the
screen, even when I leave it turned to VT1 (Ctl-Alt-F1) and then wait
for a lockup, the screen is completely blank.
I'll see about finding some more time to beat on this and get better
results back to people.
John
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13271] ath9k stop working since 2.6.29
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
-1 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, lyman
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13271
Subject : ath9k stop working since 2.6.29
Submitter : lyman <lymanrb@gmail.com>
Date : 2009-05-10 01:58 (7 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13271] ath9k stop working since 2.6.29
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, lyman
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13271
Subject : ath9k stop working since 2.6.29
Submitter : lyman <lymanrb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-05-10 01:58 (7 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29
2009-05-16 19:58 ` Rafael J. Wysocki
` (27 preceding siblings ...)
(?)
@ 2009-05-17 7:56 ` Maciej Rutecki
-1 siblings, 0 replies; 142+ messages in thread
From: Maciej Rutecki @ 2009-05-17 7:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI,
Andrew Morton, Kernel Testers List, Linus Torvalds,
Linux PM List
2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> Subject : Problem with using bluetooth adaper connected to usb port
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2009-01-13 18:34 (124 days old)
> References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By : Marcel Holtmann <marcel@holtmann.org>
2.6.30-rc6 works fine. Please remove it.
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29
2009-05-16 19:58 ` Rafael J. Wysocki
@ 2009-05-17 7:56 ` Maciej Rutecki
-1 siblings, 0 replies; 142+ messages in thread
From: Maciej Rutecki @ 2009-05-17 7:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Andrew Morton, Linus Torvalds,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> Subject : Problem with using bluetooth adaper connected to usb port
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2009-01-13 18:34 (124 days old)
> References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By : Marcel Holtmann <marcel@holtmann.org>
2.6.30-rc6 works fine. Please remove it.
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29
@ 2009-05-17 7:56 ` Maciej Rutecki
0 siblings, 0 replies; 142+ messages in thread
From: Maciej Rutecki @ 2009-05-17 7:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Andrew Morton, Linus Torvalds,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> Subject : Problem with using bluetooth adaper connected to usb port
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2009-01-13 18:34 (124 days old)
> References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By : Marcel Holtmann <marcel@holtmann.org>
2.6.30-rc6 works fine. Please remove it.
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 142+ messages in thread
* 2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29
@ 2009-06-07 10:02 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
0 siblings, 1 reply; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-06-07 10:02 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.28 and
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 introduced between 2.6.28
and 2.6.29, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-06-07 169 27 25
2009-05-31 167 27 26
2009-05-25 165 27 25
2009-05-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13463
Subject : Poor SSD performance
Submitter : Jake <ellowitz@uchicago.edu>
Date : 2009-06-05 17:37 (3 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13411
Subject : Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
Submitter : Guido <bugzilla.kernel.org@starbase12.cjb.net>
Date : 2009-05-31 12:21 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject : Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter : Alex Samad <alex@samad.com.au>
Date : 2009-05-20 0:37 (19 days old)
References : http://marc.info/?l=linux-kernel&m=124278675503699&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject : s2disk hangs with e100, kernel 2.6.29 and later
Submitter : Richard Atterer <richard@2009.atterer.net>
Date : 2009-05-16 22:51 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=Unknown
References : http://marc.info/?l=linux-kernel&m=124251446428166&w=4
http://lkml.org/lkml/2009/5/25/253
Handled-By : Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>
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 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject : i915: drm: xorg leaks drm objects massively
Submitter : Sergei Trofimovich <slyich@gmail.com>
Date : 2009-05-10 19:56 (29 days old)
References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric@belbone.be>
Date : 2009-05-08 08:48 (31 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2009-05-02 21:41 (37 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap@knobisoft.de>
Date : 2009-04-24 12:45 (45 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
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 (47 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights@fastmail.fm>
Date : 2009-04-21 17:03 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-04-06 23:52 (63 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias@archlinux-br.org>
Date : 2009-04-12 14:10 (57 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date : 2009-04-12 07:00 (57 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date : 2009-04-06 19:47 (63 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark@hell.ne.jp>
Date : 2009-04-06 19:12 (63 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject : ATA bus errors on resume
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-03-25 5:19 (75 days old)
References : http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By : Tejun Heo <htejun@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd@gmail.com>
Date : 2009-04-03 09:30 (66 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus@better.se>
Date : 2009-03-31 08:58 (69 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666@gmail.com>
Date : 2009-03-29 18:02 (71 days old)
Handled-By : Matt Carlson <mcarlson@broadcom.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat@zip.com.au>
Date : 2009-03-16 10:25 (84 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann@secunet.com>
Date : 2009-03-20 07:13 (80 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213@schottelius.org>
Date : 2009-02-13 9:33 (115 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric@anholt.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj@bk.ru>
Date : 2009-02-09 13:01 (119 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
Date : 2009-02-21 15:38 (107 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://patchwork.kernel.org/patch/20197/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (147 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me@bobcopeland.com>
Patch : http://patchwork.kernel.org/patch/28210/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-06-07 10:02 2.6.30-rc8-git4: " Rafael J. Wysocki
@ 2009-06-07 10:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson, Jan Kara
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (36 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 10:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson, Jan Kara
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date : 2009-05-03 19:46 (36 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-06-07 10:06 ` Rafael J. Wysocki
@ 2009-06-07 17:14 ` Theodore Tso
-1 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-06-07 17:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Watson,
Jan Kara, bugzilla-daemon
On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject : ext3/4 with synchronous writes gets wedged by Postfix
> Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> Date : 2009-05-03 19:46 (36 days old)
Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
wedged by Postfix". I pinged Al previously about pushing this as a
regression fix for 2.6.30, but never got a response. At this point we
might as well wait for it to go into the 2.6.31 merge window, and then
we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 17:14 ` Theodore Tso
0 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-06-07 17:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Watson,
Jan Kara, bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject : ext3/4 with synchronous writes gets wedged by Postfix
> Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> Date : 2009-05-03 19:46 (36 days old)
Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
wedged by Postfix". I pinged Al previously about pushing this as a
regression fix for 2.6.30, but never got a response. At this point we
might as well wait for it to go into the 2.6.31 merge window, and then
we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 17:17 ` Al Viro
0 siblings, 0 replies; 142+ messages in thread
From: Al Viro @ 2009-06-07 17:17 UTC (permalink / raw)
To: Theodore Tso, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, David Watson, Jan Kara, bugzilla-daemon
On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > Date : 2009-05-03 19:46 (36 days old)
>
> Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> wedged by Postfix". I pinged Al previously about pushing this as a
> regression fix for 2.6.30, but never got a response. At this point we
> might as well wait for it to go into the 2.6.31 merge window, and then
> we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
It's in mainline now, actually. But yes, we need it in -stable as well.
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 17:17 ` Al Viro
0 siblings, 0 replies; 142+ messages in thread
From: Al Viro @ 2009-06-07 17:17 UTC (permalink / raw)
To: Theodore Tso, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, David
On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > Date : 2009-05-03 19:46 (36 days old)
>
> Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> wedged by Postfix". I pinged Al previously about pushing this as a
> regression fix for 2.6.30, but never got a response. At this point we
> might as well wait for it to go into the 2.6.31 merge window, and then
> we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
It's in mainline now, actually. But yes, we need it in -stable as well.
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 20:10 ` Theodore Tso
0 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-06-07 20:10 UTC (permalink / raw)
To: Al Viro
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, David Watson, Jan Kara, bugzilla-daemon
On Sun, Jun 07, 2009 at 06:17:39PM +0100, Al Viro wrote:
> On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> > On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.28 and 2.6.29.
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > > Date : 2009-05-03 19:46 (36 days old)
> >
> > Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> > tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> > wedged by Postfix". I pinged Al previously about pushing this as a
> > regression fix for 2.6.30, but never got a response. At this point we
> > might as well wait for it to go into the 2.6.31 merge window, and then
> > we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
>
> It's in mainline now, actually. But yes, we need it in -stable as well.
Great, thanks; sorry, I didn't realize it had been queued for mainline
submisison, and it wasn't there when I looked last week. I've closed
the bugzilla entry since it is now in mainline. Would you like to
send the patch to stable@kernel.org, or shall I?
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 20:10 ` Theodore Tso
0 siblings, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-06-07 20:10 UTC (permalink / raw)
To: Al Viro
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, David Watson, Jan Kara,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
On Sun, Jun 07, 2009 at 06:17:39PM +0100, Al Viro wrote:
> On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> > On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.28 and 2.6.29.
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > > Date : 2009-05-03 19:46 (36 days old)
> >
> > Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> > tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> > wedged by Postfix". I pinged Al previously about pushing this as a
> > regression fix for 2.6.30, but never got a response. At this point we
> > might as well wait for it to go into the 2.6.31 merge window, and then
> > we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
>
> It's in mainline now, actually. But yes, we need it in -stable as well.
Great, thanks; sorry, I didn't realize it had been queued for mainline
submisison, and it wasn't there when I looked last week. I've closed
the bugzilla entry since it is now in mainline. Would you like to
send the patch to stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, or shall I?
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* 2.6.30-rc7-git4: Reported regressions 2.6.28 -> 2.6.29
@ 2009-05-30 19:50 Rafael J. Wysocki
2009-05-30 19:55 ` Rafael J. Wysocki
0 siblings, 1 reply; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-30 19:50 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.28 and
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 introduced between 2.6.28
and 2.6.29, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-05-31 167 27 26
2009-05-25 165 27 25
2009-05-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject : Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter : Alex Samad <alex@samad.com.au>
Date : 2009-05-20 0:37 (11 days old)
References : http://marc.info/?l=linux-kernel&m=124278675503699&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject : s2disk hangs with kernel 2.6.29 and later, SATA, Gigabyte EG45M-DS2H
Submitter : Richard Atterer <richard@2009.atterer.net>
Date : 2009-05-16 22:51 (15 days old)
References : http://marc.info/?l=linux-kernel&m=124251446428166&w=4
http://lkml.org/lkml/2009/5/25/253
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 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject : i915: drm: xorg leaks drm objects massively
Submitter : Sergei Trofimovich <slyich@gmail.com>
Date : 2009-05-10 19:56 (21 days old)
References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric@belbone.be>
Date : 2009-05-08 08:48 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2009-05-02 21:41 (29 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap@knobisoft.de>
Date : 2009-04-24 12:45 (37 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject : initrd fails to find /dev/sda* (sata_nv)
Submitter : Benny Halevy <bhalevy@panasas.com>
Date : 2009-04-21 7:03 (40 days old)
References : http://marc.info/?l=linux-kernel&m=124029746431777&w=4
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 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights@fastmail.fm>
Date : 2009-04-21 17:03 (40 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-04-06 23:52 (55 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias@archlinux-br.org>
Date : 2009-04-12 14:10 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date : 2009-04-12 07:00 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date : 2009-04-06 19:47 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark@hell.ne.jp>
Date : 2009-04-06 19:12 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject : ATA bus errors on resume
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-03-25 5:19 (67 days old)
References : http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By : Tejun Heo <htejun@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd@gmail.com>
Date : 2009-04-03 09:30 (58 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus@better.se>
Date : 2009-03-31 08:58 (61 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666@gmail.com>
Date : 2009-03-29 18:02 (63 days old)
Handled-By : Matt Carlson <mcarlson@broadcom.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph@xs4all.nl>
Date : 2009-03-26 16:14 (66 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat@zip.com.au>
Date : 2009-03-16 10:25 (76 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann@secunet.com>
Date : 2009-03-20 07:13 (72 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213@schottelius.org>
Date : 2009-02-13 9:33 (107 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric@anholt.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj@bk.ru>
Date : 2009-02-09 13:01 (111 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (139 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me@bobcopeland.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
Date : 2009-02-21 15:38 (99 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://patchwork.kernel.org/patch/20197/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-30 19:50 2.6.30-rc7-git4: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
@ 2009-05-30 19:55 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-30 19:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson, Jan Kara
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (28 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-30 19:55 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-30 19:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson, Jan Kara
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date : 2009-05-03 19:46 (28 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* 2.6.30-rc7: Reported regressions 2.6.28 -> 2.6.29
@ 2009-05-24 19:27 Rafael J. Wysocki
2009-05-24 19:31 ` Rafael J. Wysocki
0 siblings, 1 reply; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-24 19:27 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.28 and
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 introduced between 2.6.28
and 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-25 165 27 25
2009-05-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject : Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter : Alex Samad <alex@samad.com.au>
Date : 2009-05-20 0:37 (5 days old)
References : http://marc.info/?l=linux-kernel&m=124278675503699&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject : s2disk hangs with kernel 2.6.29 and later, SATA, Gigabyte EG45M-DS2H
Submitter : Richard Atterer <richard@2009.atterer.net>
Date : 2009-05-16 22:51 (9 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=295f00042aaf6b553b5f37348f89bab463d4a469
References : http://marc.info/?l=linux-kernel&m=124251446428166&w=4
Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject : i915: drm: xorg leaks drm objects massively
Submitter : Sergei Trofimovich <slyich@gmail.com>
Date : 2009-05-10 19:56 (15 days old)
References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13271
Subject : ath9k stop working since 2.6.29
Submitter : lyman <lymanrb@gmail.com>
Date : 2009-05-10 01:58 (15 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric@belbone.be>
Date : 2009-05-08 08:48 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2009-05-02 21:41 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13183
Subject : forcedeth: no link during initialization
Submitter : Harald Dunkel <harald.dunkel@t-online.de>
Date : 2009-04-23 13:02 (32 days old)
References : http://marc.info/?l=linux-kernel&m=124049180309233&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap@knobisoft.de>
Date : 2009-04-24 12:45 (31 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject : sata_nv incompatible with async scsi scan
Submitter : Benny Halevy <bhalevy@panasas.com>
Date : 2009-04-21 7:03 (34 days old)
References : http://marc.info/?l=linux-kernel&m=124029746431777&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights@fastmail.fm>
Date : 2009-04-21 17:03 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-04-06 23:52 (49 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias@archlinux-br.org>
Date : 2009-04-12 14:10 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date : 2009-04-12 07:00 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date : 2009-04-06 19:47 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark@hell.ne.jp>
Date : 2009-04-06 19:12 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd@gmail.com>
Date : 2009-04-03 09:30 (52 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus@better.se>
Date : 2009-03-31 08:58 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666@gmail.com>
Date : 2009-03-29 18:02 (57 days old)
Handled-By : Matt Carlson <mcarlson@broadcom.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph@xs4all.nl>
Date : 2009-03-26 16:14 (60 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat@zip.com.au>
Date : 2009-03-16 10:25 (70 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann@secunet.com>
Date : 2009-03-20 07:13 (66 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213@schottelius.org>
Date : 2009-02-13 9:33 (101 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric@anholt.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj@bk.ru>
Date : 2009-02-09 13:01 (105 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (133 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me@bobcopeland.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
Subject : cpufreq timer teardown problem
Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date : 2009-04-23 14:00 (32 days old)
References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Patch : http://patchwork.kernel.org/patch/19754/
http://patchwork.kernel.org/patch/19753/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
Date : 2009-02-21 15:38 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://patchwork.kernel.org/patch/20197/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-24 19:27 2.6.30-rc7: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
@ 2009-05-24 19:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-24 19:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson, Jan Kara
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (22 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-24 19:31 ` Rafael J. Wysocki
0 siblings, 0 replies; 142+ messages in thread
From: Rafael J. Wysocki @ 2009-05-24 19:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson, Jan Kara
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 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=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date : 2009-05-03 19:46 (22 days old)
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-05 21:58 bugzilla-daemon
2009-05-05 23:16 ` [Bug 13232] " bugzilla-daemon
` (15 more replies)
0 siblings, 16 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-05 21:58 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Summary: ext3/4 with synchronous writes gets wedged by Postfix
Product: File System
Version: 2.5
Kernel Version: 2.6.29.2
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext3
AssignedTo: fs_ext3@kernel-bugs.osdl.org
ReportedBy: kernel-nospam@dbwatson.ukfsn.org
Regression: Yes
Latest working kernel version: 2.6.28.9
Earliest failing kernel version: 2.6.29
Distribution: Ubuntu 8.04 LTS
Hardware Environment: Intel 875p chipset (ICH5), P4 with HT
Software Environment: Postfix 2.5.1-2ubuntu1.2
Problem Description:
With its queue directory on an ext3 or journalled ext4 file
system, mounted with the 'sync' option (or with the 'S' attribute
on the individual queue directories, which is a config option for
the Ubuntu package), sending more than a few messages in quick
succession through Postfix causes Postfix and any other process
attempting to modify the file system afterwards (e.g. by updating
the atime when listing a directory) to hang in uninterruptible
sleep. sync(1) will also hang afterwards. If the FS is mounted
noatime, it is still possible to read from it, although trying to
list the affected queue directories still causes ls to hang (the
list of affected directories seems to vary, but may include at
least "active" and "maildrop").
This happens whether the filesystem is on a hard disk or a RAM
disk (/dev/ramX, not tmpfs). Enabling or disabling barriers, or
changing the journalling mode doesn't help.
Ext2 seems to be unaffected, as does non-journalled ext4. XFS,
Reiser and JFS are also fine. The hang doesn't occur if the
queue directories have the 'D' attribute (and a non-sync mount)
instead of 'S'.
Nothing appears in dmesg at the time of the hang, but here's the
output from SysRq-W afterwards (ext3 FS, kernel 2.6.29.2,
non-SMP, PREEMPT_NONE):
SysRq : Show Blocked State
task PC stack pid father
kjournald D c01384df 0 2525 2
cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
[<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c0122a25>] ? del_timer+0x50/0x59
[<c01c0c75>] kjournald+0xad/0x1bb
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c01c0bc8>] ? kjournald+0x0/0x1bb
[<c012b442>] kthread+0x37/0x59
[<c012b40b>] ? kthread+0x0/0x59
[<c0103667>] kernel_thread_helper+0x7/0x10
pickup D c01384df 0 2597 2594
cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c012b8b7>] ? prepare_to_wait+0x42/0x4a
[<c01c0539>] log_wait_commit+0x90/0xf7
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c01bba9d>] journal_stop+0x1c8/0x288
[<c01b4236>] __ext3_journal_stop+0x1c/0x38
[<c01aeb96>] ext3_delete_inode+0x90/0xc2
[<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
[<c017ab82>] generic_delete_inode+0x72/0x100
[<c02c4ee1>] ? _spin_lock+0x3a/0x40
[<c017ad4c>] generic_drop_inode+0x13c/0x1da
[<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
[<c017a4e7>] iput+0x47/0x4e
[<c0173db0>] do_unlinkat+0xc1/0x137
[<c0102f87>] ? sysenter_exit+0xf/0x18
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c0173e36>] sys_unlink+0x10/0x12
[<c0102f55>] sysenter_do_call+0x12/0x35
qmgr D c01384df 0 2598 2594
cfe23e60 00000082 df9fa200 c01384df cfe23e48 c02cb5c0 cfe23e78 de32cf00
cfe23e60 c012b8b7 00000002 de324800 0000014f cfe23e78 cfe23e98 c01c0539
00000000 de3248c8 de324910 de324814 00000000 df9fa200 c012b6ee cfaa9e80
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c012b8b7>] ? prepare_to_wait+0x42/0x4a
[<c01c0539>] log_wait_commit+0x90/0xf7
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c01bba9d>] journal_stop+0x1c8/0x288
[<c01ac11e>] ? ext3_mark_iloc_dirty+0x1d8/0x34b
[<c01b4236>] __ext3_journal_stop+0x1c/0x38
[<c01b309d>] ext3_unlink+0x70/0x157
[<c0172344>] ? vfs_unlink+0x45/0xb0
[<c0172358>] vfs_unlink+0x59/0xb0
[<c0173e17>] do_unlinkat+0x128/0x137
[<c0102f87>] ? sysenter_exit+0xf/0x18
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c0173e36>] sys_unlink+0x10/0x12
[<c0102f55>] sysenter_do_call+0x12/0x35
local D c01384df 0 2654 2594
de369c74 00000096 df9f8880 c01384df de369c5c 00000286 00000000 de183b80
de324814 de324800 de324814 dd037e80 de324800 de324880 de369cc4 c01bc306
c0138489 00000246 00000046 00000001 de324a0c de324814 de324814 df59c060
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c01bc306>] start_this_handle+0x1c2/0x361
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c01bc54a>] journal_start+0xa5/0x100
[<c01b43ac>] ext3_journal_start_sb+0x48/0x4d
[<c01aec4c>] ext3_write_begin+0x84/0x1c6
[<c0139fe2>] ? __lock_acquire+0x32b/0xa21
[<c014749e>] generic_file_buffered_write+0xe1/0x292
[<c0147a94>] __generic_file_aio_write_nolock+0x25c/0x4ab
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c0147f63>] generic_file_aio_write+0x66/0xda
[<c0138f6b>] ? validate_chain+0x3f5/0x1141
[<c01aad03>] ext3_file_write+0x27/0xa8
[<c016a972>] do_sync_write+0xcc/0x102
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c016b16d>] vfs_write+0x8b/0x11f
[<c0102f87>] ? sysenter_exit+0xf/0x18
[<c016a8a6>] ? do_sync_write+0x0/0x102
[<c016b577>] sys_write+0x3d/0x64
[<c0102f55>] sysenter_do_call+0x12/0x35
postdrop D c01384df 0 2664 2663
cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
[<c012b726>] ? wake_bit_function+0x0/0x47
[<c017a5b5>] find_inode_fast+0x3f/0x4a
[<c017ba05>] insert_inode_locked+0x50/0xeb
[<c01ab90b>] ext3_new_inode+0x738/0x88f
[<c01bc550>] ? journal_start+0xab/0x100
[<c01b259a>] ext3_create+0x59/0xbf
[<c01722c4>] vfs_create+0x75/0xb0
[<c02c4dda>] ? _spin_unlock+0x1d/0x20
[<c01b2541>] ? ext3_create+0x0/0xbf
[<c0174bc3>] do_filp_open+0x644/0x713
[<c02c4dda>] ? _spin_unlock+0x1d/0x20
[<c01692ce>] do_sys_open+0x45/0xce
[<c0102f87>] ? sysenter_exit+0xf/0x18
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c01693a3>] sys_open+0x23/0x2b
[<c0102f55>] sysenter_do_call+0x12/0x35
Sched Debug Version: v0.08, 2.6.29.2-test #1
now at 166155.025991 msecs
.sysctl_sched_latency : 20.000000
.sysctl_sched_min_granularity : 4.000000
.sysctl_sched_wakeup_granularity : 5.000000
.sysctl_sched_child_runs_first : 0.000001
.sysctl_sched_features : 24191
cpu#0, 2798.181 MHz
.nr_running : 2
.load : 2048
.nr_switches : 284843
.nr_load_updates : 6497
.nr_uninterruptible : 5
.jiffies : 4294953911
.next_balance : 0.000000
.curr->pid : 2466
.clock : 166154.370058
.cpu_load[0] : 0
.cpu_load[1] : 4
.cpu_load[2] : 76
.cpu_load[3] : 160
.cpu_load[4] : 196
cfs_rq[0]:
.exec_clock : 0.000000
.MIN_vruntime : 24407.116340
.min_vruntime : 24407.114218
.max_vruntime : 24407.116340
.spread : 0.000000
.spread0 : 0.000000
.nr_running : 2
.load : 2048
.nr_spread_over : 0
rt_rq[0]:
.rt_nr_running : 0
.rt_throttled : 0
.rt_time : 0.000000
.rt_runtime : 950.000000
runnable tasks:
task PID tree-key switches prio exec-runtime
sum-exec sum-sleep
----------------------------------------------------------------------------------------------------------
Xorg 2163 24407.116340 28791 120 0
0 0.000000 0.000000 0.000000
R bash 2466 24387.418829 274 120 0
0 0.000000 0.000000 0.000000
Steps to reproduce:
# mount -o remount,sync /var
(or wherever queue_directory points to in the Postfix config)
# while true; do sendmail testaddr@localhost </dev/null; done
--- Comment #1 from Andrew Morton <akpm@linux-foundation.org> 2009-05-05 21:58:17 ---
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sun, 3 May 2009 19:48:21 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13232
>
> Summary: ext3/4 with synchronous writes gets wedged by Postfix
> Product: File System
> Version: 2.5
> Kernel Version: 2.6.29.2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: ext3
> AssignedTo: fs_ext3@kernel-bugs.osdl.org
> ReportedBy: kernel-nospam@dbwatson.ukfsn.org
> Regression: Yes
>
>
> Latest working kernel version: 2.6.28.9
> Earliest failing kernel version: 2.6.29
A very very bad regression.
> Distribution: Ubuntu 8.04 LTS
> Hardware Environment: Intel 875p chipset (ICH5), P4 with HT
> Software Environment: Postfix 2.5.1-2ubuntu1.2
>
> Problem Description:
>
> With its queue directory on an ext3 or journalled ext4 file
> system, mounted with the 'sync' option (or with the 'S' attribute
> on the individual queue directories, which is a config option for
> the Ubuntu package), sending more than a few messages in quick
> succession through Postfix causes Postfix and any other process
> attempting to modify the file system afterwards (e.g. by updating
> the atime when listing a directory) to hang in uninterruptible
> sleep. sync(1) will also hang afterwards. If the FS is mounted
> noatime, it is still possible to read from it, although trying to
> list the affected queue directories still causes ls to hang (the
> list of affected directories seems to vary, but may include at
> least "active" and "maildrop").
>
> This happens whether the filesystem is on a hard disk or a RAM
> disk (/dev/ramX, not tmpfs). Enabling or disabling barriers, or
> changing the journalling mode doesn't help.
>
> Ext2 seems to be unaffected, as does non-journalled ext4. XFS,
> Reiser and JFS are also fine. The hang doesn't occur if the
> queue directories have the 'D' attribute (and a non-sync mount)
> instead of 'S'.
>
> Nothing appears in dmesg at the time of the hang, but here's the
> output from SysRq-W afterwards (ext3 FS, kernel 2.6.29.2,
> non-SMP, PREEMPT_NONE):
>
> SysRq : Show Blocked State
> task PC stack pid father
> kjournald D c01384df 0 2525 2
> cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> 00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c0122a25>] ? del_timer+0x50/0x59
> [<c01c0c75>] kjournald+0xad/0x1bb
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c01c0bc8>] ? kjournald+0x0/0x1bb
> [<c012b442>] kthread+0x37/0x59
> [<c012b40b>] ? kthread+0x0/0x59
> [<c0103667>] kernel_thread_helper+0x7/0x10
I assume this is
while (commit_transaction->t_updates) {
DEFINE_WAIT(wait);
prepare_to_wait(&journal->j_wait_updates, &wait,
TASK_UNINTERRUPTIBLE);
if (commit_transaction->t_updates) {
spin_unlock(&commit_transaction->t_handle_lock);
spin_unlock(&journal->j_state_lock);
schedule();
I'm wondering about
: commit e219cca082f52e7dfea41f3be264b7b5eb204227
: Author: Theodore Ts'o <tytso@mit.edu>
: AuthorDate: Thu Nov 6 22:37:59 2008 -0500
: Commit: Theodore Ts'o <tytso@mit.edu>
: CommitDate: Thu Nov 6 22:37:59 2008 -0500
:
: jbd: don't give up looking for space so easily in __log_wait_for_space
but that patch was present in 2.6.28.
> pickup D c01384df 0 2597 2594
> cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> 00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> [<c01c0539>] log_wait_commit+0x90/0xf7
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c01bba9d>] journal_stop+0x1c8/0x288
> [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> [<c017ab82>] generic_delete_inode+0x72/0x100
> [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> [<c017a4e7>] iput+0x47/0x4e
> [<c0173db0>] do_unlinkat+0xc1/0x137
> [<c0102f87>] ? sysenter_exit+0xf/0x18
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c0173e36>] sys_unlink+0x10/0x12
> [<c0102f55>] sysenter_do_call+0x12/0x35
> qmgr D c01384df 0 2598 2594
> cfe23e60 00000082 df9fa200 c01384df cfe23e48 c02cb5c0 cfe23e78 de32cf00
> cfe23e60 c012b8b7 00000002 de324800 0000014f cfe23e78 cfe23e98 c01c0539
> 00000000 de3248c8 de324910 de324814 00000000 df9fa200 c012b6ee cfaa9e80
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> [<c01c0539>] log_wait_commit+0x90/0xf7
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c01bba9d>] journal_stop+0x1c8/0x288
> [<c01ac11e>] ? ext3_mark_iloc_dirty+0x1d8/0x34b
> [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> [<c01b309d>] ext3_unlink+0x70/0x157
> [<c0172344>] ? vfs_unlink+0x45/0xb0
> [<c0172358>] vfs_unlink+0x59/0xb0
> [<c0173e17>] do_unlinkat+0x128/0x137
> [<c0102f87>] ? sysenter_exit+0xf/0x18
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c0173e36>] sys_unlink+0x10/0x12
> [<c0102f55>] sysenter_do_call+0x12/0x35
> local D c01384df 0 2654 2594
> de369c74 00000096 df9f8880 c01384df de369c5c 00000286 00000000 de183b80
> de324814 de324800 de324814 dd037e80 de324800 de324880 de369cc4 c01bc306
> c0138489 00000246 00000046 00000001 de324a0c de324814 de324814 df59c060
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c01bc306>] start_this_handle+0x1c2/0x361
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c01bc54a>] journal_start+0xa5/0x100
> [<c01b43ac>] ext3_journal_start_sb+0x48/0x4d
> [<c01aec4c>] ext3_write_begin+0x84/0x1c6
> [<c0139fe2>] ? __lock_acquire+0x32b/0xa21
> [<c014749e>] generic_file_buffered_write+0xe1/0x292
> [<c0147a94>] __generic_file_aio_write_nolock+0x25c/0x4ab
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c0147f63>] generic_file_aio_write+0x66/0xda
> [<c0138f6b>] ? validate_chain+0x3f5/0x1141
> [<c01aad03>] ext3_file_write+0x27/0xa8
> [<c016a972>] do_sync_write+0xcc/0x102
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c016b16d>] vfs_write+0x8b/0x11f
> [<c0102f87>] ? sysenter_exit+0xf/0x18
> [<c016a8a6>] ? do_sync_write+0x0/0x102
> [<c016b577>] sys_write+0x3d/0x64
> [<c0102f55>] sysenter_do_call+0x12/0x35
> postdrop D c01384df 0 2664 2663
> cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> [<c012b726>] ? wake_bit_function+0x0/0x47
> [<c017a5b5>] find_inode_fast+0x3f/0x4a
> [<c017ba05>] insert_inode_locked+0x50/0xeb
> [<c01ab90b>] ext3_new_inode+0x738/0x88f
> [<c01bc550>] ? journal_start+0xab/0x100
> [<c01b259a>] ext3_create+0x59/0xbf
> [<c01722c4>] vfs_create+0x75/0xb0
> [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> [<c01b2541>] ? ext3_create+0x0/0xbf
> [<c0174bc3>] do_filp_open+0x644/0x713
> [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> [<c01692ce>] do_sys_open+0x45/0xce
> [<c0102f87>] ? sysenter_exit+0xf/0x18
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c01693a3>] sys_open+0x23/0x2b
> [<c0102f55>] sysenter_do_call+0x12/0x35
> Sched Debug Version: v0.08, 2.6.29.2-test #1
> now at 166155.025991 msecs
> .sysctl_sched_latency : 20.000000
> .sysctl_sched_min_granularity : 4.000000
> .sysctl_sched_wakeup_granularity : 5.000000
> .sysctl_sched_child_runs_first : 0.000001
> .sysctl_sched_features : 24191
>
> cpu#0, 2798.181 MHz
> .nr_running : 2
> .load : 2048
> .nr_switches : 284843
> .nr_load_updates : 6497
> .nr_uninterruptible : 5
> .jiffies : 4294953911
> .next_balance : 0.000000
> .curr->pid : 2466
> .clock : 166154.370058
> .cpu_load[0] : 0
> .cpu_load[1] : 4
> .cpu_load[2] : 76
> .cpu_load[3] : 160
> .cpu_load[4] : 196
>
> cfs_rq[0]:
> .exec_clock : 0.000000
> .MIN_vruntime : 24407.116340
> .min_vruntime : 24407.114218
> .max_vruntime : 24407.116340
> .spread : 0.000000
> .spread0 : 0.000000
> .nr_running : 2
> .load : 2048
> .nr_spread_over : 0
>
> rt_rq[0]:
> .rt_nr_running : 0
> .rt_throttled : 0
> .rt_time : 0.000000
> .rt_runtime : 950.000000
>
> runnable tasks:
> task PID tree-key switches prio exec-runtime
> sum-exec sum-sleep
> ----------------------------------------------------------------------------------------------------------
> Xorg 2163 24407.116340 28791 120 0
> 0 0.000000 0.000000 0.000000
> R bash 2466 24387.418829 274 120 0
> 0 0.000000 0.000000 0.000000
>
>
> Steps to reproduce:
>
> # mount -o remount,sync /var
> (or wherever queue_directory points to in the Postfix config)
>
> # while true; do sendmail testaddr@localhost </dev/null; done
>
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
@ 2009-05-05 23:16 ` bugzilla-daemon
2009-05-12 16:56 ` bugzilla-daemon
` (14 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-05 23:16 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Rafael J. Wysocki <rjw@sisk.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rjw@sisk.pl
Blocks| |12398
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
2009-05-05 23:16 ` [Bug 13232] " bugzilla-daemon
@ 2009-05-12 16:56 ` bugzilla-daemon
2009-05-13 13:48 ` Jan Kara
2009-05-13 13:48 ` bugzilla-daemon
` (13 subsequent siblings)
15 siblings, 1 reply; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-12 16:56 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #2 from Jan Kara <jack@suse.cz> 2009-05-12 16:56:04 ---
Hi,
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> > SysRq : Show Blocked State
> > task PC stack pid father
> > kjournald D c01384df 0 2525 2
> > cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> > de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> > 00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > Call Trace:
> > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> > [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > [<c0122a25>] ? del_timer+0x50/0x59
> > [<c01c0c75>] kjournald+0xad/0x1bb
> > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > [<c01c0bc8>] ? kjournald+0x0/0x1bb
> > [<c012b442>] kthread+0x37/0x59
> > [<c012b40b>] ? kthread+0x0/0x59
> > [<c0103667>] kernel_thread_helper+0x7/0x10
>
> I assume this is
>
> while (commit_transaction->t_updates) {
> DEFINE_WAIT(wait);
>
> prepare_to_wait(&journal->j_wait_updates, &wait,
> TASK_UNINTERRUPTIBLE);
> if (commit_transaction->t_updates) {
> spin_unlock(&commit_transaction->t_handle_lock);
> spin_unlock(&journal->j_state_lock);
> schedule();
Yes.
> I'm wondering about
>
> : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> : Author: Theodore Ts'o <tytso@mit.edu>
> : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> : Commit: Theodore Ts'o <tytso@mit.edu>
> : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> :
> : jbd: don't give up looking for space so easily in __log_wait_for_space
>
> but that patch was present in 2.6.28.
Hmm, I don't see what made this deadlock happening - as far as I can
see it's there for quite some time. See below...
> > pickup D c01384df 0 2597 2594
> > cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> > cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> > 00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > Call Trace:
> > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> > [<c01c0539>] log_wait_commit+0x90/0xf7
> > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > [<c01bba9d>] journal_stop+0x1c8/0x288
> > [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> > [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> > [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> > [<c017ab82>] generic_delete_inode+0x72/0x100
> > [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> > [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> > [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> > [<c017a4e7>] iput+0x47/0x4e
> > [<c0173db0>] do_unlinkat+0xc1/0x137
> > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > [<c0173e36>] sys_unlink+0x10/0x12
> > [<c0102f55>] sysenter_do_call+0x12/0x35
In generic_delete_inode() we mark inode as I_FREEING. Then
ext3_delete_inode() is called and because of O_SYNC it starts a
transaction commit and waits for it.
> > postdrop D c01384df 0 2664 2663
> > cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> > c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> > dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > Call Trace:
> > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> > [<c012b726>] ? wake_bit_function+0x0/0x47
> > [<c017a5b5>] find_inode_fast+0x3f/0x4a
> > [<c017ba05>] insert_inode_locked+0x50/0xeb
> > [<c01ab90b>] ext3_new_inode+0x738/0x88f
> > [<c01bc550>] ? journal_start+0xab/0x100
> > [<c01b259a>] ext3_create+0x59/0xbf
> > [<c01722c4>] vfs_create+0x75/0xb0
> > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > [<c01b2541>] ? ext3_create+0x0/0xbf
> > [<c0174bc3>] do_filp_open+0x644/0x713
> > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > [<c01692ce>] do_sys_open+0x45/0xce
> > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > [<c01693a3>] sys_open+0x23/0x2b
> > [<c0102f55>] sysenter_do_call+0x12/0x35
Here, we have started a transaction in ext3_create() and then wait in
find_inode_fast() for I_FREEING to be cleared (obviously we have
reallocated the inode and squeezed the allocation before journal_stop()
from the delete was called).
Nasty deadlock and I don't see how to fix it now - have to go home for
today... Tomorrow I'll have a look what we can do about it.
Honza
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-12 16:56 ` bugzilla-daemon
@ 2009-05-13 13:48 ` Jan Kara
2009-05-13 16:07 ` Theodore Tso
2009-05-13 16:52 ` Al Viro
0 siblings, 2 replies; 142+ messages in thread
From: Jan Kara @ 2009-05-13 13:48 UTC (permalink / raw)
To: bugzilla-daemon; +Cc: linux-ext4, Al Viro
> http://bugzilla.kernel.org/show_bug.cgi?id=13232
>
> --- Comment #2 from Jan Kara <jack@suse.cz> 2009-05-12 16:56:04 ---
> Hi,
>
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
>
> > > SysRq : Show Blocked State
> > > task PC stack pid father
> > > kjournald D c01384df 0 2525 2
> > > cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> > > de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> > > 00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> > > [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c0122a25>] ? del_timer+0x50/0x59
> > > [<c01c0c75>] kjournald+0xad/0x1bb
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c01c0bc8>] ? kjournald+0x0/0x1bb
> > > [<c012b442>] kthread+0x37/0x59
> > > [<c012b40b>] ? kthread+0x0/0x59
> > > [<c0103667>] kernel_thread_helper+0x7/0x10
> >
> > I assume this is
> >
> > while (commit_transaction->t_updates) {
> > DEFINE_WAIT(wait);
> >
> > prepare_to_wait(&journal->j_wait_updates, &wait,
> > TASK_UNINTERRUPTIBLE);
> > if (commit_transaction->t_updates) {
> > spin_unlock(&commit_transaction->t_handle_lock);
> > spin_unlock(&journal->j_state_lock);
> > schedule();
> Yes.
>
> > I'm wondering about
> >
> > : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> > : Author: Theodore Ts'o <tytso@mit.edu>
> > : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> > : Commit: Theodore Ts'o <tytso@mit.edu>
> > : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> > :
> > : jbd: don't give up looking for space so easily in __log_wait_for_space
> >
> > but that patch was present in 2.6.28.
> Hmm, I don't see what made this deadlock happening - as far as I can
> see it's there for quite some time. See below...
>
> > > pickup D c01384df 0 2597 2594
> > > cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> > > cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> > > 00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> > > [<c01c0539>] log_wait_commit+0x90/0xf7
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c01bba9d>] journal_stop+0x1c8/0x288
> > > [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> > > [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> > > [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> > > [<c017ab82>] generic_delete_inode+0x72/0x100
> > > [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> > > [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> > > [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> > > [<c017a4e7>] iput+0x47/0x4e
> > > [<c0173db0>] do_unlinkat+0xc1/0x137
> > > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c0173e36>] sys_unlink+0x10/0x12
> > > [<c0102f55>] sysenter_do_call+0x12/0x35
> In generic_delete_inode() we mark inode as I_FREEING. Then
> ext3_delete_inode() is called and because of O_SYNC it starts a
> transaction commit and waits for it.
>
> > > postdrop D c01384df 0 2664 2663
> > > cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> > > c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> > > dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> > > [<c012b726>] ? wake_bit_function+0x0/0x47
> > > [<c017a5b5>] find_inode_fast+0x3f/0x4a
> > > [<c017ba05>] insert_inode_locked+0x50/0xeb
> > > [<c01ab90b>] ext3_new_inode+0x738/0x88f
> > > [<c01bc550>] ? journal_start+0xab/0x100
> > > [<c01b259a>] ext3_create+0x59/0xbf
> > > [<c01722c4>] vfs_create+0x75/0xb0
> > > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > > [<c01b2541>] ? ext3_create+0x0/0xbf
> > > [<c0174bc3>] do_filp_open+0x644/0x713
> > > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > > [<c01692ce>] do_sys_open+0x45/0xce
> > > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c01693a3>] sys_open+0x23/0x2b
> > > [<c0102f55>] sysenter_do_call+0x12/0x35
> Here, we have started a transaction in ext3_create() and then wait in
> find_inode_fast() for I_FREEING to be cleared (obviously we have
> reallocated the inode and squeezed the allocation before journal_stop()
> from the delete was called).
> Nasty deadlock and I don't see how to fix it now - have to go home for
> today... Tomorrow I'll have a look what we can do about it.
OK, the deadlock has been introduced by ext3 variant of
261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
is really tough to avoid - we have to first allocate inode on disk so
that we know the inode number. For this we need transaction open but we
cannot afford waiting for old inode with same INO to be freed when we have
transaction open because of the above deadlock. So we'd have to wait for
inode release only after everything is done and we closed the transaction. But
that would mean reordering a lot of code in ext3/namei.c so that all the
dcache handling is done after all the IO is done.
Hmm, maybe we could change the delete side of the deadlock but that's
going to be tricky as well :(.
Al, any idea if we could somehow get away without waiting on
I_FREEING?
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 13:48 ` Jan Kara
@ 2009-05-13 16:07 ` Theodore Tso
2009-05-18 12:45 ` Jan Kara
2009-05-13 16:52 ` Al Viro
1 sibling, 1 reply; 142+ messages in thread
From: Theodore Tso @ 2009-05-13 16:07 UTC (permalink / raw)
To: Jan Kara; +Cc: bugzilla-daemon, linux-ext4, Al Viro
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
What do you mean by this?
I'm puzzled why we haven't hit this before. This looks like
long-standing issue; what unmasked it now?
> The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number.
Well, the simple thing to do is to have a way of quickly determining
that a particular inode number is in the I_FREEING state, and simply
try to avoid using that inode number. If there are no inodes
available, it can simply close the handle (since nothing else has
changed at that point), wait for the current transaction to close, and
then try again. That should fix the problem, I think.
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 16:07 ` Theodore Tso
@ 2009-05-18 12:45 ` Jan Kara
0 siblings, 0 replies; 142+ messages in thread
From: Jan Kara @ 2009-05-18 12:45 UTC (permalink / raw)
To: Theodore Tso; +Cc: bugzilla-daemon, linux-ext4, Al Viro
On Wed 13-05-09 12:07:24, Theodore Tso wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
>
> What do you mean by this?
>
> I'm puzzled why we haven't hit this before. This looks like
> long-standing issue; what unmasked it now?
Unless you mount the fs with 'sync' option, hitting this is much harder
(the window is quite small in nosync case). I think that is the main reason
why we didn't see this earlier.
> > The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number.
>
> Well, the simple thing to do is to have a way of quickly determining
> that a particular inode number is in the I_FREEING state, and simply
> try to avoid using that inode number. If there are no inodes
> available, it can simply close the handle (since nothing else has
> changed at that point), wait for the current transaction to close, and
> then try again. That should fix the problem, I think.
Yes, we could work-around it like that but other filesystems might need
similar things and generally it would be nicer if we could avoid using this
vfs-internal information in the filesystems. Al seems to have found some
other solution without changing filesystems so that would be easier for us...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 13:48 ` Jan Kara
2009-05-13 16:07 ` Theodore Tso
@ 2009-05-13 16:52 ` Al Viro
2009-05-13 18:13 ` Al Viro
2009-05-18 12:53 ` Jan Kara
1 sibling, 2 replies; 142+ messages in thread
From: Al Viro @ 2009-05-13 16:52 UTC (permalink / raw)
To: Jan Kara; +Cc: bugzilla-daemon, linux-ext4
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > Here, we have started a transaction in ext3_create() and then wait in
> > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > reallocated the inode and squeezed the allocation before journal_stop()
> > from the delete was called).
> > Nasty deadlock and I don't see how to fix it now - have to go home for
> > today... Tomorrow I'll have a look what we can do about it.
> OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number. For this we need transaction open but we
> cannot afford waiting for old inode with same INO to be freed when we have
> transaction open because of the above deadlock. So we'd have to wait for
> inode release only after everything is done and we closed the transaction. But
> that would mean reordering a lot of code in ext3/namei.c so that all the
> dcache handling is done after all the IO is done.
> Hmm, maybe we could change the delete side of the deadlock but that's
> going to be tricky as well :(.
> Al, any idea if we could somehow get away without waiting on
> I_FREEING?
At which point do we actually run into deadlock on delete side? We could,
in principle, skip everything like that in insert_inode_locked(), but
I would rather avoid the "two inodes in icache at the same time, with the
same inumber" situations completely. We might get away with that, since
everything else *will* wait, so we can afford a bunch of inodes past the
point in foo_delete_inode() that has cleared it in bitmap + new locked
one, but if it's at all possible to avoid, I'd rather avoid it.
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 16:52 ` Al Viro
@ 2009-05-13 18:13 ` Al Viro
2009-05-18 13:15 ` Theodore Tso
2009-05-18 14:10 ` Jan Kara
2009-05-18 12:53 ` Jan Kara
1 sibling, 2 replies; 142+ messages in thread
From: Al Viro @ 2009-05-13 18:13 UTC (permalink / raw)
To: Jan Kara; +Cc: bugzilla-daemon, linux-ext4, linux-fsdevel
On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> > Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> > Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
>
> At which point do we actually run into deadlock on delete side? We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely. We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
OK, that's probably the easiest way to do that, as much as I don't like it...
Since iget() et.al. will not accept I_FREEING (will wait to go away
and restart), and since we'd better have serialization between new/free
on fs data structures anyway, we can afford simply skipping I_FREEING
et.al. in insert_inode_locked().
We do that from new_inode, so it won't race with free_inode in any interesting
ways and it won't race with iget (of any origin; nfsd or in case of fs
corruption a lookup) since both still will wait for I_LOCK.
Tentative patch follow; folks, I would very much like review on that one,
since I'm far too low on caffeine and the area is nasty.
diff --git a/fs/inode.c b/fs/inode.c
index 9d26490..4406952 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
struct super_block *sb = inode->i_sb;
ino_t ino = inode->i_ino;
struct hlist_head *head = inode_hashtable + hash(sb, ino);
- struct inode *old;
inode->i_state |= I_LOCK|I_NEW;
while (1) {
+ struct hlist_node *node;
+ struct inode *old = NULL;
spin_lock(&inode_lock);
- old = find_inode_fast(sb, head, ino);
- if (likely(!old)) {
+ hlist_for_each_entry(old, node, head, i_hash) {
+ if (old->i_ino != ino)
+ continue;
+ if (old->i_sb != sb)
+ continue;
+ if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+ continue;
+ break;
+ }
+ if (likely(!node)) {
hlist_add_head(&inode->i_hash, head);
spin_unlock(&inode_lock);
return 0;
@@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
{
struct super_block *sb = inode->i_sb;
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
- struct inode *old;
inode->i_state |= I_LOCK|I_NEW;
while (1) {
+ struct hlist_node *node;
+ struct inode *old = NULL;
+
spin_lock(&inode_lock);
- old = find_inode(sb, head, test, data);
- if (likely(!old)) {
+ hlist_for_each_entry(old, node, head, i_hash) {
+ if (old->i_sb != sb)
+ continue;
+ if (!test(old, data))
+ continue;
+ if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+ continue;
+ break;
+ }
+ if (likely(!node)) {
hlist_add_head(&inode->i_hash, head);
spin_unlock(&inode_lock);
return 0;
^ permalink raw reply related [flat|nested] 142+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 18:13 ` Al Viro
@ 2009-05-18 13:15 ` Theodore Tso
2009-05-18 14:10 ` Jan Kara
1 sibling, 0 replies; 142+ messages in thread
From: Theodore Tso @ 2009-05-18 13:15 UTC (permalink / raw)
To: Al Viro; +Cc: Jan Kara, bugzilla-daemon, linux-ext4, linux-fsdevel
On Wed, May 13, 2009 at 07:13:40PM +0100, Al Viro wrote:
>
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
>
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
>
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
Sorry for not having time to review this until now. This looks good
to me.
Reviewed-by: "Theodore Ts'o" <tytso@mit.edu>
So Bug #13232 is currently marked as a 2.6.28 regression; do we feel
confident enough to push this to Linus for 2.6.30?
- Ted
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 18:13 ` Al Viro
2009-05-18 13:15 ` Theodore Tso
@ 2009-05-18 14:10 ` Jan Kara
1 sibling, 0 replies; 142+ messages in thread
From: Jan Kara @ 2009-05-18 14:10 UTC (permalink / raw)
To: Al Viro; +Cc: bugzilla-daemon, linux-ext4, linux-fsdevel
On Wed 13-05-09 19:13:40, Al Viro wrote:
> On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> > On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > > Here, we have started a transaction in ext3_create() and then wait in
> > > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > > reallocated the inode and squeezed the allocation before journal_stop()
> > > > from the delete was called).
> > > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > > today... Tomorrow I'll have a look what we can do about it.
> > > OK, the deadlock has been introduced by ext3 variant of
> > > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > > is really tough to avoid - we have to first allocate inode on disk so
> > > that we know the inode number. For this we need transaction open but we
> > > cannot afford waiting for old inode with same INO to be freed when we have
> > > transaction open because of the above deadlock. So we'd have to wait for
> > > inode release only after everything is done and we closed the transaction. But
> > > that would mean reordering a lot of code in ext3/namei.c so that all the
> > > dcache handling is done after all the IO is done.
> > > Hmm, maybe we could change the delete side of the deadlock but that's
> > > going to be tricky as well :(.
> > > Al, any idea if we could somehow get away without waiting on
> > > I_FREEING?
> >
> > At which point do we actually run into deadlock on delete side? We could,
> > in principle, skip everything like that in insert_inode_locked(), but
> > I would rather avoid the "two inodes in icache at the same time, with the
> > same inumber" situations completely. We might get away with that, since
> > everything else *will* wait, so we can afford a bunch of inodes past the
> > point in foo_delete_inode() that has cleared it in bitmap + new locked
> > one, but if it's at all possible to avoid, I'd rather avoid it.
>
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
>
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
>
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
The patch looks fine. Everyone else will either get new inode and wait
for I_LOCK or get old inode and wait for I_FREEING so everything should be
fine... You can add.
Acked-by: Jan Kara <jack@suse.cz>
Honza
>
> diff --git a/fs/inode.c b/fs/inode.c
> index 9d26490..4406952 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
> struct super_block *sb = inode->i_sb;
> ino_t ino = inode->i_ino;
> struct hlist_head *head = inode_hashtable + hash(sb, ino);
> - struct inode *old;
>
> inode->i_state |= I_LOCK|I_NEW;
> while (1) {
> + struct hlist_node *node;
> + struct inode *old = NULL;
> spin_lock(&inode_lock);
> - old = find_inode_fast(sb, head, ino);
> - if (likely(!old)) {
> + hlist_for_each_entry(old, node, head, i_hash) {
> + if (old->i_ino != ino)
> + continue;
> + if (old->i_sb != sb)
> + continue;
> + if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> + continue;
> + break;
> + }
> + if (likely(!node)) {
> hlist_add_head(&inode->i_hash, head);
> spin_unlock(&inode_lock);
> return 0;
> @@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
> {
> struct super_block *sb = inode->i_sb;
> struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> - struct inode *old;
>
> inode->i_state |= I_LOCK|I_NEW;
>
> while (1) {
> + struct hlist_node *node;
> + struct inode *old = NULL;
> +
> spin_lock(&inode_lock);
> - old = find_inode(sb, head, test, data);
> - if (likely(!old)) {
> + hlist_for_each_entry(old, node, head, i_hash) {
> + if (old->i_sb != sb)
> + continue;
> + if (!test(old, data))
> + continue;
> + if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> + continue;
> + break;
> + }
> + if (likely(!node)) {
> hlist_add_head(&inode->i_hash, head);
> spin_unlock(&inode_lock);
> return 0;
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 142+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 16:52 ` Al Viro
2009-05-13 18:13 ` Al Viro
@ 2009-05-18 12:53 ` Jan Kara
1 sibling, 0 replies; 142+ messages in thread
From: Jan Kara @ 2009-05-18 12:53 UTC (permalink / raw)
To: Al Viro; +Cc: bugzilla-daemon, linux-ext4
On Wed 13-05-09 17:52:54, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> > Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> > Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
>
> At which point do we actually run into deadlock on delete side? We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely. We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
The ordering we see on delete when the filesystem is mounted with 'sync'
option is:
DELETE CREATE
generic_delete_inode()
set I_FREEING
ext3_delete_inode
get transaction handle
do work
get transaction handle
ext3_new_inode()
reallocate inode
insert_inode_locked()
stop transaction, wait for it to commit
(waiting for CREATE process to drop its
transaction reference)
Now similar race can happen even without 'sync' mount option but it's
much harder to hit:
DELETE CREATE
generic_delete_inode()
set I_FREEING
ext3_delete_inode
get transaction handle
ext3_new_inode()
reallocate inode
insert_inode_locked()
try to get transaction handle -
- transaction is too big so we send
current transaction to commit which
again waits for CREATE to drop its
reference.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
2009-05-05 23:16 ` [Bug 13232] " bugzilla-daemon
2009-05-12 16:56 ` bugzilla-daemon
@ 2009-05-13 13:48 ` bugzilla-daemon
2009-05-13 16:07 ` bugzilla-daemon
` (12 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-13 13:48 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #3 from Jan Kara <jack@suse.cz> 2009-05-13 13:48:04 ---
> http://bugzilla.kernel.org/show_bug.cgi?id=13232
>
> --- Comment #2 from Jan Kara <jack@suse.cz> 2009-05-12 16:56:04 ---
> Hi,
>
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
>
> > > SysRq : Show Blocked State
> > > task PC stack pid father
> > > kjournald D c01384df 0 2525 2
> > > cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> > > de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> > > 00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> > > [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c0122a25>] ? del_timer+0x50/0x59
> > > [<c01c0c75>] kjournald+0xad/0x1bb
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c01c0bc8>] ? kjournald+0x0/0x1bb
> > > [<c012b442>] kthread+0x37/0x59
> > > [<c012b40b>] ? kthread+0x0/0x59
> > > [<c0103667>] kernel_thread_helper+0x7/0x10
> >
> > I assume this is
> >
> > while (commit_transaction->t_updates) {
> > DEFINE_WAIT(wait);
> >
> > prepare_to_wait(&journal->j_wait_updates, &wait,
> > TASK_UNINTERRUPTIBLE);
> > if (commit_transaction->t_updates) {
> > spin_unlock(&commit_transaction->t_handle_lock);
> > spin_unlock(&journal->j_state_lock);
> > schedule();
> Yes.
>
> > I'm wondering about
> >
> > : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> > : Author: Theodore Ts'o <tytso@mit.edu>
> > : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> > : Commit: Theodore Ts'o <tytso@mit.edu>
> > : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> > :
> > : jbd: don't give up looking for space so easily in __log_wait_for_space
> >
> > but that patch was present in 2.6.28.
> Hmm, I don't see what made this deadlock happening - as far as I can
> see it's there for quite some time. See below...
>
> > > pickup D c01384df 0 2597 2594
> > > cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> > > cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> > > 00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> > > [<c01c0539>] log_wait_commit+0x90/0xf7
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c01bba9d>] journal_stop+0x1c8/0x288
> > > [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> > > [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> > > [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> > > [<c017ab82>] generic_delete_inode+0x72/0x100
> > > [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> > > [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> > > [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> > > [<c017a4e7>] iput+0x47/0x4e
> > > [<c0173db0>] do_unlinkat+0xc1/0x137
> > > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c0173e36>] sys_unlink+0x10/0x12
> > > [<c0102f55>] sysenter_do_call+0x12/0x35
> In generic_delete_inode() we mark inode as I_FREEING. Then
> ext3_delete_inode() is called and because of O_SYNC it starts a
> transaction commit and waits for it.
>
> > > postdrop D c01384df 0 2664 2663
> > > cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> > > c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> > > dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> > > [<c012b726>] ? wake_bit_function+0x0/0x47
> > > [<c017a5b5>] find_inode_fast+0x3f/0x4a
> > > [<c017ba05>] insert_inode_locked+0x50/0xeb
> > > [<c01ab90b>] ext3_new_inode+0x738/0x88f
> > > [<c01bc550>] ? journal_start+0xab/0x100
> > > [<c01b259a>] ext3_create+0x59/0xbf
> > > [<c01722c4>] vfs_create+0x75/0xb0
> > > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > > [<c01b2541>] ? ext3_create+0x0/0xbf
> > > [<c0174bc3>] do_filp_open+0x644/0x713
> > > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > > [<c01692ce>] do_sys_open+0x45/0xce
> > > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c01693a3>] sys_open+0x23/0x2b
> > > [<c0102f55>] sysenter_do_call+0x12/0x35
> Here, we have started a transaction in ext3_create() and then wait in
> find_inode_fast() for I_FREEING to be cleared (obviously we have
> reallocated the inode and squeezed the allocation before journal_stop()
> from the delete was called).
> Nasty deadlock and I don't see how to fix it now - have to go home for
> today... Tomorrow I'll have a look what we can do about it.
OK, the deadlock has been introduced by ext3 variant of
261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
is really tough to avoid - we have to first allocate inode on disk so
that we know the inode number. For this we need transaction open but we
cannot afford waiting for old inode with same INO to be freed when we have
transaction open because of the above deadlock. So we'd have to wait for
inode release only after everything is done and we closed the transaction. But
that would mean reordering a lot of code in ext3/namei.c so that all the
dcache handling is done after all the IO is done.
Hmm, maybe we could change the delete side of the deadlock but that's
going to be tricky as well :(.
Al, any idea if we could somehow get away without waiting on
I_FREEING?
Honza
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (2 preceding siblings ...)
2009-05-13 13:48 ` bugzilla-daemon
@ 2009-05-13 16:07 ` bugzilla-daemon
2009-05-13 16:18 ` bugzilla-daemon
` (11 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-13 16:07 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #4 from Theodore Tso <tytso@mit.edu> 2009-05-13 16:07:33 ---
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
What do you mean by this?
I'm puzzled why we haven't hit this before. This looks like
long-standing issue; what unmasked it now?
> The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number.
Well, the simple thing to do is to have a way of quickly determining
that a particular inode number is in the I_FREEING state, and simply
try to avoid using that inode number. If there are no inodes
available, it can simply close the handle (since nothing else has
changed at that point), wait for the current transaction to close, and
then try again. That should fix the problem, I think.
- Ted
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (3 preceding siblings ...)
2009-05-13 16:07 ` bugzilla-daemon
@ 2009-05-13 16:18 ` bugzilla-daemon
2009-05-13 16:52 ` bugzilla-daemon
` (10 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-13 16:18 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Vincent Li <mchun.li@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mchun.li@gmail.com
--- Comment #5 from Vincent Li <mchun.li@gmail.com> 2009-05-13 16:18:57 ---
I tried to run Postfix on ubuntu 9.04 server version and followed the reporduce
command, had the same problem.
kernel version: 2.6.30-rc4
Distribution: Ubuntu 9.04
Software Environment: Postfix 2.5.1-2ubuntu1.2
also have following message poping up on control terminal:
[844,700070] INFO: task kjournald: 628 blocked for more than 120 seconds,
[844,700148] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
meassage.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (4 preceding siblings ...)
2009-05-13 16:18 ` bugzilla-daemon
@ 2009-05-13 16:52 ` bugzilla-daemon
2009-05-13 18:13 ` bugzilla-daemon
` (9 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-13 16:52 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2009-05-13 16:52:56 ---
Reply-To: viro@ZenIV.linux.org.uk
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > Here, we have started a transaction in ext3_create() and then wait in
> > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > reallocated the inode and squeezed the allocation before journal_stop()
> > from the delete was called).
> > Nasty deadlock and I don't see how to fix it now - have to go home for
> > today... Tomorrow I'll have a look what we can do about it.
> OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number. For this we need transaction open but we
> cannot afford waiting for old inode with same INO to be freed when we have
> transaction open because of the above deadlock. So we'd have to wait for
> inode release only after everything is done and we closed the transaction. But
> that would mean reordering a lot of code in ext3/namei.c so that all the
> dcache handling is done after all the IO is done.
> Hmm, maybe we could change the delete side of the deadlock but that's
> going to be tricky as well :(.
> Al, any idea if we could somehow get away without waiting on
> I_FREEING?
At which point do we actually run into deadlock on delete side? We could,
in principle, skip everything like that in insert_inode_locked(), but
I would rather avoid the "two inodes in icache at the same time, with the
same inumber" situations completely. We might get away with that, since
everything else *will* wait, so we can afford a bunch of inodes past the
point in foo_delete_inode() that has cleared it in bitmap + new locked
one, but if it's at all possible to avoid, I'd rather avoid it.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (5 preceding siblings ...)
2009-05-13 16:52 ` bugzilla-daemon
@ 2009-05-13 18:13 ` bugzilla-daemon
2009-05-18 12:45 ` bugzilla-daemon
` (8 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-13 18:13 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #7 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2009-05-13 18:13:42 ---
Reply-To: viro@ZenIV.linux.org.uk
On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> > Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> > Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
>
> At which point do we actually run into deadlock on delete side? We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely. We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
OK, that's probably the easiest way to do that, as much as I don't like it...
Since iget() et.al. will not accept I_FREEING (will wait to go away
and restart), and since we'd better have serialization between new/free
on fs data structures anyway, we can afford simply skipping I_FREEING
et.al. in insert_inode_locked().
We do that from new_inode, so it won't race with free_inode in any interesting
ways and it won't race with iget (of any origin; nfsd or in case of fs
corruption a lookup) since both still will wait for I_LOCK.
Tentative patch follow; folks, I would very much like review on that one,
since I'm far too low on caffeine and the area is nasty.
diff --git a/fs/inode.c b/fs/inode.c
index 9d26490..4406952 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
struct super_block *sb = inode->i_sb;
ino_t ino = inode->i_ino;
struct hlist_head *head = inode_hashtable + hash(sb, ino);
- struct inode *old;
inode->i_state |= I_LOCK|I_NEW;
while (1) {
+ struct hlist_node *node;
+ struct inode *old = NULL;
spin_lock(&inode_lock);
- old = find_inode_fast(sb, head, ino);
- if (likely(!old)) {
+ hlist_for_each_entry(old, node, head, i_hash) {
+ if (old->i_ino != ino)
+ continue;
+ if (old->i_sb != sb)
+ continue;
+ if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+ continue;
+ break;
+ }
+ if (likely(!node)) {
hlist_add_head(&inode->i_hash, head);
spin_unlock(&inode_lock);
return 0;
@@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned
long hashval,
{
struct super_block *sb = inode->i_sb;
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
- struct inode *old;
inode->i_state |= I_LOCK|I_NEW;
while (1) {
+ struct hlist_node *node;
+ struct inode *old = NULL;
+
spin_lock(&inode_lock);
- old = find_inode(sb, head, test, data);
- if (likely(!old)) {
+ hlist_for_each_entry(old, node, head, i_hash) {
+ if (old->i_sb != sb)
+ continue;
+ if (!test(old, data))
+ continue;
+ if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+ continue;
+ break;
+ }
+ if (likely(!node)) {
hlist_add_head(&inode->i_hash, head);
spin_unlock(&inode_lock);
return 0;
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply related [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (6 preceding siblings ...)
2009-05-13 18:13 ` bugzilla-daemon
@ 2009-05-18 12:45 ` bugzilla-daemon
2009-05-18 12:54 ` bugzilla-daemon
` (7 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-18 12:45 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #8 from Jan Kara <jack@suse.cz> 2009-05-18 12:45:23 ---
On Wed 13-05-09 12:07:24, Theodore Tso wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
>
> What do you mean by this?
>
> I'm puzzled why we haven't hit this before. This looks like
> long-standing issue; what unmasked it now?
Unless you mount the fs with 'sync' option, hitting this is much harder
(the window is quite small in nosync case). I think that is the main reason
why we didn't see this earlier.
> > The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number.
>
> Well, the simple thing to do is to have a way of quickly determining
> that a particular inode number is in the I_FREEING state, and simply
> try to avoid using that inode number. If there are no inodes
> available, it can simply close the handle (since nothing else has
> changed at that point), wait for the current transaction to close, and
> then try again. That should fix the problem, I think.
Yes, we could work-around it like that but other filesystems might need
similar things and generally it would be nicer if we could avoid using this
vfs-internal information in the filesystems. Al seems to have found some
other solution without changing filesystems so that would be easier for us...
Honza
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (7 preceding siblings ...)
2009-05-18 12:45 ` bugzilla-daemon
@ 2009-05-18 12:54 ` bugzilla-daemon
2009-05-18 13:16 ` bugzilla-daemon
` (6 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-18 12:54 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #9 from Jan Kara <jack@suse.cz> 2009-05-18 12:54:00 ---
On Wed 13-05-09 17:52:54, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> > Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> > Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
>
> At which point do we actually run into deadlock on delete side? We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely. We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
The ordering we see on delete when the filesystem is mounted with 'sync'
option is:
DELETE CREATE
generic_delete_inode()
set I_FREEING
ext3_delete_inode
get transaction handle
do work
get transaction handle
ext3_new_inode()
reallocate inode
insert_inode_locked()
stop transaction, wait for it to commit
(waiting for CREATE process to drop its
transaction reference)
Now similar race can happen even without 'sync' mount option but it's
much harder to hit:
DELETE CREATE
generic_delete_inode()
set I_FREEING
ext3_delete_inode
get transaction handle
ext3_new_inode()
reallocate inode
insert_inode_locked()
try to get transaction handle -
- transaction is too big so we send
current transaction to commit which
again waits for CREATE to drop its
reference.
Honza
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (8 preceding siblings ...)
2009-05-18 12:54 ` bugzilla-daemon
@ 2009-05-18 13:16 ` bugzilla-daemon
2009-05-18 14:10 ` bugzilla-daemon
` (5 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-18 13:16 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #10 from Theodore Tso <tytso@mit.edu> 2009-05-18 13:16:04 ---
On Wed, May 13, 2009 at 07:13:40PM +0100, Al Viro wrote:
>
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
>
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
>
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
Sorry for not having time to review this until now. This looks good
to me.
Reviewed-by: "Theodore Ts'o" <tytso@mit.edu>
So Bug #13232 is currently marked as a 2.6.28 regression; do we feel
confident enough to push this to Linus for 2.6.30?
- Ted
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (9 preceding siblings ...)
2009-05-18 13:16 ` bugzilla-daemon
@ 2009-05-18 14:10 ` bugzilla-daemon
2009-05-19 20:38 ` bugzilla-daemon
` (4 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-18 14:10 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #11 from Jan Kara <jack@suse.cz> 2009-05-18 14:10:15 ---
On Wed 13-05-09 19:13:40, Al Viro wrote:
> On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> > On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > > Here, we have started a transaction in ext3_create() and then wait in
> > > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > > reallocated the inode and squeezed the allocation before journal_stop()
> > > > from the delete was called).
> > > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > > today... Tomorrow I'll have a look what we can do about it.
> > > OK, the deadlock has been introduced by ext3 variant of
> > > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > > is really tough to avoid - we have to first allocate inode on disk so
> > > that we know the inode number. For this we need transaction open but we
> > > cannot afford waiting for old inode with same INO to be freed when we have
> > > transaction open because of the above deadlock. So we'd have to wait for
> > > inode release only after everything is done and we closed the transaction. But
> > > that would mean reordering a lot of code in ext3/namei.c so that all the
> > > dcache handling is done after all the IO is done.
> > > Hmm, maybe we could change the delete side of the deadlock but that's
> > > going to be tricky as well :(.
> > > Al, any idea if we could somehow get away without waiting on
> > > I_FREEING?
> >
> > At which point do we actually run into deadlock on delete side? We could,
> > in principle, skip everything like that in insert_inode_locked(), but
> > I would rather avoid the "two inodes in icache at the same time, with the
> > same inumber" situations completely. We might get away with that, since
> > everything else *will* wait, so we can afford a bunch of inodes past the
> > point in foo_delete_inode() that has cleared it in bitmap + new locked
> > one, but if it's at all possible to avoid, I'd rather avoid it.
>
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
>
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
>
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
The patch looks fine. Everyone else will either get new inode and wait
for I_LOCK or get old inode and wait for I_FREEING so everything should be
fine... You can add.
Acked-by: Jan Kara <jack@suse.cz>
Honza
>
> diff --git a/fs/inode.c b/fs/inode.c
> index 9d26490..4406952 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
> struct super_block *sb = inode->i_sb;
> ino_t ino = inode->i_ino;
> struct hlist_head *head = inode_hashtable + hash(sb, ino);
> - struct inode *old;
>
> inode->i_state |= I_LOCK|I_NEW;
> while (1) {
> + struct hlist_node *node;
> + struct inode *old = NULL;
> spin_lock(&inode_lock);
> - old = find_inode_fast(sb, head, ino);
> - if (likely(!old)) {
> + hlist_for_each_entry(old, node, head, i_hash) {
> + if (old->i_ino != ino)
> + continue;
> + if (old->i_sb != sb)
> + continue;
> + if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> + continue;
> + break;
> + }
> + if (likely(!node)) {
> hlist_add_head(&inode->i_hash, head);
> spin_unlock(&inode_lock);
> return 0;
> @@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
> {
> struct super_block *sb = inode->i_sb;
> struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> - struct inode *old;
>
> inode->i_state |= I_LOCK|I_NEW;
>
> while (1) {
> + struct hlist_node *node;
> + struct inode *old = NULL;
> +
> spin_lock(&inode_lock);
> - old = find_inode(sb, head, test, data);
> - if (likely(!old)) {
> + hlist_for_each_entry(old, node, head, i_hash) {
> + if (old->i_sb != sb)
> + continue;
> + if (!test(old, data))
> + continue;
> + if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> + continue;
> + break;
> + }
> + if (likely(!node)) {
> hlist_add_head(&inode->i_hash, head);
> spin_unlock(&inode_lock);
> return 0;
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (10 preceding siblings ...)
2009-05-18 14:10 ` bugzilla-daemon
@ 2009-05-19 20:38 ` bugzilla-daemon
2009-05-19 20:39 ` bugzilla-daemon
` (3 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-19 20:38 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #12 from Theodore Tso <tytso@mit.edu> 2009-05-19 20:38:32 ---
Created an attachment (id=21436)
--> (http://bugzilla.kernel.org/attachment.cgi?id=21436)
Proposed patch from Al Viro
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (11 preceding siblings ...)
2009-05-19 20:38 ` bugzilla-daemon
@ 2009-05-19 20:39 ` bugzilla-daemon
2009-06-07 19:56 ` bugzilla-daemon
` (2 subsequent siblings)
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-05-19 20:39 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Theodore Tso <tytso@mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #21436|application/octet-stream |text/plain
mime type| |
Attachment #21436|0 |1
is patch| |
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (12 preceding siblings ...)
2009-05-19 20:39 ` bugzilla-daemon
@ 2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 20:44 ` bugzilla-daemon
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-06-07 19:56 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Theodore Tso <tytso@mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tytso@mit.edu
--- Comment #13 from Theodore Tso <tytso@mit.edu> 2009-06-07 19:56:04 ---
This patch is now in the upstream kernel, so it will be in 2.6.30.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (13 preceding siblings ...)
2009-06-07 19:56 ` bugzilla-daemon
@ 2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 20:44 ` bugzilla-daemon
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-06-07 19:56 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Theodore Tso <tytso@mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |CODE_FIX
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
` (14 preceding siblings ...)
2009-06-07 19:56 ` bugzilla-daemon
@ 2009-06-07 20:44 ` bugzilla-daemon
15 siblings, 0 replies; 142+ messages in thread
From: bugzilla-daemon @ 2009-06-07 20:44 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Rafael J. Wysocki <rjw@sisk.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 142+ messages in thread
end of thread, other threads:[~2009-06-07 20:44 UTC | newest]
Thread overview: 142+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-16 19:58 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-05-16 19:58 ` Rafael J. Wysocki
2009-05-16 19:59 ` [Bug #12490] ath5k related kernel panic in 2.6.29-rc1 Rafael J. Wysocki
2009-05-16 20:04 ` [Bug #12499] Problem with using bluetooth adaper connected to usb port Rafael J. Wysocki
2009-05-16 20:04 ` Rafael J. Wysocki
2009-05-17 7:58 ` Maciej Rutecki
2009-05-17 7:58 ` Maciej Rutecki
2009-05-17 10:21 ` Rafael J. Wysocki
2009-05-17 10:21 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12861] Xorg fails to start "Failed to allocate space for kernel memory manager" Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12681] s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled) Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12705] X200: Brightness broken since 2.6.29-rc4-58-g4c098bc Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12765] i915 VT switch with AIGLX causes X lock up Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-18 7:13 ` Sitsofe Wheeler
2009-05-18 7:13 ` Sitsofe Wheeler
2009-05-18 17:10 ` Rafael J. Wysocki
2009-05-18 17:10 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12909] boot/kernel init duration regression from 2.6.28 Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12971] "tg3 transmit timed out" when transmitting at high bitrate Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12899] Crash in i915.ko: i915_driver_irq_handler Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12947] r128: system hangs when X is started with DRI enabled Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-17 16:08 ` Jos van der Ende
2009-05-17 16:08 ` Jos van der Ende
2009-05-16 20:05 ` [Bug #13001] PCI-DMA: Out of IOMMU space Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #13024] nozomi: pppd fails on kernel 2.6.29 Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-16 20:05 ` [Bug #12980] lockup in X.org Rafael J. Wysocki
2009-05-16 20:05 ` Rafael J. Wysocki
2009-05-17 15:39 ` Marcus Better
2009-05-17 15:39 ` Marcus Better
2009-05-17 17:27 ` Rafael J. Wysocki
2009-05-17 17:27 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13074] gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840) Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13072] forcedeth seems to switch off eth on shutdown Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
[not found] ` <1242563611.15249.2.camel@laptop.workgroup>
2009-05-17 12:56 ` Rafael J. Wysocki
2009-05-17 12:56 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13144] resume from suspend fails using video card i915 Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13175] sata_nv incompatible with async scsi scan Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13172] Spontaneous reboots since 2.6.29-rc* Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-17 7:53 ` Maciej Rutecki
2009-05-17 7:53 ` Maciej Rutecki
2009-05-17 10:23 ` Rafael J. Wysocki
2009-05-17 10:23 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13178] Booting very slow Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-18 8:15 ` Martin Knoblauch
2009-05-18 8:15 ` Martin Knoblauch
2009-05-18 17:13 ` Rafael J. Wysocki
2009-05-18 17:13 ` Rafael J. Wysocki
2009-05-19 0:26 ` Kay Sievers
2009-05-19 0:26 ` Kay Sievers
2009-05-19 7:22 ` Martin Knoblauch
2009-05-19 7:22 ` Martin Knoblauch
2009-05-19 8:58 ` Kay Sievers
2009-05-19 8:58 ` Kay Sievers
2009-05-20 10:14 ` Martin Knoblauch
2009-05-20 10:14 ` Martin Knoblauch
2009-05-16 20:06 ` [Bug #13186] cpufreq timer teardown problem Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-17 14:23 ` [PATCH] cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call Mathieu Desnoyers
2009-05-17 14:23 ` Mathieu Desnoyers
2009-05-17 14:29 ` [PATCH] cpufreq fix timer teardown in conservative governor Mathieu Desnoyers
2009-05-17 14:29 ` Mathieu Desnoyers
2009-05-17 14:30 ` [PATCH] cpufreq fix timer teardown in ondemand governor Mathieu Desnoyers
2009-05-17 14:30 ` Mathieu Desnoyers
2009-05-16 20:06 ` [Bug #13225] [2.6.29 regression] Software suspend no longer works Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13183] forcedeth: no link during initialization Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-18 13:25 ` Theodore Tso
2009-05-18 13:25 ` Theodore Tso
2009-05-19 17:17 ` David Watson
2009-05-19 17:17 ` David Watson
2009-05-19 17:53 ` Theodore Tso
2009-05-19 17:53 ` Theodore Tso
2009-05-19 18:27 ` John Stoffel
2009-05-19 20:41 ` Theodore Tso
2009-05-19 20:41 ` Theodore Tso
2009-05-20 16:53 ` John Stoffel
2009-05-20 16:53 ` John Stoffel
2009-05-16 20:06 ` [Bug #13271] ath9k stop working since 2.6.29 Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-17 7:56 ` 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29 Maciej Rutecki
2009-05-17 7:56 ` Maciej Rutecki
2009-05-17 7:56 ` Maciej Rutecki
-- strict thread matches above, loose matches on Subject: below --
2009-06-07 10:02 2.6.30-rc8-git4: " Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 17:14 ` Theodore Tso
2009-06-07 17:14 ` Theodore Tso
2009-06-07 17:17 ` Al Viro
2009-06-07 17:17 ` Al Viro
2009-06-07 20:10 ` Theodore Tso
2009-06-07 20:10 ` Theodore Tso
2009-05-30 19:50 2.6.30-rc7-git4: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-05-30 19:55 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-05-30 19:55 ` Rafael J. Wysocki
2009-05-24 19:27 2.6.30-rc7: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-05-24 19:31 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-05-24 19:31 ` Rafael J. Wysocki
2009-05-05 21:58 [Bug 13232] New: " bugzilla-daemon
2009-05-05 23:16 ` [Bug 13232] " bugzilla-daemon
2009-05-12 16:56 ` bugzilla-daemon
2009-05-13 13:48 ` Jan Kara
2009-05-13 16:07 ` Theodore Tso
2009-05-18 12:45 ` Jan Kara
2009-05-13 16:52 ` Al Viro
2009-05-13 18:13 ` Al Viro
2009-05-18 13:15 ` Theodore Tso
2009-05-18 14:10 ` Jan Kara
2009-05-18 12:53 ` Jan Kara
2009-05-13 13:48 ` bugzilla-daemon
2009-05-13 16:07 ` bugzilla-daemon
2009-05-13 16:18 ` bugzilla-daemon
2009-05-13 16:52 ` bugzilla-daemon
2009-05-13 18:13 ` bugzilla-daemon
2009-05-18 12:45 ` bugzilla-daemon
2009-05-18 12:54 ` bugzilla-daemon
2009-05-18 13:16 ` bugzilla-daemon
2009-05-18 14:10 ` bugzilla-daemon
2009-05-19 20:38 ` bugzilla-daemon
2009-05-19 20:39 ` bugzilla-daemon
2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 20:44 ` bugzilla-daemon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.