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

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

[bugzilla-daemon]

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


Rafael J. Wysocki <rjw@sisk.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rjw@sisk.pl
             Blocks|                            |12398




-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #2 from Jan Kara <jack@suse.cz>  2009-05-12 16:56:04 ---
  Hi,

> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).

> > SysRq : Show Blocked State
> >   task                PC stack   pid father
> > kjournald     D c01384df     0  2525      2
> >  cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> >  de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> >  00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > Call Trace:
> >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> >  [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> >  [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> >  [<c0122a25>] ? del_timer+0x50/0x59
> >  [<c01c0c75>] kjournald+0xad/0x1bb
> >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> >  [<c01c0bc8>] ? kjournald+0x0/0x1bb
> >  [<c012b442>] kthread+0x37/0x59
> >  [<c012b40b>] ? kthread+0x0/0x59
> >  [<c0103667>] kernel_thread_helper+0x7/0x10
> 
> I assume this is
> 
> 	while (commit_transaction->t_updates) {
> 		DEFINE_WAIT(wait);
> 
> 		prepare_to_wait(&journal->j_wait_updates, &wait,
> 					TASK_UNINTERRUPTIBLE);
> 		if (commit_transaction->t_updates) {
> 			spin_unlock(&commit_transaction->t_handle_lock);
> 			spin_unlock(&journal->j_state_lock);
> 			schedule();
  Yes.

> I'm wondering about
> 
> : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> : Author:     Theodore Ts'o <tytso@mit.edu>
> : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> : Commit:     Theodore Ts'o <tytso@mit.edu>
> : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> :
> :    jbd: don't give up looking for space so easily in __log_wait_for_space
> 
> but that patch was present in 2.6.28.
  Hmm, I don't see what made this deadlock happening - as far as I can
see it's there for quite some time. See below...

> > pickup        D c01384df     0  2597   2594
> >  cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> >  cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> >  00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > Call Trace:
> >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> >  [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> >  [<c01c0539>] log_wait_commit+0x90/0xf7
> >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> >  [<c01bba9d>] journal_stop+0x1c8/0x288
> >  [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> >  [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> >  [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> >  [<c017ab82>] generic_delete_inode+0x72/0x100
> >  [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> >  [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> >  [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> >  [<c017a4e7>] iput+0x47/0x4e
> >  [<c0173db0>] do_unlinkat+0xc1/0x137
> >  [<c0102f87>] ? sysenter_exit+0xf/0x18
> >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> >  [<c0173e36>] sys_unlink+0x10/0x12
> >  [<c0102f55>] sysenter_do_call+0x12/0x35
  In generic_delete_inode() we mark inode as I_FREEING. Then
ext3_delete_inode() is called and because of O_SYNC it starts a
transaction commit and waits for it.

> > postdrop      D c01384df     0  2664   2663
> >  cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> >  c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> >  dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > Call Trace:
> >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> >  [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> >  [<c012b726>] ? wake_bit_function+0x0/0x47
> >  [<c017a5b5>] find_inode_fast+0x3f/0x4a
> >  [<c017ba05>] insert_inode_locked+0x50/0xeb
> >  [<c01ab90b>] ext3_new_inode+0x738/0x88f
> >  [<c01bc550>] ? journal_start+0xab/0x100
> >  [<c01b259a>] ext3_create+0x59/0xbf
> >  [<c01722c4>] vfs_create+0x75/0xb0
> >  [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> >  [<c01b2541>] ? ext3_create+0x0/0xbf
> >  [<c0174bc3>] do_filp_open+0x644/0x713
> >  [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> >  [<c01692ce>] do_sys_open+0x45/0xce
> >  [<c0102f87>] ? sysenter_exit+0xf/0x18
> >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> >  [<c01693a3>] sys_open+0x23/0x2b
> >  [<c0102f55>] sysenter_do_call+0x12/0x35
  Here, we have started a transaction in ext3_create() and then wait in
find_inode_fast() for I_FREEING to be cleared (obviously we have
reallocated the inode and squeezed the allocation before journal_stop()
from the delete was called).
  Nasty deadlock and I don't see how to fix it now - have to go home for
today... Tomorrow I'll have a look what we can do about it.

                                    Honza

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Jan Kara]

> http://bugzilla.kernel.org/show_bug.cgi?id=13232
> 
> --- Comment #2 from Jan Kara <jack@suse.cz>  2009-05-12 16:56:04 ---
>   Hi,
> 
> > (switched to email.  Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
> 
> > > SysRq : Show Blocked State
> > >   task                PC stack   pid father
> > > kjournald     D c01384df     0  2525      2
> > >  cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> > >  de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> > >  00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > > Call Trace:
> > >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > >  [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> > >  [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> > >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > >  [<c0122a25>] ? del_timer+0x50/0x59
> > >  [<c01c0c75>] kjournald+0xad/0x1bb
> > >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > >  [<c01c0bc8>] ? kjournald+0x0/0x1bb
> > >  [<c012b442>] kthread+0x37/0x59
> > >  [<c012b40b>] ? kthread+0x0/0x59
> > >  [<c0103667>] kernel_thread_helper+0x7/0x10
> > 
> > I assume this is
> > 
> > 	while (commit_transaction->t_updates) {
> > 		DEFINE_WAIT(wait);
> > 
> > 		prepare_to_wait(&journal->j_wait_updates, &wait,
> > 					TASK_UNINTERRUPTIBLE);
> > 		if (commit_transaction->t_updates) {
> > 			spin_unlock(&commit_transaction->t_handle_lock);
> > 			spin_unlock(&journal->j_state_lock);
> > 			schedule();
>   Yes.
> 
> > I'm wondering about
> > 
> > : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> > : Author:     Theodore Ts'o <tytso@mit.edu>
> > : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> > : Commit:     Theodore Ts'o <tytso@mit.edu>
> > : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> > :
> > :    jbd: don't give up looking for space so easily in __log_wait_for_space
> > 
> > but that patch was present in 2.6.28.
>   Hmm, I don't see what made this deadlock happening - as far as I can
> see it's there for quite some time. See below...
> 
> > > pickup        D c01384df     0  2597   2594
> > >  cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> > >  cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> > >  00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > > Call Trace:
> > >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > >  [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> > >  [<c01c0539>] log_wait_commit+0x90/0xf7
> > >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > >  [<c01bba9d>] journal_stop+0x1c8/0x288
> > >  [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> > >  [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> > >  [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> > >  [<c017ab82>] generic_delete_inode+0x72/0x100
> > >  [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> > >  [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> > >  [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> > >  [<c017a4e7>] iput+0x47/0x4e
> > >  [<c0173db0>] do_unlinkat+0xc1/0x137
> > >  [<c0102f87>] ? sysenter_exit+0xf/0x18
> > >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > >  [<c0173e36>] sys_unlink+0x10/0x12
> > >  [<c0102f55>] sysenter_do_call+0x12/0x35
>   In generic_delete_inode() we mark inode as I_FREEING. Then
> ext3_delete_inode() is called and because of O_SYNC it starts a
> transaction commit and waits for it.
> 
> > > postdrop      D c01384df     0  2664   2663
> > >  cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> > >  c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> > >  dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > > Call Trace:
> > >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > >  [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> > >  [<c012b726>] ? wake_bit_function+0x0/0x47
> > >  [<c017a5b5>] find_inode_fast+0x3f/0x4a
> > >  [<c017ba05>] insert_inode_locked+0x50/0xeb
> > >  [<c01ab90b>] ext3_new_inode+0x738/0x88f
> > >  [<c01bc550>] ? journal_start+0xab/0x100
> > >  [<c01b259a>] ext3_create+0x59/0xbf
> > >  [<c01722c4>] vfs_create+0x75/0xb0
> > >  [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > >  [<c01b2541>] ? ext3_create+0x0/0xbf
> > >  [<c0174bc3>] do_filp_open+0x644/0x713
> > >  [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > >  [<c01692ce>] do_sys_open+0x45/0xce
> > >  [<c0102f87>] ? sysenter_exit+0xf/0x18
> > >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > >  [<c01693a3>] sys_open+0x23/0x2b
> > >  [<c0102f55>] sysenter_do_call+0x12/0x35
>   Here, we have started a transaction in ext3_create() and then wait in
> find_inode_fast() for I_FREEING to be cleared (obviously we have
> reallocated the inode and squeezed the allocation before journal_stop()
> from the delete was called).
>   Nasty deadlock and I don't see how to fix it now - have to go home for
> today... Tomorrow I'll have a look what we can do about it.
  OK, the deadlock has been introduced by ext3 variant of
261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
is really tough to avoid - we have to first allocate inode on disk so
that we know the inode number. For this we need transaction open but we
cannot afford waiting for old inode with same INO to be freed when we have
transaction open because of the above deadlock. So we'd have to wait for
inode release only after everything is done and we closed the transaction. But
that would mean reordering a lot of code in ext3/namei.c so that all the
dcache handling is done after all the IO is done.
  Hmm, maybe we could change the delete side of the deadlock but that's
going to be tricky as well :(.
  Al, any idea if we could somehow get away without waiting on
I_FREEING?

									Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs

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

[bugzilla-daemon]

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





--- Comment #3 from Jan Kara <jack@suse.cz>  2009-05-13 13:48:04 ---
> http://bugzilla.kernel.org/show_bug.cgi?id=13232
> 
> --- Comment #2 from Jan Kara <jack@suse.cz>  2009-05-12 16:56:04 ---
>   Hi,
> 
> > (switched to email.  Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
> 
> > > SysRq : Show Blocked State
> > >   task                PC stack   pid father
> > > kjournald     D c01384df     0  2525      2
> > >  cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> > >  de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> > >  00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > > Call Trace:
> > >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > >  [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> > >  [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> > >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > >  [<c0122a25>] ? del_timer+0x50/0x59
> > >  [<c01c0c75>] kjournald+0xad/0x1bb
> > >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > >  [<c01c0bc8>] ? kjournald+0x0/0x1bb
> > >  [<c012b442>] kthread+0x37/0x59
> > >  [<c012b40b>] ? kthread+0x0/0x59
> > >  [<c0103667>] kernel_thread_helper+0x7/0x10
> > 
> > I assume this is
> > 
> > 	while (commit_transaction->t_updates) {
> > 		DEFINE_WAIT(wait);
> > 
> > 		prepare_to_wait(&journal->j_wait_updates, &wait,
> > 					TASK_UNINTERRUPTIBLE);
> > 		if (commit_transaction->t_updates) {
> > 			spin_unlock(&commit_transaction->t_handle_lock);
> > 			spin_unlock(&journal->j_state_lock);
> > 			schedule();
>   Yes.
> 
> > I'm wondering about
> > 
> > : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> > : Author:     Theodore Ts'o <tytso@mit.edu>
> > : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> > : Commit:     Theodore Ts'o <tytso@mit.edu>
> > : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> > :
> > :    jbd: don't give up looking for space so easily in __log_wait_for_space
> > 
> > but that patch was present in 2.6.28.
>   Hmm, I don't see what made this deadlock happening - as far as I can
> see it's there for quite some time. See below...
> 
> > > pickup        D c01384df     0  2597   2594
> > >  cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> > >  cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> > >  00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > > Call Trace:
> > >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > >  [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> > >  [<c01c0539>] log_wait_commit+0x90/0xf7
> > >  [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > >  [<c01bba9d>] journal_stop+0x1c8/0x288
> > >  [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> > >  [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> > >  [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> > >  [<c017ab82>] generic_delete_inode+0x72/0x100
> > >  [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> > >  [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> > >  [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> > >  [<c017a4e7>] iput+0x47/0x4e
> > >  [<c0173db0>] do_unlinkat+0xc1/0x137
> > >  [<c0102f87>] ? sysenter_exit+0xf/0x18
> > >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > >  [<c0173e36>] sys_unlink+0x10/0x12
> > >  [<c0102f55>] sysenter_do_call+0x12/0x35
>   In generic_delete_inode() we mark inode as I_FREEING. Then
> ext3_delete_inode() is called and because of O_SYNC it starts a
> transaction commit and waits for it.
> 
> > > postdrop      D c01384df     0  2664   2663
> > >  cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> > >  c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> > >  dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > > Call Trace:
> > >  [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > >  [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> > >  [<c012b726>] ? wake_bit_function+0x0/0x47
> > >  [<c017a5b5>] find_inode_fast+0x3f/0x4a
> > >  [<c017ba05>] insert_inode_locked+0x50/0xeb
> > >  [<c01ab90b>] ext3_new_inode+0x738/0x88f
> > >  [<c01bc550>] ? journal_start+0xab/0x100
> > >  [<c01b259a>] ext3_create+0x59/0xbf
> > >  [<c01722c4>] vfs_create+0x75/0xb0
> > >  [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > >  [<c01b2541>] ? ext3_create+0x0/0xbf
> > >  [<c0174bc3>] do_filp_open+0x644/0x713
> > >  [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > >  [<c01692ce>] do_sys_open+0x45/0xce
> > >  [<c0102f87>] ? sysenter_exit+0xf/0x18
> > >  [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > >  [<c01693a3>] sys_open+0x23/0x2b
> > >  [<c0102f55>] sysenter_do_call+0x12/0x35
>   Here, we have started a transaction in ext3_create() and then wait in
> find_inode_fast() for I_FREEING to be cleared (obviously we have
> reallocated the inode and squeezed the allocation before journal_stop()
> from the delete was called).
>   Nasty deadlock and I don't see how to fix it now - have to go home for
> today... Tomorrow I'll have a look what we can do about it.
  OK, the deadlock has been introduced by ext3 variant of
261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
is really tough to avoid - we have to first allocate inode on disk so
that we know the inode number. For this we need transaction open but we
cannot afford waiting for old inode with same INO to be freed when we have
transaction open because of the above deadlock. So we'd have to wait for
inode release only after everything is done and we closed the transaction. But
that would mean reordering a lot of code in ext3/namei.c so that all the
dcache handling is done after all the IO is done.
  Hmm, maybe we could change the delete side of the deadlock but that's
going to be tricky as well :(.
  Al, any idea if we could somehow get away without waiting on
I_FREEING?

                                    Honza

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Theodore Tso]

On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
>   OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).

What do you mean by this?

I'm puzzled why we haven't hit this before.  This looks like
long-standing issue; what unmasked it now?

> The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number.

Well, the simple thing to do is to have a way of quickly determining
that a particular inode number is in the I_FREEING state, and simply
try to avoid using that inode number.  If there are no inodes
available, it can simply close the handle (since nothing else has
changed at that point), wait for the current transaction to close, and
then try again.  That should fix the problem, I think.

     	 	      	     	     	      - Ted

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

[bugzilla-daemon]

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





--- Comment #4 from Theodore Tso <tytso@mit.edu>  2009-05-13 16:07:33 ---
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
>   OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).

What do you mean by this?

I'm puzzled why we haven't hit this before.  This looks like
long-standing issue; what unmasked it now?

> The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number.

Well, the simple thing to do is to have a way of quickly determining
that a particular inode number is in the I_FREEING state, and simply
try to avoid using that inode number.  If there are no inodes
available, it can simply close the handle (since nothing else has
changed at that point), wait for the current transaction to close, and
then try again.  That should fix the problem, I think.

                                                - Ted

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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


Vincent Li <mchun.li@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mchun.li@gmail.com




--- Comment #5 from Vincent Li <mchun.li@gmail.com>  2009-05-13 16:18:57 ---
I tried to run Postfix on ubuntu 9.04 server version and followed the reporduce
command, had the same problem.

kernel version: 2.6.30-rc4
Distribution: Ubuntu 9.04 
Software Environment: Postfix 2.5.1-2ubuntu1.2

also have following message poping up on control terminal:

[844,700070] INFO: task kjournald: 628 blocked for more than 120 seconds,
[844,700148] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
meassage.

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Al Viro]

On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> >   Here, we have started a transaction in ext3_create() and then wait in
> > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > reallocated the inode and squeezed the allocation before journal_stop()
> > from the delete was called).
> >   Nasty deadlock and I don't see how to fix it now - have to go home for
> > today... Tomorrow I'll have a look what we can do about it.
>   OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number. For this we need transaction open but we
> cannot afford waiting for old inode with same INO to be freed when we have
> transaction open because of the above deadlock. So we'd have to wait for
> inode release only after everything is done and we closed the transaction. But
> that would mean reordering a lot of code in ext3/namei.c so that all the
> dcache handling is done after all the IO is done.
>   Hmm, maybe we could change the delete side of the deadlock but that's
> going to be tricky as well :(.
>   Al, any idea if we could somehow get away without waiting on
> I_FREEING?

At which point do we actually run into deadlock on delete side?  We could,
in principle, skip everything like that in insert_inode_locked(), but
I would rather avoid the "two inodes in icache at the same time, with the
same inumber" situations completely.  We might get away with that, since
everything else *will* wait, so we can afford a bunch of inodes past the
point in foo_delete_inode() that has cleared it in bitmap + new locked
one, but if it's at all possible to avoid, I'd rather avoid it.

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

[bugzilla-daemon]

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





--- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2009-05-13 16:52:56 ---
Reply-To: viro@ZenIV.linux.org.uk

On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> >   Here, we have started a transaction in ext3_create() and then wait in
> > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > reallocated the inode and squeezed the allocation before journal_stop()
> > from the delete was called).
> >   Nasty deadlock and I don't see how to fix it now - have to go home for
> > today... Tomorrow I'll have a look what we can do about it.
>   OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number. For this we need transaction open but we
> cannot afford waiting for old inode with same INO to be freed when we have
> transaction open because of the above deadlock. So we'd have to wait for
> inode release only after everything is done and we closed the transaction. But
> that would mean reordering a lot of code in ext3/namei.c so that all the
> dcache handling is done after all the IO is done.
>   Hmm, maybe we could change the delete side of the deadlock but that's
> going to be tricky as well :(.
>   Al, any idea if we could somehow get away without waiting on
> I_FREEING?

At which point do we actually run into deadlock on delete side?  We could,
in principle, skip everything like that in insert_inode_locked(), but
I would rather avoid the "two inodes in icache at the same time, with the
same inumber" situations completely.  We might get away with that, since
everything else *will* wait, so we can afford a bunch of inodes past the
point in foo_delete_inode() that has cleared it in bitmap + new locked
one, but if it's at all possible to avoid, I'd rather avoid it.

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Al Viro]

On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > >   Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > >   Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> >   OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> >   Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> >   Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
> 
> At which point do we actually run into deadlock on delete side?  We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely.  We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.

OK, that's probably the easiest way to do that, as much as I don't like it...
Since iget() et.al. will not accept I_FREEING (will wait to go away
and restart), and since we'd better have serialization between new/free
on fs data structures anyway, we can afford simply skipping I_FREEING
et.al. in insert_inode_locked().

We do that from new_inode, so it won't race with free_inode in any interesting
ways and it won't race with iget (of any origin; nfsd or in case of fs
corruption a lookup) since both still will wait for I_LOCK.

Tentative patch follow; folks, I would very much like review on that one,
since I'm far too low on caffeine and the area is nasty.

diff --git a/fs/inode.c b/fs/inode.c
index 9d26490..4406952 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
 	struct super_block *sb = inode->i_sb;
 	ino_t ino = inode->i_ino;
 	struct hlist_head *head = inode_hashtable + hash(sb, ino);
-	struct inode *old;
 
 	inode->i_state |= I_LOCK|I_NEW;
 	while (1) {
+		struct hlist_node *node;
+		struct inode *old = NULL;
 		spin_lock(&inode_lock);
-		old = find_inode_fast(sb, head, ino);
-		if (likely(!old)) {
+		hlist_for_each_entry(old, node, head, i_hash) {
+			if (old->i_ino != ino)
+				continue;
+			if (old->i_sb != sb)
+				continue;
+			if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+				continue;
+			break;
+		}
+		if (likely(!node)) {
 			hlist_add_head(&inode->i_hash, head);
 			spin_unlock(&inode_lock);
 			return 0;
@@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
 {
 	struct super_block *sb = inode->i_sb;
 	struct hlist_head *head = inode_hashtable + hash(sb, hashval);
-	struct inode *old;
 
 	inode->i_state |= I_LOCK|I_NEW;
 
 	while (1) {
+		struct hlist_node *node;
+		struct inode *old = NULL;
+
 		spin_lock(&inode_lock);
-		old = find_inode(sb, head, test, data);
-		if (likely(!old)) {
+		hlist_for_each_entry(old, node, head, i_hash) {
+			if (old->i_sb != sb)
+				continue;
+			if (!test(old, data))
+				continue;
+			if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+				continue;
+			break;
+		}
+		if (likely(!node)) {
 			hlist_add_head(&inode->i_hash, head);
 			spin_unlock(&inode_lock);
 			return 0;

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

[bugzilla-daemon]

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





--- Comment #7 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2009-05-13 18:13:42 ---
Reply-To: viro@ZenIV.linux.org.uk

On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > >   Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > >   Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> >   OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> >   Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> >   Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
> 
> At which point do we actually run into deadlock on delete side?  We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely.  We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.

OK, that's probably the easiest way to do that, as much as I don't like it...
Since iget() et.al. will not accept I_FREEING (will wait to go away
and restart), and since we'd better have serialization between new/free
on fs data structures anyway, we can afford simply skipping I_FREEING
et.al. in insert_inode_locked().

We do that from new_inode, so it won't race with free_inode in any interesting
ways and it won't race with iget (of any origin; nfsd or in case of fs
corruption a lookup) since both still will wait for I_LOCK.

Tentative patch follow; folks, I would very much like review on that one,
since I'm far too low on caffeine and the area is nasty.

diff --git a/fs/inode.c b/fs/inode.c
index 9d26490..4406952 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
     struct super_block *sb = inode->i_sb;
     ino_t ino = inode->i_ino;
     struct hlist_head *head = inode_hashtable + hash(sb, ino);
-    struct inode *old;

     inode->i_state |= I_LOCK|I_NEW;
     while (1) {
+        struct hlist_node *node;
+        struct inode *old = NULL;
         spin_lock(&inode_lock);
-        old = find_inode_fast(sb, head, ino);
-        if (likely(!old)) {
+        hlist_for_each_entry(old, node, head, i_hash) {
+            if (old->i_ino != ino)
+                continue;
+            if (old->i_sb != sb)
+                continue;
+            if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+                continue;
+            break;
+        }
+        if (likely(!node)) {
             hlist_add_head(&inode->i_hash, head);
             spin_unlock(&inode_lock);
             return 0;
@@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned
long hashval,
 {
     struct super_block *sb = inode->i_sb;
     struct hlist_head *head = inode_hashtable + hash(sb, hashval);
-    struct inode *old;

     inode->i_state |= I_LOCK|I_NEW;

     while (1) {
+        struct hlist_node *node;
+        struct inode *old = NULL;
+
         spin_lock(&inode_lock);
-        old = find_inode(sb, head, test, data);
-        if (likely(!old)) {
+        hlist_for_each_entry(old, node, head, i_hash) {
+            if (old->i_sb != sb)
+                continue;
+            if (!test(old, data))
+                continue;
+            if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+                continue;
+            break;
+        }
+        if (likely(!node)) {
             hlist_add_head(&inode->i_hash, head);
             spin_unlock(&inode_lock);
             return 0;

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

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

[Jan Kara]

On Wed 13-05-09 12:07:24, Theodore Tso wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> >   OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
> 
> What do you mean by this?
> 
> I'm puzzled why we haven't hit this before.  This looks like
> long-standing issue; what unmasked it now?
  Unless you mount the fs with 'sync' option, hitting this is much harder
(the window is quite small in nosync case). I think that is the main reason
why we didn't see this earlier.

> > The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number.
> 
> Well, the simple thing to do is to have a way of quickly determining
> that a particular inode number is in the I_FREEING state, and simply
> try to avoid using that inode number.  If there are no inodes
> available, it can simply close the handle (since nothing else has
> changed at that point), wait for the current transaction to close, and
> then try again.  That should fix the problem, I think.
  Yes, we could work-around it like that but other filesystems might need
similar things and generally it would be nicer if we could avoid using this
vfs-internal information in the filesystems. Al seems to have found some
other solution without changing filesystems so that would be easier for us...

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

[bugzilla-daemon]

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





--- Comment #8 from Jan Kara <jack@suse.cz>  2009-05-18 12:45:23 ---
On Wed 13-05-09 12:07:24, Theodore Tso wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> >   OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
> 
> What do you mean by this?
> 
> I'm puzzled why we haven't hit this before.  This looks like
> long-standing issue; what unmasked it now?
  Unless you mount the fs with 'sync' option, hitting this is much harder
(the window is quite small in nosync case). I think that is the main reason
why we didn't see this earlier.

> > The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number.
> 
> Well, the simple thing to do is to have a way of quickly determining
> that a particular inode number is in the I_FREEING state, and simply
> try to avoid using that inode number.  If there are no inodes
> available, it can simply close the handle (since nothing else has
> changed at that point), wait for the current transaction to close, and
> then try again.  That should fix the problem, I think.
  Yes, we could work-around it like that but other filesystems might need
similar things and generally it would be nicer if we could avoid using this
vfs-internal information in the filesystems. Al seems to have found some
other solution without changing filesystems so that would be easier for us...

                                    Honza

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Jan Kara]

On Wed 13-05-09 17:52:54, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > >   Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > >   Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> >   OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> >   Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> >   Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
> 
> At which point do we actually run into deadlock on delete side?  We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely.  We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
  The ordering we see on delete when the filesystem is mounted with 'sync'
option is:
  DELETE					CREATE
generic_delete_inode()
  set I_FREEING
  ext3_delete_inode
    get transaction handle
    do work
						get transaction handle
						ext3_new_inode()
						  reallocate inode
						  insert_inode_locked()
    stop transaction, wait for it to commit
    (waiting for CREATE process to drop its
    transaction reference)

  Now similar race can happen even without 'sync' mount option but it's
much harder to hit:
  DELETE					CREATE
generic_delete_inode()
  set I_FREEING
  ext3_delete_inode
						get transaction handle
						ext3_new_inode()
						  reallocate inode
						  insert_inode_locked()
    try to get transaction handle -
      - transaction is too big so we send
      current transaction to commit which
      again waits for CREATE to drop its
      reference.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

[bugzilla-daemon]

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





--- Comment #9 from Jan Kara <jack@suse.cz>  2009-05-18 12:54:00 ---
On Wed 13-05-09 17:52:54, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > >   Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > >   Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> >   OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> >   Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> >   Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
> 
> At which point do we actually run into deadlock on delete side?  We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely.  We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
  The ordering we see on delete when the filesystem is mounted with 'sync'
option is:
  DELETE                    CREATE
generic_delete_inode()
  set I_FREEING
  ext3_delete_inode
    get transaction handle
    do work
                        get transaction handle
                        ext3_new_inode()
                          reallocate inode
                          insert_inode_locked()
    stop transaction, wait for it to commit
    (waiting for CREATE process to drop its
    transaction reference)

  Now similar race can happen even without 'sync' mount option but it's
much harder to hit:
  DELETE                    CREATE
generic_delete_inode()
  set I_FREEING
  ext3_delete_inode
                        get transaction handle
                        ext3_new_inode()
                          reallocate inode
                          insert_inode_locked()
    try to get transaction handle -
      - transaction is too big so we send
      current transaction to commit which
      again waits for CREATE to drop its
      reference.

                                Honza

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Theodore Tso]

On Wed, May 13, 2009 at 07:13:40PM +0100, Al Viro wrote:
> 
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
> 
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
> 
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.

Sorry for not having time to review this until now.  This looks good
to me.

Reviewed-by: "Theodore Ts'o" <tytso@mit.edu>

So Bug #13232 is currently marked as a 2.6.28 regression; do we feel
confident enough to push this to Linus for 2.6.30?

	  	    	      	 - Ted

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

[bugzilla-daemon]

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





--- Comment #10 from Theodore Tso <tytso@mit.edu>  2009-05-18 13:16:04 ---
On Wed, May 13, 2009 at 07:13:40PM +0100, Al Viro wrote:
> 
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
> 
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
> 
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.

Sorry for not having time to review this until now.  This looks good
to me.

Reviewed-by: "Theodore Ts'o" <tytso@mit.edu>

So Bug #13232 is currently marked as a 2.6.28 regression; do we feel
confident enough to push this to Linus for 2.6.30?

                             - Ted

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Jan Kara]

On Wed 13-05-09 19:13:40, Al Viro wrote:
> On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> > On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > >   Here, we have started a transaction in ext3_create() and then wait in
> > > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > > reallocated the inode and squeezed the allocation before journal_stop()
> > > > from the delete was called).
> > > >   Nasty deadlock and I don't see how to fix it now - have to go home for
> > > > today... Tomorrow I'll have a look what we can do about it.
> > >   OK, the deadlock has been introduced by ext3 variant of
> > > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > > is really tough to avoid - we have to first allocate inode on disk so
> > > that we know the inode number. For this we need transaction open but we
> > > cannot afford waiting for old inode with same INO to be freed when we have
> > > transaction open because of the above deadlock. So we'd have to wait for
> > > inode release only after everything is done and we closed the transaction. But
> > > that would mean reordering a lot of code in ext3/namei.c so that all the
> > > dcache handling is done after all the IO is done.
> > >   Hmm, maybe we could change the delete side of the deadlock but that's
> > > going to be tricky as well :(.
> > >   Al, any idea if we could somehow get away without waiting on
> > > I_FREEING?
> > 
> > At which point do we actually run into deadlock on delete side?  We could,
> > in principle, skip everything like that in insert_inode_locked(), but
> > I would rather avoid the "two inodes in icache at the same time, with the
> > same inumber" situations completely.  We might get away with that, since
> > everything else *will* wait, so we can afford a bunch of inodes past the
> > point in foo_delete_inode() that has cleared it in bitmap + new locked
> > one, but if it's at all possible to avoid, I'd rather avoid it.
> 
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
> 
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
> 
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
  The patch looks fine. Everyone else will either get new inode and wait
for I_LOCK or get old inode and wait for I_FREEING so everything should be
fine... You can add.
  Acked-by: Jan Kara <jack@suse.cz>

									Honza
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 9d26490..4406952 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
>  	struct super_block *sb = inode->i_sb;
>  	ino_t ino = inode->i_ino;
>  	struct hlist_head *head = inode_hashtable + hash(sb, ino);
> -	struct inode *old;
>  
>  	inode->i_state |= I_LOCK|I_NEW;
>  	while (1) {
> +		struct hlist_node *node;
> +		struct inode *old = NULL;
>  		spin_lock(&inode_lock);
> -		old = find_inode_fast(sb, head, ino);
> -		if (likely(!old)) {
> +		hlist_for_each_entry(old, node, head, i_hash) {
> +			if (old->i_ino != ino)
> +				continue;
> +			if (old->i_sb != sb)
> +				continue;
> +			if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> +				continue;
> +			break;
> +		}
> +		if (likely(!node)) {
>  			hlist_add_head(&inode->i_hash, head);
>  			spin_unlock(&inode_lock);
>  			return 0;
> @@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
>  {
>  	struct super_block *sb = inode->i_sb;
>  	struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> -	struct inode *old;
>  
>  	inode->i_state |= I_LOCK|I_NEW;
>  
>  	while (1) {
> +		struct hlist_node *node;
> +		struct inode *old = NULL;
> +
>  		spin_lock(&inode_lock);
> -		old = find_inode(sb, head, test, data);
> -		if (likely(!old)) {
> +		hlist_for_each_entry(old, node, head, i_hash) {
> +			if (old->i_sb != sb)
> +				continue;
> +			if (!test(old, data))
> +				continue;
> +			if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> +				continue;
> +			break;
> +		}
> +		if (likely(!node)) {
>  			hlist_add_head(&inode->i_hash, head);
>  			spin_unlock(&inode_lock);
>  			return 0;
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

[bugzilla-daemon]

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





--- Comment #11 from Jan Kara <jack@suse.cz>  2009-05-18 14:10:15 ---
On Wed 13-05-09 19:13:40, Al Viro wrote:
> On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> > On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > >   Here, we have started a transaction in ext3_create() and then wait in
> > > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > > reallocated the inode and squeezed the allocation before journal_stop()
> > > > from the delete was called).
> > > >   Nasty deadlock and I don't see how to fix it now - have to go home for
> > > > today... Tomorrow I'll have a look what we can do about it.
> > >   OK, the deadlock has been introduced by ext3 variant of
> > > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > > is really tough to avoid - we have to first allocate inode on disk so
> > > that we know the inode number. For this we need transaction open but we
> > > cannot afford waiting for old inode with same INO to be freed when we have
> > > transaction open because of the above deadlock. So we'd have to wait for
> > > inode release only after everything is done and we closed the transaction. But
> > > that would mean reordering a lot of code in ext3/namei.c so that all the
> > > dcache handling is done after all the IO is done.
> > >   Hmm, maybe we could change the delete side of the deadlock but that's
> > > going to be tricky as well :(.
> > >   Al, any idea if we could somehow get away without waiting on
> > > I_FREEING?
> > 
> > At which point do we actually run into deadlock on delete side?  We could,
> > in principle, skip everything like that in insert_inode_locked(), but
> > I would rather avoid the "two inodes in icache at the same time, with the
> > same inumber" situations completely.  We might get away with that, since
> > everything else *will* wait, so we can afford a bunch of inodes past the
> > point in foo_delete_inode() that has cleared it in bitmap + new locked
> > one, but if it's at all possible to avoid, I'd rather avoid it.
> 
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
> 
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
> 
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
  The patch looks fine. Everyone else will either get new inode and wait
for I_LOCK or get old inode and wait for I_FREEING so everything should be
fine... You can add.
  Acked-by: Jan Kara <jack@suse.cz>

                                    Honza
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 9d26490..4406952 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
>  	struct super_block *sb = inode->i_sb;
>  	ino_t ino = inode->i_ino;
>  	struct hlist_head *head = inode_hashtable + hash(sb, ino);
> -	struct inode *old;
>  
>  	inode->i_state |= I_LOCK|I_NEW;
>  	while (1) {
> +		struct hlist_node *node;
> +		struct inode *old = NULL;
>  		spin_lock(&inode_lock);
> -		old = find_inode_fast(sb, head, ino);
> -		if (likely(!old)) {
> +		hlist_for_each_entry(old, node, head, i_hash) {
> +			if (old->i_ino != ino)
> +				continue;
> +			if (old->i_sb != sb)
> +				continue;
> +			if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> +				continue;
> +			break;
> +		}
> +		if (likely(!node)) {
>  			hlist_add_head(&inode->i_hash, head);
>  			spin_unlock(&inode_lock);
>  			return 0;
> @@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
>  {
>  	struct super_block *sb = inode->i_sb;
>  	struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> -	struct inode *old;
>  
>  	inode->i_state |= I_LOCK|I_NEW;
>  
>  	while (1) {
> +		struct hlist_node *node;
> +		struct inode *old = NULL;
> +
>  		spin_lock(&inode_lock);
> -		old = find_inode(sb, head, test, data);
> -		if (likely(!old)) {
> +		hlist_for_each_entry(old, node, head, i_hash) {
> +			if (old->i_sb != sb)
> +				continue;
> +			if (!test(old, data))
> +				continue;
> +			if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> +				continue;
> +			break;
> +		}
> +		if (likely(!node)) {
>  			hlist_add_head(&inode->i_hash, head);
>  			spin_unlock(&inode_lock);
>  			return 0;

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[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

[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

[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

[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

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

[bugzilla-daemon]

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





--- Comment #12 from Theodore Tso <tytso@mit.edu>  2009-05-19 20:38:32 ---
Created an attachment (id=21436)
 --> (http://bugzilla.kernel.org/attachment.cgi?id=21436)
Proposed patch from Al Viro

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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


Theodore Tso <tytso@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #21436|application/octet-stream    |text/plain
          mime type|                            |
  Attachment #21436|0                           |1
           is patch|                            |




-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

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

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

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

[Rafael J. Wysocki]

This message contains a list of some regressions introduced between 2.6.28 and
2.6.29, for which there are no fixes in the mainline I know of.  If any of them
have been fixed already, please let me know.

If you know of any other unresolved regressions introduced between 2.6.28
and 2.6.29, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-06-07      169       27          25
  2009-05-31      167       27          26
  2009-05-25      165       27          25
  2009-05-17      162       27          25
  2009-04-26      160       29          27
  2009-04-06      142       37          31
  2009-03-21      128       29          26
  2009-03-14      124       36          32
  2009-03-03      108       33          28
  2009-02-24       95       32          24
  2009-02-14       85       33          27
  2009-02-08       82       45          36
  2009-02-04       66       51          39
  2009-01-20       38       35          27
  2009-01-11       13       13          10


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
Subject		: Poor SSD performance
Submitter	: Jake <ellowitz@uchicago.edu>
Date		: 2009-06-05 17:37 (3 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
Submitter	: Guido <bugzilla.kernel.org@starbase12.cjb.net>
Date		: 2009-05-31 12:21 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject		: Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter	: Alex Samad <alex@samad.com.au>
Date		: 2009-05-20 0:37 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=124278675503699&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject		: s2disk hangs with e100, kernel 2.6.29 and later
Submitter	: Richard Atterer <richard@2009.atterer.net>
Date		: 2009-05-16 22:51 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=Unknown
References	: http://marc.info/?l=linux-kernel&m=124251446428166&w=4
		  http://lkml.org/lkml/2009/5/25/253
Handled-By	: Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject		: rtable leak in ipv4/route.c
Submitter	: Alexander V. Lukyanov <lav@yar.ru>
Date		: 2009-05-18 14:10 (21 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject		: i915: drm: xorg leaks drm objects massively
Submitter	: Sergei Trofimovich <slyich@gmail.com>
Date		: 2009-05-10 19:56 (29 days old)
References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4


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


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


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


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
Submitter	: fanderay <fanderay4@googlemail.com>
Date		: 2009-04-22 14:39 (47 days old)


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


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


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


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


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


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject		: ATA bus errors on resume
Submitter	: Niel Lambrechts <niel.lambrechts@gmail.com>
Date		: 2009-03-25 5:19 (75 days old)
References	: http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By	: Tejun Heo <htejun@gmail.com>


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


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


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


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


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


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


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


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

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


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


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

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

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

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

Thanks,
Rafael

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

[Rafael J. Wysocki]

This message contains a list of some regressions introduced between 2.6.28 and
2.6.29, for which there are no fixes in the mainline I know of.  If any of them
have been fixed already, please let me know.

If you know of any other unresolved regressions introduced between 2.6.28
and 2.6.29, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-06-07      169       27          25
  2009-05-31      167       27          26
  2009-05-25      165       27          25
  2009-05-17      162       27          25
  2009-04-26      160       29          27
  2009-04-06      142       37          31
  2009-03-21      128       29          26
  2009-03-14      124       36          32
  2009-03-03      108       33          28
  2009-02-24       95       32          24
  2009-02-14       85       33          27
  2009-02-08       82       45          36
  2009-02-04       66       51          39
  2009-01-20       38       35          27
  2009-01-11       13       13          10


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
Subject		: Poor SSD performance
Submitter	: Jake <ellowitz@uchicago.edu>
Date		: 2009-06-05 17:37 (3 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
Submitter	: Guido <bugzilla.kernel.org@starbase12.cjb.net>
Date		: 2009-05-31 12:21 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject		: Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter	: Alex Samad <alex@samad.com.au>
Date		: 2009-05-20 0:37 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=124278675503699&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject		: s2disk hangs with e100, kernel 2.6.29 and later
Submitter	: Richard Atterer <richard@2009.atterer.net>
Date		: 2009-05-16 22:51 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=Unknown
References	: http://marc.info/?l=linux-kernel&m=124251446428166&w=4
		  http://lkml.org/lkml/2009/5/25/253
Handled-By	: Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject		: rtable leak in ipv4/route.c
Submitter	: Alexander V. Lukyanov <lav@yar.ru>
Date		: 2009-05-18 14:10 (21 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject		: i915: drm: xorg leaks drm objects massively
Submitter	: Sergei Trofimovich <slyich@gmail.com>
Date		: 2009-05-10 19:56 (29 days old)
References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4


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


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


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


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
Submitter	: fanderay <fanderay4@googlemail.com>
Date		: 2009-04-22 14:39 (47 days old)


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


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


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


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


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


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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject		: ATA bus errors on resume
Submitter	: Niel Lambrechts <niel.lambrechts@gmail.com>
Date		: 2009-03-25 5:19 (75 days old)
References	: http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By	: Tejun Heo <htejun@gmail.com>


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


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


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


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


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


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


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


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

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


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


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

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

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

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

Thanks,
Rafael

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #12681] s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[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 (71 days old)
Handled-By	: Matt Carlson <mcarlson-dY08KVG/lbpWk0Htik3J/w@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 (119 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By	: Alexey Starikovskiy <astarikovskiy@suse.de>

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #12971] "tg3 transmit timed out" when transmitting at high bitrate

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #12909] boot/kernel init duration regression from 2.6.28

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #12899] Crash in i915.ko: i915_driver_irq_handler

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #13017] ATA bus errors on resume

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject		: ATA bus errors on resume
Submitter	: Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-03-25 5:19 (75 days old)
References	: http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By	: Tejun Heo <htejun-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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

[Bug #12980] lockup in X.org

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #13017] ATA bus errors on resume

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject		: ATA bus errors on resume
Submitter	: Niel Lambrechts <niel.lambrechts@gmail.com>
Date		: 2009-03-25 5:19 (75 days old)
References	: http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By	: Tejun Heo <htejun@gmail.com>

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #13024] nozomi: pppd fails on kernel 2.6.29

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #12980] lockup in X.org

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
Submitter	: fanderay <fanderay4-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date		: 2009-04-22 14:39 (47 days old)

[Bug #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13148
Subject		: resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
Submitter	: fanderay <fanderay4@googlemail.com>
Date		: 2009-04-22 14:39 (47 days old)

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Bug #13178] Booting very slow

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Bug #13178] Booting very slow

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

[Bug #13225] [2.6.29 regression] Software suspend no longer works

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


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

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject		: i915: drm: xorg leaks drm objects massively
Submitter	: Sergei Trofimovich <slyich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-05-10 19:56 (29 days old)
References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4

[Bug #13371] s2disk hangs with e100, kernel 2.6.29 and later

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject		: s2disk hangs with e100, kernel 2.6.29 and later
Submitter	: Richard Atterer <richard-2/EmM+jwkBzwc4Swprx3xw@public.gmane.org>
Date		: 2009-05-16 22:51 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=Unknown
References	: http://marc.info/?l=linux-kernel&m=124251446428166&w=4
		  http://lkml.org/lkml/2009/5/25/253
Handled-By	: Jeffrey Kirsher <jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

[Bug #13339] rtable leak in ipv4/route.c

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject		: rtable leak in ipv4/route.c
Submitter	: Alexander V. Lukyanov <lav-L+1EwoRT+D8@public.gmane.org>
Date		: 2009-05-18 14:10 (21 days old)

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject		: Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter	: Alex Samad <alex-SGFoFqf0RKf0CCvOHzKKcA@public.gmane.org>
Date		: 2009-05-20 0:37 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=124278675503699&w=4

[Bug #13339] rtable leak in ipv4/route.c

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject		: rtable leak in ipv4/route.c
Submitter	: Alexander V. Lukyanov <lav@yar.ru>
Date		: 2009-05-18 14:10 (21 days old)

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject		: Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter	: Alex Samad <alex@samad.com.au>
Date		: 2009-05-20 0:37 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=124278675503699&w=4

[Bug #13371] s2disk hangs with e100, kernel 2.6.29 and later

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject		: s2disk hangs with e100, kernel 2.6.29 and later
Submitter	: Richard Atterer <richard@2009.atterer.net>
Date		: 2009-05-16 22:51 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=Unknown
References	: http://marc.info/?l=linux-kernel&m=124251446428166&w=4
		  http://lkml.org/lkml/2009/5/25/253
Handled-By	: Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject		: i915: drm: xorg leaks drm objects massively
Submitter	: Sergei Trofimovich <slyich@gmail.com>
Date		: 2009-05-10 19:56 (29 days old)
References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
Submitter	: Guido <bugzilla.kernel.org-Dy4KJ/v5nlEVgfBnK23ub6xOck334EZe@public.gmane.org>
Date		: 2009-05-31 12:21 (8 days old)

[Bug #13463] Poor SSD performance

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
Subject		: Poor SSD performance
Submitter	: Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>
Date		: 2009-06-05 17:37 (3 days old)

[Bug #13463] Poor SSD performance

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
Subject		: Poor SSD performance
Submitter	: Jake <ellowitz@uchicago.edu>
Date		: 2009-06-05 17:37 (3 days old)

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

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.

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


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
Submitter	: Guido <bugzilla.kernel.org@starbase12.cjb.net>
Date		: 2009-05-31 12:21 (8 days old)

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

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

On Sun,  7 Jun 2009 12:06:23 +0200 (CEST)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
> Subject		: i915: drm: xorg leaks drm objects massively
> Submitter	: Sergei Trofimovich <slyich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2009-05-10 19:56 (29 days old)
> References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4
> 
> 
Rafael, please remove it from regression list. I haven't found kernel working
the other way. It's a bug(set of bugs) being around "forever". Many people
confirm it on various laptops/kernel versions. It's just not very noticeable.

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Sun,  7 Jun 2009 12:06:23 +0200 (CEST)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
> Subject		: i915: drm: xorg leaks drm objects massively
> Submitter	: Sergei Trofimovich <slyich@gmail.com>
> Date		: 2009-05-10 19:56 (29 days old)
> References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4
> 
> 
Rafael, please remove it from regression list. I haven't found kernel working
the other way. It's a bug(set of bugs) being around "forever". Many people
confirm it on various laptops/kernel versions. It's just not very noticeable.

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Theodore Tso]

On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> Submitter	: David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> Date		: 2009-05-03 19:46 (36 days old)

Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
wedged by Postfix".  I pinged Al previously about pushing this as a
regression fix for 2.6.30, but never got a response.  At this point we
might as well wait for it to go into the 2.6.31 merge window, and then
we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.

       	       	     	     	 	      	       - Ted

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

[Theodore Tso]

On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> Submitter	: David Watson <kernel-nospam@dbwatson.ukfsn.org>
> Date		: 2009-05-03 19:46 (36 days old)

Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
wedged by Postfix".  I pinged Al previously about pushing this as a
regression fix for 2.6.30, but never got a response.  At this point we
might as well wait for it to go into the 2.6.31 merge window, and then
we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.

       	       	     	     	 	      	       - Ted

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

[Robert Hancock]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13072
> Subject		: forcedeth seems to switch off eth on shutdown
> Submitter	: Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
> Date		: 2009-04-12 07:00 (57 days old)

Seems like it should be fixed by:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9

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

[Robert Hancock]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13072
> Subject		: forcedeth seems to switch off eth on shutdown
> Submitter	: Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY@public.gmane.org>
> Date		: 2009-04-12 07:00 (57 days old)

Seems like it should be fixed by:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9

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

[Al Viro]

On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter	: David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > Date		: 2009-05-03 19:46 (36 days old)
> 
> Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> wedged by Postfix".  I pinged Al previously about pushing this as a
> regression fix for 2.6.30, but never got a response.  At this point we
> might as well wait for it to go into the 2.6.31 merge window, and then
> we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.

It's in mainline now, actually.  But yes, we need it in -stable as well.

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

[Al Viro]

On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter	: David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > Date		: 2009-05-03 19:46 (36 days old)
> 
> Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> wedged by Postfix".  I pinged Al previously about pushing this as a
> regression fix for 2.6.30, but never got a response.  At this point we
> might as well wait for it to go into the 2.6.31 merge window, and then
> we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.

It's in mainline now, actually.  But yes, we need it in -stable as well.

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

[bugzilla-daemon]

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


Theodore Tso <tytso@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu




--- Comment #13 from Theodore Tso <tytso@mit.edu>  2009-06-07 19:56:04 ---
This patch is now in the upstream kernel, so it will be in 2.6.30.

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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


Theodore Tso <tytso@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |CODE_FIX




-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Mike Dresser]

> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).

Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed 
this.  I'd say to leave this open for now, there's at least one other 
person testing 2.6.30-rc8 to see if it's fixed or not.

Mike

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

[Mike Dresser]

> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).

Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed 
this.  I'd say to leave this open for now, there's at least one other 
person testing 2.6.30-rc8 to see if it's fixed or not.

Mike

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

[Theodore Tso]

On Sun, Jun 07, 2009 at 06:17:39PM +0100, Al Viro wrote:
> On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> > On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.28 and 2.6.29.
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter	: David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > > Date		: 2009-05-03 19:46 (36 days old)
> > 
> > Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> > tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> > wedged by Postfix".  I pinged Al previously about pushing this as a
> > regression fix for 2.6.30, but never got a response.  At this point we
> > might as well wait for it to go into the 2.6.31 merge window, and then
> > we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
> 
> It's in mainline now, actually.  But yes, we need it in -stable as well.

Great, thanks; sorry, I didn't realize it had been queued for mainline
submisison, and it wasn't there when I looked last week.  I've closed
the bugzilla entry since it is now in mainline.  Would you like to
send the patch to stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, or shall I?

						- Ted

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

[Theodore Tso]

On Sun, Jun 07, 2009 at 06:17:39PM +0100, Al Viro wrote:
> On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> > On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.28 and 2.6.29.
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject		: ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter	: David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > > Date		: 2009-05-03 19:46 (36 days old)
> > 
> > Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> > tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> > wedged by Postfix".  I pinged Al previously about pushing this as a
> > regression fix for 2.6.30, but never got a response.  At this point we
> > might as well wait for it to go into the 2.6.31 merge window, and then
> > we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
> 
> It's in mainline now, actually.  But yes, we need it in -stable as well.

Great, thanks; sorry, I didn't realize it had been queued for mainline
submisison, and it wasn't there when I looked last week.  I've closed
the bugzilla entry since it is now in mainline.  Would you like to
send the patch to stable@kernel.org, or shall I?

						- Ted

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

[bugzilla-daemon]

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


Rafael J. Wysocki <rjw@sisk.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED




-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Rafael J. Wysocki]

On Sunday 07 June 2009, Robert Hancock wrote:
> 
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13072
> > Subject		: forcedeth seems to switch off eth on shutdown
> > Submitter	: Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
> > Date		: 2009-04-12 07:00 (57 days old)
> 
> Seems like it should be fixed by:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9

Thanks, I've closed the bug.

Rafael

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

[Rafael J. Wysocki]

On Sunday 07 June 2009, Robert Hancock wrote:
> 
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13072
> > Subject		: forcedeth seems to switch off eth on shutdown
> > Submitter	: Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY@public.gmane.org>
> > Date		: 2009-04-12 07:00 (57 days old)
> 
> Seems like it should be fixed by:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9a8e32ebe269c71d8d3e78f9435fe7729f38e9

Thanks, I've closed the bug.

Rafael

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

[Rafael J. Wysocki]

On Sunday 07 June 2009, Sergei Trofimovich wrote:
> On Sun,  7 Jun 2009 12:06:23 +0200 (CEST)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
> > Subject		: i915: drm: xorg leaks drm objects massively
> > Submitter	: Sergei Trofimovich <slyich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-05-10 19:56 (29 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4
> > 
> > 
> Rafael, please remove it from regression list. I haven't found kernel working
> the other way. It's a bug(set of bugs) being around "forever". Many people
> confirm it on various laptops/kernel versions. It's just not very noticeable.

OK, dropped.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Sunday 07 June 2009, Sergei Trofimovich wrote:
> On Sun,  7 Jun 2009 12:06:23 +0200 (CEST)
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13294
> > Subject		: i915: drm: xorg leaks drm objects massively
> > Submitter	: Sergei Trofimovich <slyich@gmail.com>
> > Date		: 2009-05-10 19:56 (29 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124198547027903&w=4
> > 
> > 
> Rafael, please remove it from regression list. I haven't found kernel working
> the other way. It's a bug(set of bugs) being around "forever". Many people
> confirm it on various laptops/kernel versions. It's just not very noticeable.

OK, dropped.

Thanks,
Rafael

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

[Mathias Kretschmer]

On Sunday 07 June 2009 22:09:23 Mike Dresser wrote:
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
>
> Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed
> this.  I'd say to leave this open for now, there's at least one other
> person testing 2.6.30-rc8 to see if it's fixed or not.

I'm afraid my test here won't help much to answer this question.

I've seen no more crashes, but starting with 2.6.29 I'm seeing so many 
'reconnect_path: npd != pd' messages and am experiencing lots of 'stale NFS 
handles'  that I turned off NFS yesterday evening until I have more time to look 
into this.

-Mathias


> Mike
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Mathias Kretschmer]

On Sunday 07 June 2009 22:09:23 Mike Dresser wrote:
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
>
> Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed
> this.  I'd say to leave this open for now, there's at least one other
> person testing 2.6.30-rc8 to see if it's fixed or not.

I'm afraid my test here won't help much to answer this question.

I've seen no more crashes, but starting with 2.6.29 I'm seeing so many 
'reconnect_path: npd != pd' messages and am experiencing lots of 'stale NFS 
handles'  that I turned off NFS yesterday evening until I have more time to look 
into this.

-Mathias


> Mike
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Mathias Kretschmer]

oops.  I've overseen a BUG. this is on 2.6.30-rc8-git2 (with NFS still active):

Jun  7 00:04:29 [kernel] [18059.860915] reconnect_path: npd != pd
Jun  7 00:04:29 [kernel] [18059.876749] reconnect_path: npd != pd
Jun  7 00:04:29 [kernel] [18059.884702] reconnect_path: npd != pd
Jun  7 00:04:29 [kernel] [18060.605674] kernel BUG at lib/radix-tree.c:485!
Jun  7 00:04:29 [kernel] [18060.605689] CPU 1
Jun  7 00:04:29 [kernel] [18060.605693] Modules linked in: usbtouchscreen 
dvb_usb_cinergyT2 dummy bonding snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus 
forcedeth snd_pcm hfcpci snd_page_alloc snd_util_mem snd_hwdep
Jun  7 00:04:29 [kernel] [18060.605721] Pid: 392, comm: kswapd0 Not tainted 
2.6.30-rc8-git2 #2 empty
Jun  7 00:04:29 [kernel] [18060.605726] RIP: 0010:[<ffffffff80451ad8>]  
[<ffffffff80451ad8>] radix_tree_tag_set+0x98/0xc0
Jun  7 00:04:29 [kernel] [18060.605743] RSP: 0018:ffff880226b05cd0  EFLAGS: 
00010246
Jun  7 00:04:29 [kernel] [18060.605748] RAX: 000000000000000c RBX: 
0000000000000000 RCX: 000000000000000c
Jun  7 00:04:29 [kernel] [18060.605752] RDX: 0000000000000000 RSI: 
000000000000040c RDI: ffff88022628e360
Jun  7 00:04:29 [kernel] [18060.605757] RBP: ffff880201159c00 R08: 
ffff88020119da28 R09: 0000000000000000
Jun  7 00:04:29 [kernel] [18060.605762] R10: 0000000000000000 R11: 
0000000000000001 R12: ffff880201159c00
Jun  7 00:04:29 [kernel] [18060.605766] R13: ffff88022505f400 R14: 
ffff880201159cf8 R15: ffff88022628e35c
Jun  7 00:04:29 [kernel] [18060.605772] FS:  0000000043d51950(0000) 
GS:ffff88002804e000(0000) knlGS:00000000f4ceab90
Jun  7 00:04:29 [kernel] [18060.605777] CS:  0010 DS: 0018 ES: 0018 CR0: 
000000008005003b
Jun  7 00:04:29 [kernel] [18060.605782] CR2: 000000000044b7c0 CR3: 
00000001e45fe000 CR4: 00000000000006e0
Jun  7 00:04:29 [kernel] [18060.605786] DR0: 0000000000000000 DR1: 
0000000000000000 DR2: 0000000000000000
Jun  7 00:04:29 [kernel] [18060.605791] DR3: 0000000000000000 DR6: 
00000000ffff0ff0 DR7: 0000000000000400
Jun  7 00:04:29 [kernel] [18060.605796] Process kswapd0 (pid: 392, threadinfo 
ffff880226b04000, task ffff880227981620)
Jun  7 00:04:29 [kernel] [18060.605803]  ffff88022628e320 ffffffff8040a1d6 
ffff880201159d80 0000000000000071
Jun  7 00:04:29 [kernel] [18060.606011] RIP  [<ffffffff80451ad8>] 
radix_tree_tag_set+0x98/0xc0
Jun  7 00:04:30 [kernel] [18060.606018]  RSP <ffff880226b05cd0>
Jun  7 00:04:30 [kernel] [18060.606026] ---[ end trace 0645e929a4fa40ac ]---
Jun  7 00:04:31 [kernel] [18061.930702] reconnect_path: npd != pd
Jun  7 00:04:31 [kernel] [18061.930944] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.327856] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.328465] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.328722] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.329075] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.329598] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.329734] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.330410] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.330538] reconnect_path: npd != pd


On Monday 08 June 2009 09:27:09 Mathias Kretschmer wrote:
> On Sunday 07 June 2009 22:09:23 Mike Dresser wrote:
> > > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > > be listed and let me know (either way).
> >
> > Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed
> > this.  I'd say to leave this open for now, there's at least one other
> > person testing 2.6.30-rc8 to see if it's fixed or not.
>
> I'm afraid my test here won't help much to answer this question.
>
> I've seen no more crashes, but starting with 2.6.29 I'm seeing so many
> 'reconnect_path: npd != pd' messages and am experiencing lots of 'stale NFS
> handles'  that I turned off NFS yesterday evening until I have more time to
> look into this.
>
> -Mathias
>
> > Mike
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Mathias Kretschmer]

oops.  I've overseen a BUG. this is on 2.6.30-rc8-git2 (with NFS still active):

Jun  7 00:04:29 [kernel] [18059.860915] reconnect_path: npd != pd
Jun  7 00:04:29 [kernel] [18059.876749] reconnect_path: npd != pd
Jun  7 00:04:29 [kernel] [18059.884702] reconnect_path: npd != pd
Jun  7 00:04:29 [kernel] [18060.605674] kernel BUG at lib/radix-tree.c:485!
Jun  7 00:04:29 [kernel] [18060.605689] CPU 1
Jun  7 00:04:29 [kernel] [18060.605693] Modules linked in: usbtouchscreen 
dvb_usb_cinergyT2 dummy bonding snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus 
forcedeth snd_pcm hfcpci snd_page_alloc snd_util_mem snd_hwdep
Jun  7 00:04:29 [kernel] [18060.605721] Pid: 392, comm: kswapd0 Not tainted 
2.6.30-rc8-git2 #2 empty
Jun  7 00:04:29 [kernel] [18060.605726] RIP: 0010:[<ffffffff80451ad8>]  
[<ffffffff80451ad8>] radix_tree_tag_set+0x98/0xc0
Jun  7 00:04:29 [kernel] [18060.605743] RSP: 0018:ffff880226b05cd0  EFLAGS: 
00010246
Jun  7 00:04:29 [kernel] [18060.605748] RAX: 000000000000000c RBX: 
0000000000000000 RCX: 000000000000000c
Jun  7 00:04:29 [kernel] [18060.605752] RDX: 0000000000000000 RSI: 
000000000000040c RDI: ffff88022628e360
Jun  7 00:04:29 [kernel] [18060.605757] RBP: ffff880201159c00 R08: 
ffff88020119da28 R09: 0000000000000000
Jun  7 00:04:29 [kernel] [18060.605762] R10: 0000000000000000 R11: 
0000000000000001 R12: ffff880201159c00
Jun  7 00:04:29 [kernel] [18060.605766] R13: ffff88022505f400 R14: 
ffff880201159cf8 R15: ffff88022628e35c
Jun  7 00:04:29 [kernel] [18060.605772] FS:  0000000043d51950(0000) 
GS:ffff88002804e000(0000) knlGS:00000000f4ceab90
Jun  7 00:04:29 [kernel] [18060.605777] CS:  0010 DS: 0018 ES: 0018 CR0: 
000000008005003b
Jun  7 00:04:29 [kernel] [18060.605782] CR2: 000000000044b7c0 CR3: 
00000001e45fe000 CR4: 00000000000006e0
Jun  7 00:04:29 [kernel] [18060.605786] DR0: 0000000000000000 DR1: 
0000000000000000 DR2: 0000000000000000
Jun  7 00:04:29 [kernel] [18060.605791] DR3: 0000000000000000 DR6: 
00000000ffff0ff0 DR7: 0000000000000400
Jun  7 00:04:29 [kernel] [18060.605796] Process kswapd0 (pid: 392, threadinfo 
ffff880226b04000, task ffff880227981620)
Jun  7 00:04:29 [kernel] [18060.605803]  ffff88022628e320 ffffffff8040a1d6 
ffff880201159d80 0000000000000071
Jun  7 00:04:29 [kernel] [18060.606011] RIP  [<ffffffff80451ad8>] 
radix_tree_tag_set+0x98/0xc0
Jun  7 00:04:30 [kernel] [18060.606018]  RSP <ffff880226b05cd0>
Jun  7 00:04:30 [kernel] [18060.606026] ---[ end trace 0645e929a4fa40ac ]---
Jun  7 00:04:31 [kernel] [18061.930702] reconnect_path: npd != pd
Jun  7 00:04:31 [kernel] [18061.930944] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.327856] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.328465] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.328722] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.329075] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.329598] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.329734] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.330410] reconnect_path: npd != pd
Jun  7 00:04:32 [kernel] [18063.330538] reconnect_path: npd != pd


On Monday 08 June 2009 09:27:09 Mathias Kretschmer wrote:
> On Sunday 07 June 2009 22:09:23 Mike Dresser wrote:
> > > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > > be listed and let me know (either way).
> >
> > Still testing, but so far 2.6.30-rc8(or another RC) seems to have fixed
> > this.  I'd say to leave this open for now, there's at least one other
> > person testing 2.6.30-rc8 to see if it's fixed or not.
>
> I'm afraid my test here won't help much to answer this question.
>
> I've seen no more crashes, but starting with 2.6.29 I'm seeing so many
> 'reconnect_path: npd != pd' messages and am experiencing lots of 'stale NFS
> handles'  that I turned off NFS yesterday evening until I have more time to
> look into this.
>
> -Mathias
>
> > Mike
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- Original Message ----

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

 No change since last ping. We ruled out a non-HP NIC in the DL380. HP will try to reproduce in-house.

Martin

Re: [Bug #13178] Booting very slow

[Martin Knoblauch]

----- Original Message ----

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

 No change since last ping. We ruled out a non-HP NIC in the DL380. HP will try to reproduce in-house.

Martin

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

[Jiri Kosina]

On Sun, 7 Jun 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
> Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
> Submitter	: Guido <bugzilla.kernel.org-Dy4KJ/v5nlEVgfBnK23ub6xOck334EZe@public.gmane.org>
> Date		: 2009-05-31 12:21 (8 days old)

This is apparently caused by vendor releasing two different hardware 
products under the same VID/PID and just one of them needing blacklist 
entry. Sigh.

Waiting for verbose lsusb output from Remi, so that we could compare it 
with the output provided by the bug reporter, to see what else could be 
done to distinguish the devices from each other.

-- 
Jiri Kosina
SUSE Labs

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

[Jiri Kosina]

On Sun, 7 Jun 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
> Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
> Submitter	: Guido <bugzilla.kernel.org@starbase12.cjb.net>
> Date		: 2009-05-31 12:21 (8 days old)

This is apparently caused by vendor releasing two different hardware 
products under the same VID/PID and just one of them needing blacklist 
entry. Sigh.

Waiting for verbose lsusb output from Remi, so that we could compare it 
with the output provided by the bug reporter, to see what else could be 
done to distinguish the devices from each other.

-- 
Jiri Kosina
SUSE Labs

Re: [Bug #13178] Booting very slow

[Rafael J. Wysocki]

On Monday 08 June 2009, Martin Knoblauch wrote:
> 
> ----- Original Message ----
> 
> > From: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> > To: Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> > Cc: Kernel Testers List <kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>; Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>; Stephen Hemminger <shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org>
> > Sent: Sunday, June 7, 2009 12:06:22 PM
> > Subject: [Bug #13178] Booting very slow
> > 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13178
> > Subject        : Booting very slow
> > Submitter    : Martin Knoblauch 
> > Date        : 2009-04-24 12:45 (45 days old)
> > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> 
>  No change since last ping. We ruled out a non-HP NIC in the DL380. HP will try to reproduce in-house.

Thanks a lot for the update.

Best,
Rafael

Re: [Bug #13178] Booting very slow

[Rafael J. Wysocki]

On Monday 08 June 2009, Martin Knoblauch wrote:
> 
> ----- Original Message ----
> 
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> > To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Kernel Testers List <kernel-testers@vger.kernel.org>; Jesse Barnes <jbarnes@virtuousgeek.org>; Martin Knoblauch <spamtrap@knobisoft.de>; Stephen Hemminger <shemminger@vyatta.com>
> > Sent: Sunday, June 7, 2009 12:06:22 PM
> > Subject: [Bug #13178] Booting very slow
> > 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13178
> > Subject        : Booting very slow
> > Submitter    : Martin Knoblauch 
> > Date        : 2009-04-24 12:45 (45 days old)
> > References    : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
> 
>  No change since last ping. We ruled out a non-HP NIC in the DL380. HP will try to reproduce in-house.

Thanks a lot for the update.

Best,
Rafael

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

[Rafael J. Wysocki]

On Monday 08 June 2009, Jiri Kosina wrote:
> On Sun, 7 Jun 2009, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
> > Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
> > Submitter	: Guido <bugzilla.kernel.org-Dy4KJ/v5nlEVgfBnK23ub6xOck334EZe@public.gmane.org>
> > Date		: 2009-05-31 12:21 (8 days old)
> 
> This is apparently caused by vendor releasing two different hardware 
> products under the same VID/PID and just one of them needing blacklist 
> entry. Sigh.

Oh well.

> Waiting for verbose lsusb output from Remi, so that we could compare it 
> with the output provided by the bug reporter, to see what else could be 
> done to distinguish the devices from each other.

Thanks for the update.

Best,
Rafael

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

[Rafael J. Wysocki]

On Monday 08 June 2009, Jiri Kosina wrote:
> On Sun, 7 Jun 2009, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
> > Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
> > Submitter	: Guido <bugzilla.kernel.org@starbase12.cjb.net>
> > Date		: 2009-05-31 12:21 (8 days old)
> 
> This is apparently caused by vendor releasing two different hardware 
> products under the same VID/PID and just one of them needing blacklist 
> entry. Sigh.

Oh well.

> Waiting for verbose lsusb output from Remi, so that we could compare it 
> with the output provided by the bug reporter, to see what else could be 
> done to distinguish the devices from each other.

Thanks for the update.

Best,
Rafael

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

[Mike Dresser]

Mine crashed last night, nothing was logged in the local logfiles, but 
fortunately remote syslog got it

Jun  9 01:24:07 x kernel: ------------[ cut here ]------------
Jun  9 01:24:07 x kernel: kernel BUG at lib/radix-tree.c:485!
Jun  9 01:24:07 x kernel: invalid opcode: 0000 [#1] SMP
Jun  9 01:24:07 x kernel: last sysfs file: /sys/class/scsi_host/host0/stats
Jun  9 01:24:07 x kernel: CPU 0
Jun  9 01:24:07 x kernel: Pid: 338, comm: kswapd0 Not tainted 2.6.30-rc8 #2 S2895
Jun  9 01:24:07 x kernel: RIP: 0010:[<ffffffff803a5a04>]  [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c
Jun  9 01:24:07 x kernel: RSP: 0018:ffff88016e1e9c58  EFLAGS: 00010246
Jun  9 01:24:07 x kernel: RAX: 0000000000000038 RBX: 0000000000000000 RCX: 0000000000000038
Jun  9 01:24:07 x kernel: RDX: 0000000000000000 RSI: 00000000002faaf8 RDI: ffff88016c3b8220
Jun  9 01:24:07 x kernel: RBP: ffff88016e1e9c60 R08: 0000000000000000 R09: ffff8800927460b8
Jun  9 01:24:07 x kernel: R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800666e61c0
Jun  9 01:24:07 x kernel: R13: ffff88016dc21c00 R14: ffff8800666e62c8 R15: ffff88016c3b821c
Jun  9 01:24:07 x kernel: FS:  00007fda3776f6e0(0000) GS:ffff880028028000(0000) knlGS:0000000000000000
Jun  9 01:24:07 x kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Jun  9 01:24:07 x kernel: CR2: 00007fda368758e0 CR3: 0000000000201000 CR4: 00000000000006e0
Jun  9 01:24:07 x kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun  9 01:24:07 x kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jun  9 01:24:07 x kernel: Process kswapd0 (pid: 338, threadinfo ffff88016e1e8000, task ffff88016f245fa0)
Jun  9 01:24:07 x kernel: Stack:
Jun  9 01:24:07 x kernel:  ffff88016c3b81e0 ffff88016e1e9ca0 ffffffff8038dcd6 ffff88016e1e9d40
Jun  9 01:24:07 x kernel:  ffff8800666e6350 ffff8800666e61c0 0000000000000048 ffff88016e1e9d40
Jun  9 01:24:07 x kernel:  0000000000000080 ffff88016e1e9cc0 ffffffff8037f2d2 ffff8800666e6350
Jun  9 01:24:07 x kernel: Call Trace:
Jun  9 01:24:07 x kernel:  [<ffffffff8038dcd6>] xfs_inode_set_reclaim_tag+0x71/0x93
Jun  9 01:24:07 x kernel:  [<ffffffff8037f2d2>] xfs_reclaim+0x106/0x10d
Jun  9 01:24:07 x kernel:  [<ffffffff8038c51e>] xfs_fs_destroy_inode+0x37/0x58
Jun  9 01:24:07 x kernel:  [<ffffffff8029dde0>] destroy_inode+0x32/0x47
Jun  9 01:24:07 x kernel:  [<ffffffff8029dec9>] dispose_list+0xd4/0x102
Jun  9 01:24:07 x kernel:  [<ffffffff8029e0f0>] shrink_icache_memory+0x1f9/0x22f
Jun  9 01:24:07 x kernel:  [<ffffffff80269660>] shrink_slab+0xdf/0x154
Jun  9 01:24:07 x kernel:  [<ffffffff80269e13>] kswapd+0x48d/0x62c
Jun  9 01:24:07 x kernel:  [<ffffffff80267765>] ? isolate_pages_global+0x0/0x219
Jun  9 01:24:07 x kernel:  [<ffffffff802481b8>] ? autoremove_wake_function+0x0/0x38
Jun  9 01:24:07 x kernel:  [<ffffffff80269986>] ? kswapd+0x0/0x62c
Jun  9 01:24:07 x kernel:  [<ffffffff80269986>] ? kswapd+0x0/0x62c
Jun  9 01:24:07 x kernel:  [<ffffffff80247e1a>] kthread+0x56/0x83
Jun  9 01:24:07 x kernel:  [<ffffffff8020c9ba>] child_rip+0xa/0x20
Jun  9 01:24:07 x kernel:  [<ffffffff80247dc4>] ? kthread+0x0/0x83
Jun  9 01:24:07 x kernel:  [<ffffffff8020c9b0>] ? child_rip+0x0/0x20
Jun  9 01:24:07 x kernel: Code: 18 02 00 00 48 d3 e8 89 c1 83 e1 3f 41 0f a3 0c 11 19 c0 85 c0 75 07 49 8d 04 11 0f ab 08 48 63 c1 4d 8b 44 c0 18 4d 85 c0 75 04 <0f> 0b eb fe 41 83 eb 06 41 ff ca 45$
Jun  9 01:24:07 x kernel: RIP  [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c
Jun  9 01:24:07 x kernel:  RSP <ffff88016e1e9c58>
Jun  9 01:24:07 x kernel: ---[ end trace a0564fe308c3b2b4 ]---

CONFIG_XFS_DEBUG was on for this one.

I've noticed it's always kswapd0 that dies?

Mike

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

[Mike Dresser]

Mine crashed last night, nothing was logged in the local logfiles, but 
fortunately remote syslog got it

Jun  9 01:24:07 x kernel: ------------[ cut here ]------------
Jun  9 01:24:07 x kernel: kernel BUG at lib/radix-tree.c:485!
Jun  9 01:24:07 x kernel: invalid opcode: 0000 [#1] SMP
Jun  9 01:24:07 x kernel: last sysfs file: /sys/class/scsi_host/host0/stats
Jun  9 01:24:07 x kernel: CPU 0
Jun  9 01:24:07 x kernel: Pid: 338, comm: kswapd0 Not tainted 2.6.30-rc8 #2 S2895
Jun  9 01:24:07 x kernel: RIP: 0010:[<ffffffff803a5a04>]  [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c
Jun  9 01:24:07 x kernel: RSP: 0018:ffff88016e1e9c58  EFLAGS: 00010246
Jun  9 01:24:07 x kernel: RAX: 0000000000000038 RBX: 0000000000000000 RCX: 0000000000000038
Jun  9 01:24:07 x kernel: RDX: 0000000000000000 RSI: 00000000002faaf8 RDI: ffff88016c3b8220
Jun  9 01:24:07 x kernel: RBP: ffff88016e1e9c60 R08: 0000000000000000 R09: ffff8800927460b8
Jun  9 01:24:07 x kernel: R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800666e61c0
Jun  9 01:24:07 x kernel: R13: ffff88016dc21c00 R14: ffff8800666e62c8 R15: ffff88016c3b821c
Jun  9 01:24:07 x kernel: FS:  00007fda3776f6e0(0000) GS:ffff880028028000(0000) knlGS:0000000000000000
Jun  9 01:24:07 x kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Jun  9 01:24:07 x kernel: CR2: 00007fda368758e0 CR3: 0000000000201000 CR4: 00000000000006e0
Jun  9 01:24:07 x kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun  9 01:24:07 x kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jun  9 01:24:07 x kernel: Process kswapd0 (pid: 338, threadinfo ffff88016e1e8000, task ffff88016f245fa0)
Jun  9 01:24:07 x kernel: Stack:
Jun  9 01:24:07 x kernel:  ffff88016c3b81e0 ffff88016e1e9ca0 ffffffff8038dcd6 ffff88016e1e9d40
Jun  9 01:24:07 x kernel:  ffff8800666e6350 ffff8800666e61c0 0000000000000048 ffff88016e1e9d40
Jun  9 01:24:07 x kernel:  0000000000000080 ffff88016e1e9cc0 ffffffff8037f2d2 ffff8800666e6350
Jun  9 01:24:07 x kernel: Call Trace:
Jun  9 01:24:07 x kernel:  [<ffffffff8038dcd6>] xfs_inode_set_reclaim_tag+0x71/0x93
Jun  9 01:24:07 x kernel:  [<ffffffff8037f2d2>] xfs_reclaim+0x106/0x10d
Jun  9 01:24:07 x kernel:  [<ffffffff8038c51e>] xfs_fs_destroy_inode+0x37/0x58
Jun  9 01:24:07 x kernel:  [<ffffffff8029dde0>] destroy_inode+0x32/0x47
Jun  9 01:24:07 x kernel:  [<ffffffff8029dec9>] dispose_list+0xd4/0x102
Jun  9 01:24:07 x kernel:  [<ffffffff8029e0f0>] shrink_icache_memory+0x1f9/0x22f
Jun  9 01:24:07 x kernel:  [<ffffffff80269660>] shrink_slab+0xdf/0x154
Jun  9 01:24:07 x kernel:  [<ffffffff80269e13>] kswapd+0x48d/0x62c
Jun  9 01:24:07 x kernel:  [<ffffffff80267765>] ? isolate_pages_global+0x0/0x219
Jun  9 01:24:07 x kernel:  [<ffffffff802481b8>] ? autoremove_wake_function+0x0/0x38
Jun  9 01:24:07 x kernel:  [<ffffffff80269986>] ? kswapd+0x0/0x62c
Jun  9 01:24:07 x kernel:  [<ffffffff80269986>] ? kswapd+0x0/0x62c
Jun  9 01:24:07 x kernel:  [<ffffffff80247e1a>] kthread+0x56/0x83
Jun  9 01:24:07 x kernel:  [<ffffffff8020c9ba>] child_rip+0xa/0x20
Jun  9 01:24:07 x kernel:  [<ffffffff80247dc4>] ? kthread+0x0/0x83
Jun  9 01:24:07 x kernel:  [<ffffffff8020c9b0>] ? child_rip+0x0/0x20
Jun  9 01:24:07 x kernel: Code: 18 02 00 00 48 d3 e8 89 c1 83 e1 3f 41 0f a3 0c 11 19 c0 85 c0 75 07 49 8d 04 11 0f ab 08 48 63 c1 4d 8b 44 c0 18 4d 85 c0 75 04 <0f> 0b eb fe 41 83 eb 06 41 ff ca 45$
Jun  9 01:24:07 x kernel: RIP  [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c
Jun  9 01:24:07 x kernel:  RSP <ffff88016e1e9c58>
Jun  9 01:24:07 x kernel: ---[ end trace a0564fe308c3b2b4 ]---

CONFIG_XFS_DEBUG was on for this one.

I've noticed it's always kswapd0 that dies?

Mike

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

[Mathias Kretschmer]

same observation here. it's kswapd that dies.

swap space itself is hardly ever really used, since my box has 8GB and not 
that much stuff is running on it.

my XFS mount opts: noatime,nodiratime,logbufs=8

drive/fs config:  sata => raid6 => lvm => xfs => nfs

machine is stable for the last 36 hours with nfs turned off.

-Mathias
 
On Tuesday 09 June 2009 21:02:13 Mike Dresser wrote:
> Mine crashed last night, nothing was logged in the local logfiles, but
> fortunately remote syslog got it
>
> Jun  9 01:24:07 x kernel: ------------[ cut here ]------------
> Jun  9 01:24:07 x kernel: kernel BUG at lib/radix-tree.c:485!
> Jun  9 01:24:07 x kernel: invalid opcode: 0000 [#1] SMP
> Jun  9 01:24:07 x kernel: last sysfs file: /sys/class/scsi_host/host0/stats
> Jun  9 01:24:07 x kernel: CPU 0
> Jun  9 01:24:07 x kernel: Pid: 338, comm: kswapd0 Not tainted 2.6.30-rc8 #2
> S2895 Jun  9 01:24:07 x kernel: RIP: 0010:[<ffffffff803a5a04>] 
> [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun  9 01:24:07 x kernel:
> RSP: 0018:ffff88016e1e9c58  EFLAGS: 00010246 Jun  9 01:24:07 x kernel: RAX:
> 0000000000000038 RBX: 0000000000000000 RCX: 0000000000000038 Jun  9
> 01:24:07 x kernel: RDX: 0000000000000000 RSI: 00000000002faaf8 RDI:
> ffff88016c3b8220 Jun  9 01:24:07 x kernel: RBP: ffff88016e1e9c60 R08:
> 0000000000000000 R09: ffff8800927460b8 Jun  9 01:24:07 x kernel: R10:
> 0000000000000001 R11: 0000000000000000 R12: ffff8800666e61c0 Jun  9
> 01:24:07 x kernel: R13: ffff88016dc21c00 R14: ffff8800666e62c8 R15:
> ffff88016c3b821c Jun  9 01:24:07 x kernel: FS:  00007fda3776f6e0(0000)
> GS:ffff880028028000(0000) knlGS:0000000000000000 Jun  9 01:24:07 x kernel:
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b Jun  9 01:24:07 x kernel:
> CR2: 00007fda368758e0 CR3: 0000000000201000 CR4: 00000000000006e0 Jun  9
> 01:24:07 x kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000 Jun  9 01:24:07 x kernel: DR3: 0000000000000000 DR6:
> 00000000ffff0ff0 DR7: 0000000000000400 Jun  9 01:24:07 x kernel: Process
> kswapd0 (pid: 338, threadinfo ffff88016e1e8000, task ffff88016f245fa0) Jun 
> 9 01:24:07 x kernel: Stack:
> Jun  9 01:24:07 x kernel:  ffff88016c3b81e0 ffff88016e1e9ca0
> ffffffff8038dcd6 ffff88016e1e9d40 Jun  9 01:24:07 x kernel: 
> ffff8800666e6350 ffff8800666e61c0 0000000000000048 ffff88016e1e9d40 Jun  9
> 01:24:07 x kernel:  0000000000000080 ffff88016e1e9cc0 ffffffff8037f2d2
> ffff8800666e6350 Jun  9 01:24:07 x kernel: Call Trace:
> Jun  9 01:24:07 x kernel:  [<ffffffff8038dcd6>]
> xfs_inode_set_reclaim_tag+0x71/0x93 Jun  9 01:24:07 x kernel: 
> [<ffffffff8037f2d2>] xfs_reclaim+0x106/0x10d Jun  9 01:24:07 x kernel: 
> [<ffffffff8038c51e>] xfs_fs_destroy_inode+0x37/0x58 Jun  9 01:24:07 x
> kernel:  [<ffffffff8029dde0>] destroy_inode+0x32/0x47 Jun  9 01:24:07 x
> kernel:  [<ffffffff8029dec9>] dispose_list+0xd4/0x102 Jun  9 01:24:07 x
> kernel:  [<ffffffff8029e0f0>] shrink_icache_memory+0x1f9/0x22f Jun  9
> 01:24:07 x kernel:  [<ffffffff80269660>] shrink_slab+0xdf/0x154 Jun  9
> 01:24:07 x kernel:  [<ffffffff80269e13>] kswapd+0x48d/0x62c Jun  9 01:24:07
> x kernel:  [<ffffffff80267765>] ? isolate_pages_global+0x0/0x219 Jun  9
> 01:24:07 x kernel:  [<ffffffff802481b8>] ?
> autoremove_wake_function+0x0/0x38 Jun  9 01:24:07 x kernel: 
> [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun  9 01:24:07 x kernel: 
> [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun  9 01:24:07 x kernel: 
> [<ffffffff80247e1a>] kthread+0x56/0x83
> Jun  9 01:24:07 x kernel:  [<ffffffff8020c9ba>] child_rip+0xa/0x20
> Jun  9 01:24:07 x kernel:  [<ffffffff80247dc4>] ? kthread+0x0/0x83
> Jun  9 01:24:07 x kernel:  [<ffffffff8020c9b0>] ? child_rip+0x0/0x20
> Jun  9 01:24:07 x kernel: Code: 18 02 00 00 48 d3 e8 89 c1 83 e1 3f 41 0f
> a3 0c 11 19 c0 85 c0 75 07 49 8d 04 11 0f ab 08 48 63 c1 4d 8b 44 c0 18 4d
> 85 c0 75 04 <0f> 0b eb fe 41 83 eb 06 41 ff ca 45$ Jun  9 01:24:07 x
> kernel: RIP  [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun  9
> 01:24:07 x kernel:  RSP <ffff88016e1e9c58>
> Jun  9 01:24:07 x kernel: ---[ end trace a0564fe308c3b2b4 ]---
>
> CONFIG_XFS_DEBUG was on for this one.
>
> I've noticed it's always kswapd0 that dies?
>
> Mike

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

[Mathias Kretschmer]

same observation here. it's kswapd that dies.

swap space itself is hardly ever really used, since my box has 8GB and not 
that much stuff is running on it.

my XFS mount opts: noatime,nodiratime,logbufs=8

drive/fs config:  sata => raid6 => lvm => xfs => nfs

machine is stable for the last 36 hours with nfs turned off.

-Mathias
 
On Tuesday 09 June 2009 21:02:13 Mike Dresser wrote:
> Mine crashed last night, nothing was logged in the local logfiles, but
> fortunately remote syslog got it
>
> Jun  9 01:24:07 x kernel: ------------[ cut here ]------------
> Jun  9 01:24:07 x kernel: kernel BUG at lib/radix-tree.c:485!
> Jun  9 01:24:07 x kernel: invalid opcode: 0000 [#1] SMP
> Jun  9 01:24:07 x kernel: last sysfs file: /sys/class/scsi_host/host0/stats
> Jun  9 01:24:07 x kernel: CPU 0
> Jun  9 01:24:07 x kernel: Pid: 338, comm: kswapd0 Not tainted 2.6.30-rc8 #2
> S2895 Jun  9 01:24:07 x kernel: RIP: 0010:[<ffffffff803a5a04>] 
> [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun  9 01:24:07 x kernel:
> RSP: 0018:ffff88016e1e9c58  EFLAGS: 00010246 Jun  9 01:24:07 x kernel: RAX:
> 0000000000000038 RBX: 0000000000000000 RCX: 0000000000000038 Jun  9
> 01:24:07 x kernel: RDX: 0000000000000000 RSI: 00000000002faaf8 RDI:
> ffff88016c3b8220 Jun  9 01:24:07 x kernel: RBP: ffff88016e1e9c60 R08:
> 0000000000000000 R09: ffff8800927460b8 Jun  9 01:24:07 x kernel: R10:
> 0000000000000001 R11: 0000000000000000 R12: ffff8800666e61c0 Jun  9
> 01:24:07 x kernel: R13: ffff88016dc21c00 R14: ffff8800666e62c8 R15:
> ffff88016c3b821c Jun  9 01:24:07 x kernel: FS:  00007fda3776f6e0(0000)
> GS:ffff880028028000(0000) knlGS:0000000000000000 Jun  9 01:24:07 x kernel:
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b Jun  9 01:24:07 x kernel:
> CR2: 00007fda368758e0 CR3: 0000000000201000 CR4: 00000000000006e0 Jun  9
> 01:24:07 x kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000 Jun  9 01:24:07 x kernel: DR3: 0000000000000000 DR6:
> 00000000ffff0ff0 DR7: 0000000000000400 Jun  9 01:24:07 x kernel: Process
> kswapd0 (pid: 338, threadinfo ffff88016e1e8000, task ffff88016f245fa0) Jun 
> 9 01:24:07 x kernel: Stack:
> Jun  9 01:24:07 x kernel:  ffff88016c3b81e0 ffff88016e1e9ca0
> ffffffff8038dcd6 ffff88016e1e9d40 Jun  9 01:24:07 x kernel: 
> ffff8800666e6350 ffff8800666e61c0 0000000000000048 ffff88016e1e9d40 Jun  9
> 01:24:07 x kernel:  0000000000000080 ffff88016e1e9cc0 ffffffff8037f2d2
> ffff8800666e6350 Jun  9 01:24:07 x kernel: Call Trace:
> Jun  9 01:24:07 x kernel:  [<ffffffff8038dcd6>]
> xfs_inode_set_reclaim_tag+0x71/0x93 Jun  9 01:24:07 x kernel: 
> [<ffffffff8037f2d2>] xfs_reclaim+0x106/0x10d Jun  9 01:24:07 x kernel: 
> [<ffffffff8038c51e>] xfs_fs_destroy_inode+0x37/0x58 Jun  9 01:24:07 x
> kernel:  [<ffffffff8029dde0>] destroy_inode+0x32/0x47 Jun  9 01:24:07 x
> kernel:  [<ffffffff8029dec9>] dispose_list+0xd4/0x102 Jun  9 01:24:07 x
> kernel:  [<ffffffff8029e0f0>] shrink_icache_memory+0x1f9/0x22f Jun  9
> 01:24:07 x kernel:  [<ffffffff80269660>] shrink_slab+0xdf/0x154 Jun  9
> 01:24:07 x kernel:  [<ffffffff80269e13>] kswapd+0x48d/0x62c Jun  9 01:24:07
> x kernel:  [<ffffffff80267765>] ? isolate_pages_global+0x0/0x219 Jun  9
> 01:24:07 x kernel:  [<ffffffff802481b8>] ?
> autoremove_wake_function+0x0/0x38 Jun  9 01:24:07 x kernel: 
> [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun  9 01:24:07 x kernel: 
> [<ffffffff80269986>] ? kswapd+0x0/0x62c Jun  9 01:24:07 x kernel: 
> [<ffffffff80247e1a>] kthread+0x56/0x83
> Jun  9 01:24:07 x kernel:  [<ffffffff8020c9ba>] child_rip+0xa/0x20
> Jun  9 01:24:07 x kernel:  [<ffffffff80247dc4>] ? kthread+0x0/0x83
> Jun  9 01:24:07 x kernel:  [<ffffffff8020c9b0>] ? child_rip+0x0/0x20
> Jun  9 01:24:07 x kernel: Code: 18 02 00 00 48 d3 e8 89 c1 83 e1 3f 41 0f
> a3 0c 11 19 c0 85 c0 75 07 49 8d 04 11 0f ab 08 48 63 c1 4d 8b 44 c0 18 4d
> 85 c0 75 04 <0f> 0b eb fe 41 83 eb 06 41 ff ca 45$ Jun  9 01:24:07 x
> kernel: RIP  [<ffffffff803a5a04>] radix_tree_tag_set+0x6b/0x9c Jun  9
> 01:24:07 x kernel:  RSP <ffff88016e1e9c58>
> Jun  9 01:24:07 x kernel: ---[ end trace a0564fe308c3b2b4 ]---
>
> CONFIG_XFS_DEBUG was on for this one.
>
> I've noticed it's always kswapd0 that dies?
>
> Mike

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

[Mike Dresser]

On Tue, 9 Jun 2009, Mathias Kretschmer wrote:

> same observation here. it's kswapd that dies.
>
> swap space itself is hardly ever really used, since my box has 8GB and not
> that much stuff is running on it.

Same here, 5GB ram.. I might try turning swap off and seeing what happens.

> my XFS mount opts: noatime,nodiratime,logbufs=8

noatime,nodiratime,logbufs=8,logbsize=256k,inode64,nobarrier

> drive/fs config:  sata => raid6 => lvm => xfs => nfs

sata => 3ware in raid5 => xfs

> machine is stable for the last 36 hours with nfs turned off.

Not using NFS here.

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

[Mike Dresser]

On Tue, 9 Jun 2009, Mathias Kretschmer wrote:

> same observation here. it's kswapd that dies.
>
> swap space itself is hardly ever really used, since my box has 8GB and not
> that much stuff is running on it.

Same here, 5GB ram.. I might try turning swap off and seeing what happens.

> my XFS mount opts: noatime,nodiratime,logbufs=8

noatime,nodiratime,logbufs=8,logbsize=256k,inode64,nobarrier

> drive/fs config:  sata => raid6 => lvm => xfs => nfs

sata => 3ware in raid5 => xfs

> machine is stable for the last 36 hours with nfs turned off.

Not using NFS here.

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

[Mike Dresser]

On Tue, 9 Jun 2009, Mathias Kretschmer wrote:

> machine is stable for the last 36 hours with nfs turned off.

Is the system load different with nfs off? (no clients accessing it, etc?)

Mike

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

[Mike Dresser]

On Tue, 9 Jun 2009, Mathias Kretschmer wrote:

> machine is stable for the last 36 hours with nfs turned off.

Is the system load different with nfs off? (no clients accessing it, etc?)

Mike

Re: [Bug #13463] Poor SSD performance

[Wu Fengguang]

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
> Subject		: Poor SSD performance
> Submitter	: Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>
> Date		: 2009-06-05 17:37 (3 days old)

Hi Jake,

Could you collect some blktrace data for the dd commands on new/old
kernels?

dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct
dd if=/dev/sda of=/dev/null bs=1M count=1024


You need to install the blktrace tool and run these commands:

        cd /dev/shm
        blktrace /dev/sda # do this while dd is running
        # ^C to interrupt
        blkparse sda


Package: blktrace
Description: utilities for block layer IO tracing
 blktrace is a block layer IO tracing mechanism which provides detailed
 information about request queue operations up to user space. There are

Thanks,
Fengguang

Re: [Bug #13463] Poor SSD performance

[Wu Fengguang]

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
> Subject		: Poor SSD performance
> Submitter	: Jake <ellowitz@uchicago.edu>
> Date		: 2009-06-05 17:37 (3 days old)

Hi Jake,

Could you collect some blktrace data for the dd commands on new/old
kernels?

dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct
dd if=/dev/sda of=/dev/null bs=1M count=1024


You need to install the blktrace tool and run these commands:

        cd /dev/shm
        blktrace /dev/sda # do this while dd is running
        # ^C to interrupt
        blkparse sda


Package: blktrace
Description: utilities for block layer IO tracing
 blktrace is a block layer IO tracing mechanism which provides detailed
 information about request queue operations up to user space. There are

Thanks,
Fengguang

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

[Mike Dresser]

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

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

[Mike Dresser]

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

Re: [Bug #13463] Poor SSD performance

[Jake Ellowitz]

Dear Fengguang,

Thanks so much for the attention you paid to this problem. I did not 
want to respond until I got a chance to give the new kernel a shot to 
see if the bug was still present. It appears not to be -- hdparm and dd 
both register read speeds between 200 and 220 MB/s as opposed to the 70 
to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange 
bug has sort of resolved itself.

Best,
Jake

 

Wu Fengguang wrote:
> On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote:
>   
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
>>> Subject		: Poor SSD performance
>>> Submitter	: Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>
>>> Date		: 2009-06-05 17:37 (3 days old)
>>>       
>> Hi Jake,
>>
>> Could you collect some blktrace data for the dd commands on new/old
>> kernels?
>>
>> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct
>> dd if=/dev/sda of=/dev/null bs=1M count=1024
>>     
>
> I managed to get a SanDisk SSD for testing, and observes that
>
> - one must increase read_ahead_kb to at least max_sectors_kb or better
>   "bs=1M" to make a fair comparison
> - with increased readahead size, the dd reported throughputs are
>   75MB/s vs 77MB/s, while the blktrace reported throughputs are
>   75MB/s vs 75MB/s (buffered IO vs direct IO).
>
> Here are details.
>
> The dd throughputs are equal for rotational hard disks, but differs
> for this SanDisk SSD (with default RA parameters):
>
>         % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024
>         1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s
>         1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s
>
>         % dd if=/dev/sda of=/dev/null bs=1M count=1024             
>         1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s
>         1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s
>
> Here is the blktrace summary:
>
>    dd                                           dd-direct
> --------------------------------------------------------------------------------------
>   CPU0 (sda):                               |  CPU0 (sda):
>    Reads Queued:       9,888,   39,552KiB   |   Reads Queued:          84,   43,008KiB   
>    Read Dispatches:      302,   38,588KiB   |   Read Dispatches:       84,   43,008KiB   
>    Reads Requeued:         0                |   Reads Requeued:         0                
>    Reads Completed:      337,   44,600KiB   |   Reads Completed:       83,   42,496KiB   
>    Read Merges:        9,574,   38,296KiB   |   Read Merges:            0,        0KiB   
>    Read depth:             2                |   Read depth:             2                
>    IO unplugs:           313                |   IO unplugs:            42                
>   CPU1 (sda):                               |  CPU1 (sda):
>    Reads Queued:      11,840,   47,360KiB   |   Reads Queued:          96,   49,152KiB   
>    Read Dispatches:      372,   48,196KiB   |   Read Dispatches:       96,   49,152KiB   
>    Reads Requeued:         0                |   Reads Requeued:         0                
>    Reads Completed:      337,   42,312KiB   |   Reads Completed:       96,   49,152KiB   
>    Read Merges:       11,479,   45,916KiB   |   Read Merges:            0,        0KiB   
>    Read depth:             2                |   Read depth:             2                
>    IO unplugs:           372                |   IO unplugs:            48                
>                                             |  
>   Total (sda):                              |  Total (sda):
>    Reads Queued:      21,728,   86,912KiB   |   Reads Queued:         180,   92,160KiB   
>    Read Dispatches:      674,   86,784KiB   |   Read Dispatches:      180,   92,160KiB   
>    Reads Requeued:         0                |   Reads Requeued:         0                
>    Reads Completed:      674,   86,912KiB   |   Reads Completed:      179,   91,648KiB   
>    Read Merges:       21,053,   84,212KiB   |   Read Merges:            0,        0KiB   
>    IO unplugs:           685                |   IO unplugs:            90                
>                                             |  
>   Throughput (R/W): 69,977KiB/s / 0KiB/s    |  Throughput (R/W): 75,368KiB/s / 0KiB/s    
>   Events (sda): 46,804 entries              |  Events (sda): 1,158 entries               
>
>
> Another obvious difference is IO size.
> One is read_ahead_kb=128K, another is max_sectors_kb=512K:
>
> dd:
>   8,0    0    13497     0.804939305     0  C   R 782592 + 256 [0]
>   8,0    0    13498     0.806713692     0  C   R 782848 + 256 [0]
>   8,0    1    16275     0.808488708     0  C   R 783104 + 256 [0]
>   8,0    0    13567     0.810261350     0  C   R 783360 + 256 [0]
>   8,0    0    13636     0.812036226     0  C   R 783616 + 256 [0]
>   8,0    1    16344     0.813806353     0  C   R 783872 + 256 [0]
>   8,0    1    16413     0.815578436     0  C   R 784128 + 256 [0]
>   8,0    0    13705     0.817347935     0  C   R 784384 + 256 [0]
>
> dd-direct:
>   8,0    0      428     0.998831975     0  C   R 357376 + 1024 [0]
>   8,0    1      514     1.005683404     0  C   R 358400 + 1024 [0]
>   8,0    1      515     1.012402554     0  C   R 359424 + 1024 [0]
>   8,0    0      440     1.019303850     0  C   R 360448 + 1024 [0]
>   8,0    1      526     1.026024048     0  C   R 361472 + 1024 [0]
>   8,0    1      538     1.032875967     0  C   R 362496 + 1024 [0]
>   8,0    0      441     1.039595815     0  C   R 363520 + 1024 [0]
>
> The non-direct dd throughput can improve with 512K and 1M readahead size,
> but still a bit slower than the direct dd case:
>         1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s
>         1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s
>
>    dd-512k                                     dd-direct2
> -------------------------------------------------------------------------------------
>   Total (sda):                             |  Total (sda):
>    Reads Queued:      23,808,   95,232KiB  |   Reads Queued:         178,   91,136KiB  
>    Read Dispatches:      215,   95,232KiB  |   Read Dispatches:      178,   91,136KiB  
>    Reads Requeued:         0               |   Reads Requeued:         0               
>    Reads Completed:      215,   95,232KiB  |   Reads Completed:      177,   90,624KiB  
>    Read Merges:       23,593,   94,372KiB  |   Read Merges:            0,        0KiB  
>    IO unplugs:           236               |   IO unplugs:            89               
>                                            |  
>   Throughput (R/W): 75,222KiB/s / 0KiB/s   |  Throughput (R/W): 75,520KiB/s / 0KiB/s   
>   Events (sda): 48,687 entries             |  Events (sda): 1,145 entries              
>
> Interestingly, the throughput reported by blktrace is almost the same,
> whereas the dd report favors the dd-direct case.
>
> More parameters.
>
> [   10.137350] scsi 3:0:0:0: Direct-Access     ATA      SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5
> [   10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB)
> [   10.155060] sd 3:0:0:0: [sda] Write Protect is off
> [   10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [   10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [   10.174994]  sda:
>
>
> /dev/sda:
>
>  Model=SanDisk SSD SATA 5000 2.5               , FwRev=1.13    , SerialNo=         81402200246
>  Config={ Fixed }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
>  BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1?
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000
>  IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes:  pio0 pio1 pio2 pio3 pio4 
>  DMA modes:  mdma0 mdma1 mdma2 
>  UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
>  AdvancedPM=yes: disabled (255) WriteCache=disabled
>  Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
>
>  * signifies the current active mode
>
>
> /sys/block/sda/queue/nr_requests:128
> /sys/block/sda/queue/read_ahead_kb:128
> /sys/block/sda/queue/max_hw_sectors_kb:32767
> /sys/block/sda/queue/max_sectors_kb:512
> /sys/block/sda/queue/scheduler:noop [cfq] 
> /sys/block/sda/queue/hw_sector_size:512
> /sys/block/sda/queue/rotational:1
> /sys/block/sda/queue/nomerges:0
> /sys/block/sda/queue/rq_affinity:0
> /sys/block/sda/queue/iostats:1
> /sys/block/sda/queue/iosched/quantum:4
> /sys/block/sda/queue/iosched/fifo_expire_sync:124
> /sys/block/sda/queue/iosched/fifo_expire_async:248
> /sys/block/sda/queue/iosched/back_seek_max:16384
> /sys/block/sda/queue/iosched/back_seek_penalty:2
> /sys/block/sda/queue/iosched/slice_sync:100
> /sys/block/sda/queue/iosched/slice_async:40
> /sys/block/sda/queue/iosched/slice_async_rq:2
> /sys/block/sda/queue/iosched/slice_idle:8
>
> Thanks,
> Fengguang
>   

Re: [Bug #13463] Poor SSD performance

[Jake Ellowitz]

Dear Fengguang,

Thanks so much for the attention you paid to this problem. I did not 
want to respond until I got a chance to give the new kernel a shot to 
see if the bug was still present. It appears not to be -- hdparm and dd 
both register read speeds between 200 and 220 MB/s as opposed to the 70 
to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange 
bug has sort of resolved itself.

Best,
Jake

 

Wu Fengguang wrote:
> On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote:
>   
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
>>> Subject		: Poor SSD performance
>>> Submitter	: Jake <ellowitz@uchicago.edu>
>>> Date		: 2009-06-05 17:37 (3 days old)
>>>       
>> Hi Jake,
>>
>> Could you collect some blktrace data for the dd commands on new/old
>> kernels?
>>
>> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct
>> dd if=/dev/sda of=/dev/null bs=1M count=1024
>>     
>
> I managed to get a SanDisk SSD for testing, and observes that
>
> - one must increase read_ahead_kb to at least max_sectors_kb or better
>   "bs=1M" to make a fair comparison
> - with increased readahead size, the dd reported throughputs are
>   75MB/s vs 77MB/s, while the blktrace reported throughputs are
>   75MB/s vs 75MB/s (buffered IO vs direct IO).
>
> Here are details.
>
> The dd throughputs are equal for rotational hard disks, but differs
> for this SanDisk SSD (with default RA parameters):
>
>         % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024
>         1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s
>         1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s
>
>         % dd if=/dev/sda of=/dev/null bs=1M count=1024             
>         1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s
>         1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s
>
> Here is the blktrace summary:
>
>    dd                                           dd-direct
> --------------------------------------------------------------------------------------
>   CPU0 (sda):                               |  CPU0 (sda):
>    Reads Queued:       9,888,   39,552KiB   |   Reads Queued:          84,   43,008KiB   
>    Read Dispatches:      302,   38,588KiB   |   Read Dispatches:       84,   43,008KiB   
>    Reads Requeued:         0                |   Reads Requeued:         0                
>    Reads Completed:      337,   44,600KiB   |   Reads Completed:       83,   42,496KiB   
>    Read Merges:        9,574,   38,296KiB   |   Read Merges:            0,        0KiB   
>    Read depth:             2                |   Read depth:             2                
>    IO unplugs:           313                |   IO unplugs:            42                
>   CPU1 (sda):                               |  CPU1 (sda):
>    Reads Queued:      11,840,   47,360KiB   |   Reads Queued:          96,   49,152KiB   
>    Read Dispatches:      372,   48,196KiB   |   Read Dispatches:       96,   49,152KiB   
>    Reads Requeued:         0                |   Reads Requeued:         0                
>    Reads Completed:      337,   42,312KiB   |   Reads Completed:       96,   49,152KiB   
>    Read Merges:       11,479,   45,916KiB   |   Read Merges:            0,        0KiB   
>    Read depth:             2                |   Read depth:             2                
>    IO unplugs:           372                |   IO unplugs:            48                
>                                             |  
>   Total (sda):                              |  Total (sda):
>    Reads Queued:      21,728,   86,912KiB   |   Reads Queued:         180,   92,160KiB   
>    Read Dispatches:      674,   86,784KiB   |   Read Dispatches:      180,   92,160KiB   
>    Reads Requeued:         0                |   Reads Requeued:         0                
>    Reads Completed:      674,   86,912KiB   |   Reads Completed:      179,   91,648KiB   
>    Read Merges:       21,053,   84,212KiB   |   Read Merges:            0,        0KiB   
>    IO unplugs:           685                |   IO unplugs:            90                
>                                             |  
>   Throughput (R/W): 69,977KiB/s / 0KiB/s    |  Throughput (R/W): 75,368KiB/s / 0KiB/s    
>   Events (sda): 46,804 entries              |  Events (sda): 1,158 entries               
>
>
> Another obvious difference is IO size.
> One is read_ahead_kb=128K, another is max_sectors_kb=512K:
>
> dd:
>   8,0    0    13497     0.804939305     0  C   R 782592 + 256 [0]
>   8,0    0    13498     0.806713692     0  C   R 782848 + 256 [0]
>   8,0    1    16275     0.808488708     0  C   R 783104 + 256 [0]
>   8,0    0    13567     0.810261350     0  C   R 783360 + 256 [0]
>   8,0    0    13636     0.812036226     0  C   R 783616 + 256 [0]
>   8,0    1    16344     0.813806353     0  C   R 783872 + 256 [0]
>   8,0    1    16413     0.815578436     0  C   R 784128 + 256 [0]
>   8,0    0    13705     0.817347935     0  C   R 784384 + 256 [0]
>
> dd-direct:
>   8,0    0      428     0.998831975     0  C   R 357376 + 1024 [0]
>   8,0    1      514     1.005683404     0  C   R 358400 + 1024 [0]
>   8,0    1      515     1.012402554     0  C   R 359424 + 1024 [0]
>   8,0    0      440     1.019303850     0  C   R 360448 + 1024 [0]
>   8,0    1      526     1.026024048     0  C   R 361472 + 1024 [0]
>   8,0    1      538     1.032875967     0  C   R 362496 + 1024 [0]
>   8,0    0      441     1.039595815     0  C   R 363520 + 1024 [0]
>
> The non-direct dd throughput can improve with 512K and 1M readahead size,
> but still a bit slower than the direct dd case:
>         1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s
>         1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s
>
>    dd-512k                                     dd-direct2
> -------------------------------------------------------------------------------------
>   Total (sda):                             |  Total (sda):
>    Reads Queued:      23,808,   95,232KiB  |   Reads Queued:         178,   91,136KiB  
>    Read Dispatches:      215,   95,232KiB  |   Read Dispatches:      178,   91,136KiB  
>    Reads Requeued:         0               |   Reads Requeued:         0               
>    Reads Completed:      215,   95,232KiB  |   Reads Completed:      177,   90,624KiB  
>    Read Merges:       23,593,   94,372KiB  |   Read Merges:            0,        0KiB  
>    IO unplugs:           236               |   IO unplugs:            89               
>                                            |  
>   Throughput (R/W): 75,222KiB/s / 0KiB/s   |  Throughput (R/W): 75,520KiB/s / 0KiB/s   
>   Events (sda): 48,687 entries             |  Events (sda): 1,145 entries              
>
> Interestingly, the throughput reported by blktrace is almost the same,
> whereas the dd report favors the dd-direct case.
>
> More parameters.
>
> [   10.137350] scsi 3:0:0:0: Direct-Access     ATA      SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5
> [   10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB)
> [   10.155060] sd 3:0:0:0: [sda] Write Protect is off
> [   10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [   10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [   10.174994]  sda:
>
>
> /dev/sda:
>
>  Model=SanDisk SSD SATA 5000 2.5               , FwRev=1.13    , SerialNo=         81402200246
>  Config={ Fixed }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
>  BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1?
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000
>  IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes:  pio0 pio1 pio2 pio3 pio4 
>  DMA modes:  mdma0 mdma1 mdma2 
>  UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
>  AdvancedPM=yes: disabled (255) WriteCache=disabled
>  Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
>
>  * signifies the current active mode
>
>
> /sys/block/sda/queue/nr_requests:128
> /sys/block/sda/queue/read_ahead_kb:128
> /sys/block/sda/queue/max_hw_sectors_kb:32767
> /sys/block/sda/queue/max_sectors_kb:512
> /sys/block/sda/queue/scheduler:noop [cfq] 
> /sys/block/sda/queue/hw_sector_size:512
> /sys/block/sda/queue/rotational:1
> /sys/block/sda/queue/nomerges:0
> /sys/block/sda/queue/rq_affinity:0
> /sys/block/sda/queue/iostats:1
> /sys/block/sda/queue/iosched/quantum:4
> /sys/block/sda/queue/iosched/fifo_expire_sync:124
> /sys/block/sda/queue/iosched/fifo_expire_async:248
> /sys/block/sda/queue/iosched/back_seek_max:16384
> /sys/block/sda/queue/iosched/back_seek_penalty:2
> /sys/block/sda/queue/iosched/slice_sync:100
> /sys/block/sda/queue/iosched/slice_async:40
> /sys/block/sda/queue/iosched/slice_async_rq:2
> /sys/block/sda/queue/iosched/slice_idle:8
>
> Thanks,
> Fengguang
>   

Re: [Bug #13463] Poor SSD performance

[Wu Fengguang]

Hi Jake,

On Tue, Jun 16, 2009 at 12:09:17PM +0800, Jake Ellowitz wrote:
> Dear Fengguang,
> 
> Thanks so much for the attention you paid to this problem. I did not 
> want to respond until I got a chance to give the new kernel a shot to 
> see if the bug was still present. It appears not to be -- hdparm and dd 
> both register read speeds between 200 and 220 MB/s as opposed to the 70 
> to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange 
> bug has sort of resolved itself.

That's great!  (if convenient I'd recommend you to try the blktrace
tool on 2.6.29, it's easy to use :)

Thanks,
Fengguang

> Wu Fengguang wrote:
> > On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote:
> >   
> >>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
> >>> Subject		: Poor SSD performance
> >>> Submitter	: Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>
> >>> Date		: 2009-06-05 17:37 (3 days old)
> >>>       
> >> Hi Jake,
> >>
> >> Could you collect some blktrace data for the dd commands on new/old
> >> kernels?
> >>
> >> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct
> >> dd if=/dev/sda of=/dev/null bs=1M count=1024
> >>     
> >
> > I managed to get a SanDisk SSD for testing, and observes that
> >
> > - one must increase read_ahead_kb to at least max_sectors_kb or better
> >   "bs=1M" to make a fair comparison
> > - with increased readahead size, the dd reported throughputs are
> >   75MB/s vs 77MB/s, while the blktrace reported throughputs are
> >   75MB/s vs 75MB/s (buffered IO vs direct IO).
> >
> > Here are details.
> >
> > The dd throughputs are equal for rotational hard disks, but differs
> > for this SanDisk SSD (with default RA parameters):
> >
> >         % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024
> >         1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s
> >         1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s
> >
> >         % dd if=/dev/sda of=/dev/null bs=1M count=1024             
> >         1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s
> >         1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s
> >
> > Here is the blktrace summary:
> >
> >    dd                                           dd-direct
> > --------------------------------------------------------------------------------------
> >   CPU0 (sda):                               |  CPU0 (sda):
> >    Reads Queued:       9,888,   39,552KiB   |   Reads Queued:          84,   43,008KiB   
> >    Read Dispatches:      302,   38,588KiB   |   Read Dispatches:       84,   43,008KiB   
> >    Reads Requeued:         0                |   Reads Requeued:         0                
> >    Reads Completed:      337,   44,600KiB   |   Reads Completed:       83,   42,496KiB   
> >    Read Merges:        9,574,   38,296KiB   |   Read Merges:            0,        0KiB   
> >    Read depth:             2                |   Read depth:             2                
> >    IO unplugs:           313                |   IO unplugs:            42                
> >   CPU1 (sda):                               |  CPU1 (sda):
> >    Reads Queued:      11,840,   47,360KiB   |   Reads Queued:          96,   49,152KiB   
> >    Read Dispatches:      372,   48,196KiB   |   Read Dispatches:       96,   49,152KiB   
> >    Reads Requeued:         0                |   Reads Requeued:         0                
> >    Reads Completed:      337,   42,312KiB   |   Reads Completed:       96,   49,152KiB   
> >    Read Merges:       11,479,   45,916KiB   |   Read Merges:            0,        0KiB   
> >    Read depth:             2                |   Read depth:             2                
> >    IO unplugs:           372                |   IO unplugs:            48                
> >                                             |  
> >   Total (sda):                              |  Total (sda):
> >    Reads Queued:      21,728,   86,912KiB   |   Reads Queued:         180,   92,160KiB   
> >    Read Dispatches:      674,   86,784KiB   |   Read Dispatches:      180,   92,160KiB   
> >    Reads Requeued:         0                |   Reads Requeued:         0                
> >    Reads Completed:      674,   86,912KiB   |   Reads Completed:      179,   91,648KiB   
> >    Read Merges:       21,053,   84,212KiB   |   Read Merges:            0,        0KiB   
> >    IO unplugs:           685                |   IO unplugs:            90                
> >                                             |  
> >   Throughput (R/W): 69,977KiB/s / 0KiB/s    |  Throughput (R/W): 75,368KiB/s / 0KiB/s    
> >   Events (sda): 46,804 entries              |  Events (sda): 1,158 entries               
> >
> >
> > Another obvious difference is IO size.
> > One is read_ahead_kb=128K, another is max_sectors_kb=512K:
> >
> > dd:
> >   8,0    0    13497     0.804939305     0  C   R 782592 + 256 [0]
> >   8,0    0    13498     0.806713692     0  C   R 782848 + 256 [0]
> >   8,0    1    16275     0.808488708     0  C   R 783104 + 256 [0]
> >   8,0    0    13567     0.810261350     0  C   R 783360 + 256 [0]
> >   8,0    0    13636     0.812036226     0  C   R 783616 + 256 [0]
> >   8,0    1    16344     0.813806353     0  C   R 783872 + 256 [0]
> >   8,0    1    16413     0.815578436     0  C   R 784128 + 256 [0]
> >   8,0    0    13705     0.817347935     0  C   R 784384 + 256 [0]
> >
> > dd-direct:
> >   8,0    0      428     0.998831975     0  C   R 357376 + 1024 [0]
> >   8,0    1      514     1.005683404     0  C   R 358400 + 1024 [0]
> >   8,0    1      515     1.012402554     0  C   R 359424 + 1024 [0]
> >   8,0    0      440     1.019303850     0  C   R 360448 + 1024 [0]
> >   8,0    1      526     1.026024048     0  C   R 361472 + 1024 [0]
> >   8,0    1      538     1.032875967     0  C   R 362496 + 1024 [0]
> >   8,0    0      441     1.039595815     0  C   R 363520 + 1024 [0]
> >
> > The non-direct dd throughput can improve with 512K and 1M readahead size,
> > but still a bit slower than the direct dd case:
> >         1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s
> >         1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s
> >
> >    dd-512k                                     dd-direct2
> > -------------------------------------------------------------------------------------
> >   Total (sda):                             |  Total (sda):
> >    Reads Queued:      23,808,   95,232KiB  |   Reads Queued:         178,   91,136KiB  
> >    Read Dispatches:      215,   95,232KiB  |   Read Dispatches:      178,   91,136KiB  
> >    Reads Requeued:         0               |   Reads Requeued:         0               
> >    Reads Completed:      215,   95,232KiB  |   Reads Completed:      177,   90,624KiB  
> >    Read Merges:       23,593,   94,372KiB  |   Read Merges:            0,        0KiB  
> >    IO unplugs:           236               |   IO unplugs:            89               
> >                                            |  
> >   Throughput (R/W): 75,222KiB/s / 0KiB/s   |  Throughput (R/W): 75,520KiB/s / 0KiB/s   
> >   Events (sda): 48,687 entries             |  Events (sda): 1,145 entries              
> >
> > Interestingly, the throughput reported by blktrace is almost the same,
> > whereas the dd report favors the dd-direct case.
> >
> > More parameters.
> >
> > [   10.137350] scsi 3:0:0:0: Direct-Access     ATA      SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5
> > [   10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB)
> > [   10.155060] sd 3:0:0:0: [sda] Write Protect is off
> > [   10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > [   10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> > [   10.174994]  sda:
> >
> >
> > /dev/sda:
> >
> >  Model=SanDisk SSD SATA 5000 2.5               , FwRev=1.13    , SerialNo=         81402200246
> >  Config={ Fixed }
> >  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
> >  BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1?
> >  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000
> >  IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> >  PIO modes:  pio0 pio1 pio2 pio3 pio4 
> >  DMA modes:  mdma0 mdma1 mdma2 
> >  UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
> >  AdvancedPM=yes: disabled (255) WriteCache=disabled
> >  Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
> >
> >  * signifies the current active mode
> >
> >
> > /sys/block/sda/queue/nr_requests:128
> > /sys/block/sda/queue/read_ahead_kb:128
> > /sys/block/sda/queue/max_hw_sectors_kb:32767
> > /sys/block/sda/queue/max_sectors_kb:512
> > /sys/block/sda/queue/scheduler:noop [cfq] 
> > /sys/block/sda/queue/hw_sector_size:512
> > /sys/block/sda/queue/rotational:1
> > /sys/block/sda/queue/nomerges:0
> > /sys/block/sda/queue/rq_affinity:0
> > /sys/block/sda/queue/iostats:1
> > /sys/block/sda/queue/iosched/quantum:4
> > /sys/block/sda/queue/iosched/fifo_expire_sync:124
> > /sys/block/sda/queue/iosched/fifo_expire_async:248
> > /sys/block/sda/queue/iosched/back_seek_max:16384
> > /sys/block/sda/queue/iosched/back_seek_penalty:2
> > /sys/block/sda/queue/iosched/slice_sync:100
> > /sys/block/sda/queue/iosched/slice_async:40
> > /sys/block/sda/queue/iosched/slice_async_rq:2
> > /sys/block/sda/queue/iosched/slice_idle:8
> >
> > Thanks,
> > Fengguang
> >   

Re: [Bug #13463] Poor SSD performance

[Wu Fengguang]

Hi Jake,

On Tue, Jun 16, 2009 at 12:09:17PM +0800, Jake Ellowitz wrote:
> Dear Fengguang,
> 
> Thanks so much for the attention you paid to this problem. I did not 
> want to respond until I got a chance to give the new kernel a shot to 
> see if the bug was still present. It appears not to be -- hdparm and dd 
> both register read speeds between 200 and 220 MB/s as opposed to the 70 
> to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange 
> bug has sort of resolved itself.

That's great!  (if convenient I'd recommend you to try the blktrace
tool on 2.6.29, it's easy to use :)

Thanks,
Fengguang

> Wu Fengguang wrote:
> > On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote:
> >   
> >>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13463
> >>> Subject		: Poor SSD performance
> >>> Submitter	: Jake <ellowitz@uchicago.edu>
> >>> Date		: 2009-06-05 17:37 (3 days old)
> >>>       
> >> Hi Jake,
> >>
> >> Could you collect some blktrace data for the dd commands on new/old
> >> kernels?
> >>
> >> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct
> >> dd if=/dev/sda of=/dev/null bs=1M count=1024
> >>     
> >
> > I managed to get a SanDisk SSD for testing, and observes that
> >
> > - one must increase read_ahead_kb to at least max_sectors_kb or better
> >   "bs=1M" to make a fair comparison
> > - with increased readahead size, the dd reported throughputs are
> >   75MB/s vs 77MB/s, while the blktrace reported throughputs are
> >   75MB/s vs 75MB/s (buffered IO vs direct IO).
> >
> > Here are details.
> >
> > The dd throughputs are equal for rotational hard disks, but differs
> > for this SanDisk SSD (with default RA parameters):
> >
> >         % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024
> >         1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s
> >         1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s
> >
> >         % dd if=/dev/sda of=/dev/null bs=1M count=1024             
> >         1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s
> >         1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s
> >
> > Here is the blktrace summary:
> >
> >    dd                                           dd-direct
> > --------------------------------------------------------------------------------------
> >   CPU0 (sda):                               |  CPU0 (sda):
> >    Reads Queued:       9,888,   39,552KiB   |   Reads Queued:          84,   43,008KiB   
> >    Read Dispatches:      302,   38,588KiB   |   Read Dispatches:       84,   43,008KiB   
> >    Reads Requeued:         0                |   Reads Requeued:         0                
> >    Reads Completed:      337,   44,600KiB   |   Reads Completed:       83,   42,496KiB   
> >    Read Merges:        9,574,   38,296KiB   |   Read Merges:            0,        0KiB   
> >    Read depth:             2                |   Read depth:             2                
> >    IO unplugs:           313                |   IO unplugs:            42                
> >   CPU1 (sda):                               |  CPU1 (sda):
> >    Reads Queued:      11,840,   47,360KiB   |   Reads Queued:          96,   49,152KiB   
> >    Read Dispatches:      372,   48,196KiB   |   Read Dispatches:       96,   49,152KiB   
> >    Reads Requeued:         0                |   Reads Requeued:         0                
> >    Reads Completed:      337,   42,312KiB   |   Reads Completed:       96,   49,152KiB   
> >    Read Merges:       11,479,   45,916KiB   |   Read Merges:            0,        0KiB   
> >    Read depth:             2                |   Read depth:             2                
> >    IO unplugs:           372                |   IO unplugs:            48                
> >                                             |  
> >   Total (sda):                              |  Total (sda):
> >    Reads Queued:      21,728,   86,912KiB   |   Reads Queued:         180,   92,160KiB   
> >    Read Dispatches:      674,   86,784KiB   |   Read Dispatches:      180,   92,160KiB   
> >    Reads Requeued:         0                |   Reads Requeued:         0                
> >    Reads Completed:      674,   86,912KiB   |   Reads Completed:      179,   91,648KiB   
> >    Read Merges:       21,053,   84,212KiB   |   Read Merges:            0,        0KiB   
> >    IO unplugs:           685                |   IO unplugs:            90                
> >                                             |  
> >   Throughput (R/W): 69,977KiB/s / 0KiB/s    |  Throughput (R/W): 75,368KiB/s / 0KiB/s    
> >   Events (sda): 46,804 entries              |  Events (sda): 1,158 entries               
> >
> >
> > Another obvious difference is IO size.
> > One is read_ahead_kb=128K, another is max_sectors_kb=512K:
> >
> > dd:
> >   8,0    0    13497     0.804939305     0  C   R 782592 + 256 [0]
> >   8,0    0    13498     0.806713692     0  C   R 782848 + 256 [0]
> >   8,0    1    16275     0.808488708     0  C   R 783104 + 256 [0]
> >   8,0    0    13567     0.810261350     0  C   R 783360 + 256 [0]
> >   8,0    0    13636     0.812036226     0  C   R 783616 + 256 [0]
> >   8,0    1    16344     0.813806353     0  C   R 783872 + 256 [0]
> >   8,0    1    16413     0.815578436     0  C   R 784128 + 256 [0]
> >   8,0    0    13705     0.817347935     0  C   R 784384 + 256 [0]
> >
> > dd-direct:
> >   8,0    0      428     0.998831975     0  C   R 357376 + 1024 [0]
> >   8,0    1      514     1.005683404     0  C   R 358400 + 1024 [0]
> >   8,0    1      515     1.012402554     0  C   R 359424 + 1024 [0]
> >   8,0    0      440     1.019303850     0  C   R 360448 + 1024 [0]
> >   8,0    1      526     1.026024048     0  C   R 361472 + 1024 [0]
> >   8,0    1      538     1.032875967     0  C   R 362496 + 1024 [0]
> >   8,0    0      441     1.039595815     0  C   R 363520 + 1024 [0]
> >
> > The non-direct dd throughput can improve with 512K and 1M readahead size,
> > but still a bit slower than the direct dd case:
> >         1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s
> >         1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s
> >
> >    dd-512k                                     dd-direct2
> > -------------------------------------------------------------------------------------
> >   Total (sda):                             |  Total (sda):
> >    Reads Queued:      23,808,   95,232KiB  |   Reads Queued:         178,   91,136KiB  
> >    Read Dispatches:      215,   95,232KiB  |   Read Dispatches:      178,   91,136KiB  
> >    Reads Requeued:         0               |   Reads Requeued:         0               
> >    Reads Completed:      215,   95,232KiB  |   Reads Completed:      177,   90,624KiB  
> >    Read Merges:       23,593,   94,372KiB  |   Read Merges:            0,        0KiB  
> >    IO unplugs:           236               |   IO unplugs:            89               
> >                                            |  
> >   Throughput (R/W): 75,222KiB/s / 0KiB/s   |  Throughput (R/W): 75,520KiB/s / 0KiB/s   
> >   Events (sda): 48,687 entries             |  Events (sda): 1,145 entries              
> >
> > Interestingly, the throughput reported by blktrace is almost the same,
> > whereas the dd report favors the dd-direct case.
> >
> > More parameters.
> >
> > [   10.137350] scsi 3:0:0:0: Direct-Access     ATA      SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5
> > [   10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB)
> > [   10.155060] sd 3:0:0:0: [sda] Write Protect is off
> > [   10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > [   10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> > [   10.174994]  sda:
> >
> >
> > /dev/sda:
> >
> >  Model=SanDisk SSD SATA 5000 2.5               , FwRev=1.13    , SerialNo=         81402200246
> >  Config={ Fixed }
> >  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
> >  BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1?
> >  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000
> >  IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> >  PIO modes:  pio0 pio1 pio2 pio3 pio4 
> >  DMA modes:  mdma0 mdma1 mdma2 
> >  UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
> >  AdvancedPM=yes: disabled (255) WriteCache=disabled
> >  Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
> >
> >  * signifies the current active mode
> >
> >
> > /sys/block/sda/queue/nr_requests:128
> > /sys/block/sda/queue/read_ahead_kb:128
> > /sys/block/sda/queue/max_hw_sectors_kb:32767
> > /sys/block/sda/queue/max_sectors_kb:512
> > /sys/block/sda/queue/scheduler:noop [cfq] 
> > /sys/block/sda/queue/hw_sector_size:512
> > /sys/block/sda/queue/rotational:1
> > /sys/block/sda/queue/nomerges:0
> > /sys/block/sda/queue/rq_affinity:0
> > /sys/block/sda/queue/iostats:1
> > /sys/block/sda/queue/iosched/quantum:4
> > /sys/block/sda/queue/iosched/fifo_expire_sync:124
> > /sys/block/sda/queue/iosched/fifo_expire_async:248
> > /sys/block/sda/queue/iosched/back_seek_max:16384
> > /sys/block/sda/queue/iosched/back_seek_penalty:2
> > /sys/block/sda/queue/iosched/slice_sync:100
> > /sys/block/sda/queue/iosched/slice_async:40
> > /sys/block/sda/queue/iosched/slice_async_rq:2
> > /sys/block/sda/queue/iosched/slice_idle:8
> >
> > Thanks,
> > Fengguang
> >   

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

[Mathias Kretschmer]

On Tuesday 09 June 2009 21:22:16 Mike Dresser wrote:
> On Tue, 9 Jun 2009, Mathias Kretschmer wrote:
> > machine is stable for the last 36 hours with nfs turned off.
>
> Is the system load different with nfs off? (no clients accessing it, etc?)

Yep.

I've upgraded to 2.6.30 two days ago. So far, so good.

I've ran three Gentoo 'emerge world' sessions in parallel while forcing a 
RAID6 resync. This should have created more I/O load than this box usually 
sees. 

Of course, some other combination of events might be required to cause this 
kernel crash.

I've also turned NFS back on today. Still, no problems to report.

Cheers,

Mathias




> Mike
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Mathias Kretschmer]

On Tuesday 09 June 2009 21:22:16 Mike Dresser wrote:
> On Tue, 9 Jun 2009, Mathias Kretschmer wrote:
> > machine is stable for the last 36 hours with nfs turned off.
>
> Is the system load different with nfs off? (no clients accessing it, etc?)

Yep.

I've upgraded to 2.6.30 two days ago. So far, so good.

I've ran three Gentoo 'emerge world' sessions in parallel while forcing a 
RAID6 resync. This should have created more I/O load than this box usually 
sees. 

Of course, some other combination of events might be required to cause this 
kernel crash.

I've also turned NFS back on today. Still, no problems to report.

Cheers,

Mathias




> Mike
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Mike Dresser]

On Thu, 18 Jun 2009, Mathias Kretschmer wrote:

> I've upgraded to 2.6.30 two days ago. So far, so good.

Mine still crashes, so I've gone back to 2.6.28.9 for now.

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

[Mike Dresser]

On Thu, 18 Jun 2009, Mathias Kretschmer wrote:

> I've upgraded to 2.6.30 two days ago. So far, so good.

Mine still crashes, so I've gone back to 2.6.28.9 for now.

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

[Mike Dresser]

Tried 2.6.30-git18 the other day, machine jammed up with the usual BUG, 
though it was on radix-tree.c:464 this time.

I really should get around to putting an APC masterswitch on this 
server, since it won't reboot with anything but the power 
switch/reset(though the system is otherwise fine, interactivity is 
perfect.. just can't kill processes)

Mike

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

[Mike Dresser]

Tried 2.6.30-git18 the other day, machine jammed up with the usual BUG, 
though it was on radix-tree.c:464 this time.

I really should get around to putting an APC masterswitch on this 
server, since it won't reboot with anything but the power 
switch/reset(though the system is otherwise fine, interactivity is 
perfect.. just can't kill processes)

Mike

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

[Mathias Kretschmer]

On Thursday 25 June 2009 00:55:40 Mike Dresser wrote:
> Tried 2.6.30-git18 the other day, machine jammed up with the usual BUG,
> though it was on radix-tree.c:464 this time.

I gave up and went back to 2.6.28.9, as you mentioned before.

> I really should get around to putting an APC masterswitch on this
> server, since it won't reboot with anything but the power
> switch/reset(though the system is otherwise fine, interactivity is
> perfect.. just can't kill processes)

Yep, I had that happening a few days ago. The box worked fine, but won't 
reboot. Just hangs somewhere during unmount. I saw a kernel crash call trace 
somewhere, but it went by too quickly and I couldn't get it back.

-Mathias

> Mike

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

[Mathias Kretschmer]

On Thursday 25 June 2009 00:55:40 Mike Dresser wrote:
> Tried 2.6.30-git18 the other day, machine jammed up with the usual BUG,
> though it was on radix-tree.c:464 this time.

I gave up and went back to 2.6.28.9, as you mentioned before.

> I really should get around to putting an APC masterswitch on this
> server, since it won't reboot with anything but the power
> switch/reset(though the system is otherwise fine, interactivity is
> perfect.. just can't kill processes)

Yep, I had that happening a few days ago. The box worked fine, but won't 
reboot. Just hangs somewhere during unmount. I saw a kernel crash call trace 
somewhere, but it went by too quickly and I couldn't get it back.

-Mathias

> Mike

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

[Sitsofe Wheeler]

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

Still here on 2.6.31-rc1 but...

...this seems to be tied to the version of the Intel X drivers I have.
On another install with more recent Intel X drivers I cannot reproduce
this issue.

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

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

[Sitsofe Wheeler]

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

Still here on 2.6.31-rc1 but...

...this seems to be tied to the version of the Intel X drivers I have.
On another install with more recent Intel X drivers I cannot reproduce
this issue.

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

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

[Jesse Barnes]

On Sun, 28 Jun 2009 21:11:30 +0100
Sitsofe Wheeler <sitsofe@yahoo.com> wrote:

> On Sun, Jun 07, 2009 at 12:06:18PM +0200, Rafael J. Wysocki wrote:
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12765
> > Subject		: i915 VT switch with AIGLX causes X lock up
> > Submitter	: Sitsofe Wheeler <sitsofe@yahoo.com>
> > Date		: 2009-02-21 15:38 (107 days old)
> > First-Bad-Commit:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> > References	:
> > http://marc.info/?l=linux-kernel&m=123523074304955&w=4
> > http://lkml.org/lkml/2009/4/27/317 Handled-By	: Jesse Barnes
> > <jbarnes@virtuousgeek.org> Patch		:
> > http://patchwork.kernel.org/patch/20197/
> 
> Still here on 2.6.31-rc1 but...
> 
> ...this seems to be tied to the version of the Intel X drivers I have.
> On another install with more recent Intel X drivers I cannot reproduce
> this issue.

I guess we can mark it closed then, though I don't have the commit id
of the fix handy...

-- 
Jesse Barnes, Intel Open Source Technology Center