3.2-rc6+: Reported regressions from 3.0 and 3.1

[Evidently, vger has blocked the previous attempts to post this message for some reason. I wonder why?]

This message contains a list of some regressions from 3.0 and 3.1 for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 3.0 and 3.1, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid.

The entries below are simplified and the statistics are not present due to the continuing Bugzilla outage.

Subject : iwlagn is getting very shaky
Submitter : Norbert Preining <[email protected]>
Date : 2011-10-19 6:01
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2

Subject : Regression: "irqpoll" hasn't been working for me since March 16 IRQ
Submitter : Edward Donovan <[email protected]>
Date : 2011-10-19 22:09
Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw@mail.gmail.com References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2

Subject : 3.1+ iwlwifi lockup
Submitter : Dave Jones <[email protected]>
Date : 2011-10-31 14:34
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2

Subject : Linus GIT - INFO: possible circular locking dependency detected
Submitter : Miles Lane <[email protected]>
Date : 2011-11-03 15:57
Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2

Subject : DMA-API check_sync errors with 3.2
Submitter : Josh Boyer <[email protected]>
Date : 2011-11-08 17:31
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2

Subject : 3.2-rc1 doesn't boot on dual socket opteron without swap
Submitter : Niklas Schnelle <[email protected]>
Date : 2011-11-10 20:09
Message-ID : 1320955769.1718.8.camel@jupiter
References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2

Subject : Sparc-32 doesn't work in 3.1.
Submitter : Rob Landley <[email protected]>
Date : 2011-11-12 11:22
Message-ID : [email protected]
References : http://www.spinics.net/lists/kernel/msg1260383.html

Subject : WARNING: at fs/sysfs/sysfs.h:195 (during boot)
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2011-11-13 19:24
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2

Subject : max PWM is zero
Submitter : Marcos Paulo de Souza <[email protected]>
Date : 2011-11-15 15:14
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132137019330548&w=2

Subject : Oops on suspend with libertas SDIO (Linux 3.2-rc2)
Submitter : Sven Neumann <[email protected]>
Date : 2011-11-17 15:36
Message-ID : 1321544210.31090.6.camel@sven
References : http://marc.info/?l=linux-kernel&m=132154527715807&w=2

Subject : Impossible high cpu-time values for migration threads
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2011-11-17 22:17
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132156832124314&w=2

Subject : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2011-11-18 7:25
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2

Subject : [REGRESSION] resume takes 10s longer due to e1b6eb3 (Bluetooth: Increase HCI reset timeout ...)
Submitter : Tomáš Janoušek <[email protected]>
Date : 2011-11-18 18:40
Message-ID : [email protected]
References : http://marc.info/?l=linux-kernel&m=132164169511416&w=2

Subject : [REGRESSION] sudden cpu hogging in kernel 3.2 rc-series
Submitter : "Nicolas Kalkhof" <[email protected]>
Date : 2011-11-18 20:33
Message-ID : 506786689.810044.1321648395265.JavaMail.fmail@mwmweb010 References : http://marc.info/?l=linux-kernel&m=132164909313594&w=2

Subject : Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0
Submitter : Meelis Roos <[email protected]>
Date : 2011-11-22 10:15
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132195700023709&w=2

Subject : 3.2-rc2 regression: floppy driver breaks boot
Submitter : Pavel Machek <[email protected]>
Date : 2011-11-22 11:14
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132196052124801&w=2

Subject : [regression 3.1.0 -> 3.20rc] USB Oops
Submitter : Norbert Preining <[email protected]>
Date : 2011-11-22 12:52
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132196644726900&w=2

Subject : Freezing of tasks failed after 20.01 seconds in kernel 3.2.0-rc2
Submitter : Belisko Marek <[email protected]>
Date : 2011-11-22 21:20
Message-ID :
CAAfyv36nxYq1EA2pcHi5WR1BdWYHp2sQTY1mMA4Q3JjcOG5RDw@mail.gmail.com References : http://marc.info/?l=linux-kernel&m=132199691706100&w=2

Subject : 3.2.0-rc2+git: possible recursive locking detected in process
memory freeing
Submitter : Meelis Roos <[email protected]>
Date : 2011-11-23 13:12
Message-ID : [email protected] References : http://lkml.org/lkml/2011/11/23/159

Subject : i915: 3.2 rc1/2 KMS regression
Submitter : Patrik Kullman <[email protected]>
Date : 2011-11-23 23:43
Message-ID : CAGPN=9THOv- [email protected] References : http://marc.info/?l=linux-kernel&m=132209186403288&w=2

Subject : 3.2-rc2: regression after hibernate: lots of warnings, broken
system
Submitter : Pavel Machek <[email protected]>
Date : 2011-11-24 15:40
Message-ID : [email protected]
References : http://marc.info/?l=linux-kernel&m=132214929818015&w=2

Subject : [regression] WARNING: at drivers/block/floppy.c:2929
do_fd_request+0xb7/0xb9() in 3.2.0-rc2 and 3
Submitter : Ralf Hildebrandt <[email protected]>
Date : 2011-11-25 10:34
Message-ID : [email protected]
References : http://marc.info/?l=linux-kernel&m=132221799501685&w=2

Subject : [BUG] 3.2-rcX radeon KMS system freeze
Submitter : Bob Tracy <[email protected]>
Date : 2011-11-25 20:33
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132225331312019&w=2

Subject : 3.2-rc2 regression due to commit "USB: EHCI: fix HUB TT scheduling
issue with iso transfer" 811c926c538f7e8d3c08b630dd5844efd7e000f6 Submitter : Sander Eikelenboom <[email protected]>
Date : 2011-11-26 15:47
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132232295425393&w=2

Subject : 3.2-rc3+: [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer
elapsed... GPU hung
Submitter : Sergei Trofimovich <[email protected]>
Date : 2011-12-02 17:56
Message-ID : [email protected]
References : http://marc.info/?l=linux-kernel&m=132284845705156&w=2

Subject : [BUG] deadlock: jfs (3.2.0-rc4-00154-g8e8da02)
Submitter : Nico Schottelius <[email protected]>
Date : 2011-12-06 10:05
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132317917827825&w=2

Subject : [3.2-rc4] pcnet32: DMA-API: device driver tries to sync DMA
memory it has not allocated
Submitter : Tetsuo Handa <[email protected]>
Date : 2011-12-09 3:40
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132340215706219&w=2

Subject : Enabling FCoE point-to-point mode triggers a deadlock
Submitter : Bart Van Assche <[email protected]>
Date : 2011-12-09 14:33
References : http://permalink.gmane.org/gmane.linux.scsi.open-fcoe.devel/11451

Subject : iwlagn unusable in 3.2.0rc4
Submitter : Dave Jones <[email protected]>
Date : 2011-12-09 19:42
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132345984724433&w=2

Subject : DRM nouveau crash with 3.2.0-rc5
Submitter : "Berck E. Nash" <[email protected]>
Date : 2011-12-10 5:10
Message-ID : [email protected]
References : http://marc.info/?l=linux-kernel&m=132349393700419&w=2

Subject : Reiserfs.c bug in 3.2-rc5
Submitter : "Jorge Bastos" <[email protected]>
Date : 2011-12-10 23:48
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132356156914296&w=2

Subject : [REGRESSION] 3.2.0-rc3 Bluetooth L2CAP Linux to Linux rfcomm
fails
Submitter : David Fries <[email protected]>
Date : 2011-12-11 5:16
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132358071417198&w=2

Subject : recent regression: after resume the mouse and X is extremely slow
Submitter : Norbert Preining <[email protected]>
Date : 2011-12-11 22:13
Message-ID : [email protected] References : http://marc.info/?l=linux-kernel&m=132364169929740&w=2

Thanks!

Edward fixed this in commit 52553ddffad76ccf192d4dd9ce88d5818f57f62a.

I *think* this is fixed by the revert in commit 5e442a493fc5.

I'm pretty sure this is fixed by commit b1f44e13a525.

This is a combination one, I think. There's some kexec trouble with DRI and Radeons, and there on PPC the SLUB case was done incorrectly.

The PPC case was fixed, the DRI/Radeon/kexec thing is pending for next release, I'm afraid.

This is i915 vs VT-d. It may be fixed in current -git, but basically people should try to avoid using VT-d with i915, there seem to be hardware bugs wrt the graphics semaphores and power management code.

Hmm. I'd love to get more info. Turning off floppy support may work around it, but I don't think we've actually seen the oops.

Fixed by commit ed4a51842a9d which reverted the problematic commit.

This should be fixed by commit 4eabc941259f.

I wonder if that's related to the floppy issue above? Nothing really changed in the floppy driver itself, so it should be something about the block layer..

Fixed by commit e3420901eba6.

I think this is the same i915 issue above, fixed by the same commit ed4a51842a9d.

That's an odd bug-report. I think Nico should try to cut-and-paste more of the relevant problem..

It's all there in the attached xz-file, but I doubt anybody followed up on it because it's so hidden..

Unpacked, and added Dave and jfs-discussion to the cc:

    [ 6281.127353] =================================
    [ 6281.127355] [ INFO: inconsistent lock state ]
    [ 6281.127358] 3.2.0-rc4-00154-g8e8da02 #91
    [ 6281.127360] ---------------------------------
    [ 6281.127363] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
    [ 6281.127366] kswapd0/30 [HC0[0]:SC0[0]:HE1:SE1] takes:
    [ 6281.127368]  (&jfs_ip->rdwrlock#2){++++?+}, at:
[<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
    [ 6281.127381] {RECLAIM_FS-ON-W} state was registered at:
    [ 6281.127383]   [<ffffffff810a2c71>] mark_held_locks+0x61/0x140
    [ 6281.127392]   [<ffffffff810a3401>] lockdep_trace_alloc+0x71/0xd0
    [ 6281.127399]   [<ffffffff8115daed>] kmem_cache_alloc+0x2d/0x170
    [ 6281.127406]   [<ffffffff8124d7d6>] radix_tree_preload+0x66/0xf0
    [ 6281.127414]   [<ffffffff81110e93>] add_to_page_cache_locked+0x73/0x170
    [ 6281.127422]   [<ffffffff81110fb1>] add_to_page_cache_lru+0x21/0x50
    [ 6281.127428]   [<ffffffff8111112a>] do_read_cache_page+0x6a/0x170
    [ 6281.127434]   [<ffffffff8111127c>] read_cache_page_async+0x1c/0x20
    [ 6281.127441]   [<ffffffff8111128e>] read_cache_page+0xe/0x20
    [ 6281.127446]   [<ffffffffa01ae406>] __get_metapage+0x1c6/0x5c0 [jfs]
    [ 6281.127455]   [<ffffffffa01a018a>] diWrite+0xea/0x7f0 [jfs]
    [ 6281.127461]   [<ffffffffa01b3b04>] txCommit+0x1d4/0xe40 [jfs]
    [ 6281.127468]   [<ffffffffa01982e3>] jfs_unlink+0x2a3/0x390 [jfs]
    [ 6281.127474]   [<ffffffff8118255f>] vfs_unlink+0x9f/0x110
    [ 6281.127479]   [<ffffffff8118277a>] do_unlinkat+0x1aa/0x1d0
    [ 6281.127482]   [<ffffffff81184236>] sys_unlink+0x16/0x20
    [ 6281.127486]   [<ffffffff8143e202>] system_call_fastpath+0x16/0x1b
    [ 6281.127491] irq event stamp: 26965295
    [ 6281.127493] hardirqs last  enabled at (26965295):
[<ffffffff8111a3d5>] clear_page_dirty_for_io+0x105/0x130
    [ 6281.127498] hardirqs last disabled at (26965294):
[<ffffffff8111a378>] clear_page_dirty_for_io+0xa8/0x130
    [ 6281.127503] softirqs last  enabled at (26964300):
[<ffffffff8106cda7>] __do_softirq+0x137/0x2a0
    [ 6281.127508] softirqs last disabled at (26964283):
[<ffffffff814404fc>] call_softirq+0x1c/0x30
    [ 6281.127513]
    [ 6281.127514] other info that might help us debug this:
    [ 6281.127516]  Possible unsafe locking scenario:
    [ 6281.127517]
    [ 6281.127518]        CPU0
    [ 6281.127519]        ----
    [ 6281.127521]   lock(&jfs_ip->rdwrlock);
    [ 6281.127524]   <Interrupt>
    [ 6281.127525]     lock(&jfs_ip->rdwrlock);
    [ 6281.127528]
    [ 6281.127529]  *** DEADLOCK ***
    [ 6281.127529]
    [ 6281.127531] no locks held by kswapd0/30.
    [ 6281.127533]
    [ 6281.127533] stack backtrace:
    [ 6281.127536] Pid: 30, comm: kswapd0 Tainted: G         C
3.2.0-rc4-00154-g8e8da02 #91
    [ 6281.127539] Call Trace:
    [ 6281.127545]  [<ffffffff8143374c>] print_usage_bug.part.34+0x285/0x294
    [ 6281.127552]  [<ffffffff8102494f>] ? save_stack_trace+0x2f/0x50
    [ 6281.127559]  [<ffffffff8109ffe0>] mark_lock+0x540/0x600
    [ 6281.127564]  [<ffffffff8109ef60>] ?
print_irq_inversion_bug.part.31+0x1f0/0x1f0
    [ 6281.127568]  [<ffffffff810a0677>] __lock_acquire+0x5d7/0x1d10
    [ 6281.127573]  [<ffffffff81118394>] ? free_pcppages_bulk+0x34/0x430
    [ 6281.127580]  [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
    [ 6281.127584]  [<ffffffff810a23a2>] lock_acquire+0x92/0x160
    [ 6281.127590]  [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
    [ 6281.127595]  [<ffffffff811a5253>] ? create_empty_buffers+0x53/0xe0
    [ 6281.127600]  [<ffffffff8108e77f>] down_write_nested+0x2f/0x60
    [ 6281.127606]  [<ffffffffa01958d7>] ? jfs_get_block+0x57/0x220 [jfs]
    [ 6281.127612]  [<ffffffffa01958d7>] jfs_get_block+0x57/0x220 [jfs]
    [ 6281.127616]  [<ffffffff8143d24b>] ? _raw_spin_unlock+0x2b/0x60
    [ 6281.127620]  [<ffffffff811a65d1>] __block_write_full_page+0x101/0x3a0
    [ 6281.127625]  [<ffffffff811a5fe0>] ? block_read_full_page+0x3d0/0x3d0
    [ 6281.127631]  [<ffffffffa0195880>] ? jfs_writepage+0x20/0x20 [jfs]
    [ 6281.127637]  [<ffffffff811a6954>] block_write_full_page_endio+0xe4/0x130
    [ 6281.127642]  [<ffffffff811a69b5>] block_write_full_page+0x15/0x20
    [ 6281.127651]  [<ffffffffa0195878>] jfs_writepage+0x18/0x20 [jfs]
    [ 6281.127657]  [<ffffffff8112427c>] shrink_page_list+0x56c/0x980
    [ 6281.127662]  [<ffffffff8111e596>] ? __pagevec_release+0x26/0x40
    [ 6281.127666]  [<ffffffff81124ac2>] shrink_inactive_list+0x152/0x4f0
    [ 6281.127670]  [<ffffffff8112563c>] shrink_zone+0x47c/0x5c0
    [ 6281.127673]  [<ffffffff81122fef>] ? shrink_slab+0x1ff/0x380
    [ 6281.127678]  [<ffffffff8143945b>] ? __schedule+0x35b/0xa30
    [ 6281.127682]  [<ffffffff811269c5>] balance_pgdat+0x4e5/0x6d0
    [ 6281.127685]  [<ffffffff81126d28>] kswapd+0x178/0x440
    [ 6281.127691]  [<ffffffff81089840>] ? __init_waitqueue_head+0x60/0x60
    [ 6281.127695]  [<ffffffff81126bb0>] ? balance_pgdat+0x6d0/0x6d0
    [ 6281.127699]  [<ffffffff81088e97>] kthread+0xa7/0xb0
    [ 6281.127703]  [<ffffffff810a2efd>] ? trace_hardirqs_on+0xd/0x10
    [ 6281.127707]  [<ffffffff81440404>] kernel_thread_helper+0x4/0x10
    [ 6281.127711]  [<ffffffff8143d838>] ? retint_restore_args+0x13/0x13
    [ 6281.127715]  [<ffffffff81088df0>] ? __init_kthread_worker+0x70/0x70
    [ 6281.127719]  [<ffffffff81440400>] ? gs_change+0x13/0x13

Hmm?

Linus

I don't think this is a regression. It's been seen before, but the patch never got submitted, or was lost somewhere. I believe this will fix it.

vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL

lockdep reports a deadlock in jfs because a special inode's rw semaphore is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used when __read_cache_page() calls add_to_page_cache_lru().

index c106d3b..c9ea3df 100644
@@ -1828,7 +1828,7 @@ repeat:
 		page = __page_cache_alloc(gfp | __GFP_COLD);
 		if (!page)
 			return ERR_PTR(-ENOMEM);
-		err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
+		err = add_to_page_cache_lru(page, mapping, index, gfp);
 		if (unlikely(err)) {
 			page_cache_release(page);
 			if (err == -EEXIST)

Hmm. This patch looks obviously correct. But it looks *so* obviously correct that it just makes me suspicious - this is not new or seldom used code, it's been this way for ages and used all the time. That line literally goes back to 2007, commit eb2be189317d0. And it looks like even before that we had a GFP_KERNEL for the add_to_page_cache() case and that goes back to before the git history. So this is *ancient*.

Maybe almost nobody uses __read_cache_page() with a non-GFP_KERNEL gfp and as a result we've not noticed.

Or maybe there is some crazy reason why it calls "add_to_page_cache()" with GFP_KERNEL.

Adding the usual suspects for mm/filemap.c to the cc line (Andrew is already cc'd, but Al and Hugh should comment).

Ack's, people? Is it really as obvious as it looks, and we've just had this bug forever?

Linus

--- snip snip ---

Certainly

from me (and add_to_page_cache_locked does the masking of inappropriate bits when passing on down, so no need to worry about that aspect).

I agree that it's odd that we've never noticed it before, but I don't think the GFP_KERNEL there has any more significance than oversight. Nick cleaned up some similar instances in filemap.c a few years back, I guess ones he hit in testing, but this just got left over.

page_cache_read()'s GFP_KERNEL looks similarly worrying, but as it's only called by filemap_fault(), I suppose it's actually okay.

Ooh, maybe you should also update that comment on GFP_KERNEL above read_cache_page_gfp()...

Hugh

I was grepping for possibilities of that hitting us right now... OK, rigth you are.

[ updated to remove now-obsolete comment in read_cache_page_gfp()]

lockdep reports a deadlock in jfs because a special inode's rw semaphore is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used when __read_cache_page() calls add_to_page_cache_lru().

index c106d3b..5f0a3c9 100644
@@ -1828,7 +1828,7 @@ repeat:
 		page = __page_cache_alloc(gfp | __GFP_COLD);
 		if (!page)
 			return ERR_PTR(-ENOMEM);
-		err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
+		err = add_to_page_cache_lru(page, mapping, index, gfp);
 		if (unlikely(err)) {
 			page_cache_release(page);
 			if (err == -EEXIST)

@@ -1925,10 +1925,7 @@ static struct page *wait_on_page_read(struct page *page)
  * @gfp:	the page allocator flags to use if allocating
  *
  * This is the same as "read_mapping_page(mapping, index, NULL)", but with
- * any new page allocations done using the specified allocation flags. Note
- * that the Radix tree operations will still use GFP_KERNEL, so you can't
- * expect to do this atomically or anything like that - but you can pass in
- * other page requirements.
+ * any new page allocations done using the specified allocation flags.
  *
  * If the page does not get brought uptodate, return -EIO.
  */

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Well hang on, it's not just a lockdep splat. The kernel actually will deadlock if we reenter JFS via this GFP_KERNEL allocation attempt, yes?

Was that GFP_NOFS allocation recently added to JFS? If not then we should backport this deadlock fix into -stable, no?

Yes, it could result in a real deadlock.

Yes, that would make sense.

Shaggy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

From: Linus Torvalds <torvalds-de/[email protected]>
Date: Tue, 20 Dec 2011 18:31:15 -0800

It is.

i915 HDMI log spam, reported against -rc1:

http://permalink.gmane.org/gmane.linux.kernel/1212638

remains present in mainline. The latest patches (afaik) were posted earlier this month:

Subject: Intel HDMI ELD fixes v2
http://permalink.gmane.org/gmane.linux.kernel/1226920

Cheers,

Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Dave and I didn't think the log spam warranted pulling these patches in past the merge window. They're pending 3.3 at this point.

[email protected]

Well, it's not clear this is a regression. Also I didn't get any reply
from the reporter for a week so I'm inclined to declare it ENORESPONSE...

Honza

Jan Kara <[email protected]>
SUSE Labs, CR

[...]

I believe we already have a fix for this, but not yet in mainline:
http://thread.gmane.org/gmane.linux.nfs/45336

Regards,
Srivatsa S. Bhat

I don't believe this is a regression at all. As far as I know, It's always been the case that these sleeps weren't freezable. I even have a similar bug open for RHEL6 which has a 2.6.32-based kernel...

If people are seeing this more now, then it might be some subtle difference in timing or differences in what userspace is doing at the time the freezer runs.

In any case, the final fix didn't make 3.2, but should go in early for 3.3.

Jeff Layton <[email protected]>

This one looks a bit similar to the one reported at
http://thread.gmane.org/gmane.linux.kernel/1230509/ which is fixed by commit 29495aa04a30c21565243c5b9c028510446d242c.

Regards,
Srivatsa S. Bhat