Prev: Hello
Next: ocfs2: Zero the tail cluster when extending past i_size v2
From: Linus Torvalds on 4 Jul 2010 23:50
Hey everybody, there's finally a new -rc out there..

I've been back online for a week, and at least judging by the kinds of
patches and pull requests I've been getting, I have to say that I
think that having been strict for -rc3 ended up working out pretty
well. The diffstat of rc3..rc4 looks quite reasonable, despite the
longer window between rc's. And while there were certainly some things
that needed fixing, I'm hoping that we'll have a timely 2.6.35 release
despite my vacation (my longest time away from the kernel in many
years, I do believe - I followed email on a cellphone, but did not a
single kernel compile, and had a great time under water).

So go out and test -rc4. It fixes a number of regressions, a couple of
them harking back to from before 2.6.34. Networking, cfq, i915 and
radeo. And filesystem writeback performance issues, etc. It's all
good.

Linus
From: Xiaotian Feng on 5 Jul 2010 06:30
On Mon, Jul 5, 2010 at 11:44 AM, Linus Torvalds
<torvalds(a)linux-foundation.org> wrote:
> Hey everybody, there's finally a new -rc out there..
>
> I've been back online for a week, and at least judging by the kinds of
> patches and pull requests I've been getting, I have to say that I
> think that having been strict for -rc3 ended up working out pretty
> well. The diffstat of rc3..rc4 looks quite reasonable, despite the
> longer window between rc's. And while there were certainly some things
> that needed fixing, I'm hoping that we'll have a timely 2.6.35 release
> despite my vacation (my longest time away from the kernel in many
> years, I do believe - I followed email on a cellphone, but did not a
> single kernel compile, and had a great time under water).
>
> So go out and test -rc4. It fixes a number of regressions, a couple of
> them harking back to from before 2.6.34. Networking, cfq, i915 and
> radeo. And filesystem writeback performance issues, etc. It's all
> good.

I'm facing some drm issue with -rc4, my x-windows is messed up and can
not be used. I got floods of following messages, kernel config is
attached. I have the same issue on -mmotm-rc3.

[ 34.532132] BUG: scheduling while atomic: plymouthd/177/0x00000002
[ 34.532133] INFO: lockdep is turned off.
[ 34.532135] Modules linked in: radeon(+) ttm drm_kms_helper drm
i2c_algo_bit i2c_core
[ 34.532139] Pid: 177, comm: plymouthd Tainted: G D I 2.6.35-rc4+ #39
[ 34.532141] Call Trace:
[ 34.532144] [<ffffffff8104361a>] __schedule_bug+0x77/0x7c
[ 34.532146] [<ffffffff814f9592>] schedule+0xd3/0x695
[ 34.532149] [<ffffffff81301fc9>] ? tty_release+0x301/0x602
[ 34.532152] [<ffffffff814fa64c>] __mutex_lock_common+0x29d/0x461
[ 34.532154] [<ffffffff81301fc9>] ? tty_release+0x301/0x602
[ 34.532156] [<ffffffff814fbebc>] ? _raw_spin_unlock+0x4a/0x57
[ 34.532159] [<ffffffff814fa8c5>] mutex_lock_nested+0x39/0x3e
[ 34.532161] [<ffffffff81301fc9>] tty_release+0x301/0x602
[ 34.532164] [<ffffffff8110a06b>] ? __cache_free+0x3a/0x1bc
[ 34.532167] [<ffffffff8111a636>] fput+0x135/0x1e2
[ 34.532170] [<ffffffff811177e5>] filp_close+0x68/0x72
[ 34.532172] [<ffffffff81052047>] put_files_struct+0xbd/0x171
[ 34.532175] [<ffffffff81052146>] exit_files+0x4b/0x53
[ 34.532177] [<ffffffff81053bb2>] do_exit+0x294/0x756
[ 34.532180] [<ffffffff81050bd6>] ? kmsg_dump+0x155/0x16f
[ 34.532182] [<ffffffff814fd6ec>] oops_end+0xbe/0xc6
[ 34.532185] [<ffffffff81033022>] no_context+0x1fc/0x20b
[ 34.532188] [<ffffffff810331c3>] __bad_area_nosemaphore+0x192/0x1b5
[ 34.532196] [<ffffffffa0023e39>] ? drm_fb_release+0x2f/0x7e [drm]
[ 34.532199] [<ffffffff810331f9>] bad_area_nosemaphore+0x13/0x15
[ 34.532201] [<ffffffff814ff441>] do_page_fault+0x15d/0x283
[ 34.532209] [<ffffffffa0023e39>] ? drm_fb_release+0x2f/0x7e [drm]
[ 34.532211] [<ffffffff814fca25>] page_fault+0x25/0x30
[ 34.532219] [<ffffffffa0023e39>] ? drm_fb_release+0x2f/0x7e [drm]
[ 34.532222] [<ffffffff8127be8a>] ? __list_add+0x3f/0x81
[ 34.532225] [<ffffffff814fa4e0>] __mutex_lock_common+0x131/0x461
[ 34.532233] [<ffffffffa0023e39>] ? drm_fb_release+0x2f/0x7e [drm]
[ 34.532239] [<ffffffffa001b104>] ? drm_release+0x2bd/0x63e [drm]
[ 34.532242] [<ffffffff814fa8c5>] mutex_lock_nested+0x39/0x3e
[ 34.532250] [<ffffffffa0023e39>] drm_fb_release+0x2f/0x7e [drm]
[ 34.532257] [<ffffffffa001b1da>] drm_release+0x393/0x63e [drm]
[ 34.532259] [<ffffffff8111a636>] fput+0x135/0x1e2
[ 34.532262] [<ffffffff811177e5>] filp_close+0x68/0x72
[ 34.532265] [<ffffffff811178cb>] sys_close+0xdc/0x116
[ 34.532268] [<ffffffff81009cc2>] system_call_fastpath+0x16/0x1b

>
>                   Linus
>
From: Linus Torvalds on 9 Jul 2010 17:50
On Mon, Jul 5, 2010 at 3:22 AM, Xiaotian Feng <xtfeng(a)gmail.com> wrote:
>
> I'm facing some drm issue with -rc4, my x-windows is messed up and can
> not be used. I got floods of following messages, kernel config is
> attached. I have the same issue on -mmotm-rc3.

It looks like the first oops that causes this problem is missing. It
looks to me that the "scheduling while atomic" issue happens because
you had an oops in drm_fb_release->mutex_lock_nested->oops, and then
when that kills the process, we get that secondary "scheduling while
atomic" thing.

But I'd really like to see the first oops itself. It _looks_ like it
should be a page fault with this backtrace:

> [ � 34.532219] �[<ffffffffa0023e39>] ? drm_fb_release+0x2f/0x7e [drm]
> [ � 34.532222] �[<ffffffff8127be8a>] ? __list_add+0x3f/0x81
> [ � 34.532225] �[<ffffffff814fa4e0>] __mutex_lock_common+0x131/0x461
> [ � 34.532233] �[<ffffffffa0023e39>] ? drm_fb_release+0x2f/0x7e [drm]
> [ � 34.532239] �[<ffffffffa001b104>] ? drm_release+0x2bd/0x63e [drm]
> [ � 34.532242] �[<ffffffff814fa8c5>] mutex_lock_nested+0x39/0x3e
> [ � 34.532250] �[<ffffffffa0023e39>] drm_fb_release+0x2f/0x7e [drm]
> [ � 34.532257] �[<ffffffffa001b1da>] drm_release+0x393/0x63e [drm]
> [ � 34.532259] �[<ffffffff8111a636>] fput+0x135/0x1e2
> [ � 34.532262] �[<ffffffff811177e5>] filp_close+0x68/0x72
> [ � 34.532265] �[<ffffffff811178cb>] sys_close+0xdc/0x116
> [ � 34.532268] �[<ffffffff81009cc2>] system_call_fastpath+0x16/0x1b

but I'd like to see the actual register state etc from the oops too.

And if it all scrolls away so quickly that you can't see it, then I
suspect we need some help in the form of a bisection or something. Was
2.6.35-rc3 fine for you? If so, it should bisect pretty well - there's
only a few hundred commits, so you should be able to do it in eight or
nine recompiles.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: Hello
Next: ocfs2: Zero the tail cluster when extending past i_size v2