2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29

2.6.30-rc6: 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-05-17      162       27          25
  2009-04-26      160       29          27
  2009-04-06      142       37          31
  2009-03-21      128       29          26
  2009-03-14      124       36          32
  2009-03-03      108       33          28
  2009-02-24       95       32          24
  2009-02-14       85       33          27
  2009-02-08       82       45          36
  2009-02-04       66       51          39
  2009-01-20       38       35          27
  2009-01-11       13       13          10



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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13271
Subject		: ath9k stop working since 2.6.29
Submitter	: lyman <lymanrb@gmail.com>
Date		: 2009-05-10 01:58 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject		: WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter	: cedric <cedric@belbone.be>
Date		: 2009-05-08 08:48 (9 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject		: ext3/4 with synchronous writes gets wedged by Postfix
Submitter	: David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date		: 2009-05-03 19:46 (14 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject		: [2.6.29 regression] Software suspend no longer works
Submitter	: Artem S. Tashkinov <t.artem@mailcity.com>
Date		: 2009-05-02 21:41 (15 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13183
Subject		: forcedeth: no link during initialization
Submitter	: Harald Dunkel <harald.dunkel@t-online.de>
Date		: 2009-04-23 13:02 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049180309233&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject		: Booting very slow
Submitter	: Martin Knoblauch <spamtrap@knobisoft.de>
Date		: 2009-04-24 12:45 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=124057716231773&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject		: sata_nv incompatible with async scsi scan
Submitter	: Benny Halevy <bhalevy@panasas.com>
Date		: 2009-04-21 7:03 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124029746431777&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13172
Subject		: Spontaneous reboots since 2.6.29-rc*
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2009-04-17 17:03 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=123998788921733&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject		: resume from suspend fails using video card i915
Submitter	: C Sights <csights@fastmail.fm>
Date		: 2009-04-21 17:03 (26 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject		: can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter	: Maxim Levitsky <maximlevitsky@gmail.com>
Date		: 2009-04-06 23:52 (41 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References	: http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject		: gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter	: Paulo Matias <matias@archlinux-br.org>
Date		: 2009-04-12 14:10 (35 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject		: forcedeth seems to switch off eth on shutdown
Submitter	: Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date		: 2009-04-12 07:00 (35 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject		: After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter	: Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date		: 2009-04-06 19:47 (41 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject		: nozomi: pppd fails on kernel 2.6.29
Submitter	: Mark Karpeles <mark@hell.ne.jp>
Date		: 2009-04-06 19:12 (41 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject		: PCI-DMA: Out of IOMMU space
Submitter	:  <optimusgd@gmail.com>
Date		: 2009-04-03 09:30 (44 days old)
References	: http://lkml.org/lkml/2009/4/28/133


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject		: lockup in X.org
Submitter	: Marcus Better <marcus@better.se>
Date		: 2009-03-31 08:58 (47 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject		: "tg3 transmit timed out" when transmitting at high bitrate
Submitter	: Nikolay <dobrev666@gmail.com>
Date		: 2009-03-29 18:02 (49 days old)
Handled-By	: Matt Carlson <mcarlson@broadcom.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject		: r128: system hangs when X is started with DRI enabled
Submitter	: Jos van der Ende <seraph@xs4all.nl>
Date		: 2009-03-26 16:14 (52 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject		: boot/kernel init duration regression from 2.6.28
Submitter	: CaT <cat@zip.com.au>
Date		: 2009-03-16 10:25 (62 days old)
References	: http://marc.info/?l=linux-kernel&m=123720083515950&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject		: Crash in i915.ko: i915_driver_irq_handler
Submitter	: Helge Bahmann <helge.bahmann@secunet.com>
Date		: 2009-03-20 07:13 (58 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12861
Subject		: Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter	: Emil Karlson <jkarlson@cc.hut.fi>
Date		: 2009-03-12 12:06 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab657db12d7020629f26f30d287558a8d0e32b41


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject		: X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter	: Nico Schottelius <nico-linux-20090213@schottelius.org>
Date		: 2009-02-13 9:33 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References	: http://marc.info/?l=linux-kernel&m=123451768406825&w=4
		  http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By	: Eric Anholt <eric@anholt.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject		: s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter	: Orivej Desh <smpuj@bk.ru>
Date		: 2009-02-09 13:01 (97 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By	: Alexey Starikovskiy <astarikovskiy@suse.de>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject		: Problem with using bluetooth adaper connected to usb port
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2009-01-13 18:34 (124 days old)
References	: http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By	: Marcel Holtmann <marcel@holtmann.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject		: ath5k related kernel panic in 2.6.29-rc1
Submitter	: Sergey S. Kostyliov <rathamahata@gmail.com>
Date		: 2009-01-12 7:38 (125 days old)
References	: http://marc.info/?l=linux-kernel&m=123174591509586&w=4
		  http://lkml.org/lkml/2009/4/6/527
Handled-By	: Bob Copeland <me@bobcopeland.com>


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
Subject		: cpufreq timer teardown problem
Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date		: 2009-04-23 14:00 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Patch		: http://patchwork.kernel.org/patch/19754/
		  http://patchwork.kernel.org/patch/19753/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject		: i915 VT switch with AIGLX causes X lock up
Submitter	: Sitsofe Wheeler <sitsofe@yahoo.com>
Date		: 2009-02-21 15:38 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4
		  http://lkml.org/lkml/2009/4/27/317
Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
Patch		: http://patchwork.kernel.org/patch/20197/


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

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

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

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

Thanks,
Rafael

2.6.30-rc6: 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-05-17      162       27          25
  2009-04-26      160       29          27
  2009-04-06      142       37          31
  2009-03-21      128       29          26
  2009-03-14      124       36          32
  2009-03-03      108       33          28
  2009-02-24       95       32          24
  2009-02-14       85       33          27
  2009-02-08       82       45          36
  2009-02-04       66       51          39
  2009-01-20       38       35          27
  2009-01-11       13       13          10



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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13271
Subject		: ath9k stop working since 2.6.29
Submitter	: lyman <lymanrb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-10 01:58 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject		: WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter	: cedric <cedric-x1Cn44Nr1HaZIoH1IeqzKA@public.gmane.org>
Date		: 2009-05-08 08:48 (9 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject		: ext3/4 with synchronous writes gets wedged by Postfix
Submitter	: David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date		: 2009-05-03 19:46 (14 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject		: [2.6.29 regression] Software suspend no longer works
Submitter	: Artem S. Tashkinov <t.artem-VInPYn6yXxRWk0Htik3J/w@public.gmane.org>
Date		: 2009-05-02 21:41 (15 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13183
Subject		: forcedeth: no link during initialization
Submitter	: Harald Dunkel <harald.dunkel-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Date		: 2009-04-23 13:02 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049180309233&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject		: Booting very slow
Submitter	: Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
Date		: 2009-04-24 12:45 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=124057716231773&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject		: sata_nv incompatible with async scsi scan
Submitter	: Benny Halevy <bhalevy-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
Date		: 2009-04-21 7:03 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124029746431777&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13172
Subject		: Spontaneous reboots since 2.6.29-rc*
Submitter	: Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-17 17:03 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=123998788921733&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject		: resume from suspend fails using video card i915
Submitter	: C Sights <csights-97jfqw80gc6171pxa8y+qA@public.gmane.org>
Date		: 2009-04-21 17:03 (26 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject		: can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter	: Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-06 23:52 (41 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References	: http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject		: gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter	: Paulo Matias <matias-fd97jBR+K/6SGgWmA85PRw@public.gmane.org>
Date		: 2009-04-12 14:10 (35 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject		: forcedeth seems to switch off eth on shutdown
Submitter	: Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY@public.gmane.org>
Date		: 2009-04-12 07:00 (35 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject		: After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter	: Yaroslav Isakov <yaroslav.isakov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-06 19:47 (41 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject		: nozomi: pppd fails on kernel 2.6.29
Submitter	: Mark Karpeles <mark-pwcEARUeV57PDbFq/vQRIQ@public.gmane.org>
Date		: 2009-04-06 19:12 (41 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject		: PCI-DMA: Out of IOMMU space
Submitter	:  <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-03 09:30 (44 days old)
References	: http://lkml.org/lkml/2009/4/28/133


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject		: lockup in X.org
Submitter	: Marcus Better <marcus-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
Date		: 2009-03-31 08:58 (47 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject		: "tg3 transmit timed out" when transmitting at high bitrate
Submitter	: Nikolay <dobrev666-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-03-29 18:02 (49 days old)
Handled-By	: Matt Carlson <mcarlson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject		: r128: system hangs when X is started with DRI enabled
Submitter	: Jos van der Ende <seraph-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-03-26 16:14 (52 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject		: boot/kernel init duration regression from 2.6.28
Submitter	: CaT <cat-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org>
Date		: 2009-03-16 10:25 (62 days old)
References	: http://marc.info/?l=linux-kernel&m=123720083515950&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject		: Crash in i915.ko: i915_driver_irq_handler
Submitter	: Helge Bahmann <helge.bahmann-opNxpl+3fjRBDgjK7y7TUQ@public.gmane.org>
Date		: 2009-03-20 07:13 (58 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12861
Subject		: Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter	: Emil Karlson <jkarlson-kf+aQKke1yb1KXRcyAk9cg@public.gmane.org>
Date		: 2009-03-12 12:06 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab657db12d7020629f26f30d287558a8d0e32b41


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject		: X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter	: Nico Schottelius <nico-linux-20090213-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date		: 2009-02-13 9:33 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References	: http://marc.info/?l=linux-kernel&m=123451768406825&w=4
		  http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By	: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject		: s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter	: Orivej Desh <smpuj-5URONGGNgjI@public.gmane.org>
Date		: 2009-02-09 13:01 (97 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By	: Alexey Starikovskiy <astarikovskiy-l3A5Bk7waGM@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject		: Problem with using bluetooth adaper connected to usb port
Submitter	: Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-13 18:34 (124 days old)
References	: http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By	: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject		: ath5k related kernel panic in 2.6.29-rc1
Submitter	: Sergey S. Kostyliov <rathamahata-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-12 7:38 (125 days old)
References	: http://marc.info/?l=linux-kernel&m=123174591509586&w=4
		  http://lkml.org/lkml/2009/4/6/527
Handled-By	: Bob Copeland <me-aXfl/3sk2vNUbtYUoyoikg@public.gmane.org>


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
Subject		: cpufreq timer teardown problem
Submitter	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Date		: 2009-04-23 14:00 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/19754/
		  http://patchwork.kernel.org/patch/19753/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject		: i915 VT switch with AIGLX causes X lock up
Submitter	: Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date		: 2009-02-21 15:38 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4
		  http://lkml.org/lkml/2009/4/27/317
Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/20197/


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

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

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

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

Thanks,
Rafael

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

[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 (125 days old)
References	: http://marc.info/?l=linux-kernel&m=123174591509586&w=4
		  http://lkml.org/lkml/2009/4/6/527
Handled-By	: Bob Copeland <me@bobcopeland.com>

[Bug #12499] Problem with using bluetooth adaper connected to usb port

[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=12499
Subject		: Problem with using bluetooth adaper connected to usb port
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2009-01-13 18:34 (124 days old)
References	: http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By	: Marcel Holtmann <marcel@holtmann.org>

[Bug #12499] Problem with using bluetooth adaper connected to usb port

[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=12499
Subject		: Problem with using bluetooth adaper connected to usb port
Submitter	: Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-13 18:34 (124 days old)
References	: http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By	: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>

[Bug #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 (97 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By	: Alexey Starikovskiy <astarikovskiy@suse.de>

[Bug #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 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References	: http://marc.info/?l=linux-kernel&m=123451768406825&w=4
		  http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By	: Eric Anholt <eric@anholt.net>

[Bug #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 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4
		  http://lkml.org/lkml/2009/4/27/317
Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
Patch		: http://patchwork.kernel.org/patch/20197/

[Bug #12861] Xorg fails to start "Failed to allocate space for kernel memory manager"

[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=12861
Subject		: Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter	: Emil Karlson <jkarlson@cc.hut.fi>
Date		: 2009-03-12 12:06 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab657db12d7020629f26f30d287558a8d0e32b41

[Bug #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-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date		: 2009-02-13 9:33 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References	: http://marc.info/?l=linux-kernel&m=123451768406825&w=4
		  http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By	: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>

[Bug #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-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date		: 2009-02-21 15:38 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4
		  http://lkml.org/lkml/2009/4/27/317
Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/20197/

[Bug #12861] Xorg fails to start "Failed to allocate space for kernel memory manager"

[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=12861
Subject		: Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter	: Emil Karlson <jkarlson-kf+aQKke1yb1KXRcyAk9cg@public.gmane.org>
Date		: 2009-03-12 12:06 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab657db12d7020629f26f30d287558a8d0e32b41

[Bug #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 (58 days old)

[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 (62 days old)
References	: http://marc.info/?l=linux-kernel&m=123720083515950&w=4

[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 (49 days old)
Handled-By	: Matt Carlson <mcarlson@broadcom.com>

[Bug #12947] r128: system hangs when X is started with DRI enabled

[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=12947
Subject		: r128: system hangs when X is started with DRI enabled
Submitter	: Jos van der Ende <seraph@xs4all.nl>
Date		: 2009-03-26 16:14 (52 days old)

[Bug #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-opNxpl+3fjRBDgjK7y7TUQ@public.gmane.org>
Date		: 2009-03-20 07:13 (58 days old)

[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-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org>
Date		: 2009-03-16 10:25 (62 days old)
References	: http://marc.info/?l=linux-kernel&m=123720083515950&w=4

[Bug #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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-03-29 18:02 (49 days old)
Handled-By	: Matt Carlson <mcarlson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>

[Bug #12947] r128: system hangs when X is started with DRI enabled

[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=12947
Subject		: r128: system hangs when X is started with DRI enabled
Submitter	: Jos van der Ende <seraph-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-03-26 16:14 (52 days old)

[Bug #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 (47 days old)

[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 (44 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 (41 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-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
Date		: 2009-03-31 08:58 (47 days old)

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-03 09:30 (44 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-pwcEARUeV57PDbFq/vQRIQ@public.gmane.org>
Date		: 2009-04-06 19:12 (41 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 (35 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 (41 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 (35 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-Mmb7MZpHnFY@public.gmane.org>
Date		: 2009-04-12 07:00 (35 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-06 19:47 (41 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-fd97jBR+K/6SGgWmA85PRw@public.gmane.org>
Date		: 2009-04-12 14:10 (35 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 (41 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References	: http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>

[Bug #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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-06 23:52 (41 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References	: http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>

[Bug #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 (26 days old)

[Bug #13172] Spontaneous reboots since 2.6.29-rc*

[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=13172
Subject		: Spontaneous reboots since 2.6.29-rc*
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2009-04-17 17:03 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=123998788921733&w=4

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

[Bug #13175] sata_nv incompatible with async scsi scan

[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=13175
Subject		: sata_nv incompatible with async scsi scan
Submitter	: Benny Halevy <bhalevy@panasas.com>
Date		: 2009-04-21 7:03 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124029746431777&w=4

[Bug #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-97jfqw80gc6171pxa8y+qA@public.gmane.org>
Date		: 2009-04-21 17:03 (26 days old)

[Bug #13172] Spontaneous reboots since 2.6.29-rc*

[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=13172
Subject		: Spontaneous reboots since 2.6.29-rc*
Submitter	: Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-17 17:03 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=123998788921733&w=4

[Bug #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-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
Date		: 2009-04-24 12:45 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=124057716231773&w=4

[Bug #13175] sata_nv incompatible with async scsi scan

[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=13175
Subject		: sata_nv incompatible with async scsi scan
Submitter	: Benny Halevy <bhalevy-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
Date		: 2009-04-21 7:03 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=124029746431777&w=4

[Bug #13186] cpufreq timer teardown problem

[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=13186
Subject		: cpufreq timer teardown problem
Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date		: 2009-04-23 14:00 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Patch		: http://patchwork.kernel.org/patch/19754/
		  http://patchwork.kernel.org/patch/19753/

[Bug #13183] forcedeth: no link during initialization

[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=13183
Subject		: forcedeth: no link during initialization
Submitter	: Harald Dunkel <harald.dunkel@t-online.de>
Date		: 2009-04-23 13:02 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049180309233&w=4

[Bug #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 (15 days old)

[Bug #13186] cpufreq timer teardown problem

[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=13186
Subject		: cpufreq timer teardown problem
Submitter	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Date		: 2009-04-23 14:00 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/19754/
		  http://patchwork.kernel.org/patch/19753/

[Bug #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-VInPYn6yXxRWk0Htik3J/w@public.gmane.org>
Date		: 2009-05-02 21:41 (15 days old)

[Bug #13183] forcedeth: no link during initialization

[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=13183
Subject		: forcedeth: no link during initialization
Submitter	: Harald Dunkel <harald.dunkel-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Date		: 2009-04-23 13:02 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124049180309233&w=4

[Bug #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 (9 days old)

[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 (14 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-x1Cn44Nr1HaZIoH1IeqzKA@public.gmane.org>
Date		: 2009-05-08 08:48 (9 days old)

[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-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date		: 2009-05-03 19:46 (14 days old)

[Bug #13271] ath9k stop working since 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=13271
Subject		: ath9k stop working since 2.6.29
Submitter	: lyman <lymanrb@gmail.com>
Date		: 2009-05-10 01:58 (7 days old)

[Bug #13271] ath9k stop working since 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=13271
Subject		: ath9k stop working since 2.6.29
Submitter	: lyman <lymanrb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-10 01:58 (7 days old)

Re: [Bug #13172] Spontaneous reboots since 2.6.29-rc*

[Maciej Rutecki]

2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13172
> Subject         : Spontaneous reboots since 2.6.29-rc*
> Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date            : 2009-04-17 17:03 (30 days old)
> References      : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
>
>

I try:
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

from:
http://marc.info/?l=linux-kernel&m=124022460715035&w=4

Spontaneous reboots occur less often than in previous .config. From
last report it occur once or twice. I think, it's hardware/bios/mtrr
issue.

Because of this I think we should remove this regression from list,
until I find out, why it happen, or more people report this. What do
You think?

Regards


-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: [Bug #13172] Spontaneous reboots since 2.6.29-rc*

[Maciej Rutecki]

2009/5/16 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13172
> Subject         : Spontaneous reboots since 2.6.29-rc*
> Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date            : 2009-04-17 17:03 (30 days old)
> References      : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
>
>

I try:
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

from:
http://marc.info/?l=linux-kernel&m=124022460715035&w=4

Spontaneous reboots occur less often than in previous .config. From
last report it occur once or twice. I think, it's hardware/bios/mtrr
issue.

Because of this I think we should remove this regression from list,
until I find out, why it happen, or more people report this. What do
You think?

Regards


-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29

[Maciej Rutecki]

2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:


> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> Subject         : Problem with using bluetooth adaper connected to usb port
> Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date            : 2009-01-13 18:34 (124 days old)
> References      : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By      : Marcel Holtmann <marcel@holtmann.org>

2.6.30-rc6 works fine. Please remove it.


Regards
-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29

[Maciej Rutecki]

2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:


> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> Subject         : Problem with using bluetooth adaper connected to usb port
> Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date            : 2009-01-13 18:34 (124 days old)
> References      : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By      : Marcel Holtmann <marcel@holtmann.org>

2.6.30-rc6 works fine. Please remove it.


Regards
-- 
Maciej Rutecki
http://www.maciek.unixy.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29

[Maciej Rutecki]

2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:


> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> Subject         : Problem with using bluetooth adaper connected to usb port
> Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date            : 2009-01-13 18:34 (124 days old)
> References      : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By      : Marcel Holtmann <marcel@holtmann.org>

2.6.30-rc6 works fine. Please remove it.


Regards
-- 
Maciej Rutecki
http://www.maciek.unixy.pl
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [Bug #12499] Problem with using bluetooth adaper connected to usb port

[Maciej Rutecki]

2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> Subject         : Problem with using bluetooth adaper connected to usb port
> Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date            : 2009-01-13 18:34 (124 days old)
> References      : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By      : Marcel Holtmann <marcel@holtmann.org>
>

2.6.30-rc6 works fine. Please, remove it.

Thanks
-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: [Bug #12499] Problem with using bluetooth adaper connected to usb port

[Maciej Rutecki]

2009/5/16 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> Subject         : Problem with using bluetooth adaper connected to usb port
> Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date            : 2009-01-13 18:34 (124 days old)
> References      : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> Handled-By      : Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
>

2.6.30-rc6 works fine. Please, remove it.

Thanks
-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: [Bug #12499] Problem with using bluetooth adaper connected to usb port

[Rafael J. Wysocki]

On Sunday 17 May 2009, Maciej Rutecki wrote:
> 2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> > Subject         : Problem with using bluetooth adaper connected to usb port
> > Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date            : 2009-01-13 18:34 (124 days old)
> > References      : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> > Handled-By      : Marcel Holtmann <marcel@holtmann.org>
> >
> 
> 2.6.30-rc6 works fine. Please, remove it.

Removed.

Thanks,
Rafael

Re: [Bug #12499] Problem with using bluetooth adaper connected to usb port

[Rafael J. Wysocki]

On Sunday 17 May 2009, Maciej Rutecki wrote:
> 2009/5/16 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12499
> > Subject         : Problem with using bluetooth adaper connected to usb port
> > Submitter       : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date            : 2009-01-13 18:34 (124 days old)
> > References      : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
> > Handled-By      : Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
> >
> 
> 2.6.30-rc6 works fine. Please, remove it.

Removed.

Thanks,
Rafael

Re: [Bug #13172] Spontaneous reboots since 2.6.29-rc*

[Rafael J. Wysocki]

On Sunday 17 May 2009, Maciej Rutecki wrote:
> 2009/5/16 Rafael J. Wysocki <rjw@sisk.pl>:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13172
> > Subject         : Spontaneous reboots since 2.6.29-rc*
> > Submitter       : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date            : 2009-04-17 17:03 (30 days old)
> > References      : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
> >
> >
> 
> I try:
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
> 
> from:
> http://marc.info/?l=linux-kernel&m=124022460715035&w=4
> 
> Spontaneous reboots occur less often than in previous .config. From
> last report it occur once or twice. I think, it's hardware/bios/mtrr
> issue.
> 
> Because of this I think we should remove this regression from list,
> until I find out, why it happen, or more people report this. What do
> You think?

I've closed the bug.  Pleaes reopen it once you've found the root cause.

Thanks,
Rafael

Re: [Bug #13172] Spontaneous reboots since 2.6.29-rc*

[Rafael J. Wysocki]

On Sunday 17 May 2009, Maciej Rutecki wrote:
> 2009/5/16 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13172
> > Subject         : Spontaneous reboots since 2.6.29-rc*
> > Submitter       : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date            : 2009-04-17 17:03 (30 days old)
> > References      : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
> >
> >
> 
> I try:
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
> 
> from:
> http://marc.info/?l=linux-kernel&m=124022460715035&w=4
> 
> Spontaneous reboots occur less often than in previous .config. From
> last report it occur once or twice. I think, it's hardware/bios/mtrr
> issue.
> 
> Because of this I think we should remove this regression from list,
> until I find out, why it happen, or more people report this. What do
> You think?

I've closed the bug.  Pleaes reopen it once you've found the root cause.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Sunday 17 May 2009, Daniel Bierstedt wrote:
> Hello,
> 
> as I wrote on 26'th of April:
> 
> yes, this bug entry should be listed. This bug prevents people from
> using live-cd's or testing the 2.6.29 (if they know about this bug...).
> 
> Meanwhile I did some tests with knoppix 6 (2.6.28.4) and the
> systemrescue-cd (2.6.27.somewhat). Both could deal with eth0, but the
> physical device remained dead...

Thanks for the update.

Rafael

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

[Rafael J. Wysocki]

On Sunday 17 May 2009, Daniel Bierstedt wrote:
> Hello,
> 
> as I wrote on 26'th of April:
> 
> yes, this bug entry should be listed. This bug prevents people from
> using live-cd's or testing the 2.6.29 (if they know about this bug...).
> 
> Meanwhile I did some tests with knoppix 6 (2.6.28.4) and the
> systemrescue-cd (2.6.27.somewhat). Both could deal with eth0, but the
> physical device remained dead...

Thanks for the update.

Rafael

[PATCH] cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

[Mathieu Desnoyers]

* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject		: cpufreq timer teardown problem
> Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date		: 2009-04-23 14:00 (24 days old)
> References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch		: http://patchwork.kernel.org/patch/19754/
> 		  http://patchwork.kernel.org/patch/19753/

The patches linked above depend on the following patch to remove
circular locking dependency :


cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

(the following issue was faced when using cancel_delayed_work_sync() in the
timer teardown (which fixes a race).

* KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:
> Hi
> 
> my box output following warnings.
> it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
> 
> A: work -> do_dbs_timer()  -> cpu_policy_rwsem
> B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
> 
> 

Hrm, I think it must be due to my attempt to fix the timer teardown race
in ondemand governor mixed with new locking behavior in 2.6.30-rc.

The rwlock seems to be taken around the whole call to
cpufreq_governor_dbs(), when it should be only taken around accesses to
the locked data, and especially *not* around the call to
dbs_timer_exit().

Reverting my fix attempt would put the teardown race back in place
(replacing the cancel_delayed_work_sync by cancel_delayed_work).
Instead, a proper fix would imply modifying this critical section :

cpufreq.c: __cpufreq_remove_dev()
...
        if (cpufreq_driver->target)
                __cpufreq_governor(data, CPUFREQ_GOV_STOP);

        unlock_policy_rwsem_write(cpu);

To make sure the __cpufreq_governor() callback is not called with rwsem
held. This would allow execution of cancel_delayed_work_sync() without
being nested within the rwsem.

Applies on top of the 2.6.30-rc5 tree.

Required to remove circular dep in teardown of both conservative and
ondemande governors so they can use cancel_delayed_work_sync().
CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
unneeded.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Greg KH <greg@kroah.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
CC: Ben Slusky <sluskyb@paranoiacs.org>
CC: Dave Jones <davej@redhat.com>
CC: Chris Wright <chrisw@sous-sol.org>
CC: Andrew Morton <akpm@linux-foundation.org>
---
 drivers/cpufreq/cpufreq.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6-lttng/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq.c	2009-05-10 14:41:53.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq.c	2009-05-10 14:42:29.000000000 -0400
@@ -1070,11 +1070,11 @@ static int __cpufreq_remove_dev(struct s
 	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
 #endif
 
+	unlock_policy_rwsem_write(cpu);
+
 	if (cpufreq_driver->target)
 		__cpufreq_governor(data, CPUFREQ_GOV_STOP);
 
-	unlock_policy_rwsem_write(cpu);
-
 	kobject_put(&data->kobj);
 
 	/* we need to make sure that the underlying kobj is actually

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[PATCH] cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

[Mathieu Desnoyers]

* Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject		: cpufreq timer teardown problem
> Submitter	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Date		: 2009-04-23 14:00 (24 days old)
> References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/19754/
> 		  http://patchwork.kernel.org/patch/19753/

The patches linked above depend on the following patch to remove
circular locking dependency :


cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

(the following issue was faced when using cancel_delayed_work_sync() in the
timer teardown (which fixes a race).

* KOSAKI Motohiro (kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org) wrote:
> Hi
> 
> my box output following warnings.
> it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
> 
> A: work -> do_dbs_timer()  -> cpu_policy_rwsem
> B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
> 
> 

Hrm, I think it must be due to my attempt to fix the timer teardown race
in ondemand governor mixed with new locking behavior in 2.6.30-rc.

The rwlock seems to be taken around the whole call to
cpufreq_governor_dbs(), when it should be only taken around accesses to
the locked data, and especially *not* around the call to
dbs_timer_exit().

Reverting my fix attempt would put the teardown race back in place
(replacing the cancel_delayed_work_sync by cancel_delayed_work).
Instead, a proper fix would imply modifying this critical section :

cpufreq.c: __cpufreq_remove_dev()
...
        if (cpufreq_driver->target)
                __cpufreq_governor(data, CPUFREQ_GOV_STOP);

        unlock_policy_rwsem_write(cpu);

To make sure the __cpufreq_governor() callback is not called with rwsem
held. This would allow execution of cancel_delayed_work_sync() without
being nested within the rwsem.

Applies on top of the 2.6.30-rc5 tree.

Required to remove circular dep in teardown of both conservative and
ondemande governors so they can use cancel_delayed_work_sync().
CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
unneeded.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
CC: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
CC: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
CC: "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>
CC: Ben Slusky <sluskyb-k/7z6JowIC0cuXOPmUuyGA@public.gmane.org>
CC: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
CC: Chris Wright <chrisw-69jw2NvuJkxg9hUCZPvPmw@public.gmane.org>
CC: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
---
 drivers/cpufreq/cpufreq.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6-lttng/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq.c	2009-05-10 14:41:53.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq.c	2009-05-10 14:42:29.000000000 -0400
@@ -1070,11 +1070,11 @@ static int __cpufreq_remove_dev(struct s
 	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
 #endif
 
+	unlock_policy_rwsem_write(cpu);
+
 	if (cpufreq_driver->target)
 		__cpufreq_governor(data, CPUFREQ_GOV_STOP);
 
-	unlock_policy_rwsem_write(cpu);
-
 	kobject_put(&data->kobj);
 
 	/* we need to make sure that the underlying kobj is actually

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[PATCH] cpufreq fix timer teardown in conservative governor

[Mathieu Desnoyers]

* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject		: cpufreq timer teardown problem
> Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date		: 2009-04-23 14:00 (24 days old)
> References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch		: http://patchwork.kernel.org/patch/19754/
> 		  http://patchwork.kernel.org/patch/19753/
> 

(re-send with updated changelog)

cpufreq fix timer teardown in conservative governor

The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.

The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :

dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.

Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

The following patch applies to 2.6.30-rc2. Stable kernels have a similar
issue which should also be fixed, but the code changed between 2.6.29
and 2.6.30, so this patch only applies to 2.6.30-rc.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: gregkh@suse.de
CC: stable@kernel.org
CC: cpufreq@vger.kernel.org
CC: Ingo Molnar <mingo@elte.hu>
CC: rjw@sisk.pl
CC: Ben Slusky <sluskyb@paranoiacs.org>
CC: Dave Jones <davej@redhat.com>
---
 drivers/cpufreq/cpufreq_conservative.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6-lttng/drivers/cpufreq/cpufreq_conservative.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq_conservative.c	2009-04-23 23:22:15.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq_conservative.c	2009-04-23 23:24:38.000000000 -0400
@@ -91,6 +91,9 @@ static unsigned int dbs_enable;	/* numbe
  * (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
  * cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
  * is recursive for the same process. -Venki
+ * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
+ * would deadlock with cancel_delayed_work_sync(), which is needed for proper
+ * raceless workqueue teardown.
  */
 static DEFINE_MUTEX(dbs_mutex);
 
@@ -542,7 +545,7 @@ static inline void dbs_timer_init(struct
 static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
 {
 	dbs_info->enable = 0;
-	cancel_delayed_work(&dbs_info->work);
+	cancel_delayed_work_sync(&dbs_info->work);
 }
 
 static int cpufreq_governor_dbs(struct cpufreq_policy *policy,

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[PATCH] cpufreq fix timer teardown in conservative governor

[Mathieu Desnoyers]

* Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject		: cpufreq timer teardown problem
> Submitter	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Date		: 2009-04-23 14:00 (24 days old)
> References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/19754/
> 		  http://patchwork.kernel.org/patch/19753/
> 

(re-send with updated changelog)

cpufreq fix timer teardown in conservative governor

The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.

The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :

dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.

Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

The following patch applies to 2.6.30-rc2. Stable kernels have a similar
issue which should also be fixed, but the code changed between 2.6.29
and 2.6.30, so this patch only applies to 2.6.30-rc.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
CC: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
CC: gregkh-l3A5Bk7waGM@public.gmane.org
CC: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
CC: cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
CC: rjw-KKrjLPT3xs0@public.gmane.org
CC: Ben Slusky <sluskyb-k/7z6JowIC0cuXOPmUuyGA@public.gmane.org>
CC: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 drivers/cpufreq/cpufreq_conservative.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6-lttng/drivers/cpufreq/cpufreq_conservative.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq_conservative.c	2009-04-23 23:22:15.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq_conservative.c	2009-04-23 23:24:38.000000000 -0400
@@ -91,6 +91,9 @@ static unsigned int dbs_enable;	/* numbe
  * (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
  * cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
  * is recursive for the same process. -Venki
+ * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
+ * would deadlock with cancel_delayed_work_sync(), which is needed for proper
+ * raceless workqueue teardown.
  */
 static DEFINE_MUTEX(dbs_mutex);
 
@@ -542,7 +545,7 @@ static inline void dbs_timer_init(struct
 static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
 {
 	dbs_info->enable = 0;
-	cancel_delayed_work(&dbs_info->work);
+	cancel_delayed_work_sync(&dbs_info->work);
 }
 
 static int cpufreq_governor_dbs(struct cpufreq_policy *policy,

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[PATCH] cpufreq fix timer teardown in ondemand governor

[Mathieu Desnoyers]

* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject		: cpufreq timer teardown problem
> Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date		: 2009-04-23 14:00 (24 days old)
> References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch		: http://patchwork.kernel.org/patch/19754/
> 		  http://patchwork.kernel.org/patch/19753/
> 

(updated changelog)

cpufreq fix timer teardown in ondemand governor

The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.

The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :

dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.

The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.

Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: gregkh@suse.de
CC: stable@kernel.org
CC: cpufreq@vger.kernel.org
CC: Ingo Molnar <mingo@elte.hu>
CC: rjw@sisk.pl
CC: Ben Slusky <sluskyb@paranoiacs.org>
CC: Dave Jones <davej@redhat.com>
---
 drivers/cpufreq/cpufreq_ondemand.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6-lttng/drivers/cpufreq/cpufreq_ondemand.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq_ondemand.c	2009-04-23 23:25:00.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq_ondemand.c	2009-04-23 23:25:39.000000000 -0400
@@ -98,6 +98,9 @@ static unsigned int dbs_enable;	/* numbe
  * (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
  * cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
  * is recursive for the same process. -Venki
+ * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
+ * would deadlock with cancel_delayed_work_sync(), which is needed for proper
+ * raceless workqueue teardown.
  */
 static DEFINE_MUTEX(dbs_mutex);
 
@@ -562,7 +565,7 @@ static inline void dbs_timer_init(struct
 static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
 {
 	dbs_info->enable = 0;
-	cancel_delayed_work(&dbs_info->work);
+	cancel_delayed_work_sync(&dbs_info->work);
 }
 
 static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[PATCH] cpufreq fix timer teardown in ondemand governor

[Mathieu Desnoyers]

* Rafael J. Wysocki (rjw-KKrjLPT3xs0@public.gmane.org) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject		: cpufreq timer teardown problem
> Submitter	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Date		: 2009-04-23 14:00 (24 days old)
> References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By	: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/19754/
> 		  http://patchwork.kernel.org/patch/19753/
> 

(updated changelog)

cpufreq fix timer teardown in ondemand governor

The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.

The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :

dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.

The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.

Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
CC: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
CC: gregkh-l3A5Bk7waGM@public.gmane.org
CC: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
CC: cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
CC: rjw-KKrjLPT3xs0@public.gmane.org
CC: Ben Slusky <sluskyb-k/7z6JowIC0cuXOPmUuyGA@public.gmane.org>
CC: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 drivers/cpufreq/cpufreq_ondemand.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6-lttng/drivers/cpufreq/cpufreq_ondemand.c
===================================================================
--- linux-2.6-lttng.orig/drivers/cpufreq/cpufreq_ondemand.c	2009-04-23 23:25:00.000000000 -0400
+++ linux-2.6-lttng/drivers/cpufreq/cpufreq_ondemand.c	2009-04-23 23:25:39.000000000 -0400
@@ -98,6 +98,9 @@ static unsigned int dbs_enable;	/* numbe
  * (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
  * cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
  * is recursive for the same process. -Venki
+ * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
+ * would deadlock with cancel_delayed_work_sync(), which is needed for proper
+ * raceless workqueue teardown.
  */
 static DEFINE_MUTEX(dbs_mutex);
 
@@ -562,7 +565,7 @@ static inline void dbs_timer_init(struct
 static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
 {
 	dbs_info->enable = 0;
-	cancel_delayed_work(&dbs_info->work);
+	cancel_delayed_work_sync(&dbs_info->work);
 }
 
 static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [Bug #12980] lockup in X.org

[Marcus Better]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rafael J. Wysocki wrote:
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12980
> Subject		: lockup in X.org
> Submitter	: Marcus Better <marcus@better.se>
> Date		: 2009-03-31 08:58 (47 days old)

Bug went away for unknown reason, hasn't occurred in more than a month.

Cheers,

Marcus

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoQL78ACgkQXjXn6TzcAQlQNQCcDH+GrasHNGT7UrrsvfNOH/iy
hlkAoMo9JJ+33MJLPrTF49HgfgcIdp/r
=ovke
-----END PGP SIGNATURE-----

Re: [Bug #12980] lockup in X.org

[Marcus Better]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rafael J. Wysocki wrote:
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12980
> Subject		: lockup in X.org
> Submitter	: Marcus Better <marcus-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
> Date		: 2009-03-31 08:58 (47 days old)

Bug went away for unknown reason, hasn't occurred in more than a month.

Cheers,

Marcus

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoQL78ACgkQXjXn6TzcAQlQNQCcDH+GrasHNGT7UrrsvfNOH/iy
hlkAoMo9JJ+33MJLPrTF49HgfgcIdp/r
=ovke
-----END PGP SIGNATURE-----

Re: [Bug #12947] r128: system hangs when X is started with DRI enabled

[Jos van der Ende]

On Sat, 16 May 2009 22:05:58 +0200 (CEST)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).

The bug is still present in 2.6.29.3, but we've found the likely cause and a potential fix. As soon as I have access to the system again, I will test this patch. Unfortunately I won't be anywhere near the system this week. I'll get back to it on Monday 25th.


-- 
Jos van der Ende <seraph@xs4all.nl>

Re: [Bug #12947] r128: system hangs when X is started with DRI enabled

[Jos van der Ende]

On Sat, 16 May 2009 22:05:58 +0200 (CEST)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).

The bug is still present in 2.6.29.3, but we've found the likely cause and a potential fix. As soon as I have access to the system again, I will test this patch. Unfortunately I won't be anywhere near the system this week. I'll get back to it on Monday 25th.


-- 
Jos van der Ende <seraph-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>

Re: [Bug #12980] lockup in X.org

[Rafael J. Wysocki]

On Sunday 17 May 2009, Marcus Better wrote:
> Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12980
> > Subject		: lockup in X.org
> > Submitter	: Marcus Better <marcus@better.se>
> > Date		: 2009-03-31 08:58 (47 days old)
> 
> Bug went away for unknown reason, hasn't occurred in more than a month.

Thanks, bug closed.

Best,
Rafael

Re: [Bug #12980] lockup in X.org

[Rafael J. Wysocki]

On Sunday 17 May 2009, Marcus Better wrote:
> Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12980
> > Subject		: lockup in X.org
> > Submitter	: Marcus Better <marcus-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
> > Date		: 2009-03-31 08:58 (47 days old)
> 
> Bug went away for unknown reason, hasn't occurred in more than a month.

Thanks, bug closed.

Best,
Rafael

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

[Sitsofe Wheeler]

On Sat, May 16, 2009 at 10:05:57PM +0200, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12765
> Subject		: i915 VT switch with AIGLX causes X lock up
> Submitter	: Sitsofe Wheeler <sitsofe@yahoo.com>
> Date		: 2009-02-21 15:38 (85 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> 		  http://lkml.org/lkml/2009/4/27/317
> Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
> Patch		: http://patchwork.kernel.org/patch/20197/

Yes, this problem is still here in 2.6.30-rc6-00026-g0f6f49a .

-- 
Sitsofe | http://sucs.org/~sits/

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

[Sitsofe Wheeler]

On Sat, May 16, 2009 at 10:05:57PM +0200, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12765
> Subject		: i915 VT switch with AIGLX causes X lock up
> Submitter	: Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
> Date		: 2009-02-21 15:38 (85 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> 		  http://lkml.org/lkml/2009/4/27/317
> Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/20197/

Yes, this problem is still here in 2.6.30-rc6-00026-g0f6f49a .

-- 
Sitsofe | http://sucs.org/~sits/

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

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- Original Message ----

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

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

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

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

Cheers
Martin

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

[Theodore Tso]

On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> Submitter	: David Watson <kernel-nospam@dbwatson.ukfsn.org>
> Date		: 2009-05-03 19:46 (14 days old)

This turned out to be caused by change in the VFS, as documented in
the bug report.  Al Viro has a patch, which I've reviewed.

David, would you be able to try testing Al's proposed patch, since you
have an easy reproduction case?  Thanks,

						- Ted

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

[Theodore Tso]

On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> Submitter	: David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> Date		: 2009-05-03 19:46 (14 days old)

This turned out to be caused by change in the VFS, as documented in
the bug report.  Al Viro has a patch, which I've reviewed.

David, would you be able to try testing Al's proposed patch, since you
have an easy reproduction case?  Thanks,

						- Ted

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

[Rafael J. Wysocki]

On Monday 18 May 2009, Sitsofe Wheeler wrote:
> On Sat, May 16, 2009 at 10:05:57PM +0200, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12765
> > Subject		: i915 VT switch with AIGLX causes X lock up
> > Submitter	: Sitsofe Wheeler <sitsofe@yahoo.com>
> > Date		: 2009-02-21 15:38 (85 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> > References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> > 		  http://lkml.org/lkml/2009/4/27/317
> > Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
> > Patch		: http://patchwork.kernel.org/patch/20197/
> 
> Yes, this problem is still here in 2.6.30-rc6-00026-g0f6f49a .

Thanks for the update.

Rafael

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

[Rafael J. Wysocki]

On Monday 18 May 2009, Sitsofe Wheeler wrote:
> On Sat, May 16, 2009 at 10:05:57PM +0200, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12765
> > Subject		: i915 VT switch with AIGLX causes X lock up
> > Submitter	: Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-02-21 15:38 (85 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> > References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> > 		  http://lkml.org/lkml/2009/4/27/317
> > Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
> > Patch		: http://patchwork.kernel.org/patch/20197/
> 
> Yes, this problem is still here in 2.6.30-rc6-00026-g0f6f49a .

Thanks for the update.

Rafael

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

[Rafael J. Wysocki]

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

Thanks a lot for doing this.

Best,
Rafael

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

[Kay Sievers]

On Mon, May 18, 2009 at 10:15, Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org> wrote:

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

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

Thanks,
Kay

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

[Martin Knoblauch]

----- Original Message ----

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

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

Cheers
Martin

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

[Kay Sievers]

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

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

Cheers,
Kay

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

[David Watson]

On Mon 18 May 2009, Theodore Tso wrote:
> On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter	: David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > Date		: 2009-05-03 19:46 (14 days old)
> 
> This turned out to be caused by change in the VFS, as documented in
> the bug report.  Al Viro has a patch, which I've reviewed.
> 
> David, would you be able to try testing Al's proposed patch, since you
> have an easy reproduction case?  Thanks,

Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.

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

[David Watson]

On Mon 18 May 2009, Theodore Tso wrote:
> On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter	: David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > Date		: 2009-05-03 19:46 (14 days old)
> 
> This turned out to be caused by change in the VFS, as documented in
> the bug report.  Al Viro has a patch, which I've reviewed.
> 
> David, would you be able to try testing Al's proposed patch, since you
> have an easy reproduction case?  Thanks,

Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.

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

[Theodore Tso]

On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
> On Mon 18 May 2009, Theodore Tso wrote:
> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter	: David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > > Date		: 2009-05-03 19:46 (14 days old)
> > 
> > This turned out to be caused by change in the VFS, as documented in
> > the bug report.  Al Viro has a patch, which I've reviewed.
> > 
> > David, would you be able to try testing Al's proposed patch, since you
> > have an easy reproduction case?  Thanks,
> 
> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.

Thanks, David.

Al, Jan Kara and I have reviewed your patch, and we can add a
Tested-by: from David Watson (assuming David, you don't mind your name
or e-mail address showing up in the Kernel commit logs --- if you want
us to suppress one or both, please let us know).  Given this is a
2.6.28 regression, and this can certainly affect real-life users, I
think we should push your patch to Linus for 2.6.30.  Do you agree?

Regards,

						- Ted

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

[Theodore Tso]

On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
> On Mon 18 May 2009, Theodore Tso wrote:
> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter	: David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > > Date		: 2009-05-03 19:46 (14 days old)
> > 
> > This turned out to be caused by change in the VFS, as documented in
> > the bug report.  Al Viro has a patch, which I've reviewed.
> > 
> > David, would you be able to try testing Al's proposed patch, since you
> > have an easy reproduction case?  Thanks,
> 
> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.

Thanks, David.

Al, Jan Kara and I have reviewed your patch, and we can add a
Tested-by: from David Watson (assuming David, you don't mind your name
or e-mail address showing up in the Kernel commit logs --- if you want
us to suppress one or both, please let us know).  Given this is a
2.6.28 regression, and this can certainly affect real-life users, I
think we should push your patch to Linus for 2.6.30.  Do you agree?

Regards,

						- Ted

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

[John Stoffel]

>>>>> "Theodore" == Theodore Tso <tytso@mit.edu> writes:

Theodore> On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
>> On Mon 18 May 2009, Theodore Tso wrote:
>> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
>> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
>> > > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
>> > > Submitter	: David Watson <kernel-nospam@dbwatson.ukfsn.org>
>> > > Date		: 2009-05-03 19:46 (14 days old)
>> > 
>> > This turned out to be caused by change in the VFS, as documented in
>> > the bug report.  Al Viro has a patch, which I've reviewed.
>> > 
>> > David, would you be able to try testing Al's proposed patch, since you
>> > have an easy reproduction case?  Thanks,
>> 
>> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.


Theodore> Al, Jan Kara and I have reviewed your patch, and we can add
Theodore> a Tested-by: from David Watson (assuming David, you don't
Theodore> mind your name or e-mail address showing up in the Kernel
Theodore> commit logs --- if you want us to suppress one or both,
Theodore> please let us know).  Given this is a 2.6.28 regression, and
Theodore> this can certainly affect real-life users, I think we should
Theodore> push your patch to Linus for 2.6.30.  Do you agree?

I wonder if this is the reason my main file server has been locking up
solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
Since it's my main file server at home, and with my home dir NFS
mounted from it onto another system, it's been hard to catch.  I spent
some time fiddling around getting netconsole setup, but then I ran out
of time.

My system is a Debian, pretty upto date, PIII, 550Mhz Dual CPU, 3Gb
RAM, lots of SCSI, SATA and IDE busses, with various types of devices
on all the busses, from DLT tape drive and library, to a mix of disks.
I'm also running ext4 on a mirrored pair disks I use for spooling
backups to tape from.  Ext3 on the rest of my mirrored filesystems as
well. 

If someone could send me the patch, I'll apply it and see how well
2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
Reproducing the problem was pretty easy for me.  

Thanks,
John

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

[Theodore Tso]

On Tue, May 19, 2009 at 02:27:14PM -0400, John Stoffel wrote:
> I wonder if this is the reason my main file server has been locking up
> solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
> Since it's my main file server at home, and with my home dir NFS
> mounted from it onto another system, it's been hard to catch.  I spent
> some time fiddling around getting netconsole setup, but then I ran out
> of time.

Unless you have your partition mounted with the "sync" mount option
(which has negative performance implifications; it makes sense for a
mail queue directory, but not necessarily for a general purpose file
server) or you have a directory chattr'ed with the sync flag, probably
not...

If you want to try it, though, the patch is available here:

   http://bugzilla.kernel.org/attachment.cgi?id=21436

> If someone could send me the patch, I'll apply it and see how well
> 2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
> Reproducing the problem was pretty easy for me.  

Anything on the console?  Any oops messages, or soft lockup warnings?

What filesystem(s) are you using? 


						- Ted

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

[Theodore Tso]

On Tue, May 19, 2009 at 02:27:14PM -0400, John Stoffel wrote:
> I wonder if this is the reason my main file server has been locking up
> solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
> Since it's my main file server at home, and with my home dir NFS
> mounted from it onto another system, it's been hard to catch.  I spent
> some time fiddling around getting netconsole setup, but then I ran out
> of time.

Unless you have your partition mounted with the "sync" mount option
(which has negative performance implifications; it makes sense for a
mail queue directory, but not necessarily for a general purpose file
server) or you have a directory chattr'ed with the sync flag, probably
not...

If you want to try it, though, the patch is available here:

   http://bugzilla.kernel.org/attachment.cgi?id=21436

> If someone could send me the patch, I'll apply it and see how well
> 2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
> Reproducing the problem was pretty easy for me.  

Anything on the console?  Any oops messages, or soft lockup warnings?

What filesystem(s) are you using? 


						- Ted

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

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

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

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

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

 I will continue the discussion under the original topic.

Cheers

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

[John Stoffel]

>>>>> "Theodore" == Theodore Tso <tytso@mit.edu> writes:

Oops.  It looks like 2.6.29.3 is actually quite solid.  My fault, I
must have gotten confused.  I know that 2.6.30-rc* was unstable on
there and locked up easily.  


Theodore> On Tue, May 19, 2009 at 02:27:14PM -0400, John Stoffel wrote:
>> I wonder if this is the reason my main file server has been locking up
>> solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
>> Since it's my main file server at home, and with my home dir NFS
>> mounted from it onto another system, it's been hard to catch.  I spent
>> some time fiddling around getting netconsole setup, but then I ran out
>> of time.

Theodore> Unless you have your partition mounted with the "sync" mount
Theodore> option (which has negative performance implifications; it
Theodore> makes sense for a mail queue directory, but not necessarily
Theodore> for a general purpose file server) or you have a directory
Theodore> chattr'ed with the sync flag, probably not...

Theodore> If you want to try it, though, the patch is available here:

Theodore>    http://bugzilla.kernel.org/attachment.cgi?id=21436

Ok, then it's probably not something I need to test, since I'm only
mounting stuff noatime.  

>> If someone could send me the patch, I'll apply it and see how well
>> 2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
>> Reproducing the problem was pretty easy for me.  

Theodore> Anything on the console?  Any oops messages, or soft lockup warnings?

Nothing.  I've not had the time lately to reboot the system to try
2.6.29 or newer with all the lockup debugging stuff yet.  Maybe
tonight I'll get a chance.

Theodore> What filesystem(s) are you using?

ext3 for everything, except one staging area running ext4 which is
only used for bacula to stage data before writing to tape.  It's solid
under 2.6.29.3 (dammit, I must have mis-remembered) and it's been up
now for six days running backups and serving NFS files.  

Here's my filesystems:

  > mount
  /dev/sda2 on / type ext3 (rw,errors=remount-ro)
  tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
  proc on /proc type proc (rw,noexec,nosuid,nodev)
  sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
  procbususb on /proc/bus/usb type usbfs (rw)
  /udev on /dev type tmpfs (rw,mode=0755)
  tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
  devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
  fusectl on /sys/fs/fuse/connections type fusectl (rw)
  /dev/sda5 on /var type ext3 (rw,noatime)
  /dev/sda1 on /boot type ext3 (rw,noatime)
  /dev/sda6 on /usr type ext3 (rw,noatime)
  /dev/dm-1 on /home type ext3 (rw,noatime)
  /dev/dm-2 on /local type ext3 (rw,noatime)
  overflow on /tmp type tmpfs (rw,size=1048576,mode=1777,size=50%)
  rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
  nfsd on /proc/fs/nfsd type nfsd (rw)
  binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
  (rw,noexec,nosuid,nodev)
  /dev/mapper/onetwenty-staging on /staging type ext4 (rw,noatime)


When the system locks up, there's nothing in the logs, nothing on the
screen, even when I leave it turned to VT1 (Ctl-Alt-F1) and then wait
for a lockup, the screen is completely blank.

I'll see about finding some more time to beat on this and get better
results back to people.

John

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

[John Stoffel]

>>>>> "Theodore" == Theodore Tso <tytso-3s7WtUTddSA@public.gmane.org> writes:

Oops.  It looks like 2.6.29.3 is actually quite solid.  My fault, I
must have gotten confused.  I know that 2.6.30-rc* was unstable on
there and locked up easily.  


Theodore> On Tue, May 19, 2009 at 02:27:14PM -0400, John Stoffel wrote:
>> I wonder if this is the reason my main file server has been locking up
>> solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
>> Since it's my main file server at home, and with my home dir NFS
>> mounted from it onto another system, it's been hard to catch.  I spent
>> some time fiddling around getting netconsole setup, but then I ran out
>> of time.

Theodore> Unless you have your partition mounted with the "sync" mount
Theodore> option (which has negative performance implifications; it
Theodore> makes sense for a mail queue directory, but not necessarily
Theodore> for a general purpose file server) or you have a directory
Theodore> chattr'ed with the sync flag, probably not...

Theodore> If you want to try it, though, the patch is available here:

Theodore>    http://bugzilla.kernel.org/attachment.cgi?id=21436

Ok, then it's probably not something I need to test, since I'm only
mounting stuff noatime.  

>> If someone could send me the patch, I'll apply it and see how well
>> 2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
>> Reproducing the problem was pretty easy for me.  

Theodore> Anything on the console?  Any oops messages, or soft lockup warnings?

Nothing.  I've not had the time lately to reboot the system to try
2.6.29 or newer with all the lockup debugging stuff yet.  Maybe
tonight I'll get a chance.

Theodore> What filesystem(s) are you using?

ext3 for everything, except one staging area running ext4 which is
only used for bacula to stage data before writing to tape.  It's solid
under 2.6.29.3 (dammit, I must have mis-remembered) and it's been up
now for six days running backups and serving NFS files.  

Here's my filesystems:

  > mount
  /dev/sda2 on / type ext3 (rw,errors=remount-ro)
  tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
  proc on /proc type proc (rw,noexec,nosuid,nodev)
  sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
  procbususb on /proc/bus/usb type usbfs (rw)
  /udev on /dev type tmpfs (rw,mode=0755)
  tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
  devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
  fusectl on /sys/fs/fuse/connections type fusectl (rw)
  /dev/sda5 on /var type ext3 (rw,noatime)
  /dev/sda1 on /boot type ext3 (rw,noatime)
  /dev/sda6 on /usr type ext3 (rw,noatime)
  /dev/dm-1 on /home type ext3 (rw,noatime)
  /dev/dm-2 on /local type ext3 (rw,noatime)
  overflow on /tmp type tmpfs (rw,size=1048576,mode=1777,size=50%)
  rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
  nfsd on /proc/fs/nfsd type nfsd (rw)
  binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
  (rw,noexec,nosuid,nodev)
  /dev/mapper/onetwenty-staging on /staging type ext4 (rw,noatime)


When the system locks up, there's nothing in the logs, nothing on the
screen, even when I leave it turned to VT1 (Ctl-Alt-F1) and then wait
for a lockup, the screen is completely blank.

I'll see about finding some more time to beat on this and get better
results back to people.

John

[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 #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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-03 09:30 (66 days old)
References	: http://lkml.org/lkml/2009/4/28/133

[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 (58 days old)
References	: http://lkml.org/lkml/2009/4/28/133

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-03 09:30 (58 days old)
References	: http://lkml.org/lkml/2009/4/28/133

[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 (52 days old)
References	: http://lkml.org/lkml/2009/4/28/133

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-03 09:30 (52 days old)
References	: http://lkml.org/lkml/2009/4/28/133

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[FUJITA Tomonori]

On Mon, 4 May 2009 10:27:11 +0500
**UNKNOWN CHARSET** <optimusgd@gmail.com> wrote:

> 2009/4/28 FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>:
> > On Tue, 28 Apr 2009 14:18:57 +0500
> > **UNKNOWN CHARSET** <optimusgd@gmail.com> wrote:
> >
> >> No, it is regression. I can reproduce that without allowdac and any
> >> other unnecessary boot options.
> >
> > Hmm, in the bug repport, you said that you can't reproduce the problem:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=13001#c15
> >
> > I can't find your comment like, "I can reproduce that without
> > allowdac".
> 
> I was under a misapprehension. Later discussion was been in linux-pci
> mailing list
> http://markmail.org/message/pbng73ojpllln5fl

You didn't CC to me so it was impossible for me to track this bug.


> >> In later discussion Grant Grundler ask
> >> me apply patch that show 32 bit dma devices in my system. Results I
> >> attached to bugreport. Looks like only one 32 bit dma device in my
> >> system is ata controller, sata-nv.
> >
> > Hmm, looks like http://bugzilla.kernel.org/attachment.cgi?id=20895
> > said that pata_amd and sata_nv use 32bit dma mask.
> >
> >
> >> I can stable reproduce IOMMU out of space when I write data to sata
> >> drive.
> >
> > Ok, let's figure out what's wrong.
> >
> > First, can you test v2.6.30-rc3 with the following patch?
> >
> > http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug.diff
> >
> >
> > Note that please enable CONFIG_DMA_API_DEBUG, CONFIG_IOMMU_DEBUG, and
> > CONFIG_IOMMU_LEAK and see if you can reproduce the problem (of course,
> > don't use any kernel option).
> >
> > When the kernel is out of IOMMU space, it prints some useful
> > information.
> >
> 
> I can't reproduce bug in 2.6.30-rc3. I read and wrote ~ 100gb data
> from and to sata drive. Dmesg has two warnings during boot,

Thanks, then let's debug 2.6.29.2.

http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug-2.6.29.diff

As you did with 2.6.30-rc3, enable CONFIG_DMA_API_DEBUG,
CONFIG_IOMMU_DEBUG, and CONFIG_IOMMU_LEAK and don't use any kernel
boot option.

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[FUJITA Tomonori]

On Mon, 4 May 2009 10:27:11 +0500
**UNKNOWN CHARSET** <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> 2009/4/28 FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>:
> > On Tue, 28 Apr 2009 14:18:57 +0500
> > **UNKNOWN CHARSET** <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> No, it is regression. I can reproduce that without allowdac and any
> >> other unnecessary boot options.
> >
> > Hmm, in the bug repport, you said that you can't reproduce the problem:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=13001#c15
> >
> > I can't find your comment like, "I can reproduce that without
> > allowdac".
> 
> I was under a misapprehension. Later discussion was been in linux-pci
> mailing list
> http://markmail.org/message/pbng73ojpllln5fl

You didn't CC to me so it was impossible for me to track this bug.


> >> In later discussion Grant Grundler ask
> >> me apply patch that show 32 bit dma devices in my system. Results I
> >> attached to bugreport. Looks like only one 32 bit dma device in my
> >> system is ata controller, sata-nv.
> >
> > Hmm, looks like http://bugzilla.kernel.org/attachment.cgi?id=20895
> > said that pata_amd and sata_nv use 32bit dma mask.
> >
> >
> >> I can stable reproduce IOMMU out of space when I write data to sata
> >> drive.
> >
> > Ok, let's figure out what's wrong.
> >
> > First, can you test v2.6.30-rc3 with the following patch?
> >
> > http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug.diff
> >
> >
> > Note that please enable CONFIG_DMA_API_DEBUG, CONFIG_IOMMU_DEBUG, and
> > CONFIG_IOMMU_LEAK and see if you can reproduce the problem (of course,
> > don't use any kernel option).
> >
> > When the kernel is out of IOMMU space, it prints some useful
> > information.
> >
> 
> I can't reproduce bug in 2.6.30-rc3. I read and wrote ~ 100gb data
> from and to sata drive. Dmesg has two warnings during boot,

Thanks, then let's debug 2.6.29.2.

http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug-2.6.29.diff

As you did with 2.6.30-rc3, enable CONFIG_DMA_API_DEBUG,
CONFIG_IOMMU_DEBUG, and CONFIG_IOMMU_LEAK and don't use any kernel
boot option.

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[FUJITA Tomonori]

On Tue, 5 May 2009 10:46:16 +0500
**UNKNOWN CHARSET** <optimusgd@gmail.com> wrote:

> Full dmesg there: http://bugzilla.kernel.org/attachment.cgi?id=21222
> Got this:
> ------------[ cut here ]------------
> WARNING: at fs/namei.c:1251 lookup_one_len+0xe9/0x100()
> Hardware name: HP xw9400 Workstation
> Modules linked in: fuse nfs auth_rpcgss lockd sunrpc scsi_wait_scan
> usbhid ohci_hcd usb_storage usb_libusual ehci_hcd usbcore
> Pid: 2717, comm: mount Not tainted 2.6.30-rc4-git1 #1
> Call Trace:
>  [<ffffffff8023ceca>] ? warn_slowpath+0xea/0x160
>  [<ffffffff80564d06>] ? printk+0x4e/0x58
>  [<ffffffff8032daea>] ? prepare_error_buf+0x51a/0x610
>  [<ffffffff802a0cfe>] ? new_slab+0x1ee/0x330
>  [<ffffffff8032dcc1>] ? reiserfs_info+0x71/0xa0
>  [<ffffffff802b3df9>] ? lookup_one_len+0xe9/0x100
>  [<ffffffff8033eaed>] ? reiserfs_xattr_init+0x3d/0xb0
>  [<ffffffff8032c4e3>] ? reiserfs_fill_super+0x663/0xb50
>  [<ffffffff805678f2>] ? __down_write_nested+0xb2/0xc0
>  [<ffffffff802a39e5>] ? kmem_cache_alloc+0x65/0xa0
>  [<ffffffff802acb22>] ? sget+0x3c2/0x410
>  [<ffffffff802ace94>] ? get_sb_bdev+0x174/0x1a0
>  [<ffffffff8032be80>] ? reiserfs_fill_super+0x0/0xb50
>  [<ffffffff802ab926>] ? vfs_kern_mount+0x56/0xd0
>  [<ffffffff802aba03>] ? do_kern_mount+0x53/0x120
>  [<ffffffff802c474a>] ? do_mount+0x2ba/0x8c0
>  [<ffffffff805691c8>] ? bad_gs+0xc34/0x1e0c
>  [<ffffffff802c4e1d>] ? sys_mount+0xcd/0x100
>  [<ffffffff8020b4eb>] ? system_call_fastpath+0x16/0x1b
> ---[ end trace 93edef2de057a0ed ]---

I think that this is a known issue.


> ------------[ cut here ]------------
> WARNING: at lib/dma-debug.c:625 check_unmap+0x3b3/0x610()
> Hardware name: HP xw9400 Workstation
> forcedeth 0000:00:09.0: DMA-API: device driver frees DMA memory with
> wrong function [device address=0x0000000023780c02] [size=42 bytes]
> [mapped as single] [unmapped as page]
> Modules linked in: nfsd exportfs iptable_filter iptable_mangle
> ip_tables x_tables snd_seq snd_seq_device vboxnetflt vboxdrv
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec nvidia(P) snd_pcm
> snd_timer snd firewire_ohci firewire_core soundcore snd_page_alloc
> tpm_infineon tpm forcedeth floppy tpm_bios fuse nfs auth_rpcgss lockd
> sunrpc scsi_wait_scan usbhid ohci_hcd usb_storage usb_libusual
> ehci_hcd usbcore
> Pid: 0, comm: swapper Tainted: P        W  2.6.30-rc4-git1 #1
> Call Trace:
>  <IRQ>  [<ffffffff8023ceca>] ? warn_slowpath+0xea/0x160
>  [<ffffffff80231ad7>] ? task_rq_lock+0x47/0x90
>  [<ffffffff8029b287>] ? dma_pool_alloc+0x1b7/0x2d0
>  [<ffffffffa0059692>] ? ohci_urb_enqueue+0x1a2/0x980 [ohci_hcd]
>  [<ffffffff80231a63>] ? __wake_up+0x43/0x70
>  [<ffffffff802343f4>] ? find_busiest_group+0x244/0x920
>  [<ffffffffa00073b7>] ? usb_hcd_submit_urb+0x117/0xa40 [usbcore]
>  [<ffffffff803f0bb3>] ? check_unmap+0x3b3/0x610
>  [<ffffffff803f0e58>] ? debug_dma_unmap_page+0x48/0x50
>  [<ffffffffa014e639>] ? nv_tx_done_optimized+0xd9/0x2c0 [forcedeth]
>  [<ffffffffa0151346>] ? nv_napi_poll+0x76/0x630 [forcedeth]
>  [<ffffffff80256a1b>] ? hrtimer_get_next_event+0xdb/0xf0
>  [<ffffffff804dcc47>] ? net_rx_action+0x87/0x130
>  [<ffffffff802421fb>] ? __do_softirq+0x7b/0x110
>  [<ffffffff8020c56c>] ? call_softirq+0x1c/0x30
>  [<ffffffff8020e315>] ? do_softirq+0x35/0x80
>  [<ffffffff80242055>] ? irq_exit+0x95/0xa0
>  [<ffffffff8020db05>] ? do_IRQ+0x85/0xf0
>  [<ffffffff8020be13>] ? ret_from_intr+0x0/0xa
>  <EOI>  [<ffffffff80213182>] ? default_idle+0x42/0x50
>  [<ffffffff802131c4>] ? c1e_idle+0x34/0x100
>  [<ffffffff80258279>] ? __atomic_notifier_call_chain+0x19/0x50
>  [<ffffffff8020a09a>] ? cpu_idle+0x5a/0xc0
> ---[ end trace 93edef2de057a0ee ]---

Can you submit a bug report to netdev@vger.kernel.org? Well, I think
that the driver just uses pci_unmap_page for the areas mapped via
pci_map_single. That's not nice but causes no harm.

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[FUJITA Tomonori]

On Tue, 5 May 2009 10:46:16 +0500
**UNKNOWN CHARSET** <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Full dmesg there: http://bugzilla.kernel.org/attachment.cgi?id=21222
> Got this:
> ------------[ cut here ]------------
> WARNING: at fs/namei.c:1251 lookup_one_len+0xe9/0x100()
> Hardware name: HP xw9400 Workstation
> Modules linked in: fuse nfs auth_rpcgss lockd sunrpc scsi_wait_scan
> usbhid ohci_hcd usb_storage usb_libusual ehci_hcd usbcore
> Pid: 2717, comm: mount Not tainted 2.6.30-rc4-git1 #1
> Call Trace:
>  [<ffffffff8023ceca>] ? warn_slowpath+0xea/0x160
>  [<ffffffff80564d06>] ? printk+0x4e/0x58
>  [<ffffffff8032daea>] ? prepare_error_buf+0x51a/0x610
>  [<ffffffff802a0cfe>] ? new_slab+0x1ee/0x330
>  [<ffffffff8032dcc1>] ? reiserfs_info+0x71/0xa0
>  [<ffffffff802b3df9>] ? lookup_one_len+0xe9/0x100
>  [<ffffffff8033eaed>] ? reiserfs_xattr_init+0x3d/0xb0
>  [<ffffffff8032c4e3>] ? reiserfs_fill_super+0x663/0xb50
>  [<ffffffff805678f2>] ? __down_write_nested+0xb2/0xc0
>  [<ffffffff802a39e5>] ? kmem_cache_alloc+0x65/0xa0
>  [<ffffffff802acb22>] ? sget+0x3c2/0x410
>  [<ffffffff802ace94>] ? get_sb_bdev+0x174/0x1a0
>  [<ffffffff8032be80>] ? reiserfs_fill_super+0x0/0xb50
>  [<ffffffff802ab926>] ? vfs_kern_mount+0x56/0xd0
>  [<ffffffff802aba03>] ? do_kern_mount+0x53/0x120
>  [<ffffffff802c474a>] ? do_mount+0x2ba/0x8c0
>  [<ffffffff805691c8>] ? bad_gs+0xc34/0x1e0c
>  [<ffffffff802c4e1d>] ? sys_mount+0xcd/0x100
>  [<ffffffff8020b4eb>] ? system_call_fastpath+0x16/0x1b
> ---[ end trace 93edef2de057a0ed ]---

I think that this is a known issue.


> ------------[ cut here ]------------
> WARNING: at lib/dma-debug.c:625 check_unmap+0x3b3/0x610()
> Hardware name: HP xw9400 Workstation
> forcedeth 0000:00:09.0: DMA-API: device driver frees DMA memory with
> wrong function [device address=0x0000000023780c02] [size=42 bytes]
> [mapped as single] [unmapped as page]
> Modules linked in: nfsd exportfs iptable_filter iptable_mangle
> ip_tables x_tables snd_seq snd_seq_device vboxnetflt vboxdrv
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec nvidia(P) snd_pcm
> snd_timer snd firewire_ohci firewire_core soundcore snd_page_alloc
> tpm_infineon tpm forcedeth floppy tpm_bios fuse nfs auth_rpcgss lockd
> sunrpc scsi_wait_scan usbhid ohci_hcd usb_storage usb_libusual
> ehci_hcd usbcore
> Pid: 0, comm: swapper Tainted: P        W  2.6.30-rc4-git1 #1
> Call Trace:
>  <IRQ>  [<ffffffff8023ceca>] ? warn_slowpath+0xea/0x160
>  [<ffffffff80231ad7>] ? task_rq_lock+0x47/0x90
>  [<ffffffff8029b287>] ? dma_pool_alloc+0x1b7/0x2d0
>  [<ffffffffa0059692>] ? ohci_urb_enqueue+0x1a2/0x980 [ohci_hcd]
>  [<ffffffff80231a63>] ? __wake_up+0x43/0x70
>  [<ffffffff802343f4>] ? find_busiest_group+0x244/0x920
>  [<ffffffffa00073b7>] ? usb_hcd_submit_urb+0x117/0xa40 [usbcore]
>  [<ffffffff803f0bb3>] ? check_unmap+0x3b3/0x610
>  [<ffffffff803f0e58>] ? debug_dma_unmap_page+0x48/0x50
>  [<ffffffffa014e639>] ? nv_tx_done_optimized+0xd9/0x2c0 [forcedeth]
>  [<ffffffffa0151346>] ? nv_napi_poll+0x76/0x630 [forcedeth]
>  [<ffffffff80256a1b>] ? hrtimer_get_next_event+0xdb/0xf0
>  [<ffffffff804dcc47>] ? net_rx_action+0x87/0x130
>  [<ffffffff802421fb>] ? __do_softirq+0x7b/0x110
>  [<ffffffff8020c56c>] ? call_softirq+0x1c/0x30
>  [<ffffffff8020e315>] ? do_softirq+0x35/0x80
>  [<ffffffff80242055>] ? irq_exit+0x95/0xa0
>  [<ffffffff8020db05>] ? do_IRQ+0x85/0xf0
>  [<ffffffff8020be13>] ? ret_from_intr+0x0/0xa
>  <EOI>  [<ffffffff80213182>] ? default_idle+0x42/0x50
>  [<ffffffff802131c4>] ? c1e_idle+0x34/0x100
>  [<ffffffff80258279>] ? __atomic_notifier_call_chain+0x19/0x50
>  [<ffffffff8020a09a>] ? cpu_idle+0x5a/0xc0
> ---[ end trace 93edef2de057a0ee ]---

Can you submit a bug report to netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org? Well, I think
that the driver just uses pci_unmap_page for the areas mapped via
pci_map_single. That's not nice but causes no harm.

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[Данила Жукоцкий]

Full dmesg there: http://bugzilla.kernel.org/attachment.cgi?id=21222
Got this:
------------[ cut here ]------------
WARNING: at fs/namei.c:1251 lookup_one_len+0xe9/0x100()
Hardware name: HP xw9400 Workstation
Modules linked in: fuse nfs auth_rpcgss lockd sunrpc scsi_wait_scan
usbhid ohci_hcd usb_storage usb_libusual ehci_hcd usbcore
Pid: 2717, comm: mount Not tainted 2.6.30-rc4-git1 #1
Call Trace:
 [<ffffffff8023ceca>] ? warn_slowpath+0xea/0x160
 [<ffffffff80564d06>] ? printk+0x4e/0x58
 [<ffffffff8032daea>] ? prepare_error_buf+0x51a/0x610
 [<ffffffff802a0cfe>] ? new_slab+0x1ee/0x330
 [<ffffffff8032dcc1>] ? reiserfs_info+0x71/0xa0
 [<ffffffff802b3df9>] ? lookup_one_len+0xe9/0x100
 [<ffffffff8033eaed>] ? reiserfs_xattr_init+0x3d/0xb0
 [<ffffffff8032c4e3>] ? reiserfs_fill_super+0x663/0xb50
 [<ffffffff805678f2>] ? __down_write_nested+0xb2/0xc0
 [<ffffffff802a39e5>] ? kmem_cache_alloc+0x65/0xa0
 [<ffffffff802acb22>] ? sget+0x3c2/0x410
 [<ffffffff802ace94>] ? get_sb_bdev+0x174/0x1a0
 [<ffffffff8032be80>] ? reiserfs_fill_super+0x0/0xb50
 [<ffffffff802ab926>] ? vfs_kern_mount+0x56/0xd0
 [<ffffffff802aba03>] ? do_kern_mount+0x53/0x120
 [<ffffffff802c474a>] ? do_mount+0x2ba/0x8c0
 [<ffffffff805691c8>] ? bad_gs+0xc34/0x1e0c
 [<ffffffff802c4e1d>] ? sys_mount+0xcd/0x100
 [<ffffffff8020b4eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 93edef2de057a0ed ]---

and

------------[ cut here ]------------
WARNING: at lib/dma-debug.c:625 check_unmap+0x3b3/0x610()
Hardware name: HP xw9400 Workstation
forcedeth 0000:00:09.0: DMA-API: device driver frees DMA memory with
wrong function [device address=0x0000000023780c02] [size=42 bytes]
[mapped as single] [unmapped as page]
Modules linked in: nfsd exportfs iptable_filter iptable_mangle
ip_tables x_tables snd_seq snd_seq_device vboxnetflt vboxdrv
snd_hda_codec_realtek snd_hda_intel snd_hda_codec nvidia(P) snd_pcm
snd_timer snd firewire_ohci firewire_core soundcore snd_page_alloc
tpm_infineon tpm forcedeth floppy tpm_bios fuse nfs auth_rpcgss lockd
sunrpc scsi_wait_scan usbhid ohci_hcd usb_storage usb_libusual
ehci_hcd usbcore
Pid: 0, comm: swapper Tainted: P        W  2.6.30-rc4-git1 #1
Call Trace:
 <IRQ>  [<ffffffff8023ceca>] ? warn_slowpath+0xea/0x160
 [<ffffffff80231ad7>] ? task_rq_lock+0x47/0x90
 [<ffffffff8029b287>] ? dma_pool_alloc+0x1b7/0x2d0
 [<ffffffffa0059692>] ? ohci_urb_enqueue+0x1a2/0x980 [ohci_hcd]
 [<ffffffff80231a63>] ? __wake_up+0x43/0x70
 [<ffffffff802343f4>] ? find_busiest_group+0x244/0x920
 [<ffffffffa00073b7>] ? usb_hcd_submit_urb+0x117/0xa40 [usbcore]
 [<ffffffff803f0bb3>] ? check_unmap+0x3b3/0x610
 [<ffffffff803f0e58>] ? debug_dma_unmap_page+0x48/0x50
 [<ffffffffa014e639>] ? nv_tx_done_optimized+0xd9/0x2c0 [forcedeth]
 [<ffffffffa0151346>] ? nv_napi_poll+0x76/0x630 [forcedeth]
 [<ffffffff80256a1b>] ? hrtimer_get_next_event+0xdb/0xf0
 [<ffffffff804dcc47>] ? net_rx_action+0x87/0x130
 [<ffffffff802421fb>] ? __do_softirq+0x7b/0x110
 [<ffffffff8020c56c>] ? call_softirq+0x1c/0x30
 [<ffffffff8020e315>] ? do_softirq+0x35/0x80
 [<ffffffff80242055>] ? irq_exit+0x95/0xa0
 [<ffffffff8020db05>] ? do_IRQ+0x85/0xf0
 [<ffffffff8020be13>] ? ret_from_intr+0x0/0xa
 <EOI>  [<ffffffff80213182>] ? default_idle+0x42/0x50
 [<ffffffff802131c4>] ? c1e_idle+0x34/0x100
 [<ffffffff80258279>] ? __atomic_notifier_call_chain+0x19/0x50
 [<ffffffff8020a09a>] ? cpu_idle+0x5a/0xc0
---[ end trace 93edef2de057a0ee ]---



2009/5/5 adam radford <aradford@gmail.com>:
> 2009/5/4 Grant Grundler <grundler@google.com>:
>> 2009/5/3 Данила Жукоцкий <optimusgd@gmail.com>:
>> ...
>>> WARNING: at lib/dma-debug.c:607 check_unmap+0x542/0x610()
>>> Hardware name: HP xw9400 Workstation
>>> 3w-9xxx 0001:45:00.0: DMA-API: device driver tries to free DMA memory
>>> it has not allocated [device address=0x0000000000000000] [size=36
>>> bytes]
>>
>> This is definitely a driver bug. Just follow the stack trace back to
>> the device driver.
>>
>
> I think this is a regression from the scsi_dma_map()/unmap() changes a while
> back.
>
> Can you try this patch?
>
> Thanks,
>
> -Adam
>
> diff -Naur linux-2.6.30-rc4/drivers/scsi/3w-9xxx.c
> linux-2.6.30-rc4.new/drivers/scsi/3w-9xxx.c
> --- linux-2.6.30-rc4/drivers/scsi/3w-9xxx.c     2009-05-04 21:19:49.000000000 -0700
> +++ linux-2.6.30-rc4.new/drivers/scsi/3w-9xxx.c 2009-05-04
> 21:23:59.000000000 -0700
> @@ -1978,7 +1978,8 @@
>  {
>        struct scsi_cmnd *cmd = tw_dev->srb[request_id];
>
> -       scsi_dma_unmap(cmd);
> +       if (cmd->SCp.phase == TW_PHASE_SGLIST)
> +               scsi_dma_unmap(cmd);
>  } /* End twa_unmap_scsi_data() */
>
>  /* scsi_host_template initializer */
>



-- 
С уважением Данила Жукоцкий, системный администратор ЗАО "Роснефтегазмаш"

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[Данила Жукоцкий]

Full dmesg there: http://bugzilla.kernel.org/attachment.cgi?id=21222
Got this:
------------[ cut here ]------------
WARNING: at fs/namei.c:1251 lookup_one_len+0xe9/0x100()
Hardware name: HP xw9400 Workstation
Modules linked in: fuse nfs auth_rpcgss lockd sunrpc scsi_wait_scan
usbhid ohci_hcd usb_storage usb_libusual ehci_hcd usbcore
Pid: 2717, comm: mount Not tainted 2.6.30-rc4-git1 #1
Call Trace:
 [<ffffffff8023ceca>] ? warn_slowpath+0xea/0x160
 [<ffffffff80564d06>] ? printk+0x4e/0x58
 [<ffffffff8032daea>] ? prepare_error_buf+0x51a/0x610
 [<ffffffff802a0cfe>] ? new_slab+0x1ee/0x330
 [<ffffffff8032dcc1>] ? reiserfs_info+0x71/0xa0
 [<ffffffff802b3df9>] ? lookup_one_len+0xe9/0x100
 [<ffffffff8033eaed>] ? reiserfs_xattr_init+0x3d/0xb0
 [<ffffffff8032c4e3>] ? reiserfs_fill_super+0x663/0xb50
 [<ffffffff805678f2>] ? __down_write_nested+0xb2/0xc0
 [<ffffffff802a39e5>] ? kmem_cache_alloc+0x65/0xa0
 [<ffffffff802acb22>] ? sget+0x3c2/0x410
 [<ffffffff802ace94>] ? get_sb_bdev+0x174/0x1a0
 [<ffffffff8032be80>] ? reiserfs_fill_super+0x0/0xb50
 [<ffffffff802ab926>] ? vfs_kern_mount+0x56/0xd0
 [<ffffffff802aba03>] ? do_kern_mount+0x53/0x120
 [<ffffffff802c474a>] ? do_mount+0x2ba/0x8c0
 [<ffffffff805691c8>] ? bad_gs+0xc34/0x1e0c
 [<ffffffff802c4e1d>] ? sys_mount+0xcd/0x100
 [<ffffffff8020b4eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace 93edef2de057a0ed ]---

and

------------[ cut here ]------------
WARNING: at lib/dma-debug.c:625 check_unmap+0x3b3/0x610()
Hardware name: HP xw9400 Workstation
forcedeth 0000:00:09.0: DMA-API: device driver frees DMA memory with
wrong function [device address=0x0000000023780c02] [size=42 bytes]
[mapped as single] [unmapped as page]
Modules linked in: nfsd exportfs iptable_filter iptable_mangle
ip_tables x_tables snd_seq snd_seq_device vboxnetflt vboxdrv
snd_hda_codec_realtek snd_hda_intel snd_hda_codec nvidia(P) snd_pcm
snd_timer snd firewire_ohci firewire_core soundcore snd_page_alloc
tpm_infineon tpm forcedeth floppy tpm_bios fuse nfs auth_rpcgss lockd
sunrpc scsi_wait_scan usbhid ohci_hcd usb_storage usb_libusual
ehci_hcd usbcore
Pid: 0, comm: swapper Tainted: P        W  2.6.30-rc4-git1 #1
Call Trace:
 <IRQ>  [<ffffffff8023ceca>] ? warn_slowpath+0xea/0x160
 [<ffffffff80231ad7>] ? task_rq_lock+0x47/0x90
 [<ffffffff8029b287>] ? dma_pool_alloc+0x1b7/0x2d0
 [<ffffffffa0059692>] ? ohci_urb_enqueue+0x1a2/0x980 [ohci_hcd]
 [<ffffffff80231a63>] ? __wake_up+0x43/0x70
 [<ffffffff802343f4>] ? find_busiest_group+0x244/0x920
 [<ffffffffa00073b7>] ? usb_hcd_submit_urb+0x117/0xa40 [usbcore]
 [<ffffffff803f0bb3>] ? check_unmap+0x3b3/0x610
 [<ffffffff803f0e58>] ? debug_dma_unmap_page+0x48/0x50
 [<ffffffffa014e639>] ? nv_tx_done_optimized+0xd9/0x2c0 [forcedeth]
 [<ffffffffa0151346>] ? nv_napi_poll+0x76/0x630 [forcedeth]
 [<ffffffff80256a1b>] ? hrtimer_get_next_event+0xdb/0xf0
 [<ffffffff804dcc47>] ? net_rx_action+0x87/0x130
 [<ffffffff802421fb>] ? __do_softirq+0x7b/0x110
 [<ffffffff8020c56c>] ? call_softirq+0x1c/0x30
 [<ffffffff8020e315>] ? do_softirq+0x35/0x80
 [<ffffffff80242055>] ? irq_exit+0x95/0xa0
 [<ffffffff8020db05>] ? do_IRQ+0x85/0xf0
 [<ffffffff8020be13>] ? ret_from_intr+0x0/0xa
 <EOI>  [<ffffffff80213182>] ? default_idle+0x42/0x50
 [<ffffffff802131c4>] ? c1e_idle+0x34/0x100
 [<ffffffff80258279>] ? __atomic_notifier_call_chain+0x19/0x50
 [<ffffffff8020a09a>] ? cpu_idle+0x5a/0xc0
---[ end trace 93edef2de057a0ee ]---



2009/5/5 adam radford <aradford-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 2009/5/4 Grant Grundler <grundler-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>:
>> 2009/5/3 Данила Жукоцкий <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> ...
>>> WARNING: at lib/dma-debug.c:607 check_unmap+0x542/0x610()
>>> Hardware name: HP xw9400 Workstation
>>> 3w-9xxx 0001:45:00.0: DMA-API: device driver tries to free DMA memory
>>> it has not allocated [device address=0x0000000000000000] [size=36
>>> bytes]
>>
>> This is definitely a driver bug. Just follow the stack trace back to
>> the device driver.
>>
>
> I think this is a regression from the scsi_dma_map()/unmap() changes a while
> back.
>
> Can you try this patch?
>
> Thanks,
>
> -Adam
>
> diff -Naur linux-2.6.30-rc4/drivers/scsi/3w-9xxx.c
> linux-2.6.30-rc4.new/drivers/scsi/3w-9xxx.c
> --- linux-2.6.30-rc4/drivers/scsi/3w-9xxx.c     2009-05-04 21:19:49.000000000 -0700
> +++ linux-2.6.30-rc4.new/drivers/scsi/3w-9xxx.c 2009-05-04
> 21:23:59.000000000 -0700
> @@ -1978,7 +1978,8 @@
>  {
>        struct scsi_cmnd *cmd = tw_dev->srb[request_id];
>
> -       scsi_dma_unmap(cmd);
> +       if (cmd->SCp.phase == TW_PHASE_SGLIST)
> +               scsi_dma_unmap(cmd);
>  } /* End twa_unmap_scsi_data() */
>
>  /* scsi_host_template initializer */
>



-- 
С уважением Данила Жукоцкий, системный администратор ЗАО "Роснефтегазмаш"

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[adam radford]

2009/5/4 Grant Grundler <grundler@google.com>:
> 2009/5/3 Данила Жукоцкий <optimusgd@gmail.com>:
> ...
>> WARNING: at lib/dma-debug.c:607 check_unmap+0x542/0x610()
>> Hardware name: HP xw9400 Workstation
>> 3w-9xxx 0001:45:00.0: DMA-API: device driver tries to free DMA memory
>> it has not allocated [device address=0x0000000000000000] [size=36
>> bytes]
>
> This is definitely a driver bug. Just follow the stack trace back to
> the device driver.
>

I think this is a regression from the scsi_dma_map()/unmap() changes a while
back.

Can you try this patch?

Thanks,

-Adam

diff -Naur linux-2.6.30-rc4/drivers/scsi/3w-9xxx.c
linux-2.6.30-rc4.new/drivers/scsi/3w-9xxx.c
--- linux-2.6.30-rc4/drivers/scsi/3w-9xxx.c	2009-05-04 21:19:49.000000000 -0700
+++ linux-2.6.30-rc4.new/drivers/scsi/3w-9xxx.c	2009-05-04
21:23:59.000000000 -0700
@@ -1978,7 +1978,8 @@
 {
 	struct scsi_cmnd *cmd = tw_dev->srb[request_id];

-	scsi_dma_unmap(cmd);
+	if (cmd->SCp.phase == TW_PHASE_SGLIST)
+		scsi_dma_unmap(cmd);
 } /* End twa_unmap_scsi_data() */

 /* scsi_host_template initializer */

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[Grant Grundler]

2009/5/3 Данила Жукоцкий <optimusgd@gmail.com>:
...
> WARNING: at lib/dma-debug.c:607 check_unmap+0x542/0x610()
> Hardware name: HP xw9400 Workstation
> 3w-9xxx 0001:45:00.0: DMA-API: device driver tries to free DMA memory
> it has not allocated [device address=0x0000000000000000] [size=36
> bytes]

This is definitely a driver bug. Just follow the stack trace back to
the device driver.

thanks!
grant

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[Grant Grundler]

2009/5/3 Данила Жукоцкий <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
...
> WARNING: at lib/dma-debug.c:607 check_unmap+0x542/0x610()
> Hardware name: HP xw9400 Workstation
> 3w-9xxx 0001:45:00.0: DMA-API: device driver tries to free DMA memory
> it has not allocated [device address=0x0000000000000000] [size=36
> bytes]

This is definitely a driver bug. Just follow the stack trace back to
the device driver.

thanks!
grant

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[Данила Жукоцкий]

2009/4/28 FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>:
> On Tue, 28 Apr 2009 14:18:57 +0500
> **UNKNOWN CHARSET** <optimusgd@gmail.com> wrote:
>
>> No, it is regression. I can reproduce that without allowdac and any
>> other unnecessary boot options.
>
> Hmm, in the bug repport, you said that you can't reproduce the problem:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13001#c15
>
> I can't find your comment like, "I can reproduce that without
> allowdac".

I was under a misapprehension. Later discussion was been in linux-pci
mailing list
http://markmail.org/message/pbng73ojpllln5fl

>
>> In later discussion Grant Grundler ask
>> me apply patch that show 32 bit dma devices in my system. Results I
>> attached to bugreport. Looks like only one 32 bit dma device in my
>> system is ata controller, sata-nv.
>
> Hmm, looks like http://bugzilla.kernel.org/attachment.cgi?id=20895
> said that pata_amd and sata_nv use 32bit dma mask.
>
>
>> I can stable reproduce IOMMU out of space when I write data to sata
>> drive.
>
> Ok, let's figure out what's wrong.
>
> First, can you test v2.6.30-rc3 with the following patch?
>
> http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug.diff
>
>
> Note that please enable CONFIG_DMA_API_DEBUG, CONFIG_IOMMU_DEBUG, and
> CONFIG_IOMMU_LEAK and see if you can reproduce the problem (of course,
> don't use any kernel option).
>
> When the kernel is out of IOMMU space, it prints some useful
> information.
>

I can't reproduce bug in 2.6.30-rc3. I read and wrote ~ 100gb data
from and to sata drive. Dmesg has two warnings during boot,

------------[ cut here ]------------
WARNING: at lib/dma-debug.c:607 check_unmap+0x542/0x610()
Hardware name: HP xw9400 Workstation
3w-9xxx 0001:45:00.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x0000000000000000] [size=36
bytes]
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.30-rc3-git7 #1
Call Trace:
 <IRQ>  [<ffffffff8023ce2a>] ? warn_slowpath+0xea/0x160
 [<ffffffff802589ae>] ? sched_clock_cpu+0x6e/0x240
 [<ffffffff802370a2>] ? scheduler_tick+0xc2/0x220
 [<ffffffff80259f4b>] ? getnstimeofday+0x5b/0xe0
 [<ffffffff80256b30>] ? ktime_get_ts+0x30/0x60
 [<ffffffff80256b6c>] ? ktime_get+0xc/0x50
 [<ffffffff8021d828>] ? lapic_next_event+0x18/0x20
 [<ffffffff8025e1d6>] ? tick_dev_program_event+0x36/0xb0
 [<ffffffff8021e29c>] ? smp_apic_timer_interrupt+0x6c/0xa0
 [<ffffffff8020bf83>] ? apic_timer_interrupt+0x13/0x20
 [<ffffffff8023db13>] ? vprintk+0x2d3/0x420
 [<ffffffff803f0b12>] ? check_unmap+0x542/0x610
 [<ffffffff803f0d0e>] ? debug_dma_unmap_sg+0xde/0x180
 [<ffffffff8046c0fb>] ? scsi_dma_unmap+0x6b/0xa0
 [<ffffffff80472559>] ? twa_interrupt+0x3e9/0x6a0
 [<ffffffff80256f2d>] ? __hrtimer_start_range_ns+0x12d/0x2b0
 [<ffffffff8026b3b9>] ? handle_IRQ_event+0x59/0x130
 [<ffffffff8026d4e1>] ? handle_edge_irq+0xc1/0x160
 [<ffffffff8020e377>] ? handle_irq+0x17/0x20
 [<ffffffff8020dae5>] ? do_IRQ+0x65/0xf0
 [<ffffffff8020be13>] ? ret_from_intr+0x0/0xa
 <EOI>  [<ffffffff80213182>] ? default_idle+0x42/0x50
 [<ffffffff802131c4>] ? c1e_idle+0x34/0x100
 [<ffffffff802581d9>] ? __atomic_notifier_call_chain+0x19/0x50
 [<ffffffff8020a09a>] ? cpu_idle+0x5a/0xc0
---[ end trace eedd91b655a6fdac ]---

and

------------[ cut here ]------------
WARNING: at fs/namei.c:1251 lookup_one_len+0xe9/0x100()
Hardware name: HP xw9400 Workstation
Modules linked in: fuse nfs auth_rpcgss lockd sunrpc scsi_wait_scan
usbhid ohci_hcd usb_storage usb_libusual ehci_hcd usbcore
Pid: 2807, comm: mount Tainted: G        W  2.6.30-rc3-git7 #1
Call Trace:
 [<ffffffff8023ce2a>] ? warn_slowpath+0xea/0x160
 [<ffffffff80564ac6>] ? printk+0x4e/0x58
 [<ffffffff8032d8ba>] ? prepare_error_buf+0x51a/0x610
 [<ffffffff802a0afe>] ? new_slab+0x1ee/0x330
 [<ffffffff8032da91>] ? reiserfs_info+0x71/0xa0
 [<ffffffff802b3bb9>] ? lookup_one_len+0xe9/0x100
 [<ffffffff8033e8bd>] ? reiserfs_xattr_init+0x3d/0xb0
 [<ffffffff8032c2b3>] ? reiserfs_fill_super+0x663/0xb50
 [<ffffffff803dfad2>] ? kobject_get+0x12/0x20
 [<ffffffff80457864>] ? get_device+0x14/0x20
 [<ffffffff805676b2>] ? __down_write_nested+0xb2/0xc0
 [<ffffffff802a37e5>] ? kmem_cache_alloc+0x65/0xa0
 [<ffffffff802ac922>] ? sget+0x3c2/0x410
 [<ffffffff802acc94>] ? get_sb_bdev+0x174/0x1a0
 [<ffffffff8032bc50>] ? reiserfs_fill_super+0x0/0xb50
 [<ffffffff802ab726>] ? vfs_kern_mount+0x56/0xd0
 [<ffffffff802ab803>] ? do_kern_mount+0x53/0x120
 [<ffffffff802c450a>] ? do_mount+0x2ba/0x8c0
 [<ffffffff80568f88>] ? bad_gs+0xc34/0x1e0c
 [<ffffffff802c4bdd>] ? sys_mount+0xcd/0x100
 [<ffffffff8020b4eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace eedd91b655a6fdae ]---

So I hope that bug is gone.

-- 
С уважением Данила Жукоцкий, системный администратор ЗАО "Роснефтегазмаш"

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[Данила Жукоцкий]

2009/4/28 FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>:
> On Tue, 28 Apr 2009 14:18:57 +0500
> **UNKNOWN CHARSET** <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> No, it is regression. I can reproduce that without allowdac and any
>> other unnecessary boot options.
>
> Hmm, in the bug repport, you said that you can't reproduce the problem:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13001#c15
>
> I can't find your comment like, "I can reproduce that without
> allowdac".

I was under a misapprehension. Later discussion was been in linux-pci
mailing list
http://markmail.org/message/pbng73ojpllln5fl

>
>> In later discussion Grant Grundler ask
>> me apply patch that show 32 bit dma devices in my system. Results I
>> attached to bugreport. Looks like only one 32 bit dma device in my
>> system is ata controller, sata-nv.
>
> Hmm, looks like http://bugzilla.kernel.org/attachment.cgi?id=20895
> said that pata_amd and sata_nv use 32bit dma mask.
>
>
>> I can stable reproduce IOMMU out of space when I write data to sata
>> drive.
>
> Ok, let's figure out what's wrong.
>
> First, can you test v2.6.30-rc3 with the following patch?
>
> http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug.diff
>
>
> Note that please enable CONFIG_DMA_API_DEBUG, CONFIG_IOMMU_DEBUG, and
> CONFIG_IOMMU_LEAK and see if you can reproduce the problem (of course,
> don't use any kernel option).
>
> When the kernel is out of IOMMU space, it prints some useful
> information.
>

I can't reproduce bug in 2.6.30-rc3. I read and wrote ~ 100gb data
from and to sata drive. Dmesg has two warnings during boot,

------------[ cut here ]------------
WARNING: at lib/dma-debug.c:607 check_unmap+0x542/0x610()
Hardware name: HP xw9400 Workstation
3w-9xxx 0001:45:00.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x0000000000000000] [size=36
bytes]
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.30-rc3-git7 #1
Call Trace:
 <IRQ>  [<ffffffff8023ce2a>] ? warn_slowpath+0xea/0x160
 [<ffffffff802589ae>] ? sched_clock_cpu+0x6e/0x240
 [<ffffffff802370a2>] ? scheduler_tick+0xc2/0x220
 [<ffffffff80259f4b>] ? getnstimeofday+0x5b/0xe0
 [<ffffffff80256b30>] ? ktime_get_ts+0x30/0x60
 [<ffffffff80256b6c>] ? ktime_get+0xc/0x50
 [<ffffffff8021d828>] ? lapic_next_event+0x18/0x20
 [<ffffffff8025e1d6>] ? tick_dev_program_event+0x36/0xb0
 [<ffffffff8021e29c>] ? smp_apic_timer_interrupt+0x6c/0xa0
 [<ffffffff8020bf83>] ? apic_timer_interrupt+0x13/0x20
 [<ffffffff8023db13>] ? vprintk+0x2d3/0x420
 [<ffffffff803f0b12>] ? check_unmap+0x542/0x610
 [<ffffffff803f0d0e>] ? debug_dma_unmap_sg+0xde/0x180
 [<ffffffff8046c0fb>] ? scsi_dma_unmap+0x6b/0xa0
 [<ffffffff80472559>] ? twa_interrupt+0x3e9/0x6a0
 [<ffffffff80256f2d>] ? __hrtimer_start_range_ns+0x12d/0x2b0
 [<ffffffff8026b3b9>] ? handle_IRQ_event+0x59/0x130
 [<ffffffff8026d4e1>] ? handle_edge_irq+0xc1/0x160
 [<ffffffff8020e377>] ? handle_irq+0x17/0x20
 [<ffffffff8020dae5>] ? do_IRQ+0x65/0xf0
 [<ffffffff8020be13>] ? ret_from_intr+0x0/0xa
 <EOI>  [<ffffffff80213182>] ? default_idle+0x42/0x50
 [<ffffffff802131c4>] ? c1e_idle+0x34/0x100
 [<ffffffff802581d9>] ? __atomic_notifier_call_chain+0x19/0x50
 [<ffffffff8020a09a>] ? cpu_idle+0x5a/0xc0
---[ end trace eedd91b655a6fdac ]---

and

------------[ cut here ]------------
WARNING: at fs/namei.c:1251 lookup_one_len+0xe9/0x100()
Hardware name: HP xw9400 Workstation
Modules linked in: fuse nfs auth_rpcgss lockd sunrpc scsi_wait_scan
usbhid ohci_hcd usb_storage usb_libusual ehci_hcd usbcore
Pid: 2807, comm: mount Tainted: G        W  2.6.30-rc3-git7 #1
Call Trace:
 [<ffffffff8023ce2a>] ? warn_slowpath+0xea/0x160
 [<ffffffff80564ac6>] ? printk+0x4e/0x58
 [<ffffffff8032d8ba>] ? prepare_error_buf+0x51a/0x610
 [<ffffffff802a0afe>] ? new_slab+0x1ee/0x330
 [<ffffffff8032da91>] ? reiserfs_info+0x71/0xa0
 [<ffffffff802b3bb9>] ? lookup_one_len+0xe9/0x100
 [<ffffffff8033e8bd>] ? reiserfs_xattr_init+0x3d/0xb0
 [<ffffffff8032c2b3>] ? reiserfs_fill_super+0x663/0xb50
 [<ffffffff803dfad2>] ? kobject_get+0x12/0x20
 [<ffffffff80457864>] ? get_device+0x14/0x20
 [<ffffffff805676b2>] ? __down_write_nested+0xb2/0xc0
 [<ffffffff802a37e5>] ? kmem_cache_alloc+0x65/0xa0
 [<ffffffff802ac922>] ? sget+0x3c2/0x410
 [<ffffffff802acc94>] ? get_sb_bdev+0x174/0x1a0
 [<ffffffff8032bc50>] ? reiserfs_fill_super+0x0/0xb50
 [<ffffffff802ab726>] ? vfs_kern_mount+0x56/0xd0
 [<ffffffff802ab803>] ? do_kern_mount+0x53/0x120
 [<ffffffff802c450a>] ? do_mount+0x2ba/0x8c0
 [<ffffffff80568f88>] ? bad_gs+0xc34/0x1e0c
 [<ffffffff802c4bdd>] ? sys_mount+0xcd/0x100
 [<ffffffff8020b4eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace eedd91b655a6fdae ]---

So I hope that bug is gone.

-- 
С уважением Данила Жукоцкий, системный администратор ЗАО "Роснефтегазмаш"

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[FUJITA Tomonori]

On Tue, 28 Apr 2009 14:18:57 +0500
**UNKNOWN CHARSET** <optimusgd@gmail.com> wrote:

> No, it is regression. I can reproduce that without allowdac and any
> other unnecessary boot options.

Hmm, in the bug repport, you said that you can't reproduce the problem:

http://bugzilla.kernel.org/show_bug.cgi?id=13001#c15

I can't find your comment like, "I can reproduce that without
allowdac".

> In later discussion Grant Grundler ask
> me apply patch that show 32 bit dma devices in my system. Results I
> attached to bugreport. Looks like only one 32 bit dma device in my
> system is ata controller, sata-nv.

Hmm, looks like http://bugzilla.kernel.org/attachment.cgi?id=20895
said that pata_amd and sata_nv use 32bit dma mask.


> I can stable reproduce IOMMU out of space when I write data to sata
> drive.

Ok, let's figure out what's wrong.

First, can you test v2.6.30-rc3 with the following patch?

http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug.diff


Note that please enable CONFIG_DMA_API_DEBUG, CONFIG_IOMMU_DEBUG, and
CONFIG_IOMMU_LEAK and see if you can reproduce the problem (of course,
don't use any kernel option).

When the kernel is out of IOMMU space, it prints some useful
information.

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[FUJITA Tomonori]

On Tue, 28 Apr 2009 14:18:57 +0500
**UNKNOWN CHARSET** <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> No, it is regression. I can reproduce that without allowdac and any
> other unnecessary boot options.

Hmm, in the bug repport, you said that you can't reproduce the problem:

http://bugzilla.kernel.org/show_bug.cgi?id=13001#c15

I can't find your comment like, "I can reproduce that without
allowdac".

> In later discussion Grant Grundler ask
> me apply patch that show 32 bit dma devices in my system. Results I
> attached to bugreport. Looks like only one 32 bit dma device in my
> system is ata controller, sata-nv.

Hmm, looks like http://bugzilla.kernel.org/attachment.cgi?id=20895
said that pata_amd and sata_nv use 32bit dma mask.


> I can stable reproduce IOMMU out of space when I write data to sata
> drive.

Ok, let's figure out what's wrong.

First, can you test v2.6.30-rc3 with the following patch?

http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug.diff


Note that please enable CONFIG_DMA_API_DEBUG, CONFIG_IOMMU_DEBUG, and
CONFIG_IOMMU_LEAK and see if you can reproduce the problem (of course,
don't use any kernel option).

When the kernel is out of IOMMU space, it prints some useful
information.

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[Данила Жукоцкий]

No, it is regression. I can reproduce that without allowdac and any
other unnecessary boot options. In later discussion Grant Grundler ask
me apply patch that show 32 bit dma devices in my system. Results I
attached to bugreport. Looks like only one 32 bit dma device in my
system is ata controller, sata-nv. I can stable reproduce IOMMU out of
space when I write data to sata drive.

2009/4/28 FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>:
> On Sun, 26 Apr 2009 11:46:28 +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=13001
>> Subject               : PCI-DMA: Out of IOMMU space
>> Submitter     :  <optimusgd@gmail.com>
>> Date          : 2009-04-03 09:30 (24 days old)
>
> Probably, this is not a regression.
>
> He doesn't hit this problem with 2.6.29 when he uses the kernel boot
> option that he used with 2.6.28. I have no idea how not using
> 'allowdac' can solve the problem though.
>



-- 
С уважением Данила Жукоцкий, системный администратор ЗАО "Роснефтегазмаш"

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[Данила Жукоцкий]

No, it is regression. I can reproduce that without allowdac and any
other unnecessary boot options. In later discussion Grant Grundler ask
me apply patch that show 32 bit dma devices in my system. Results I
attached to bugreport. Looks like only one 32 bit dma device in my
system is ata controller, sata-nv. I can stable reproduce IOMMU out of
space when I write data to sata drive.

2009/4/28 FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>:
> On Sun, 26 Apr 2009 11:46:28 +0200 (CEST)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.28 and 2.6.29.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13001
>> Subject               : PCI-DMA: Out of IOMMU space
>> Submitter     :  <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date          : 2009-04-03 09:30 (24 days old)
>
> Probably, this is not a regression.
>
> He doesn't hit this problem with 2.6.29 when he uses the kernel boot
> option that he used with 2.6.28. I have no idea how not using
> 'allowdac' can solve the problem though.
>



-- 
С уважением Данила Жукоцкий, системный администратор ЗАО "Роснефтегазмаш"

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[FUJITA Tomonori]

On Sun, 26 Apr 2009 11:46:28 +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=13001
> Subject		: PCI-DMA: Out of IOMMU space
> Submitter	:  <optimusgd@gmail.com>
> Date		: 2009-04-03 09:30 (24 days old)

Probably, this is not a regression.

He doesn't hit this problem with 2.6.29 when he uses the kernel boot
option that he used with 2.6.28. I have no idea how not using
'allowdac' can solve the problem though.

Re: [Bug #13001] PCI-DMA: Out of IOMMU space

[FUJITA Tomonori]

On Sun, 26 Apr 2009 11:46:28 +0200 (CEST)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13001
> Subject		: PCI-DMA: Out of IOMMU space
> Submitter	:  <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-04-03 09:30 (24 days old)

Probably, this is not a regression.

He doesn't hit this problem with 2.6.29 when he uses the kernel boot
option that he used with 2.6.28. I have no idea how not using
'allowdac' can solve the problem though.

[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 (24 days old)

[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 (24 days old)

[Bug #13001] PCI-DMA: Out of IOMMU space

[Rafael J. Wysocki]

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

The following bug entry is on the current list of known regressions
from 2.6.28.  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 (4 days old)

[Bug #13001] PCI-DMA: Out of IOMMU space

[Rafael J. Wysocki]

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

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject		: PCI-DMA: Out of IOMMU space
Submitter	:  <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-03 09:30 (4 days old)