2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29

2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29

[Rafael J. Wysocki]

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

[Bug #12490] ath5k related kernel panic in 2.6.29-rc1

[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=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/

[Bug #12765] i915 VT switch with AIGLX causes X lock up

[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=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 #12681] s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)

[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=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>

[Bug #12705] X200: Brightness broken since 2.6.29-rc4-58-g4c098bc

[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=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 #12971] "tg3 transmit timed out" when transmitting at high bitrate

[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=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 #12909] boot/kernel init duration regression from 2.6.28

[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=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 #12899] Crash in i915.ko: i915_driver_irq_handler

[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=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 #13017] ATA bus errors on resume

[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=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 #13001] PCI-DMA: Out of IOMMU space

[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=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 #13024] nozomi: pppd fails on kernel 2.6.29

[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=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 #12980] lockup in X.org

[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=12980
Subject		: lockup in X.org
Submitter	: Marcus Better <marcus@better.se>
Date		: 2009-03-31 08:58 (69 days old)

[Bug #13074] gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)

[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=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 #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error

[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=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 #13072] forcedeth seems to switch off eth on shutdown

[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=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 #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G

[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>

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of 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)

[Bug #13144] resume from suspend fails using video card i915

[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=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 #13178] Booting very slow

[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=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 #13232] ext3/4 with synchronous writes gets wedged by Postfix

[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=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 #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming

[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=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 #13225] [2.6.29 regression] Software suspend no longer works

[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=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 #13339] rtable leak in ipv4/route.c

[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=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 #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[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=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 #13371] s2disk hangs with e100, kernel 2.6.29 and later

[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=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 #13294] i915: drm: xorg leaks drm objects massively

[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=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 #13463] Poor SSD performance

[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=13463
Subject		: Poor SSD performance
Submitter	: Jake <ellowitz@uchicago.edu>
Date		: 2009-06-05 17:37 (3 days old)

[Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[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=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)

Re: [Bug #13294] i915: drm: xorg leaks drm objects massively

[Sergei Trofimovich]

[-- 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 --]

Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix

[Theodore Tso]

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

Re: [Bug #13072] forcedeth seems to switch off eth on shutdown

[Robert Hancock]

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

Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix

[Al Viro]

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.

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mike Dresser]

> 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

Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix

[Theodore Tso]

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

Re: [Bug #13072] forcedeth seems to switch off eth on shutdown

[Rafael J. Wysocki]

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

Re: [Bug #13294] i915: drm: xorg leaks drm objects massively

[Rafael J. Wysocki]

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

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mathias Kretschmer]

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/

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mathias Kretschmer]

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/

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- 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

Re: [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Jiri Kosina]

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

Re: [Bug #13178] Booting very slow

[Rafael J. Wysocki]

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

Re: [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Rafael J. Wysocki]

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

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mike Dresser]

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

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mathias Kretschmer]

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

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mike Dresser]

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.

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mike Dresser]

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

Re: [Bug #13463] Poor SSD performance

[Wu Fengguang]

> 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

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mike Dresser]

2.6.30-rc8 still has issues, even with swapoff -a, it still died in kswapd0

Re: [Bug #13463] Poor SSD performance

[Jake Ellowitz]

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
>   

Re: [Bug #13463] Poor SSD performance

[Wu 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 <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
> >   

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mathias Kretschmer]

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/

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mike Dresser]

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.

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mike Dresser]

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

Re: [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree)

[Mathias Kretschmer]

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

Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up

[Sitsofe Wheeler]

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/

Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up

[Jesse Barnes]

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

Re: [Bug 13178] Booting very slow

[Rafael J. Wysocki]

On Monday 01 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: Saturday, May 30, 2009 9:55:37 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 (37 days old)
> > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> 
>  We (HP and myself) are trying to track it down.

OK, thanks for the update.

Rafael

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- 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: Saturday, May 30, 2009 9:55:37 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 (37 days old)
> References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4

 We (HP and myself) are trying to track it down.

Cheers
Martin

[Bug #13178] Booting very slow

[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=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

Re: [Bug #13178] Booting very slow

[Rafael J. Wysocki]

On Wednesday 27 May 2009, Andrew Morton wrote:
> On Tue, 26 May 2009 01:04:04 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Monday 25 May 2009, Martin Knoblauch wrote:
> > > 
> > > ----- Original Message ----
> > > 
> > > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > > To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > > > Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> > > > Sent: Sunday, May 24, 2009 9:31:18 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 (31 days old)
> > > > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> > > 
> > >  Still happens with 2.6.30-rc7. But see my comment on bz. I would be willing to leave this as "fuzzy timing related problem.
> > 
> > OK
> > 
> > I've closed it as "unreproducible".
> > 
> 
> afacit this should remain open.  It's a reproducible regression on one
> of Martin's machines and it has been bisected down to a particular
> commit which quite clearly has the potential to increase device
> intialisation times by a lot.  Especially if that commit was buggy.

OK, reopened.

Re: [Bug #13178] Booting very slow

[Andrew Morton]

On Tue, 26 May 2009 01:04:04 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Monday 25 May 2009, Martin Knoblauch wrote:
> > 
> > ----- Original Message ----
> > 
> > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > > Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> > > Sent: Sunday, May 24, 2009 9:31:18 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 (31 days old)
> > > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> > 
> >  Still happens with 2.6.30-rc7. But see my comment on bz. I would be willing to leave this as "fuzzy timing related problem.
> 
> OK
> 
> I've closed it as "unreproducible".
> 

afacit this should remain open.  It's a reproducible regression on one
of Martin's machines and it has been bisected down to a particular
commit which quite clearly has the potential to increase device
intialisation times by a lot.  Especially if that commit was buggy.

Re: [Bug #13178] Booting very slow

[Rafael J. Wysocki]

On Monday 25 May 2009, Martin Knoblauch wrote:
> 
> ----- Original Message ----
> 
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> > To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> > Sent: Sunday, May 24, 2009 9:31:18 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 (31 days old)
> > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> 
>  Still happens with 2.6.30-rc7. But see my comment on bz. I would be willing to leave this as "fuzzy timing related problem.

OK

I've closed it as "unreproducible".

Thanks,
Rafael

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- Original Message ----

> From: Rafael J. Wysocki <rjw@sisk.pl>
> To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> Sent: Sunday, May 24, 2009 9:31:18 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 (31 days old)
> References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4

 Still happens with 2.6.30-rc7. But see my comment on bz. I would be willing to leave this as "fuzzy timing related problem.

Cheers
Martin

[Bug #13178] Booting very slow

[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=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

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

 ------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de



----- Original Message ----
> From: Kay Sievers <kay.sievers@vrfy.org>
> To: Martin Knoblauch <spamtrap@knobisoft.de>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Kernel Testers List <kernel-testers@vger.kernel.org>
> Sent: Tuesday, May 19, 2009 10:58:24 AM
> Subject: Re: [Bug #13178] Booting very slow
> 
> On Tue, May 19, 2009 at 09:22, Martin Knoblauch wrote:
> >> >  The issue is still open. It turns out that starting with 2.6.29-rc1
> >> /proc/mounts already has a "sysfs" line when entering the startup scripts 
> from
> >> initrd. This breaks the RHEL4 firmware hotplug script.
> >>
> >> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
> >> leaves the sysfs entry in /proc/mounts behind, which then shows up as
> >> a duplicate when running in the real rootfs?
> >
> >  could be. Remains the question, why it never showed up before 2.6.29. I 
> compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the 
> module-binaries.
> 
> I wouldn't be surprised if we are just "too fast" again now with the
> async stuff, for another piece of rather fragile userspace bootup
> logic, making some wrong assumptions. Are you compiling-in the modules
> for the root disk and the root filesystem?
> 
> Cheers,
> Kay

 timing may actually be the answer. I finally manged to bisect the thing and the first bad commit is this one:

|commit 1120f8b8169fb2cb51219d326892d963e762edb6
|Author: Stephen Hemminger <shemminger@vyatta.com>
|Date:   Thu Dec 18 09:17:16 2008 -0800
|
|    PCI: handle long delays in VPD access
|
|    Accessing the VPD area can take a long time.  The existing
|    VPD access code fails consistently on my hardware. There are comments
|
|    Change the access routines to:
|      * use a mutex rather than spinning with IRQ's disabled and lock held
|      * have a much longer timeout
|      * call cond_resched while spinning
|
|    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
|    Reviewed-by: Matthew Wilcox <willy@linux.intel.com>
|    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

  And no, the "cciss", "ext3" and "jbd" are modules in my intrd image.

 I will continue the discussion under the original topic.

Cheers

Re: [Bug #13178] Booting very slow

[Kay Sievers]

On Tue, May 19, 2009 at 09:22, Martin Knoblauch <spamtrap@knobisoft.de> wrote:
>> >  The issue is still open. It turns out that starting with 2.6.29-rc1
>> /proc/mounts already has a "sysfs" line when entering the startup scripts from
>> initrd. This breaks the RHEL4 firmware hotplug script.
>>
>> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
>> leaves the sysfs entry in /proc/mounts behind, which then shows up as
>> a duplicate when running in the real rootfs?
>
>  could be. Remains the question, why it never showed up before 2.6.29. I compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the module-binaries.

I wouldn't be surprised if we are just "too fast" again now with the
async stuff, for another piece of rather fragile userspace bootup
logic, making some wrong assumptions. Are you compiling-in the modules
for the root disk and the root filesystem?

Cheers,
Kay

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- Original Message ----

> From: Kay Sievers <kay.sievers@vrfy.org>
> To: Martin Knoblauch <spamtrap@knobisoft.de>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Kernel Testers List <kernel-testers@vger.kernel.org>
> Sent: Tuesday, May 19, 2009 2:26:04 AM
> Subject: Re: [Bug #13178] Booting very slow
> 
> On Mon, May 18, 2009 at 10:15, Martin Knoblauch wrote:
> 
> >> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13178
> >> Subject        : Booting very slow
> >> Submitter    : Martin Knoblauch
> >> Date        : 2009-04-24 12:45 (23 days old)
> >> References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> >
> >  The issue is still open. It turns out that starting with 2.6.29-rc1 
> /proc/mounts already has a "sysfs" line when entering the startup scripts from 
> initrd. This breaks the RHEL4 firmware hotplug script.
> 
> Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
> leaves the sysfs entry in /proc/mounts behind, which then shows up as
> a duplicate when running in the real rootfs?
> 

 could be. Remains the question, why it never showed up before 2.6.29. I compared my initrd images for 2.6.28 and 2.6.29-rc1, and they only differ in the module-binaries.

Cheers
Martin

Re: [Bug #13178] Booting very slow

[Kay Sievers]

On Mon, May 18, 2009 at 10:15, Martin Knoblauch <spamtrap@knobisoft.de> wrote:

>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13178
>> Subject        : Booting very slow
>> Submitter    : Martin Knoblauch
>> Date        : 2009-04-24 12:45 (23 days old)
>> References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
>
>  The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.

Is that possibly a missing/failing "umount /sys" _in_ initramfs, which
leaves the sysfs entry in /proc/mounts behind, which then shows up as
a duplicate when running in the real rootfs?

Thanks,
Kay

Re: [Bug #13178] Booting very slow

[Rafael J. Wysocki]

On Monday 18 May 2009, Martin Knoblauch wrote:
> 
> ----- Original Message ----
> 
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> > To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> > Sent: Saturday, May 16, 2009 10:06:02 PM
> > Subject: [Bug #13178] Booting very slow
> > 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13178
> > Subject        : Booting very slow
> > Submitter    : Martin Knoblauch 
> > Date        : 2009-04-24 12:45 (23 days old)
> > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> 
>  The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.
> 
> Simple fix to user space is available. I do not know how important this issue is.
> 
> Anyway, I am in the process of bisecting the problem. It is just a bit tedious in the my customers and employers environment :-(

Thanks a lot for doing this.

Best,
Rafael

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- Original Message ----

> From: Rafael J. Wysocki <rjw@sisk.pl>
> To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> Sent: Saturday, May 16, 2009 10:06:02 PM
> Subject: [Bug #13178] Booting very slow
> 
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13178
> Subject        : Booting very slow
> Submitter    : Martin Knoblauch 
> Date        : 2009-04-24 12:45 (23 days old)
> References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4

 The issue is still open. It turns out that starting with 2.6.29-rc1 /proc/mounts already has a "sysfs" line when entering the startup scripts from initrd. This breaks the RHEL4 firmware hotplug script.

Simple fix to user space is available. I do not know how important this issue is.

Anyway, I am in the process of bisecting the problem. It is just a bit tedious in the my customers and employers environment :-(

Cheers
Martin

[Bug #13178] Booting very slow

[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=13178
Subject		: Booting very slow
Submitter	: Martin Knoblauch <spamtrap@knobisoft.de>
Date		: 2009-04-24 12:45 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=124057716231773&w=4

Re: [Bug #13178] Booting very slow

[Rafael J. Wysocki]

On Monday 27 April 2009, Martin Knoblauch wrote:
> 
> ----- Original Message ----
> 
> > From: Martin Knoblauch <spamtrap@knobisoft.de>
> > To: Rafael J. Wysocki <rjw@sisk.pl>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Kernel Testers List <kernel-testers@vger.kernel.org>
> > Sent: Monday, April 27, 2009 9:18:53 AM
> > Subject: Re: [Bug #13178] Booting very slow
> > 
> > ----- Original Message ----
> > 
> > > From: Rafael J. Wysocki 
> > > To: Linux Kernel Mailing List 
> > > Cc: Kernel Testers List ; Martin Knoblauch 
> > 
> > > Sent: Sunday, April 26, 2009 11:46:31 AM
> > > 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 (3 days old)
> > > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> > 
> > Not really sure whether this is a real regression. Between 2.6.28 and 2.6.29 the 
> > content of /proc/mounts for sysfs changed from
> > 
> > /sys /sys sysfs rw 0 0
> > 
> > to
> > 
> > none /sys sysfs rw 0 0
> > 
> > 
> > This breaks RHEL-4.3 userland which parses /proc/mounts in the firmware hotplug 
> > agent to find the mount-point for sysfs. As a result firmware loading started to 
> > fail in 2.6.29. There is a simple fix in the /etc/hotplug/firmware.agent script 
> > (just assume /sys as it is done elsewhere).
> > 
> > Your call.
> > 
> > Cheers
> > Martin
> 
>  Actually I have to correct myself. The reason for the failure to parse /proc/mounts for "sysfs" is that there are two lines:
> 
> [hotplug]# uname -a
> Linux lpsdm52 2.6.30-rc3-git2-nfs_ra #3 SMP Mon Apr 27 10:21:31 CEST 2009 x86_64 x86_64 x86_64 GNU/Linux
> [hotplug]# grep sysfs /proc/mounts
> none /sys sysfs rw,relatime 0 0
> /sys /sys sysfs rw,relatime 0 0
> 
>  This breaks the "firmware.agent" /sys-parsing code. There still exists the simple fix to userspace, but I now think that this is a real regression that should be fixed.

Thanks for the update.

Rafael

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- Original Message ----

> From: Martin Knoblauch <spamtrap@knobisoft.de>
> To: Rafael J. Wysocki <rjw@sisk.pl>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Kernel Testers List <kernel-testers@vger.kernel.org>
> Sent: Monday, April 27, 2009 9:18:53 AM
> Subject: Re: [Bug #13178] Booting very slow
> 
> ----- Original Message ----
> 
> > From: Rafael J. Wysocki 
> > To: Linux Kernel Mailing List 
> > Cc: Kernel Testers List ; Martin Knoblauch 
> 
> > Sent: Sunday, April 26, 2009 11:46:31 AM
> > 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 (3 days old)
> > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> 
> Not really sure whether this is a real regression. Between 2.6.28 and 2.6.29 the 
> content of /proc/mounts for sysfs changed from
> 
> /sys /sys sysfs rw 0 0
> 
> to
> 
> none /sys sysfs rw 0 0
> 
> 
> This breaks RHEL-4.3 userland which parses /proc/mounts in the firmware hotplug 
> agent to find the mount-point for sysfs. As a result firmware loading started to 
> fail in 2.6.29. There is a simple fix in the /etc/hotplug/firmware.agent script 
> (just assume /sys as it is done elsewhere).
> 
> Your call.
> 
> Cheers
> Martin

 Actually I have to correct myself. The reason for the failure to parse /proc/mounts for "sysfs" is that there are two lines:

[hotplug]# uname -a
Linux lpsdm52 2.6.30-rc3-git2-nfs_ra #3 SMP Mon Apr 27 10:21:31 CEST 2009 x86_64 x86_64 x86_64 GNU/Linux
[hotplug]# grep sysfs /proc/mounts
none /sys sysfs rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0

 This breaks the "firmware.agent" /sys-parsing code. There still exists the simple fix to userspace, but I now think that this is a real regression that should be fixed.

Cheers
Martin

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- Original Message ----

> From: Rafael J. Wysocki <rjw@sisk.pl>
> To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Martin Knoblauch <spamtrap@knobisoft.de>
> Sent: Sunday, April 26, 2009 11:46:31 AM
> 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 (3 days old)
> References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4

 Not really sure whether this is a real regression. Between 2.6.28 and 2.6.29 the content of /proc/mounts for sysfs changed from

/sys /sys sysfs rw 0 0

to

none /sys sysfs rw 0 0


 This breaks RHEL-4.3 userland which parses /proc/mounts in the firmware hotplug agent to find the mount-point for sysfs. As a result firmware loading started to fail in 2.6.29. There is a simple fix in the /etc/hotplug/firmware.agent script (just assume /sys as it is done elsewhere).

 Your call.

Cheers
Martin

[Bug #13178] Booting very slow

[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=13178
Subject		: Booting very slow
Submitter	: Martin Knoblauch <spamtrap@knobisoft.de>
Date		: 2009-04-24 12:45 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124057716231773&w=4