* 2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29 @ 2009-06-07 10:02 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:02 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List, Natalie Protasevich, Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List This message contains a list of some regressions introduced between 2.6.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] 151+ messages in thread
* 2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29 @ 2009-06-07 10:02 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ 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] 151+ messages in thread
* [Bug #12490] ath5k related kernel panic in 2.6.29-rc1 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:03 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:03 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-aXfl/3sk2vNUbtYUoyoikg@public.gmane.org> Patch : http://patchwork.kernel.org/patch/28210/ ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12490] ath5k related kernel panic in 2.6.29-rc1 @ 2009-06-07 10:03 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:03 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 (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/ ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12899] Crash in i915.ko: i915_driver_irq_handler 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (80 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12899] Crash in i915.ko: i915_driver_irq_handler @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (80 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12681] s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled) 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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-5URONGGNgjI@public.gmane.org> 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-l3A5Bk7waGM@public.gmane.org> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12681] s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled) @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (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> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12705] X200: Brightness broken since 2.6.29-rc4-58-g4c098bc 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.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-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12705] X200: Brightness broken since 2.6.29-rc4-58-g4c098bc @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (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> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12909] boot/kernel init duration regression from 2.6.28 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org> Date : 2009-03-16 10:25 (84 days old) References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4 ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12909] boot/kernel init duration regression from 2.6.28 @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (84 days old) References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4 ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12765] i915 VT switch with AIGLX causes X lock up 2009-06-07 10:02 ` Rafael J. Wysocki ` (5 preceding siblings ...) (?) @ 2009-06-07 10:06 ` Rafael J. Wysocki 2009-06-28 20:11 ` Sitsofe Wheeler -1 siblings, 1 reply; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (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/ ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up 2009-06-07 10:06 ` [Bug #12765] i915 VT switch with AIGLX causes X lock up Rafael J. Wysocki @ 2009-06-28 20:11 ` Sitsofe Wheeler 0 siblings, 0 replies; 151+ messages in thread From: Sitsofe Wheeler @ 2009-06-28 20:11 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, DRI, Jesse Barnes, Michel Dänzer On Sun, Jun 07, 2009 at 12:06:18PM +0200, Rafael J. Wysocki wrote: > > 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 (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-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org> > Patch : http://patchwork.kernel.org/patch/20197/ Still here on 2.6.31-rc1 but... ...this seems to be tied to the version of the Intel X drivers I have. On another install with more recent Intel X drivers I cannot reproduce this issue. -- Sitsofe | http://sucs.org/~sits/ ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up @ 2009-06-28 20:11 ` Sitsofe Wheeler 0 siblings, 0 replies; 151+ messages in thread From: Sitsofe Wheeler @ 2009-06-28 20:11 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, DRI, Jesse Barnes, Michel Dänzer On Sun, Jun 07, 2009 at 12:06:18PM +0200, Rafael J. Wysocki wrote: > > 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/ Still here on 2.6.31-rc1 but... ...this seems to be tied to the version of the Intel X drivers I have. On another install with more recent Intel X drivers I cannot reproduce this issue. -- Sitsofe | http://sucs.org/~sits/ ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up 2009-06-28 20:11 ` Sitsofe Wheeler (?) @ 2009-07-20 18:11 ` Jesse Barnes -1 siblings, 0 replies; 151+ messages in thread From: Jesse Barnes @ 2009-07-20 18:11 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Dave Airlie, DRI, Michel Dänzer On Sun, 28 Jun 2009 21:11:30 +0100 Sitsofe Wheeler <sitsofe@yahoo.com> wrote: > On Sun, Jun 07, 2009 at 12:06:18PM +0200, Rafael J. Wysocki wrote: > > > > 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/ > > Still here on 2.6.31-rc1 but... > > ...this seems to be tied to the version of the Intel X drivers I have. > On another install with more recent Intel X drivers I cannot reproduce > this issue. I guess we can mark it closed then, though I don't have the commit id of the fix handy... -- Jesse Barnes, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12971] "tg3 transmit timed out" when transmitting at high bitrate 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (71 days old) Handled-By : Matt Carlson <mcarlson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12971] "tg3 transmit timed out" when transmitting at high bitrate @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (71 days old) Handled-By : Matt Carlson <mcarlson@broadcom.com> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13001] PCI-DMA: Out of IOMMU space 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, FUJITA Tomonori, Grant Grundler, optimusgd-Re5JQEeQqe8AvxtiuMwx3w 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-04-03 09:30 (66 days old) References : http://lkml.org/lkml/2009/4/28/133 ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13001] PCI-DMA: Out of IOMMU space @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (66 days old) References : http://lkml.org/lkml/2009/4/28/133 ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12980] lockup in X.org 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (69 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #12980] lockup in X.org @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (69 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13024] nozomi: pppd fails on kernel 2.6.29 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (63 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13024] nozomi: pppd fails on kernel 2.6.29 @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 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 (63 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13017] ATA bus errors on resume 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Niel Lambrechts, Tejun Heo 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=13017 Subject : ATA bus errors on resume Submitter : Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13017] ATA bus errors on resume @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Niel Lambrechts, Tejun Heo 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=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> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13072] forcedeth seems to switch off eth on shutdown 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (57 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13072] forcedeth seems to switch off eth on shutdown @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (57 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13072] forcedeth seems to switch off eth on shutdown 2009-06-07 10:06 ` Rafael J. Wysocki (?) @ 2009-06-07 17:14 ` Robert Hancock [not found] ` <4A2BF577.1050003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> -1 siblings, 1 reply; 151+ messages in thread From: Robert Hancock @ 2009-06-07 17:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Daniel Bierstedt 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=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 (57 days old) Seems like it should be fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9 ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <4A2BF577.1050003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [Bug #13072] forcedeth seems to switch off eth on shutdown 2009-06-07 17:14 ` Robert Hancock @ 2009-06-07 20:50 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 20:50 UTC (permalink / raw) To: Robert Hancock; +Cc: LKML, Kernel Testers List, Daniel Bierstedt On Sunday 07 June 2009, Robert Hancock wrote: > > 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=13072 > > Subject : forcedeth seems to switch off eth on shutdown > > Submitter : Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> > > Date : 2009-04-12 07:00 (57 days old) > > Seems like it should be fixed by: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9 Thanks, I've closed the bug. Rafael ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13072] forcedeth seems to switch off eth on shutdown @ 2009-06-07 20:50 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 20:50 UTC (permalink / raw) To: Robert Hancock; +Cc: LKML, Kernel Testers List, Daniel Bierstedt On Sunday 07 June 2009, Robert Hancock wrote: > > 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=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 (57 days old) > > Seems like it should be fixed by: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9 Thanks, I've closed the bug. Rafael ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13072] forcedeth seems to switch off eth on shutdown 2009-06-07 10:06 ` Rafael J. Wysocki (?) (?) @ 2009-06-07 17:14 ` Robert Hancock -1 siblings, 0 replies; 151+ messages in thread From: Robert Hancock @ 2009-06-07 17:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Daniel Bierstedt 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=13072 > Subject : forcedeth seems to switch off eth on shutdown > Submitter : Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> > Date : 2009-04-12 07:00 (57 days old) Seems like it should be fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9 ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (63 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (63 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13074] gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840) 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (57 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13074] gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840) @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (57 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, fanderay, Heiko Carstens, Len Brown, Lin Ming, Linus Torvalds, Mattia Dongili This message has been generated automatically as a part of a report of 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=13148 Subject : resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present Submitter : fanderay <fanderay4-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> Date : 2009-04-22 14:39 (47 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, fanderay, Heiko Carstens, Len Brown, Lin Ming, Linus Torvalds, Mattia Dongili This message has been generated automatically as a part of a report of 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=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) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13144] resume from suspend fails using video card i915 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (48 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13144] resume from suspend fails using video card i915 @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (48 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-KKrjLPT3xs0@public.gmane.org> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (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> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (31 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (31 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ messages in thread
[parent not found: <20090607171418.GA22756-3s7WtUTddSA@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix 2009-06-07 17:14 ` Theodore Tso @ 2009-06-07 17:17 ` Al Viro -1 siblings, 0 replies; 151+ 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] 151+ 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; 151+ 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] 151+ messages in thread
[parent not found: <20090607171739.GI8633-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix 2009-06-07 17:17 ` Al Viro @ 2009-06-07 20:10 ` Theodore Tso -1 siblings, 0 replies; 151+ 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] 151+ 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; 151+ 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] 151+ messages in thread
* [Bug #13225] [2.6.29 regression] Software suspend no longer works 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (37 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13225] [2.6.29 regression] Software suspend no longer works @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10: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 (37 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13178] Booting very slow 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jesse Barnes, Martin Knoblauch, Stephen Hemminger 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 (45 days old) References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4 ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13178] Booting very slow @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jesse Barnes, Martin Knoblauch, Stephen Hemminger 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 (45 days old) References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4 ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13178] Booting very slow 2009-06-07 10:06 ` Rafael J. Wysocki @ 2009-06-08 8:46 ` Martin Knoblauch -1 siblings, 0 replies; 151+ messages in thread From: Martin Knoblauch @ 2009-06-08 8:46 UTC (permalink / raw) To: Rafael J. Wysocki, Linux Kernel Mailing List Cc: Kernel Testers List, Jesse Barnes, Stephen Hemminger, James Owens ----- 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>; Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>; Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>; Stephen Hemminger <shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org> > Sent: Sunday, June 7, 2009 12:06:22 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 (45 days old) > References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4 No change since last ping. We ruled out a non-HP NIC in the DL380. HP will try to reproduce in-house. Martin ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13178] Booting very slow @ 2009-06-08 8:46 ` Martin Knoblauch 0 siblings, 0 replies; 151+ messages in thread From: Martin Knoblauch @ 2009-06-08 8:46 UTC (permalink / raw) To: Rafael J. Wysocki, Linux Kernel Mailing List Cc: Kernel Testers List, Jesse Barnes, Stephen Hemminger, James Owens ----- 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>; Jesse Barnes <jbarnes@virtuousgeek.org>; Martin Knoblauch <spamtrap@knobisoft.de>; Stephen Hemminger <shemminger@vyatta.com> > Sent: Sunday, June 7, 2009 12:06:22 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 (45 days old) > References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4 No change since last ping. We ruled out a non-HP NIC in the DL380. HP will try to reproduce in-house. Martin ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <712849.19962.qm-VAEUvbQToQWvuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>]
* Re: [Bug #13178] Booting very slow 2009-06-08 8:46 ` Martin Knoblauch @ 2009-06-08 11:12 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-08 11:12 UTC (permalink / raw) To: Martin Knoblauch Cc: Linux Kernel Mailing List, Kernel Testers List, Jesse Barnes, Stephen Hemminger, James Owens On Monday 08 June 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>; Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>; Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>; Stephen Hemminger <shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org> > > Sent: Sunday, June 7, 2009 12:06:22 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 (45 days old) > > References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4 > > No change since last ping. We ruled out a non-HP NIC in the DL380. HP will try to reproduce in-house. Thanks a lot for the update. Best, Rafael ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13178] Booting very slow @ 2009-06-08 11:12 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-08 11:12 UTC (permalink / raw) To: Martin Knoblauch Cc: Linux Kernel Mailing List, Kernel Testers List, Jesse Barnes, Stephen Hemminger, James Owens On Monday 08 June 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>; Jesse Barnes <jbarnes@virtuousgeek.org>; Martin Knoblauch <spamtrap@knobisoft.de>; Stephen Hemminger <shemminger@vyatta.com> > > Sent: Sunday, June 7, 2009 12:06:22 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 (45 days old) > > References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4 > > No change since last ping. We ruled out a non-HP NIC in the DL380. HP will try to reproduce in-house. Thanks a lot for the update. Best, Rafael ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13294] i915: drm: xorg leaks drm objects massively 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Sergei Trofimovich This message has been generated automatically as a part of a report of 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=13294 Subject : i915: drm: xorg leaks drm objects massively Submitter : Sergei Trofimovich <slyich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2009-05-10 19:56 (29 days old) References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4 ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13294] i915: drm: xorg leaks drm objects massively @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Sergei Trofimovich This message has been generated automatically as a part of a report of 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=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 ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13294] i915: drm: xorg leaks drm objects massively 2009-06-07 10:06 ` Rafael J. Wysocki @ 2009-06-07 13:50 ` Sergei Trofimovich -1 siblings, 0 replies; 151+ messages in thread From: Sergei Trofimovich @ 2009-06-07 13:50 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 1015 bytes --] On Sun, 7 Jun 2009 12:06:23 +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). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13294 > Subject : i915: drm: xorg leaks drm objects massively > Submitter : Sergei Trofimovich <slyich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2009-05-10 19:56 (29 days old) > References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4 > > Rafael, please remove it from regression list. I haven't found kernel working the other way. It's a bug(set of bugs) being around "forever". Many people confirm it on various laptops/kernel versions. It's just not very noticeable. -- Sergei [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13294] i915: drm: xorg leaks drm objects massively @ 2009-06-07 13:50 ` Sergei Trofimovich 0 siblings, 0 replies; 151+ messages in thread From: Sergei Trofimovich @ 2009-06-07 13:50 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 964 bytes --] On Sun, 7 Jun 2009 12:06:23 +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). > > > 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 > > Rafael, please remove it from regression list. I haven't found kernel working the other way. It's a bug(set of bugs) being around "forever". Many people confirm it on various laptops/kernel versions. It's just not very noticeable. -- Sergei [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <20090607165018.4c946a30-b59k1isJxu/84SrubaaLTA@public.gmane.org>]
* Re: [Bug #13294] i915: drm: xorg leaks drm objects massively 2009-06-07 13:50 ` Sergei Trofimovich @ 2009-06-07 21:00 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 21:00 UTC (permalink / raw) To: Sergei Trofimovich; +Cc: Linux Kernel Mailing List, Kernel Testers List On Sunday 07 June 2009, Sergei Trofimovich wrote: > On Sun, 7 Jun 2009 12:06:23 +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). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13294 > > Subject : i915: drm: xorg leaks drm objects massively > > Submitter : Sergei Trofimovich <slyich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Date : 2009-05-10 19:56 (29 days old) > > References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4 > > > > > Rafael, please remove it from regression list. I haven't found kernel working > the other way. It's a bug(set of bugs) being around "forever". Many people > confirm it on various laptops/kernel versions. It's just not very noticeable. OK, dropped. Thanks, Rafael ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13294] i915: drm: xorg leaks drm objects massively @ 2009-06-07 21:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 21:00 UTC (permalink / raw) To: Sergei Trofimovich; +Cc: Linux Kernel Mailing List, Kernel Testers List On Sunday 07 June 2009, Sergei Trofimovich wrote: > On Sun, 7 Jun 2009 12:06:23 +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). > > > > > > 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 > > > > > Rafael, please remove it from regression list. I haven't found kernel working > the other way. It's a bug(set of bugs) being around "forever". Many people > confirm it on various laptops/kernel versions. It's just not very noticeable. OK, dropped. Thanks, Rafael ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13339] rtable leak in ipv4/route.c 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexander V. Lukyanov, David S. Miller, Eric Dumazet, Neil Horman 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=13339 Subject : rtable leak in ipv4/route.c Submitter : Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org> Date : 2009-05-18 14:10 (21 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13339] rtable leak in ipv4/route.c @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexander V. Lukyanov, David S. Miller, Eric Dumazet, Neil Horman 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=13339 Subject : rtable leak in ipv4/route.c Submitter : Alexander V. Lukyanov <lav@yar.ru> Date : 2009-05-18 14:10 (21 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13371] s2disk hangs with e100, kernel 2.6.29 and later 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Bartlomiej Zolnierkiewicz, Jeffrey Kirsher, Richard Atterer 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=13371 Subject : s2disk hangs with e100, kernel 2.6.29 and later Submitter : Richard Atterer <richard-2/EmM+jwkBzwc4Swprx3xw@public.gmane.org> 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13371] s2disk hangs with e100, kernel 2.6.29 and later @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Bartlomiej Zolnierkiewicz, Jeffrey Kirsher, Richard Atterer 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=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> ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alex Samad, Dave Chinner 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=13375 Subject : Kernel crash with 2.6.29 + nfs + xfs (radix-tree) Submitter : Alex Samad <alex-SGFoFqf0RKf0CCvOHzKKcA@public.gmane.org> Date : 2009-05-20 0:37 (19 days old) References : http://marc.info/?l=linux-kernel&m=124278675503699&w=4 ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alex Samad, Dave Chinner 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=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 ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-07 10:06 ` Rafael J. Wysocki @ 2009-06-07 20:09 ` Mike Dresser -1 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-07 20:09 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner > introduced between 2.6.28 and 2.6.29. Please verify if it still should > be listed and let me know (either way). Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed this. I'd say to leave this open for now, there's at least one other person testing 2.6.30-rc8 to see if it's fixed or not. Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-07 20:09 ` Mike Dresser 0 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-07 20:09 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner > introduced between 2.6.28 and 2.6.29. Please verify if it still should > be listed and let me know (either way). Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed this. I'd say to leave this open for now, there's at least one other person testing 2.6.30-rc8 to see if it's fixed or not. Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <alpine.DEB.1.10.0906071608010.3914-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>]
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-07 20:09 ` Mike Dresser @ 2009-06-08 7:27 ` Mathias Kretschmer -1 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-08 7:27 UTC (permalink / raw) To: Mike Dresser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Sunday 07 June 2009 22:09:23 Mike Dresser wrote: > > introduced between 2.6.28 and 2.6.29. Please verify if it still should > > be listed and let me know (either way). > > Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed > this. I'd say to leave this open for now, there's at least one other > person testing 2.6.30-rc8 to see if it's fixed or not. I'm afraid my test here won't help much to answer this question. I've seen no more crashes, but starting with 2.6.29 I'm seeing so many 'reconnect_path: npd != pd' messages and am experiencing lots of 'stale NFS handles' that I turned off NFS yesterday evening until I have more time to look into this. -Mathias > Mike > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-08 7:27 ` Mathias Kretschmer 0 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-08 7:27 UTC (permalink / raw) To: Mike Dresser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Sunday 07 June 2009 22:09:23 Mike Dresser wrote: > > introduced between 2.6.28 and 2.6.29. Please verify if it still should > > be listed and let me know (either way). > > Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed > this. I'd say to leave this open for now, there's at least one other > person testing 2.6.30-rc8 to see if it's fixed or not. I'm afraid my test here won't help much to answer this question. I've seen no more crashes, but starting with 2.6.29 I'm seeing so many 'reconnect_path: npd != pd' messages and am experiencing lots of 'stale NFS handles' that I turned off NFS yesterday evening until I have more time to look into this. -Mathias > Mike > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <200906080927.10479.posting-ZcF2+9dVbKo@public.gmane.org>]
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-08 7:27 ` Mathias Kretschmer @ 2009-06-08 7:40 ` Mathias Kretschmer -1 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-08 7:40 UTC (permalink / raw) To: Mike Dresser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner oops. I've overseen a BUG. this is on 2.6.30-rc8-git2 (with NFS still active): Jun 7 00:04:29 [kernel] [18059.860915] reconnect_path: npd != pd Jun 7 00:04:29 [kernel] [18059.876749] reconnect_path: npd != pd Jun 7 00:04:29 [kernel] [18059.884702] reconnect_path: npd != pd Jun 7 00:04:29 [kernel] [18060.605674] kernel BUG at lib/radix-tree.c:485! Jun 7 00:04:29 [kernel] [18060.605689] CPU 1 Jun 7 00:04:29 [kernel] [18060.605693] Modules linked in: usbtouchscreen dvb_usb_cinergyT2 dummy bonding snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus forcedeth snd_pcm hfcpci snd_page_alloc snd_util_mem snd_hwdep Jun 7 00:04:29 [kernel] [18060.605721] Pid: 392, comm: kswapd0 Not tainted 2.6.30-rc8-git2 #2 empty Jun 7 00:04:29 [kernel] [18060.605726] RIP: 0010:[<ffffffff80451ad8>] [<ffffffff80451ad8>] radix_tree_tag_set+0x98/0xc0 Jun 7 00:04:29 [kernel] [18060.605743] RSP: 0018:ffff880226b05cd0 EFLAGS: 00010246 Jun 7 00:04:29 [kernel] [18060.605748] RAX: 000000000000000c RBX: 0000000000000000 RCX: 000000000000000c Jun 7 00:04:29 [kernel] [18060.605752] RDX: 0000000000000000 RSI: 000000000000040c RDI: ffff88022628e360 Jun 7 00:04:29 [kernel] [18060.605757] RBP: ffff880201159c00 R08: ffff88020119da28 R09: 0000000000000000 Jun 7 00:04:29 [kernel] [18060.605762] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880201159c00 Jun 7 00:04:29 [kernel] [18060.605766] R13: ffff88022505f400 R14: ffff880201159cf8 R15: ffff88022628e35c Jun 7 00:04:29 [kernel] [18060.605772] FS: 0000000043d51950(0000) GS:ffff88002804e000(0000) knlGS:00000000f4ceab90 Jun 7 00:04:29 [kernel] [18060.605777] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Jun 7 00:04:29 [kernel] [18060.605782] CR2: 000000000044b7c0 CR3: 00000001e45fe000 CR4: 00000000000006e0 Jun 7 00:04:29 [kernel] [18060.605786] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jun 7 00:04:29 [kernel] [18060.605791] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jun 7 00:04:29 [kernel] [18060.605796] Process kswapd0 (pid: 392, threadinfo ffff880226b04000, task ffff880227981620) Jun 7 00:04:29 [kernel] [18060.605803] ffff88022628e320 ffffffff8040a1d6 ffff880201159d80 0000000000000071 Jun 7 00:04:29 [kernel] [18060.606011] RIP [<ffffffff80451ad8>] radix_tree_tag_set+0x98/0xc0 Jun 7 00:04:30 [kernel] [18060.606018] RSP <ffff880226b05cd0> Jun 7 00:04:30 [kernel] [18060.606026] ---[ end trace 0645e929a4fa40ac ]--- Jun 7 00:04:31 [kernel] [18061.930702] reconnect_path: npd != pd Jun 7 00:04:31 [kernel] [18061.930944] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.327856] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.328465] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.328722] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.329075] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.329598] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.329734] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.330410] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.330538] reconnect_path: npd != pd On Monday 08 June 2009 09:27:09 Mathias Kretschmer wrote: > On Sunday 07 June 2009 22:09:23 Mike Dresser wrote: > > > introduced between 2.6.28 and 2.6.29. Please verify if it still should > > > be listed and let me know (either way). > > > > Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed > > this. I'd say to leave this open for now, there's at least one other > > person testing 2.6.30-rc8 to see if it's fixed or not. > > I'm afraid my test here won't help much to answer this question. > > I've seen no more crashes, but starting with 2.6.29 I'm seeing so many > 'reconnect_path: npd != pd' messages and am experiencing lots of 'stale NFS > handles' that I turned off NFS yesterday evening until I have more time to > look into this. > > -Mathias > > > Mike > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > > in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-08 7:40 ` Mathias Kretschmer 0 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-08 7:40 UTC (permalink / raw) To: Mike Dresser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner oops. I've overseen a BUG. this is on 2.6.30-rc8-git2 (with NFS still active): Jun 7 00:04:29 [kernel] [18059.860915] reconnect_path: npd != pd Jun 7 00:04:29 [kernel] [18059.876749] reconnect_path: npd != pd Jun 7 00:04:29 [kernel] [18059.884702] reconnect_path: npd != pd Jun 7 00:04:29 [kernel] [18060.605674] kernel BUG at lib/radix-tree.c:485! Jun 7 00:04:29 [kernel] [18060.605689] CPU 1 Jun 7 00:04:29 [kernel] [18060.605693] Modules linked in: usbtouchscreen dvb_usb_cinergyT2 dummy bonding snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus forcedeth snd_pcm hfcpci snd_page_alloc snd_util_mem snd_hwdep Jun 7 00:04:29 [kernel] [18060.605721] Pid: 392, comm: kswapd0 Not tainted 2.6.30-rc8-git2 #2 empty Jun 7 00:04:29 [kernel] [18060.605726] RIP: 0010:[<ffffffff80451ad8>] [<ffffffff80451ad8>] radix_tree_tag_set+0x98/0xc0 Jun 7 00:04:29 [kernel] [18060.605743] RSP: 0018:ffff880226b05cd0 EFLAGS: 00010246 Jun 7 00:04:29 [kernel] [18060.605748] RAX: 000000000000000c RBX: 0000000000000000 RCX: 000000000000000c Jun 7 00:04:29 [kernel] [18060.605752] RDX: 0000000000000000 RSI: 000000000000040c RDI: ffff88022628e360 Jun 7 00:04:29 [kernel] [18060.605757] RBP: ffff880201159c00 R08: ffff88020119da28 R09: 0000000000000000 Jun 7 00:04:29 [kernel] [18060.605762] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880201159c00 Jun 7 00:04:29 [kernel] [18060.605766] R13: ffff88022505f400 R14: ffff880201159cf8 R15: ffff88022628e35c Jun 7 00:04:29 [kernel] [18060.605772] FS: 0000000043d51950(0000) GS:ffff88002804e000(0000) knlGS:00000000f4ceab90 Jun 7 00:04:29 [kernel] [18060.605777] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Jun 7 00:04:29 [kernel] [18060.605782] CR2: 000000000044b7c0 CR3: 00000001e45fe000 CR4: 00000000000006e0 Jun 7 00:04:29 [kernel] [18060.605786] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jun 7 00:04:29 [kernel] [18060.605791] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jun 7 00:04:29 [kernel] [18060.605796] Process kswapd0 (pid: 392, threadinfo ffff880226b04000, task ffff880227981620) Jun 7 00:04:29 [kernel] [18060.605803] ffff88022628e320 ffffffff8040a1d6 ffff880201159d80 0000000000000071 Jun 7 00:04:29 [kernel] [18060.606011] RIP [<ffffffff80451ad8>] radix_tree_tag_set+0x98/0xc0 Jun 7 00:04:30 [kernel] [18060.606018] RSP <ffff880226b05cd0> Jun 7 00:04:30 [kernel] [18060.606026] ---[ end trace 0645e929a4fa40ac ]--- Jun 7 00:04:31 [kernel] [18061.930702] reconnect_path: npd != pd Jun 7 00:04:31 [kernel] [18061.930944] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.327856] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.328465] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.328722] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.329075] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.329598] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.329734] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.330410] reconnect_path: npd != pd Jun 7 00:04:32 [kernel] [18063.330538] reconnect_path: npd != pd On Monday 08 June 2009 09:27:09 Mathias Kretschmer wrote: > On Sunday 07 June 2009 22:09:23 Mike Dresser wrote: > > > introduced between 2.6.28 and 2.6.29. Please verify if it still should > > > be listed and let me know (either way). > > > > Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed > > this. I'd say to leave this open for now, there's at least one other > > person testing 2.6.30-rc8 to see if it's fixed or not. > > I'm afraid my test here won't help much to answer this question. > > I've seen no more crashes, but starting with 2.6.29 I'm seeing so many > 'reconnect_path: npd != pd' messages and am experiencing lots of 'stale NFS > handles' that I turned off NFS yesterday evening until I have more time to > look into this. > > -Mathias > > > Mike > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > > in the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <200906080940.14650.posting-ZcF2+9dVbKo@public.gmane.org>]
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-08 7:40 ` Mathias Kretschmer @ 2009-06-09 19:02 ` Mike Dresser -1 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-09 19:02 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner Mine crashed last night, nothing was logged in the local logfiles, but fortunately remote syslog got it Jun 9 01:24:07 x kernel: ------------[ cut here ]------------ Jun 9 01:24:07 x kernel: kernel BUG at lib/radix-tree.c:485! Jun 9 01:24:07 x kernel: invalid opcode: 0000 [#1] SMP Jun 9 01:24:07 x kernel: last sysfs file: /sys/class/scsi_host/host0/stats Jun 9 01:24:07 x kernel: CPU 0 Jun 9 01:24:07 x kernel: Pid: 338, comm: kswapd0 Not tainted 2.6.30-rc8 #2 S2895 Jun 9 01:24:07 x kernel: RIP: 0010:[<ffffffff803a5a04>] [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun 9 01:24:07 x kernel: RSP: 0018:ffff88016e1e9c58 EFLAGS: 00010246 Jun 9 01:24:07 x kernel: RAX: 0000000000000038 RBX: 0000000000000000 RCX: 0000000000000038 Jun 9 01:24:07 x kernel: RDX: 0000000000000000 RSI: 00000000002faaf8 RDI: ffff88016c3b8220 Jun 9 01:24:07 x kernel: RBP: ffff88016e1e9c60 R08: 0000000000000000 R09: ffff8800927460b8 Jun 9 01:24:07 x kernel: R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800666e61c0 Jun 9 01:24:07 x kernel: R13: ffff88016dc21c00 R14: ffff8800666e62c8 R15: ffff88016c3b821c Jun 9 01:24:07 x kernel: FS: 00007fda3776f6e0(0000) GS:ffff880028028000(0000) knlGS:0000000000000000 Jun 9 01:24:07 x kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Jun 9 01:24:07 x kernel: CR2: 00007fda368758e0 CR3: 0000000000201000 CR4: 00000000000006e0 Jun 9 01:24:07 x kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jun 9 01:24:07 x kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jun 9 01:24:07 x kernel: Process kswapd0 (pid: 338, threadinfo ffff88016e1e8000, task ffff88016f245fa0) Jun 9 01:24:07 x kernel: Stack: Jun 9 01:24:07 x kernel: ffff88016c3b81e0 ffff88016e1e9ca0 ffffffff8038dcd6 ffff88016e1e9d40 Jun 9 01:24:07 x kernel: ffff8800666e6350 ffff8800666e61c0 0000000000000048 ffff88016e1e9d40 Jun 9 01:24:07 x kernel: 0000000000000080 ffff88016e1e9cc0 ffffffff8037f2d2 ffff8800666e6350 Jun 9 01:24:07 x kernel: Call Trace: Jun 9 01:24:07 x kernel: [<ffffffff8038dcd6>] xfs_inode_set_reclaim_tag+0x71/0x93 Jun 9 01:24:07 x kernel: [<ffffffff8037f2d2>] xfs_reclaim+0x106/0x10d Jun 9 01:24:07 x kernel: [<ffffffff8038c51e>] xfs_fs_destroy_inode+0x37/0x58 Jun 9 01:24:07 x kernel: [<ffffffff8029dde0>] destroy_inode+0x32/0x47 Jun 9 01:24:07 x kernel: [<ffffffff8029dec9>] dispose_list+0xd4/0x102 Jun 9 01:24:07 x kernel: [<ffffffff8029e0f0>] shrink_icache_memory+0x1f9/0x22f Jun 9 01:24:07 x kernel: [<ffffffff80269660>] shrink_slab+0xdf/0x154 Jun 9 01:24:07 x kernel: [<ffffffff80269e13>] kswapd+0x48d/0x62c Jun 9 01:24:07 x kernel: [<ffffffff80267765>] ? isolate_pages_global+0x0/0x219 Jun 9 01:24:07 x kernel: [<ffffffff802481b8>] ? autoremove_wake_function+0x0/0x38 Jun 9 01:24:07 x kernel: [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun 9 01:24:07 x kernel: [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun 9 01:24:07 x kernel: [<ffffffff80247e1a>] kthread+0x56/0x83 Jun 9 01:24:07 x kernel: [<ffffffff8020c9ba>] child_rip+0xa/0x20 Jun 9 01:24:07 x kernel: [<ffffffff80247dc4>] ? kthread+0x0/0x83 Jun 9 01:24:07 x kernel: [<ffffffff8020c9b0>] ? child_rip+0x0/0x20 Jun 9 01:24:07 x kernel: Code: 18 02 00 00 48 d3 e8 89 c1 83 e1 3f 41 0f a3 0c 11 19 c0 85 c0 75 07 49 8d 04 11 0f ab 08 48 63 c1 4d 8b 44 c0 18 4d 85 c0 75 04 <0f> 0b eb fe 41 83 eb 06 41 ff ca 45$ Jun 9 01:24:07 x kernel: RIP [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun 9 01:24:07 x kernel: RSP <ffff88016e1e9c58> Jun 9 01:24:07 x kernel: ---[ end trace a0564fe308c3b2b4 ]--- CONFIG_XFS_DEBUG was on for this one. I've noticed it's always kswapd0 that dies? Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-09 19:02 ` Mike Dresser 0 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-09 19:02 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner Mine crashed last night, nothing was logged in the local logfiles, but fortunately remote syslog got it Jun 9 01:24:07 x kernel: ------------[ cut here ]------------ Jun 9 01:24:07 x kernel: kernel BUG at lib/radix-tree.c:485! Jun 9 01:24:07 x kernel: invalid opcode: 0000 [#1] SMP Jun 9 01:24:07 x kernel: last sysfs file: /sys/class/scsi_host/host0/stats Jun 9 01:24:07 x kernel: CPU 0 Jun 9 01:24:07 x kernel: Pid: 338, comm: kswapd0 Not tainted 2.6.30-rc8 #2 S2895 Jun 9 01:24:07 x kernel: RIP: 0010:[<ffffffff803a5a04>] [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun 9 01:24:07 x kernel: RSP: 0018:ffff88016e1e9c58 EFLAGS: 00010246 Jun 9 01:24:07 x kernel: RAX: 0000000000000038 RBX: 0000000000000000 RCX: 0000000000000038 Jun 9 01:24:07 x kernel: RDX: 0000000000000000 RSI: 00000000002faaf8 RDI: ffff88016c3b8220 Jun 9 01:24:07 x kernel: RBP: ffff88016e1e9c60 R08: 0000000000000000 R09: ffff8800927460b8 Jun 9 01:24:07 x kernel: R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800666e61c0 Jun 9 01:24:07 x kernel: R13: ffff88016dc21c00 R14: ffff8800666e62c8 R15: ffff88016c3b821c Jun 9 01:24:07 x kernel: FS: 00007fda3776f6e0(0000) GS:ffff880028028000(0000) knlGS:0000000000000000 Jun 9 01:24:07 x kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Jun 9 01:24:07 x kernel: CR2: 00007fda368758e0 CR3: 0000000000201000 CR4: 00000000000006e0 Jun 9 01:24:07 x kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jun 9 01:24:07 x kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jun 9 01:24:07 x kernel: Process kswapd0 (pid: 338, threadinfo ffff88016e1e8000, task ffff88016f245fa0) Jun 9 01:24:07 x kernel: Stack: Jun 9 01:24:07 x kernel: ffff88016c3b81e0 ffff88016e1e9ca0 ffffffff8038dcd6 ffff88016e1e9d40 Jun 9 01:24:07 x kernel: ffff8800666e6350 ffff8800666e61c0 0000000000000048 ffff88016e1e9d40 Jun 9 01:24:07 x kernel: 0000000000000080 ffff88016e1e9cc0 ffffffff8037f2d2 ffff8800666e6350 Jun 9 01:24:07 x kernel: Call Trace: Jun 9 01:24:07 x kernel: [<ffffffff8038dcd6>] xfs_inode_set_reclaim_tag+0x71/0x93 Jun 9 01:24:07 x kernel: [<ffffffff8037f2d2>] xfs_reclaim+0x106/0x10d Jun 9 01:24:07 x kernel: [<ffffffff8038c51e>] xfs_fs_destroy_inode+0x37/0x58 Jun 9 01:24:07 x kernel: [<ffffffff8029dde0>] destroy_inode+0x32/0x47 Jun 9 01:24:07 x kernel: [<ffffffff8029dec9>] dispose_list+0xd4/0x102 Jun 9 01:24:07 x kernel: [<ffffffff8029e0f0>] shrink_icache_memory+0x1f9/0x22f Jun 9 01:24:07 x kernel: [<ffffffff80269660>] shrink_slab+0xdf/0x154 Jun 9 01:24:07 x kernel: [<ffffffff80269e13>] kswapd+0x48d/0x62c Jun 9 01:24:07 x kernel: [<ffffffff80267765>] ? isolate_pages_global+0x0/0x219 Jun 9 01:24:07 x kernel: [<ffffffff802481b8>] ? autoremove_wake_function+0x0/0x38 Jun 9 01:24:07 x kernel: [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun 9 01:24:07 x kernel: [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun 9 01:24:07 x kernel: [<ffffffff80247e1a>] kthread+0x56/0x83 Jun 9 01:24:07 x kernel: [<ffffffff8020c9ba>] child_rip+0xa/0x20 Jun 9 01:24:07 x kernel: [<ffffffff80247dc4>] ? kthread+0x0/0x83 Jun 9 01:24:07 x kernel: [<ffffffff8020c9b0>] ? child_rip+0x0/0x20 Jun 9 01:24:07 x kernel: Code: 18 02 00 00 48 d3 e8 89 c1 83 e1 3f 41 0f a3 0c 11 19 c0 85 c0 75 07 49 8d 04 11 0f ab 08 48 63 c1 4d 8b 44 c0 18 4d 85 c0 75 04 <0f> 0b eb fe 41 83 eb 06 41 ff ca 45$ Jun 9 01:24:07 x kernel: RIP [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun 9 01:24:07 x kernel: RSP <ffff88016e1e9c58> Jun 9 01:24:07 x kernel: ---[ end trace a0564fe308c3b2b4 ]--- CONFIG_XFS_DEBUG was on for this one. I've noticed it's always kswapd0 that dies? Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <alpine.DEB.1.10.0906091457510.28108-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>]
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-09 19:02 ` Mike Dresser @ 2009-06-09 19:11 ` Mathias Kretschmer -1 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-09 19:11 UTC (permalink / raw) To: Mike Dresser Cc: Mathias Kretschmer, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner same observation here. it's kswapd that dies. swap space itself is hardly ever really used, since my box has 8GB and not that much stuff is running on it. my XFS mount opts: noatime,nodiratime,logbufs=8 drive/fs config: sata => raid6 => lvm => xfs => nfs machine is stable for the last 36 hours with nfs turned off. -Mathias On Tuesday 09 June 2009 21:02:13 Mike Dresser wrote: > Mine crashed last night, nothing was logged in the local logfiles, but > fortunately remote syslog got it > > Jun 9 01:24:07 x kernel: ------------[ cut here ]------------ > Jun 9 01:24:07 x kernel: kernel BUG at lib/radix-tree.c:485! > Jun 9 01:24:07 x kernel: invalid opcode: 0000 [#1] SMP > Jun 9 01:24:07 x kernel: last sysfs file: /sys/class/scsi_host/host0/stats > Jun 9 01:24:07 x kernel: CPU 0 > Jun 9 01:24:07 x kernel: Pid: 338, comm: kswapd0 Not tainted 2.6.30-rc8 #2 > S2895 Jun 9 01:24:07 x kernel: RIP: 0010:[<ffffffff803a5a04>] > [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun 9 01:24:07 x kernel: > RSP: 0018:ffff88016e1e9c58 EFLAGS: 00010246 Jun 9 01:24:07 x kernel: RAX: > 0000000000000038 RBX: 0000000000000000 RCX: 0000000000000038 Jun 9 > 01:24:07 x kernel: RDX: 0000000000000000 RSI: 00000000002faaf8 RDI: > ffff88016c3b8220 Jun 9 01:24:07 x kernel: RBP: ffff88016e1e9c60 R08: > 0000000000000000 R09: ffff8800927460b8 Jun 9 01:24:07 x kernel: R10: > 0000000000000001 R11: 0000000000000000 R12: ffff8800666e61c0 Jun 9 > 01:24:07 x kernel: R13: ffff88016dc21c00 R14: ffff8800666e62c8 R15: > ffff88016c3b821c Jun 9 01:24:07 x kernel: FS: 00007fda3776f6e0(0000) > GS:ffff880028028000(0000) knlGS:0000000000000000 Jun 9 01:24:07 x kernel: > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Jun 9 01:24:07 x kernel: > CR2: 00007fda368758e0 CR3: 0000000000201000 CR4: 00000000000006e0 Jun 9 > 01:24:07 x kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 Jun 9 01:24:07 x kernel: DR3: 0000000000000000 DR6: > 00000000ffff0ff0 DR7: 0000000000000400 Jun 9 01:24:07 x kernel: Process > kswapd0 (pid: 338, threadinfo ffff88016e1e8000, task ffff88016f245fa0) Jun > 9 01:24:07 x kernel: Stack: > Jun 9 01:24:07 x kernel: ffff88016c3b81e0 ffff88016e1e9ca0 > ffffffff8038dcd6 ffff88016e1e9d40 Jun 9 01:24:07 x kernel: > ffff8800666e6350 ffff8800666e61c0 0000000000000048 ffff88016e1e9d40 Jun 9 > 01:24:07 x kernel: 0000000000000080 ffff88016e1e9cc0 ffffffff8037f2d2 > ffff8800666e6350 Jun 9 01:24:07 x kernel: Call Trace: > Jun 9 01:24:07 x kernel: [<ffffffff8038dcd6>] > xfs_inode_set_reclaim_tag+0x71/0x93 Jun 9 01:24:07 x kernel: > [<ffffffff8037f2d2>] xfs_reclaim+0x106/0x10d Jun 9 01:24:07 x kernel: > [<ffffffff8038c51e>] xfs_fs_destroy_inode+0x37/0x58 Jun 9 01:24:07 x > kernel: [<ffffffff8029dde0>] destroy_inode+0x32/0x47 Jun 9 01:24:07 x > kernel: [<ffffffff8029dec9>] dispose_list+0xd4/0x102 Jun 9 01:24:07 x > kernel: [<ffffffff8029e0f0>] shrink_icache_memory+0x1f9/0x22f Jun 9 > 01:24:07 x kernel: [<ffffffff80269660>] shrink_slab+0xdf/0x154 Jun 9 > 01:24:07 x kernel: [<ffffffff80269e13>] kswapd+0x48d/0x62c Jun 9 01:24:07 > x kernel: [<ffffffff80267765>] ? isolate_pages_global+0x0/0x219 Jun 9 > 01:24:07 x kernel: [<ffffffff802481b8>] ? > autoremove_wake_function+0x0/0x38 Jun 9 01:24:07 x kernel: > [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun 9 01:24:07 x kernel: > [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun 9 01:24:07 x kernel: > [<ffffffff80247e1a>] kthread+0x56/0x83 > Jun 9 01:24:07 x kernel: [<ffffffff8020c9ba>] child_rip+0xa/0x20 > Jun 9 01:24:07 x kernel: [<ffffffff80247dc4>] ? kthread+0x0/0x83 > Jun 9 01:24:07 x kernel: [<ffffffff8020c9b0>] ? child_rip+0x0/0x20 > Jun 9 01:24:07 x kernel: Code: 18 02 00 00 48 d3 e8 89 c1 83 e1 3f 41 0f > a3 0c 11 19 c0 85 c0 75 07 49 8d 04 11 0f ab 08 48 63 c1 4d 8b 44 c0 18 4d > 85 c0 75 04 <0f> 0b eb fe 41 83 eb 06 41 ff ca 45$ Jun 9 01:24:07 x > kernel: RIP [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun 9 > 01:24:07 x kernel: RSP <ffff88016e1e9c58> > Jun 9 01:24:07 x kernel: ---[ end trace a0564fe308c3b2b4 ]--- > > CONFIG_XFS_DEBUG was on for this one. > > I've noticed it's always kswapd0 that dies? > > Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-09 19:11 ` Mathias Kretschmer 0 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-09 19:11 UTC (permalink / raw) To: Mike Dresser Cc: Mathias Kretschmer, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner same observation here. it's kswapd that dies. swap space itself is hardly ever really used, since my box has 8GB and not that much stuff is running on it. my XFS mount opts: noatime,nodiratime,logbufs=8 drive/fs config: sata => raid6 => lvm => xfs => nfs machine is stable for the last 36 hours with nfs turned off. -Mathias On Tuesday 09 June 2009 21:02:13 Mike Dresser wrote: > Mine crashed last night, nothing was logged in the local logfiles, but > fortunately remote syslog got it > > Jun 9 01:24:07 x kernel: ------------[ cut here ]------------ > Jun 9 01:24:07 x kernel: kernel BUG at lib/radix-tree.c:485! > Jun 9 01:24:07 x kernel: invalid opcode: 0000 [#1] SMP > Jun 9 01:24:07 x kernel: last sysfs file: /sys/class/scsi_host/host0/stats > Jun 9 01:24:07 x kernel: CPU 0 > Jun 9 01:24:07 x kernel: Pid: 338, comm: kswapd0 Not tainted 2.6.30-rc8 #2 > S2895 Jun 9 01:24:07 x kernel: RIP: 0010:[<ffffffff803a5a04>] > [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun 9 01:24:07 x kernel: > RSP: 0018:ffff88016e1e9c58 EFLAGS: 00010246 Jun 9 01:24:07 x kernel: RAX: > 0000000000000038 RBX: 0000000000000000 RCX: 0000000000000038 Jun 9 > 01:24:07 x kernel: RDX: 0000000000000000 RSI: 00000000002faaf8 RDI: > ffff88016c3b8220 Jun 9 01:24:07 x kernel: RBP: ffff88016e1e9c60 R08: > 0000000000000000 R09: ffff8800927460b8 Jun 9 01:24:07 x kernel: R10: > 0000000000000001 R11: 0000000000000000 R12: ffff8800666e61c0 Jun 9 > 01:24:07 x kernel: R13: ffff88016dc21c00 R14: ffff8800666e62c8 R15: > ffff88016c3b821c Jun 9 01:24:07 x kernel: FS: 00007fda3776f6e0(0000) > GS:ffff880028028000(0000) knlGS:0000000000000000 Jun 9 01:24:07 x kernel: > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Jun 9 01:24:07 x kernel: > CR2: 00007fda368758e0 CR3: 0000000000201000 CR4: 00000000000006e0 Jun 9 > 01:24:07 x kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 Jun 9 01:24:07 x kernel: DR3: 0000000000000000 DR6: > 00000000ffff0ff0 DR7: 0000000000000400 Jun 9 01:24:07 x kernel: Process > kswapd0 (pid: 338, threadinfo ffff88016e1e8000, task ffff88016f245fa0) Jun > 9 01:24:07 x kernel: Stack: > Jun 9 01:24:07 x kernel: ffff88016c3b81e0 ffff88016e1e9ca0 > ffffffff8038dcd6 ffff88016e1e9d40 Jun 9 01:24:07 x kernel: > ffff8800666e6350 ffff8800666e61c0 0000000000000048 ffff88016e1e9d40 Jun 9 > 01:24:07 x kernel: 0000000000000080 ffff88016e1e9cc0 ffffffff8037f2d2 > ffff8800666e6350 Jun 9 01:24:07 x kernel: Call Trace: > Jun 9 01:24:07 x kernel: [<ffffffff8038dcd6>] > xfs_inode_set_reclaim_tag+0x71/0x93 Jun 9 01:24:07 x kernel: > [<ffffffff8037f2d2>] xfs_reclaim+0x106/0x10d Jun 9 01:24:07 x kernel: > [<ffffffff8038c51e>] xfs_fs_destroy_inode+0x37/0x58 Jun 9 01:24:07 x > kernel: [<ffffffff8029dde0>] destroy_inode+0x32/0x47 Jun 9 01:24:07 x > kernel: [<ffffffff8029dec9>] dispose_list+0xd4/0x102 Jun 9 01:24:07 x > kernel: [<ffffffff8029e0f0>] shrink_icache_memory+0x1f9/0x22f Jun 9 > 01:24:07 x kernel: [<ffffffff80269660>] shrink_slab+0xdf/0x154 Jun 9 > 01:24:07 x kernel: [<ffffffff80269e13>] kswapd+0x48d/0x62c Jun 9 01:24:07 > x kernel: [<ffffffff80267765>] ? isolate_pages_global+0x0/0x219 Jun 9 > 01:24:07 x kernel: [<ffffffff802481b8>] ? > autoremove_wake_function+0x0/0x38 Jun 9 01:24:07 x kernel: > [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun 9 01:24:07 x kernel: > [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun 9 01:24:07 x kernel: > [<ffffffff80247e1a>] kthread+0x56/0x83 > Jun 9 01:24:07 x kernel: [<ffffffff8020c9ba>] child_rip+0xa/0x20 > Jun 9 01:24:07 x kernel: [<ffffffff80247dc4>] ? kthread+0x0/0x83 > Jun 9 01:24:07 x kernel: [<ffffffff8020c9b0>] ? child_rip+0x0/0x20 > Jun 9 01:24:07 x kernel: Code: 18 02 00 00 48 d3 e8 89 c1 83 e1 3f 41 0f > a3 0c 11 19 c0 85 c0 75 07 49 8d 04 11 0f ab 08 48 63 c1 4d 8b 44 c0 18 4d > 85 c0 75 04 <0f> 0b eb fe 41 83 eb 06 41 ff ca 45$ Jun 9 01:24:07 x > kernel: RIP [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun 9 > 01:24:07 x kernel: RSP <ffff88016e1e9c58> > Jun 9 01:24:07 x kernel: ---[ end trace a0564fe308c3b2b4 ]--- > > CONFIG_XFS_DEBUG was on for this one. > > I've noticed it's always kswapd0 that dies? > > Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <200906092111.54073.mathias-ZcF2+9dVbKo@public.gmane.org>]
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-09 19:11 ` Mathias Kretschmer @ 2009-06-09 19:16 ` Mike Dresser -1 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-09 19:16 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Tue, 9 Jun 2009, Mathias Kretschmer wrote: > same observation here. it's kswapd that dies. > > swap space itself is hardly ever really used, since my box has 8GB and not > that much stuff is running on it. Same here, 5GB ram.. I might try turning swap off and seeing what happens. > my XFS mount opts: noatime,nodiratime,logbufs=8 noatime,nodiratime,logbufs=8,logbsize=256k,inode64,nobarrier > drive/fs config: sata => raid6 => lvm => xfs => nfs sata => 3ware in raid5 => xfs > machine is stable for the last 36 hours with nfs turned off. Not using NFS here. ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-09 19:16 ` Mike Dresser 0 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-09 19:16 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Tue, 9 Jun 2009, Mathias Kretschmer wrote: > same observation here. it's kswapd that dies. > > swap space itself is hardly ever really used, since my box has 8GB and not > that much stuff is running on it. Same here, 5GB ram.. I might try turning swap off and seeing what happens. > my XFS mount opts: noatime,nodiratime,logbufs=8 noatime,nodiratime,logbufs=8,logbsize=256k,inode64,nobarrier > drive/fs config: sata => raid6 => lvm => xfs => nfs sata => 3ware in raid5 => xfs > machine is stable for the last 36 hours with nfs turned off. Not using NFS here. ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-09 19:11 ` Mathias Kretschmer @ 2009-06-09 19:22 ` Mike Dresser -1 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-09 19:22 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Tue, 9 Jun 2009, Mathias Kretschmer wrote: > machine is stable for the last 36 hours with nfs turned off. Is the system load different with nfs off? (no clients accessing it, etc?) Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-09 19:22 ` Mike Dresser 0 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-09 19:22 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Tue, 9 Jun 2009, Mathias Kretschmer wrote: > machine is stable for the last 36 hours with nfs turned off. Is the system load different with nfs off? (no clients accessing it, etc?) Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <alpine.DEB.1.10.0906091521470.9067-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>]
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-09 19:22 ` Mike Dresser @ 2009-06-15 17:25 ` Mike Dresser -1 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-15 17:25 UTC (permalink / raw) To: Mike Dresser Cc: Mathias Kretschmer, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner 2.6.30-rc8 still has issues, even with swapoff -a, it still died in kswapd0 ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-15 17:25 ` Mike Dresser 0 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-15 17:25 UTC (permalink / raw) To: Mike Dresser Cc: Mathias Kretschmer, Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner 2.6.30-rc8 still has issues, even with swapoff -a, it still died in kswapd0 ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-09 19:22 ` Mike Dresser @ 2009-06-18 21:55 ` Mathias Kretschmer -1 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-18 21:55 UTC (permalink / raw) To: Mike Dresser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Tuesday 09 June 2009 21:22:16 Mike Dresser wrote: > On Tue, 9 Jun 2009, Mathias Kretschmer wrote: > > machine is stable for the last 36 hours with nfs turned off. > > Is the system load different with nfs off? (no clients accessing it, etc?) Yep. I've upgraded to 2.6.30 two days ago. So far, so good. I've ran three Gentoo 'emerge world' sessions in parallel while forcing a RAID6 resync. This should have created more I/O load than this box usually sees. Of course, some other combination of events might be required to cause this kernel crash. I've also turned NFS back on today. Still, no problems to report. Cheers, Mathias > Mike > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-18 21:55 ` Mathias Kretschmer 0 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-18 21:55 UTC (permalink / raw) To: Mike Dresser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Tuesday 09 June 2009 21:22:16 Mike Dresser wrote: > On Tue, 9 Jun 2009, Mathias Kretschmer wrote: > > machine is stable for the last 36 hours with nfs turned off. > > Is the system load different with nfs off? (no clients accessing it, etc?) Yep. I've upgraded to 2.6.30 two days ago. So far, so good. I've ran three Gentoo 'emerge world' sessions in parallel while forcing a RAID6 resync. This should have created more I/O load than this box usually sees. Of course, some other combination of events might be required to cause this kernel crash. I've also turned NFS back on today. Still, no problems to report. Cheers, Mathias > Mike > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <200906182355.57100.mathias-ZcF2+9dVbKo@public.gmane.org>]
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-18 21:55 ` Mathias Kretschmer @ 2009-06-19 15:16 ` Mike Dresser -1 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-19 15:16 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Thu, 18 Jun 2009, Mathias Kretschmer wrote: > I've upgraded to 2.6.30 two days ago. So far, so good. Mine still crashes, so I've gone back to 2.6.28.9 for now. ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-19 15:16 ` Mike Dresser 0 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-19 15:16 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Thu, 18 Jun 2009, Mathias Kretschmer wrote: > I've upgraded to 2.6.30 two days ago. So far, so good. Mine still crashes, so I've gone back to 2.6.28.9 for now. ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-18 21:55 ` Mathias Kretschmer @ 2009-06-24 22:55 ` Mike Dresser -1 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-24 22:55 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner Tried 2.6.30-git18 the other day, machine jammed up with the usual BUG, though it was on radix-tree.c:464 this time. I really should get around to putting an APC masterswitch on this server, since it won't reboot with anything but the power switch/reset(though the system is otherwise fine, interactivity is perfect.. just can't kill processes) Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-24 22:55 ` Mike Dresser 0 siblings, 0 replies; 151+ messages in thread From: Mike Dresser @ 2009-06-24 22:55 UTC (permalink / raw) To: Mathias Kretschmer Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner Tried 2.6.30-git18 the other day, machine jammed up with the usual BUG, though it was on radix-tree.c:464 this time. I really should get around to putting an APC masterswitch on this server, since it won't reboot with anything but the power switch/reset(though the system is otherwise fine, interactivity is perfect.. just can't kill processes) Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <4A42AEEC.9070002-d1V2JtDI1HZNJje9z4SY99BPR1lH4CV8@public.gmane.org>]
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) 2009-06-24 22:55 ` Mike Dresser @ 2009-06-25 6:14 ` Mathias Kretschmer -1 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-25 6:14 UTC (permalink / raw) To: Mike Dresser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Thursday 25 June 2009 00:55:40 Mike Dresser wrote: > Tried 2.6.30-git18 the other day, machine jammed up with the usual BUG, > though it was on radix-tree.c:464 this time. I gave up and went back to 2.6.28.9, as you mentioned before. > I really should get around to putting an APC masterswitch on this > server, since it won't reboot with anything but the power > switch/reset(though the system is otherwise fine, interactivity is > perfect.. just can't kill processes) Yep, I had that happening a few days ago. The box worked fine, but won't reboot. Just hangs somewhere during unmount. I saw a kernel crash call trace somewhere, but it went by too quickly and I couldn't get it back. -Mathias > Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) @ 2009-06-25 6:14 ` Mathias Kretschmer 0 siblings, 0 replies; 151+ messages in thread From: Mathias Kretschmer @ 2009-06-25 6:14 UTC (permalink / raw) To: Mike Dresser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Alex Samad, Dave Chinner On Thursday 25 June 2009 00:55:40 Mike Dresser wrote: > Tried 2.6.30-git18 the other day, machine jammed up with the usual BUG, > though it was on radix-tree.c:464 this time. I gave up and went back to 2.6.28.9, as you mentioned before. > I really should get around to putting an APC masterswitch on this > server, since it won't reboot with anything but the power > switch/reset(though the system is otherwise fine, interactivity is > perfect.. just can't kill processes) Yep, I had that happening a few days ago. The box worked fine, but won't reboot. Just hangs somewhere during unmount. I saw a kernel crash call trace somewhere, but it went by too quickly and I couldn't get it back. -Mathias > Mike ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Guido, Jiri Kosina, Remi Cattiau 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=13411 Subject : Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 Submitter : Guido <bugzilla.kernel.org-Dy4KJ/v5nlEVgfBnK23ub6xOck334EZe@public.gmane.org> Date : 2009-05-31 12:21 (8 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Guido, Jiri Kosina, Remi Cattiau 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=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) ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 2009-06-07 10:06 ` Rafael J. Wysocki @ 2009-06-08 11:04 ` Jiri Kosina -1 siblings, 0 replies; 151+ messages in thread From: Jiri Kosina @ 2009-06-08 11:04 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Guido, Remi Cattiau On Sun, 7 Jun 2009, 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=13411 > Subject : Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 > Submitter : Guido <bugzilla.kernel.org-Dy4KJ/v5nlEVgfBnK23ub6xOck334EZe@public.gmane.org> > Date : 2009-05-31 12:21 (8 days old) This is apparently caused by vendor releasing two different hardware products under the same VID/PID and just one of them needing blacklist entry. Sigh. Waiting for verbose lsusb output from Remi, so that we could compare it with the output provided by the bug reporter, to see what else could be done to distinguish the devices from each other. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 @ 2009-06-08 11:04 ` Jiri Kosina 0 siblings, 0 replies; 151+ messages in thread From: Jiri Kosina @ 2009-06-08 11:04 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Guido, Remi Cattiau On Sun, 7 Jun 2009, 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=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) This is apparently caused by vendor releasing two different hardware products under the same VID/PID and just one of them needing blacklist entry. Sigh. Waiting for verbose lsusb output from Remi, so that we could compare it with the output provided by the bug reporter, to see what else could be done to distinguish the devices from each other. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <alpine.LNX.2.00.0906081302010.7457-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>]
* Re: [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 2009-06-08 11:04 ` Jiri Kosina @ 2009-06-08 11:37 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-08 11:37 UTC (permalink / raw) To: Jiri Kosina Cc: Linux Kernel Mailing List, Kernel Testers List, Guido, Remi Cattiau On Monday 08 June 2009, Jiri Kosina wrote: > On Sun, 7 Jun 2009, 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=13411 > > Subject : Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 > > Submitter : Guido <bugzilla.kernel.org-Dy4KJ/v5nlEVgfBnK23ub6xOck334EZe@public.gmane.org> > > Date : 2009-05-31 12:21 (8 days old) > > This is apparently caused by vendor releasing two different hardware > products under the same VID/PID and just one of them needing blacklist > entry. Sigh. Oh well. > Waiting for verbose lsusb output from Remi, so that we could compare it > with the output provided by the bug reporter, to see what else could be > done to distinguish the devices from each other. Thanks for the update. Best, Rafael ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 @ 2009-06-08 11:37 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-08 11:37 UTC (permalink / raw) To: Jiri Kosina Cc: Linux Kernel Mailing List, Kernel Testers List, Guido, Remi Cattiau On Monday 08 June 2009, Jiri Kosina wrote: > On Sun, 7 Jun 2009, 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=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) > > This is apparently caused by vendor releasing two different hardware > products under the same VID/PID and just one of them needing blacklist > entry. Sigh. Oh well. > Waiting for verbose lsusb output from Remi, so that we could compare it > with the output provided by the bug reporter, to see what else could be > done to distinguish the devices from each other. Thanks for the update. Best, Rafael ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13463] Poor SSD performance 2009-06-07 10:02 ` Rafael J. Wysocki @ 2009-06-07 10:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jake 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=13463 Subject : Poor SSD performance Submitter : Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org> Date : 2009-06-05 17:37 (3 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* [Bug #13463] Poor SSD performance @ 2009-06-07 10:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ messages in thread From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jake 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=13463 Subject : Poor SSD performance Submitter : Jake <ellowitz@uchicago.edu> Date : 2009-06-05 17:37 (3 days old) ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13463] Poor SSD performance 2009-06-07 10:06 ` Rafael J. Wysocki @ 2009-06-10 6:37 ` Wu Fengguang -1 siblings, 0 replies; 151+ messages in thread From: Wu Fengguang @ 2009-06-10 6:37 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Jake, tj-DgEjT+Ai2ygdnm+yROfE0A, Andrew Morton > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13463 > Subject : Poor SSD performance > Submitter : Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org> > Date : 2009-06-05 17:37 (3 days old) Hi Jake, Could you collect some blktrace data for the dd commands on new/old kernels? dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct dd if=/dev/sda of=/dev/null bs=1M count=1024 You need to install the blktrace tool and run these commands: cd /dev/shm blktrace /dev/sda # do this while dd is running # ^C to interrupt blkparse sda Package: blktrace Description: utilities for block layer IO tracing blktrace is a block layer IO tracing mechanism which provides detailed information about request queue operations up to user space. There are Thanks, Fengguang ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13463] Poor SSD performance @ 2009-06-10 6:37 ` Wu Fengguang 0 siblings, 0 replies; 151+ messages in thread From: Wu Fengguang @ 2009-06-10 6:37 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Jake, tj, Andrew Morton > 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) Hi Jake, Could you collect some blktrace data for the dd commands on new/old kernels? dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct dd if=/dev/sda of=/dev/null bs=1M count=1024 You need to install the blktrace tool and run these commands: cd /dev/shm blktrace /dev/sda # do this while dd is running # ^C to interrupt blkparse sda Package: blktrace Description: utilities for block layer IO tracing blktrace is a block layer IO tracing mechanism which provides detailed information about request queue operations up to user space. There are Thanks, Fengguang ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <20090611031153.GA7007@localhost>]
* Re: [Bug #13463] Poor SSD performance [not found] ` <20090611031153.GA7007@localhost> @ 2009-06-16 4:09 ` Jake Ellowitz 0 siblings, 0 replies; 151+ messages in thread From: Jake Ellowitz @ 2009-06-16 4:09 UTC (permalink / raw) To: Wu Fengguang Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, tj-DgEjT+Ai2ygdnm+yROfE0A, Andrew Morton, Jens Axboe Dear Fengguang, Thanks so much for the attention you paid to this problem. I did not want to respond until I got a chance to give the new kernel a shot to see if the bug was still present. It appears not to be -- hdparm and dd both register read speeds between 200 and 220 MB/s as opposed to the 70 to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange bug has sort of resolved itself. Best, Jake Wu Fengguang wrote: > On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote: > >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13463 >>> Subject : Poor SSD performance >>> Submitter : Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org> >>> Date : 2009-06-05 17:37 (3 days old) >>> >> Hi Jake, >> >> Could you collect some blktrace data for the dd commands on new/old >> kernels? >> >> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct >> dd if=/dev/sda of=/dev/null bs=1M count=1024 >> > > I managed to get a SanDisk SSD for testing, and observes that > > - one must increase read_ahead_kb to at least max_sectors_kb or better > "bs=1M" to make a fair comparison > - with increased readahead size, the dd reported throughputs are > 75MB/s vs 77MB/s, while the blktrace reported throughputs are > 75MB/s vs 75MB/s (buffered IO vs direct IO). > > Here are details. > > The dd throughputs are equal for rotational hard disks, but differs > for this SanDisk SSD (with default RA parameters): > > % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024 > 1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s > 1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s > > % dd if=/dev/sda of=/dev/null bs=1M count=1024 > 1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s > 1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s > > Here is the blktrace summary: > > dd dd-direct > -------------------------------------------------------------------------------------- > CPU0 (sda): | CPU0 (sda): > Reads Queued: 9,888, 39,552KiB | Reads Queued: 84, 43,008KiB > Read Dispatches: 302, 38,588KiB | Read Dispatches: 84, 43,008KiB > Reads Requeued: 0 | Reads Requeued: 0 > Reads Completed: 337, 44,600KiB | Reads Completed: 83, 42,496KiB > Read Merges: 9,574, 38,296KiB | Read Merges: 0, 0KiB > Read depth: 2 | Read depth: 2 > IO unplugs: 313 | IO unplugs: 42 > CPU1 (sda): | CPU1 (sda): > Reads Queued: 11,840, 47,360KiB | Reads Queued: 96, 49,152KiB > Read Dispatches: 372, 48,196KiB | Read Dispatches: 96, 49,152KiB > Reads Requeued: 0 | Reads Requeued: 0 > Reads Completed: 337, 42,312KiB | Reads Completed: 96, 49,152KiB > Read Merges: 11,479, 45,916KiB | Read Merges: 0, 0KiB > Read depth: 2 | Read depth: 2 > IO unplugs: 372 | IO unplugs: 48 > | > Total (sda): | Total (sda): > Reads Queued: 21,728, 86,912KiB | Reads Queued: 180, 92,160KiB > Read Dispatches: 674, 86,784KiB | Read Dispatches: 180, 92,160KiB > Reads Requeued: 0 | Reads Requeued: 0 > Reads Completed: 674, 86,912KiB | Reads Completed: 179, 91,648KiB > Read Merges: 21,053, 84,212KiB | Read Merges: 0, 0KiB > IO unplugs: 685 | IO unplugs: 90 > | > Throughput (R/W): 69,977KiB/s / 0KiB/s | Throughput (R/W): 75,368KiB/s / 0KiB/s > Events (sda): 46,804 entries | Events (sda): 1,158 entries > > > Another obvious difference is IO size. > One is read_ahead_kb=128K, another is max_sectors_kb=512K: > > dd: > 8,0 0 13497 0.804939305 0 C R 782592 + 256 [0] > 8,0 0 13498 0.806713692 0 C R 782848 + 256 [0] > 8,0 1 16275 0.808488708 0 C R 783104 + 256 [0] > 8,0 0 13567 0.810261350 0 C R 783360 + 256 [0] > 8,0 0 13636 0.812036226 0 C R 783616 + 256 [0] > 8,0 1 16344 0.813806353 0 C R 783872 + 256 [0] > 8,0 1 16413 0.815578436 0 C R 784128 + 256 [0] > 8,0 0 13705 0.817347935 0 C R 784384 + 256 [0] > > dd-direct: > 8,0 0 428 0.998831975 0 C R 357376 + 1024 [0] > 8,0 1 514 1.005683404 0 C R 358400 + 1024 [0] > 8,0 1 515 1.012402554 0 C R 359424 + 1024 [0] > 8,0 0 440 1.019303850 0 C R 360448 + 1024 [0] > 8,0 1 526 1.026024048 0 C R 361472 + 1024 [0] > 8,0 1 538 1.032875967 0 C R 362496 + 1024 [0] > 8,0 0 441 1.039595815 0 C R 363520 + 1024 [0] > > The non-direct dd throughput can improve with 512K and 1M readahead size, > but still a bit slower than the direct dd case: > 1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s > 1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s > > dd-512k dd-direct2 > ------------------------------------------------------------------------------------- > Total (sda): | Total (sda): > Reads Queued: 23,808, 95,232KiB | Reads Queued: 178, 91,136KiB > Read Dispatches: 215, 95,232KiB | Read Dispatches: 178, 91,136KiB > Reads Requeued: 0 | Reads Requeued: 0 > Reads Completed: 215, 95,232KiB | Reads Completed: 177, 90,624KiB > Read Merges: 23,593, 94,372KiB | Read Merges: 0, 0KiB > IO unplugs: 236 | IO unplugs: 89 > | > Throughput (R/W): 75,222KiB/s / 0KiB/s | Throughput (R/W): 75,520KiB/s / 0KiB/s > Events (sda): 48,687 entries | Events (sda): 1,145 entries > > Interestingly, the throughput reported by blktrace is almost the same, > whereas the dd report favors the dd-direct case. > > More parameters. > > [ 10.137350] scsi 3:0:0:0: Direct-Access ATA SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5 > [ 10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB) > [ 10.155060] sd 3:0:0:0: [sda] Write Protect is off > [ 10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [ 10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA > [ 10.174994] sda: > > > /dev/sda: > > Model=SanDisk SSD SATA 5000 2.5 , FwRev=1.13 , SerialNo= 81402200246 > Config={ Fixed } > RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 > BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1? > CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000 > IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} > PIO modes: pio0 pio1 pio2 pio3 pio4 > DMA modes: mdma0 mdma1 mdma2 > UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 > AdvancedPM=yes: disabled (255) WriteCache=disabled > Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7 > > * signifies the current active mode > > > /sys/block/sda/queue/nr_requests:128 > /sys/block/sda/queue/read_ahead_kb:128 > /sys/block/sda/queue/max_hw_sectors_kb:32767 > /sys/block/sda/queue/max_sectors_kb:512 > /sys/block/sda/queue/scheduler:noop [cfq] > /sys/block/sda/queue/hw_sector_size:512 > /sys/block/sda/queue/rotational:1 > /sys/block/sda/queue/nomerges:0 > /sys/block/sda/queue/rq_affinity:0 > /sys/block/sda/queue/iostats:1 > /sys/block/sda/queue/iosched/quantum:4 > /sys/block/sda/queue/iosched/fifo_expire_sync:124 > /sys/block/sda/queue/iosched/fifo_expire_async:248 > /sys/block/sda/queue/iosched/back_seek_max:16384 > /sys/block/sda/queue/iosched/back_seek_penalty:2 > /sys/block/sda/queue/iosched/slice_sync:100 > /sys/block/sda/queue/iosched/slice_async:40 > /sys/block/sda/queue/iosched/slice_async_rq:2 > /sys/block/sda/queue/iosched/slice_idle:8 > > Thanks, > Fengguang > ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13463] Poor SSD performance @ 2009-06-16 4:09 ` Jake Ellowitz 0 siblings, 0 replies; 151+ messages in thread From: Jake Ellowitz @ 2009-06-16 4:09 UTC (permalink / raw) To: Wu Fengguang Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, tj, Andrew Morton, Jens Axboe Dear Fengguang, Thanks so much for the attention you paid to this problem. I did not want to respond until I got a chance to give the new kernel a shot to see if the bug was still present. It appears not to be -- hdparm and dd both register read speeds between 200 and 220 MB/s as opposed to the 70 to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange bug has sort of resolved itself. Best, Jake Wu Fengguang wrote: > On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote: > >>> 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) >>> >> Hi Jake, >> >> Could you collect some blktrace data for the dd commands on new/old >> kernels? >> >> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct >> dd if=/dev/sda of=/dev/null bs=1M count=1024 >> > > I managed to get a SanDisk SSD for testing, and observes that > > - one must increase read_ahead_kb to at least max_sectors_kb or better > "bs=1M" to make a fair comparison > - with increased readahead size, the dd reported throughputs are > 75MB/s vs 77MB/s, while the blktrace reported throughputs are > 75MB/s vs 75MB/s (buffered IO vs direct IO). > > Here are details. > > The dd throughputs are equal for rotational hard disks, but differs > for this SanDisk SSD (with default RA parameters): > > % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024 > 1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s > 1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s > > % dd if=/dev/sda of=/dev/null bs=1M count=1024 > 1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s > 1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s > > Here is the blktrace summary: > > dd dd-direct > -------------------------------------------------------------------------------------- > CPU0 (sda): | CPU0 (sda): > Reads Queued: 9,888, 39,552KiB | Reads Queued: 84, 43,008KiB > Read Dispatches: 302, 38,588KiB | Read Dispatches: 84, 43,008KiB > Reads Requeued: 0 | Reads Requeued: 0 > Reads Completed: 337, 44,600KiB | Reads Completed: 83, 42,496KiB > Read Merges: 9,574, 38,296KiB | Read Merges: 0, 0KiB > Read depth: 2 | Read depth: 2 > IO unplugs: 313 | IO unplugs: 42 > CPU1 (sda): | CPU1 (sda): > Reads Queued: 11,840, 47,360KiB | Reads Queued: 96, 49,152KiB > Read Dispatches: 372, 48,196KiB | Read Dispatches: 96, 49,152KiB > Reads Requeued: 0 | Reads Requeued: 0 > Reads Completed: 337, 42,312KiB | Reads Completed: 96, 49,152KiB > Read Merges: 11,479, 45,916KiB | Read Merges: 0, 0KiB > Read depth: 2 | Read depth: 2 > IO unplugs: 372 | IO unplugs: 48 > | > Total (sda): | Total (sda): > Reads Queued: 21,728, 86,912KiB | Reads Queued: 180, 92,160KiB > Read Dispatches: 674, 86,784KiB | Read Dispatches: 180, 92,160KiB > Reads Requeued: 0 | Reads Requeued: 0 > Reads Completed: 674, 86,912KiB | Reads Completed: 179, 91,648KiB > Read Merges: 21,053, 84,212KiB | Read Merges: 0, 0KiB > IO unplugs: 685 | IO unplugs: 90 > | > Throughput (R/W): 69,977KiB/s / 0KiB/s | Throughput (R/W): 75,368KiB/s / 0KiB/s > Events (sda): 46,804 entries | Events (sda): 1,158 entries > > > Another obvious difference is IO size. > One is read_ahead_kb=128K, another is max_sectors_kb=512K: > > dd: > 8,0 0 13497 0.804939305 0 C R 782592 + 256 [0] > 8,0 0 13498 0.806713692 0 C R 782848 + 256 [0] > 8,0 1 16275 0.808488708 0 C R 783104 + 256 [0] > 8,0 0 13567 0.810261350 0 C R 783360 + 256 [0] > 8,0 0 13636 0.812036226 0 C R 783616 + 256 [0] > 8,0 1 16344 0.813806353 0 C R 783872 + 256 [0] > 8,0 1 16413 0.815578436 0 C R 784128 + 256 [0] > 8,0 0 13705 0.817347935 0 C R 784384 + 256 [0] > > dd-direct: > 8,0 0 428 0.998831975 0 C R 357376 + 1024 [0] > 8,0 1 514 1.005683404 0 C R 358400 + 1024 [0] > 8,0 1 515 1.012402554 0 C R 359424 + 1024 [0] > 8,0 0 440 1.019303850 0 C R 360448 + 1024 [0] > 8,0 1 526 1.026024048 0 C R 361472 + 1024 [0] > 8,0 1 538 1.032875967 0 C R 362496 + 1024 [0] > 8,0 0 441 1.039595815 0 C R 363520 + 1024 [0] > > The non-direct dd throughput can improve with 512K and 1M readahead size, > but still a bit slower than the direct dd case: > 1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s > 1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s > > dd-512k dd-direct2 > ------------------------------------------------------------------------------------- > Total (sda): | Total (sda): > Reads Queued: 23,808, 95,232KiB | Reads Queued: 178, 91,136KiB > Read Dispatches: 215, 95,232KiB | Read Dispatches: 178, 91,136KiB > Reads Requeued: 0 | Reads Requeued: 0 > Reads Completed: 215, 95,232KiB | Reads Completed: 177, 90,624KiB > Read Merges: 23,593, 94,372KiB | Read Merges: 0, 0KiB > IO unplugs: 236 | IO unplugs: 89 > | > Throughput (R/W): 75,222KiB/s / 0KiB/s | Throughput (R/W): 75,520KiB/s / 0KiB/s > Events (sda): 48,687 entries | Events (sda): 1,145 entries > > Interestingly, the throughput reported by blktrace is almost the same, > whereas the dd report favors the dd-direct case. > > More parameters. > > [ 10.137350] scsi 3:0:0:0: Direct-Access ATA SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5 > [ 10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB) > [ 10.155060] sd 3:0:0:0: [sda] Write Protect is off > [ 10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [ 10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA > [ 10.174994] sda: > > > /dev/sda: > > Model=SanDisk SSD SATA 5000 2.5 , FwRev=1.13 , SerialNo= 81402200246 > Config={ Fixed } > RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 > BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1? > CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000 > IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} > PIO modes: pio0 pio1 pio2 pio3 pio4 > DMA modes: mdma0 mdma1 mdma2 > UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 > AdvancedPM=yes: disabled (255) WriteCache=disabled > Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7 > > * signifies the current active mode > > > /sys/block/sda/queue/nr_requests:128 > /sys/block/sda/queue/read_ahead_kb:128 > /sys/block/sda/queue/max_hw_sectors_kb:32767 > /sys/block/sda/queue/max_sectors_kb:512 > /sys/block/sda/queue/scheduler:noop [cfq] > /sys/block/sda/queue/hw_sector_size:512 > /sys/block/sda/queue/rotational:1 > /sys/block/sda/queue/nomerges:0 > /sys/block/sda/queue/rq_affinity:0 > /sys/block/sda/queue/iostats:1 > /sys/block/sda/queue/iosched/quantum:4 > /sys/block/sda/queue/iosched/fifo_expire_sync:124 > /sys/block/sda/queue/iosched/fifo_expire_async:248 > /sys/block/sda/queue/iosched/back_seek_max:16384 > /sys/block/sda/queue/iosched/back_seek_penalty:2 > /sys/block/sda/queue/iosched/slice_sync:100 > /sys/block/sda/queue/iosched/slice_async:40 > /sys/block/sda/queue/iosched/slice_async_rq:2 > /sys/block/sda/queue/iosched/slice_idle:8 > > Thanks, > Fengguang > ^ permalink raw reply [flat|nested] 151+ messages in thread
[parent not found: <4A371AED.5080800-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>]
* Re: [Bug #13463] Poor SSD performance 2009-06-16 4:09 ` Jake Ellowitz @ 2009-06-16 12:28 ` Wu Fengguang -1 siblings, 0 replies; 151+ messages in thread From: Wu Fengguang @ 2009-06-16 12:28 UTC (permalink / raw) To: Jake Ellowitz Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Andrew Morton, Jens Axboe Hi Jake, On Tue, Jun 16, 2009 at 12:09:17PM +0800, Jake Ellowitz wrote: > Dear Fengguang, > > Thanks so much for the attention you paid to this problem. I did not > want to respond until I got a chance to give the new kernel a shot to > see if the bug was still present. It appears not to be -- hdparm and dd > both register read speeds between 200 and 220 MB/s as opposed to the 70 > to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange > bug has sort of resolved itself. That's great! (if convenient I'd recommend you to try the blktrace tool on 2.6.29, it's easy to use :) Thanks, Fengguang > Wu Fengguang wrote: > > On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote: > > > >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13463 > >>> Subject : Poor SSD performance > >>> Submitter : Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org> > >>> Date : 2009-06-05 17:37 (3 days old) > >>> > >> Hi Jake, > >> > >> Could you collect some blktrace data for the dd commands on new/old > >> kernels? > >> > >> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct > >> dd if=/dev/sda of=/dev/null bs=1M count=1024 > >> > > > > I managed to get a SanDisk SSD for testing, and observes that > > > > - one must increase read_ahead_kb to at least max_sectors_kb or better > > "bs=1M" to make a fair comparison > > - with increased readahead size, the dd reported throughputs are > > 75MB/s vs 77MB/s, while the blktrace reported throughputs are > > 75MB/s vs 75MB/s (buffered IO vs direct IO). > > > > Here are details. > > > > The dd throughputs are equal for rotational hard disks, but differs > > for this SanDisk SSD (with default RA parameters): > > > > % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024 > > 1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s > > 1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s > > > > % dd if=/dev/sda of=/dev/null bs=1M count=1024 > > 1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s > > 1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s > > > > Here is the blktrace summary: > > > > dd dd-direct > > -------------------------------------------------------------------------------------- > > CPU0 (sda): | CPU0 (sda): > > Reads Queued: 9,888, 39,552KiB | Reads Queued: 84, 43,008KiB > > Read Dispatches: 302, 38,588KiB | Read Dispatches: 84, 43,008KiB > > Reads Requeued: 0 | Reads Requeued: 0 > > Reads Completed: 337, 44,600KiB | Reads Completed: 83, 42,496KiB > > Read Merges: 9,574, 38,296KiB | Read Merges: 0, 0KiB > > Read depth: 2 | Read depth: 2 > > IO unplugs: 313 | IO unplugs: 42 > > CPU1 (sda): | CPU1 (sda): > > Reads Queued: 11,840, 47,360KiB | Reads Queued: 96, 49,152KiB > > Read Dispatches: 372, 48,196KiB | Read Dispatches: 96, 49,152KiB > > Reads Requeued: 0 | Reads Requeued: 0 > > Reads Completed: 337, 42,312KiB | Reads Completed: 96, 49,152KiB > > Read Merges: 11,479, 45,916KiB | Read Merges: 0, 0KiB > > Read depth: 2 | Read depth: 2 > > IO unplugs: 372 | IO unplugs: 48 > > | > > Total (sda): | Total (sda): > > Reads Queued: 21,728, 86,912KiB | Reads Queued: 180, 92,160KiB > > Read Dispatches: 674, 86,784KiB | Read Dispatches: 180, 92,160KiB > > Reads Requeued: 0 | Reads Requeued: 0 > > Reads Completed: 674, 86,912KiB | Reads Completed: 179, 91,648KiB > > Read Merges: 21,053, 84,212KiB | Read Merges: 0, 0KiB > > IO unplugs: 685 | IO unplugs: 90 > > | > > Throughput (R/W): 69,977KiB/s / 0KiB/s | Throughput (R/W): 75,368KiB/s / 0KiB/s > > Events (sda): 46,804 entries | Events (sda): 1,158 entries > > > > > > Another obvious difference is IO size. > > One is read_ahead_kb=128K, another is max_sectors_kb=512K: > > > > dd: > > 8,0 0 13497 0.804939305 0 C R 782592 + 256 [0] > > 8,0 0 13498 0.806713692 0 C R 782848 + 256 [0] > > 8,0 1 16275 0.808488708 0 C R 783104 + 256 [0] > > 8,0 0 13567 0.810261350 0 C R 783360 + 256 [0] > > 8,0 0 13636 0.812036226 0 C R 783616 + 256 [0] > > 8,0 1 16344 0.813806353 0 C R 783872 + 256 [0] > > 8,0 1 16413 0.815578436 0 C R 784128 + 256 [0] > > 8,0 0 13705 0.817347935 0 C R 784384 + 256 [0] > > > > dd-direct: > > 8,0 0 428 0.998831975 0 C R 357376 + 1024 [0] > > 8,0 1 514 1.005683404 0 C R 358400 + 1024 [0] > > 8,0 1 515 1.012402554 0 C R 359424 + 1024 [0] > > 8,0 0 440 1.019303850 0 C R 360448 + 1024 [0] > > 8,0 1 526 1.026024048 0 C R 361472 + 1024 [0] > > 8,0 1 538 1.032875967 0 C R 362496 + 1024 [0] > > 8,0 0 441 1.039595815 0 C R 363520 + 1024 [0] > > > > The non-direct dd throughput can improve with 512K and 1M readahead size, > > but still a bit slower than the direct dd case: > > 1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s > > 1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s > > > > dd-512k dd-direct2 > > ------------------------------------------------------------------------------------- > > Total (sda): | Total (sda): > > Reads Queued: 23,808, 95,232KiB | Reads Queued: 178, 91,136KiB > > Read Dispatches: 215, 95,232KiB | Read Dispatches: 178, 91,136KiB > > Reads Requeued: 0 | Reads Requeued: 0 > > Reads Completed: 215, 95,232KiB | Reads Completed: 177, 90,624KiB > > Read Merges: 23,593, 94,372KiB | Read Merges: 0, 0KiB > > IO unplugs: 236 | IO unplugs: 89 > > | > > Throughput (R/W): 75,222KiB/s / 0KiB/s | Throughput (R/W): 75,520KiB/s / 0KiB/s > > Events (sda): 48,687 entries | Events (sda): 1,145 entries > > > > Interestingly, the throughput reported by blktrace is almost the same, > > whereas the dd report favors the dd-direct case. > > > > More parameters. > > > > [ 10.137350] scsi 3:0:0:0: Direct-Access ATA SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5 > > [ 10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB) > > [ 10.155060] sd 3:0:0:0: [sda] Write Protect is off > > [ 10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00 > > [ 10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA > > [ 10.174994] sda: > > > > > > /dev/sda: > > > > Model=SanDisk SSD SATA 5000 2.5 , FwRev=1.13 , SerialNo= 81402200246 > > Config={ Fixed } > > RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 > > BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1? > > CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000 > > IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} > > PIO modes: pio0 pio1 pio2 pio3 pio4 > > DMA modes: mdma0 mdma1 mdma2 > > UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 > > AdvancedPM=yes: disabled (255) WriteCache=disabled > > Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7 > > > > * signifies the current active mode > > > > > > /sys/block/sda/queue/nr_requests:128 > > /sys/block/sda/queue/read_ahead_kb:128 > > /sys/block/sda/queue/max_hw_sectors_kb:32767 > > /sys/block/sda/queue/max_sectors_kb:512 > > /sys/block/sda/queue/scheduler:noop [cfq] > > /sys/block/sda/queue/hw_sector_size:512 > > /sys/block/sda/queue/rotational:1 > > /sys/block/sda/queue/nomerges:0 > > /sys/block/sda/queue/rq_affinity:0 > > /sys/block/sda/queue/iostats:1 > > /sys/block/sda/queue/iosched/quantum:4 > > /sys/block/sda/queue/iosched/fifo_expire_sync:124 > > /sys/block/sda/queue/iosched/fifo_expire_async:248 > > /sys/block/sda/queue/iosched/back_seek_max:16384 > > /sys/block/sda/queue/iosched/back_seek_penalty:2 > > /sys/block/sda/queue/iosched/slice_sync:100 > > /sys/block/sda/queue/iosched/slice_async:40 > > /sys/block/sda/queue/iosched/slice_async_rq:2 > > /sys/block/sda/queue/iosched/slice_idle:8 > > > > Thanks, > > Fengguang > > ^ permalink raw reply [flat|nested] 151+ messages in thread
* Re: [Bug #13463] Poor SSD performance @ 2009-06-16 12:28 ` Wu Fengguang 0 siblings, 0 replies; 151+ messages in thread From: Wu Fengguang @ 2009-06-16 12:28 UTC (permalink / raw) To: Jake Ellowitz Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, tj@kernel.org, Andrew Morton, Jens Axboe Hi Jake, On Tue, Jun 16, 2009 at 12:09:17PM +0800, Jake Ellowitz wrote: > Dear Fengguang, > > Thanks so much for the attention you paid to this problem. I did not > want to respond until I got a chance to give the new kernel a shot to > see if the bug was still present. It appears not to be -- hdparm and dd > both register read speeds between 200 and 220 MB/s as opposed to the 70 > to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange > bug has sort of resolved itself. That's great! (if convenient I'd recommend you to try the blktrace tool on 2.6.29, it's easy to use :) Thanks, Fengguang > Wu Fengguang wrote: > > On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote: > > > >>> 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) > >>> > >> Hi Jake, > >> > >> Could you collect some blktrace data for the dd commands on new/old > >> kernels? > >> > >> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct > >> dd if=/dev/sda of=/dev/null bs=1M count=1024 > >> > > > > I managed to get a SanDisk SSD for testing, and observes that > > > > - one must increase read_ahead_kb to at least max_sectors_kb or better > > "bs=1M" to make a fair comparison > > - with increased readahead size, the dd reported throughputs are > > 75MB/s vs 77MB/s, while the blktrace reported throughputs are > > 75MB/s vs 75MB/s (buffered IO vs direct IO). > > > > Here are details. > > > > The dd throughputs are equal for rotational hard disks, but differs > > for this SanDisk SSD (with default RA parameters): > > > > % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024 > > 1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s > > 1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s > > > > % dd if=/dev/sda of=/dev/null bs=1M count=1024 > > 1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s > > 1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s > > > > Here is the blktrace summary: > > > > dd dd-direct > > -------------------------------------------------------------------------------------- > > CPU0 (sda): | CPU0 (sda): > > Reads Queued: 9,888, 39,552KiB | Reads Queued: 84, 43,008KiB > > Read Dispatches: 302, 38,588KiB | Read Dispatches: 84, 43,008KiB > > Reads Requeued: 0 | Reads Requeued: 0 > > Reads Completed: 337, 44,600KiB | Reads Completed: 83, 42,496KiB > > Read Merges: 9,574, 38,296KiB | Read Merges: 0, 0KiB > > Read depth: 2 | Read depth: 2 > > IO unplugs: 313 | IO unplugs: 42 > > CPU1 (sda): | CPU1 (sda): > > Reads Queued: 11,840, 47,360KiB | Reads Queued: 96, 49,152KiB > > Read Dispatches: 372, 48,196KiB | Read Dispatches: 96, 49,152KiB > > Reads Requeued: 0 | Reads Requeued: 0 > > Reads Completed: 337, 42,312KiB | Reads Completed: 96, 49,152KiB > > Read Merges: 11,479, 45,916KiB | Read Merges: 0, 0KiB > > Read depth: 2 | Read depth: 2 > > IO unplugs: 372 | IO unplugs: 48 > > | > > Total (sda): | Total (sda): > > Reads Queued: 21,728, 86,912KiB | Reads Queued: 180, 92,160KiB > > Read Dispatches: 674, 86,784KiB | Read Dispatches: 180, 92,160KiB > > Reads Requeued: 0 | Reads Requeued: 0 > > Reads Completed: 674, 86,912KiB | Reads Completed: 179, 91,648KiB > > Read Merges: 21,053, 84,212KiB | Read Merges: 0, 0KiB > > IO unplugs: 685 | IO unplugs: 90 > > | > > Throughput (R/W): 69,977KiB/s / 0KiB/s | Throughput (R/W): 75,368KiB/s / 0KiB/s > > Events (sda): 46,804 entries | Events (sda): 1,158 entries > > > > > > Another obvious difference is IO size. > > One is read_ahead_kb=128K, another is max_sectors_kb=512K: > > > > dd: > > 8,0 0 13497 0.804939305 0 C R 782592 + 256 [0] > > 8,0 0 13498 0.806713692 0 C R 782848 + 256 [0] > > 8,0 1 16275 0.808488708 0 C R 783104 + 256 [0] > > 8,0 0 13567 0.810261350 0 C R 783360 + 256 [0] > > 8,0 0 13636 0.812036226 0 C R 783616 + 256 [0] > > 8,0 1 16344 0.813806353 0 C R 783872 + 256 [0] > > 8,0 1 16413 0.815578436 0 C R 784128 + 256 [0] > > 8,0 0 13705 0.817347935 0 C R 784384 + 256 [0] > > > > dd-direct: > > 8,0 0 428 0.998831975 0 C R 357376 + 1024 [0] > > 8,0 1 514 1.005683404 0 C R 358400 + 1024 [0] > > 8,0 1 515 1.012402554 0 C R 359424 + 1024 [0] > > 8,0 0 440 1.019303850 0 C R 360448 + 1024 [0] > > 8,0 1 526 1.026024048 0 C R 361472 + 1024 [0] > > 8,0 1 538 1.032875967 0 C R 362496 + 1024 [0] > > 8,0 0 441 1.039595815 0 C R 363520 + 1024 [0] > > > > The non-direct dd throughput can improve with 512K and 1M readahead size, > > but still a bit slower than the direct dd case: > > 1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s > > 1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s > > > > dd-512k dd-direct2 > > ------------------------------------------------------------------------------------- > > Total (sda): | Total (sda): > > Reads Queued: 23,808, 95,232KiB | Reads Queued: 178, 91,136KiB > > Read Dispatches: 215, 95,232KiB | Read Dispatches: 178, 91,136KiB > > Reads Requeued: 0 | Reads Requeued: 0 > > Reads Completed: 215, 95,232KiB | Reads Completed: 177, 90,624KiB > > Read Merges: 23,593, 94,372KiB | Read Merges: 0, 0KiB > > IO unplugs: 236 | IO unplugs: 89 > > | > > Throughput (R/W): 75,222KiB/s / 0KiB/s | Throughput (R/W): 75,520KiB/s / 0KiB/s > > Events (sda): 48,687 entries | Events (sda): 1,145 entries > > > > Interestingly, the throughput reported by blktrace is almost the same, > > whereas the dd report favors the dd-direct case. > > > > More parameters. > > > > [ 10.137350] scsi 3:0:0:0: Direct-Access ATA SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5 > > [ 10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB) > > [ 10.155060] sd 3:0:0:0: [sda] Write Protect is off > > [ 10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00 > > [ 10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA > > [ 10.174994] sda: > > > > > > /dev/sda: > > > > Model=SanDisk SSD SATA 5000 2.5 , FwRev=1.13 , SerialNo= 81402200246 > > Config={ Fixed } > > RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 > > BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1? > > CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000 > > IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} > > PIO modes: pio0 pio1 pio2 pio3 pio4 > > DMA modes: mdma0 mdma1 mdma2 > > UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 > > AdvancedPM=yes: disabled (255) WriteCache=disabled > > Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7 > > > > * signifies the current active mode > > > > > > /sys/block/sda/queue/nr_requests:128 > > /sys/block/sda/queue/read_ahead_kb:128 > > /sys/block/sda/queue/max_hw_sectors_kb:32767 > > /sys/block/sda/queue/max_sectors_kb:512 > > /sys/block/sda/queue/scheduler:noop [cfq] > > /sys/block/sda/queue/hw_sector_size:512 > > /sys/block/sda/queue/rotational:1 > > /sys/block/sda/queue/nomerges:0 > > /sys/block/sda/queue/rq_affinity:0 > > /sys/block/sda/queue/iostats:1 > > /sys/block/sda/queue/iosched/quantum:4 > > /sys/block/sda/queue/iosched/fifo_expire_sync:124 > > /sys/block/sda/queue/iosched/fifo_expire_async:248 > > /sys/block/sda/queue/iosched/back_seek_max:16384 > > /sys/block/sda/queue/iosched/back_seek_penalty:2 > > /sys/block/sda/queue/iosched/slice_sync:100 > > /sys/block/sda/queue/iosched/slice_async:40 > > /sys/block/sda/queue/iosched/slice_async_rq:2 > > /sys/block/sda/queue/iosched/slice_idle:8 > > > > Thanks, > > Fengguang > > ^ permalink raw reply [flat|nested] 151+ 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; 151+ messages in thread From: Rafael J. Wysocki @ 2009-05-30 19:50 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List, Natalie Protasevich, Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List This message contains a list of some regressions introduced between 2.6.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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ messages in thread
* 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29 @ 2009-05-16 19:58 Rafael J. Wysocki 2009-05-16 20:06 ` Rafael J. Wysocki 0 siblings, 1 reply; 151+ 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] 151+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix 2009-05-16 19:58 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki @ 2009-05-16 20:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ messages in thread
[parent not found: <20090518132517.GL32019-3s7WtUTddSA@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix 2009-05-18 13:25 ` Theodore Tso @ 2009-05-19 17:17 ` David Watson -1 siblings, 0 replies; 151+ 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] 151+ 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; 151+ 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] 151+ messages in thread
[parent not found: <20090519171713.GA3354-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix 2009-05-19 17:17 ` David Watson @ 2009-05-19 17:53 ` Theodore Tso -1 siblings, 0 replies; 151+ 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] 151+ 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; 151+ 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] 151+ 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 [not found] ` <18962.64002.324970.49512-HgN6juyGXH5AfugRpC6u6w@public.gmane.org> -1 siblings, 1 reply; 151+ 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] 151+ messages in thread
[parent not found: <18962.64002.324970.49512-HgN6juyGXH5AfugRpC6u6w@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix 2009-05-19 18:27 ` John Stoffel @ 2009-05-19 20:41 ` Theodore Tso 0 siblings, 0 replies; 151+ 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] 151+ 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; 151+ 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] 151+ messages in thread
[parent not found: <20090519204152.GE9053-3s7WtUTddSA@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix 2009-05-19 20:41 ` Theodore Tso @ 2009-05-20 16:53 ` John Stoffel -1 siblings, 0 replies; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ 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; 151+ 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] 151+ messages in thread
end of thread, other threads:[~2009-07-20 18:11 UTC | newest]
Thread overview: 151+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-07 10:02 2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-06-07 10:02 ` Rafael J. Wysocki
2009-06-07 10:03 ` [Bug #12490] ath5k related kernel panic in 2.6.29-rc1 Rafael J. Wysocki
2009-06-07 10:03 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12899] Crash in i915.ko: i915_driver_irq_handler Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12681] s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled) Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12705] X200: Brightness broken since 2.6.29-rc4-58-g4c098bc Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12909] boot/kernel init duration regression from 2.6.28 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12765] i915 VT switch with AIGLX causes X lock up Rafael J. Wysocki
2009-06-28 20:11 ` Sitsofe Wheeler
2009-06-28 20:11 ` Sitsofe Wheeler
2009-07-20 18:11 ` Jesse Barnes
2009-06-07 10:06 ` [Bug #12971] "tg3 transmit timed out" when transmitting at high bitrate Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13001] PCI-DMA: Out of IOMMU space Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12980] lockup in X.org Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13024] nozomi: pppd fails on kernel 2.6.29 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13017] ATA bus errors on resume Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13072] forcedeth seems to switch off eth on shutdown Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 17:14 ` Robert Hancock
[not found] ` <4A2BF577.1050003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-06-07 20:50 ` Rafael J. Wysocki
2009-06-07 20:50 ` Rafael J. Wysocki
2009-06-07 17:14 ` Robert Hancock
2009-06-07 10:06 ` [Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13074] gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840) Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13144] resume from suspend fails using video card i915 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming Rafael J. Wysocki
2009-06-07 10:06 ` 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
[not found] ` <20090607171418.GA22756-3s7WtUTddSA@public.gmane.org>
2009-06-07 17:17 ` Al Viro
2009-06-07 17:17 ` Al Viro
[not found] ` <20090607171739.GI8633-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2009-06-07 20:10 ` Theodore Tso
2009-06-07 20:10 ` Theodore Tso
2009-06-07 10:06 ` [Bug #13225] [2.6.29 regression] Software suspend no longer works Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13178] Booting very slow Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-08 8:46 ` Martin Knoblauch
2009-06-08 8:46 ` Martin Knoblauch
[not found] ` <712849.19962.qm-VAEUvbQToQWvuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2009-06-08 11:12 ` Rafael J. Wysocki
2009-06-08 11:12 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13294] i915: drm: xorg leaks drm objects massively Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 13:50 ` Sergei Trofimovich
2009-06-07 13:50 ` Sergei Trofimovich
[not found] ` <20090607165018.4c946a30-b59k1isJxu/84SrubaaLTA@public.gmane.org>
2009-06-07 21:00 ` Rafael J. Wysocki
2009-06-07 21:00 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13339] rtable leak in ipv4/route.c Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13371] s2disk hangs with e100, kernel 2.6.29 and later Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 20:09 ` Mike Dresser
2009-06-07 20:09 ` Mike Dresser
[not found] ` <alpine.DEB.1.10.0906071608010.3914-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>
2009-06-08 7:27 ` Mathias Kretschmer
2009-06-08 7:27 ` Mathias Kretschmer
[not found] ` <200906080927.10479.posting-ZcF2+9dVbKo@public.gmane.org>
2009-06-08 7:40 ` Mathias Kretschmer
2009-06-08 7:40 ` Mathias Kretschmer
[not found] ` <200906080940.14650.posting-ZcF2+9dVbKo@public.gmane.org>
2009-06-09 19:02 ` Mike Dresser
2009-06-09 19:02 ` Mike Dresser
[not found] ` <alpine.DEB.1.10.0906091457510.28108-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>
2009-06-09 19:11 ` Mathias Kretschmer
2009-06-09 19:11 ` Mathias Kretschmer
[not found] ` <200906092111.54073.mathias-ZcF2+9dVbKo@public.gmane.org>
2009-06-09 19:16 ` Mike Dresser
2009-06-09 19:16 ` Mike Dresser
2009-06-09 19:22 ` Mike Dresser
2009-06-09 19:22 ` Mike Dresser
[not found] ` <alpine.DEB.1.10.0906091521470.9067-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>
2009-06-15 17:25 ` Mike Dresser
2009-06-15 17:25 ` Mike Dresser
2009-06-18 21:55 ` Mathias Kretschmer
2009-06-18 21:55 ` Mathias Kretschmer
[not found] ` <200906182355.57100.mathias-ZcF2+9dVbKo@public.gmane.org>
2009-06-19 15:16 ` Mike Dresser
2009-06-19 15:16 ` Mike Dresser
2009-06-24 22:55 ` Mike Dresser
2009-06-24 22:55 ` Mike Dresser
[not found] ` <4A42AEEC.9070002-d1V2JtDI1HZNJje9z4SY99BPR1lH4CV8@public.gmane.org>
2009-06-25 6:14 ` Mathias Kretschmer
2009-06-25 6:14 ` Mathias Kretschmer
2009-06-07 10:06 ` [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-08 11:04 ` Jiri Kosina
2009-06-08 11:04 ` Jiri Kosina
[not found] ` <alpine.LNX.2.00.0906081302010.7457-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2009-06-08 11:37 ` Rafael J. Wysocki
2009-06-08 11:37 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13463] Poor SSD performance Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-10 6:37 ` Wu Fengguang
2009-06-10 6:37 ` Wu Fengguang
[not found] ` <20090611031153.GA7007@localhost>
2009-06-16 4:09 ` Jake Ellowitz
2009-06-16 4:09 ` Jake Ellowitz
[not found] ` <4A371AED.5080800-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>
2009-06-16 12:28 ` Wu Fengguang
2009-06-16 12:28 ` Wu Fengguang
-- strict thread matches above, loose matches on Subject: below --
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-16 19:58 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29 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
[not found] ` <20090518132517.GL32019-3s7WtUTddSA@public.gmane.org>
2009-05-19 17:17 ` David Watson
2009-05-19 17:17 ` David Watson
[not found] ` <20090519171713.GA3354-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
2009-05-19 17:53 ` Theodore Tso
2009-05-19 17:53 ` Theodore Tso
2009-05-19 18:27 ` John Stoffel
[not found] ` <18962.64002.324970.49512-HgN6juyGXH5AfugRpC6u6w@public.gmane.org>
2009-05-19 20:41 ` Theodore Tso
2009-05-19 20:41 ` Theodore Tso
[not found] ` <20090519204152.GE9053-3s7WtUTddSA@public.gmane.org>
2009-05-20 16:53 ` John Stoffel
2009-05-20 16:53 ` John Stoffel
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.