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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject : rtable leak in ipv4/route.c
Submitter : Alexander V. Lukyanov <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2009-03-25 5:19 (75 days old)
References : http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By : Tejun Heo <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2009-03-29 18:02 (71 days old)
Handled-By : Matt Carlson <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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
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 <[email protected]>
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 <[email protected]>
Patch : http://patchwork.kernel.org/patch/28210/
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 <[email protected]>
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 <[email protected]>
Patch : http://patchwork.kernel.org/patch/20197/
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2009-03-25 5:19 (75 days old)
References : http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By : Tejun Heo <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2009-03-29 18:02 (71 days old)
Handled-By : Matt Carlson <[email protected]>
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 <[email protected]>
Date : 2009-03-16 10:25 (84 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
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 <[email protected]>
Date : 2009-03-20 07:13 (80 days old)
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 : <[email protected]>
Date : 2009-04-03 09:30 (66 days old)
References : http://lkml.org/lkml/2009/4/28/133
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 <[email protected]>
Date : 2009-04-12 14:10 (57 days old)
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 <[email protected]>
Date : 2009-04-24 12:45 (45 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
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 <[email protected]>
Date : 2009-04-06 19:47 (63 days old)
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2009-04-22 14:39 (47 days old)
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 <[email protected]>
Date : 2009-05-03 19:46 (36 days old)
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 <[email protected]>
Date : 2009-05-08 08:48 (31 days old)
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 <[email protected]>
Date : 2009-04-12 07:00 (57 days old)
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 <[email protected]>
Date : 2009-04-06 19:12 (63 days old)
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 <[email protected]>
Date : 2009-03-31 08:58 (69 days old)
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 <[email protected]>
Date : 2009-04-21 17:03 (48 days old)
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 <[email protected]>
Date : 2009-05-02 21:41 (37 days old)
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 <[email protected]>
Date : 2009-05-18 14:10 (21 days old)
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 <[email protected]>
Date : 2009-05-20 0:37 (19 days old)
References : http://marc.info/?l=linux-kernel&m=124278675503699&w=4
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 <[email protected]>
Date : 2009-06-05 17:37 (3 days old)
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 <[email protected]>
Date : 2009-05-31 12:21 (8 days old)
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2009-05-10 19:56 (29 days old)
References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4
On Sun, 7 Jun 2009 12:06:23 +0200 (CEST)
"Rafael J. Wysocki" <[email protected]> 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 <[email protected]>
> 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
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 <[email protected]>
> 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
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 <[email protected]>
> 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
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 <[email protected]>
> > 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.
> 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
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 <[email protected]>
> > > 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 [email protected], or shall I?
- Ted
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 <[email protected]>
> > 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
On Sunday 07 June 2009, Sergei Trofimovich wrote:
> On Sun, 7 Jun 2009 12:06:23 +0200 (CEST)
> "Rafael J. Wysocki" <[email protected]> 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 <[email protected]>
> > 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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 [email protected]
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
----- Original Message ----
> From: Rafael J. Wysocki <[email protected]>
> To: Linux Kernel Mailing List <[email protected]>
> Cc: Kernel Testers List <[email protected]>; Jesse Barnes <[email protected]>; Martin Knoblauch <[email protected]>; Stephen Hemminger <[email protected]>
> 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
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 <[email protected]>
> 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
On Monday 08 June 2009, Martin Knoblauch wrote:
>
> ----- Original Message ----
>
> > From: Rafael J. Wysocki <[email protected]>
> > To: Linux Kernel Mailing List <[email protected]>
> > Cc: Kernel Testers List <[email protected]>; Jesse Barnes <[email protected]>; Martin Knoblauch <[email protected]>; Stephen Hemminger <[email protected]>
> > 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
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 <[email protected]>
> > 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
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
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
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.
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
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13463
> Subject : Poor SSD performance
> Submitter : Jake <[email protected]>
> 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
2.6.30-rc8 still has issues, even with swapoff -a, it still died in kswapd0
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 <[email protected]>
>>> 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
>
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 <[email protected]>
> >>> 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
> >
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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.
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
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
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 <[email protected]>
> 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 <[email protected]>
> 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/
On Sun, 28 Jun 2009 21:11:30 +0100
Sitsofe Wheeler <[email protected]> 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 <[email protected]>
> > 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
> > <[email protected]> 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