Mailing List Archive

On Tue, 28 Feb 2006 04:24:39 -0800
Andrew Morton <akpm@osdl.org> wrote:

> +s390-multiple-subchannel-sets-support-fix.patch

If neither Greg nor Martin (on cc:) object, I'd prefer this patch to be
replaced with the one in
http://marc.theaimsgroup.com/?l=linux-kernel&m=114102840429459&q=raw
(it has a better check of the response code).

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

On Tue, 2006-02-28 at 15:41 +0100, Cornelia Huck wrote:
> On Tue, 28 Feb 2006 04:24:39 -0800
> Andrew Morton <akpm@osdl.org> wrote:
>
> > +s390-multiple-subchannel-sets-support-fix.patch
>
> If neither Greg nor Martin (on cc:) object, I'd prefer this patch to be
> replaced with the one in
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114102840429459&q=raw
> (it has a better check of the response code).

Fine with me.

--
blue skies,
Martin

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH


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

Hi,

On 28/02/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm1/
>
>
> - A large procfs rework from Eric Biederman.
>
> - The swap prefetching patch is back.
>
[snip]
> +inotify-lock-avoidance-with-parent-watch-status-in-dentry.patch
> +inotify-lock-avoidance-with-parent-watch-status-in-dentry-fix.patch

I have noticed this:
Feb 28 15:13:42 ltg01-sid kernel: BUG: warning at
/usr/src/linux-mm/fs/inotify.c:533/inotify_d_instantiate()
Feb 28 15:13:42 ltg01-sid kernel: [show_trace+13/15] show_trace+0xd/0xf
Feb 28 15:13:42 ltg01-sid kernel: [dump_stack+21/23] dump_stack+0x15/0x17
Feb 28 15:13:42 ltg01-sid kernel: [inotify_d_instantiate+47/98]
inotify_d_instantiate+0x2f/0x62
Feb 28 15:13:42 ltg01-sid kernel: [d_instantiate+70/114]
d_instantiate+0x46/0x72
Feb 28 15:13:42 ltg01-sid kernel: [ext3_add_nondir+44/64]
ext3_add_nondir+0x2c/0x40
Feb 28 15:13:42 ltg01-sid kernel: [ext3_link+163/217] ext3_link+0xa3/0xd9
Feb 28 15:13:42 ltg01-sid kernel: [vfs_link+292/379] vfs_link+0x124/0x17b
Feb 28 15:13:42 ltg01-sid kernel: [sys_linkat+157/218] sys_linkat+0x9d/0xda
Feb 28 15:13:42 ltg01-sid kernel: [sys_link+20/25] sys_link+0x14/0x19
Feb 28 15:13:42 ltg01-sid kernel: [syscall_call+7/11] syscall_call+0x7/0xb

Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-dmesg
Here is config http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-config

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
-
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/

From: Cornelia Huck <cornelia.huck@de.ibm.com>

> If neither Greg nor Martin (on cc:) object, I'd prefer this patch
> to be
> replaced with the one in
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114102840429459&q=raw
> (it has a better check of the response code).

No objections here. Thanks Cornelia.

Greg Smith
-
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/

On 28/02/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi,
>
> On 28/02/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm1/
> >
> >
> > - A large procfs rework from Eric Biederman.
> >
> > - The swap prefetching patch is back.
> >
> [snip]
> > +inotify-lock-avoidance-with-parent-watch-status-in-dentry.patch
> > +inotify-lock-avoidance-with-parent-watch-status-in-dentry-fix.patch
>
> I have noticed this:
> Feb 28 15:13:42 ltg01-sid kernel: BUG: warning at
> /usr/src/linux-mm/fs/inotify.c:533/inotify_d_instantiate()
> Feb 28 15:13:42 ltg01-sid kernel: [show_trace+13/15] show_trace+0xd/0xf
> Feb 28 15:13:42 ltg01-sid kernel: [dump_stack+21/23] dump_stack+0x15/0x17
> Feb 28 15:13:42 ltg01-sid kernel: [inotify_d_instantiate+47/98]
> inotify_d_instantiate+0x2f/0x62
> Feb 28 15:13:42 ltg01-sid kernel: [d_instantiate+70/114]
> d_instantiate+0x46/0x72
> Feb 28 15:13:42 ltg01-sid kernel: [ext3_add_nondir+44/64]
> ext3_add_nondir+0x2c/0x40
> Feb 28 15:13:42 ltg01-sid kernel: [ext3_link+163/217] ext3_link+0xa3/0xd9
> Feb 28 15:13:42 ltg01-sid kernel: [vfs_link+292/379] vfs_link+0x124/0x17b
> Feb 28 15:13:42 ltg01-sid kernel: [sys_linkat+157/218] sys_linkat+0x9d/0xda
> Feb 28 15:13:42 ltg01-sid kernel: [sys_link+20/25] sys_link+0x14/0x19
> Feb 28 15:13:42 ltg01-sid kernel: [syscall_call+7/11] syscall_call+0x7/0xb
>
> Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-dmesg
> Here is config http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-config

This patch is causing that warning
inotify-lock-avoidance-with-parent-watch-status-in-dentry.patch

It's full reproductible on my system, it appears when I start mozilla
thunderbird (v 1.0.7).

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
-
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/

On Tue, Feb 28, 2006 at 04:24:39AM -0800, Andrew Morton wrote:
[...]
> +mips-fixed-collision-of-rtc-function-name.patch
> +rtc-subsystem-library-functions.patch
> +rtc-subsystem-class.patch
> +rtc-subsystem-class-fix.patch
> +rtc-subsystem-class-fix-2.patch
>
> Updated rtc subsystem patches

in drives/Makefile the line

obj-$(CONFIG_RTC_CLASS) += /rtc

causes the missing symbols
WARNING: /lib/modules/2.6.16-rc5-mm1-1/kernel/drivers/rtc/rtc-test.ko needs unknown symbol rtc_time_to_tm
WARNING: /lib/modules/2.6.16-rc5-mm1-1/kernel/drivers/rtc/rtc-core.ko needs unknown symbol rtc_valid_tm
WARNING: /lib/modules/2.6.16-rc5-mm1-1/kernel/drivers/rtc/rtc-sysfs.ko needs unknown symbol rtc_tm_to_tim

when CONFIG_RTC_*=m. Maybe obj-y is nedded instead?

--
mattia
:wq!
-
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/

On 2/28/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm1/
>

Ok, something is definately broken in this kernel.

If I launch Eclipse (http://www.eclipse.org/) while running a
2.6.16-rc5-mm1 kernel it loads for a second or two and then the box
just locks up solid.

I then went back to my previous kernel, 2.6.16-rc4-mm2, and there's no
problem what-so-ever when running that kernel (everything else
identical) - eclipse loads and runs just fine.

Since I'm in X when the lockup happens and I don't have enough time
from clicking the eclipse icon to the box locks up to make a switch to
a text console I don't know if an Oops or similar is dumped to the
console (there's nothing in the locks after a reboot) :-(

Unfortunately I don't have a second box to use with serial console or
netconsole, but I'll see if I can somehow get some console messages -
perhaps by slowing down the eclipse load process somehow... I'll see
what I can do and report back when I have more into.
If all else fails and noone on LKML can suggest patches to try and
revert or similar I guess I'll eventually do a git bisect, but I'd
rather try other things first...

The version of Eclipse I'm running is 3.1.2

The problem is completely reproducible (well, at least it occoured 6
times in a row and that's how many times I tried).

Sorry for the lack of detail, but I thought I'd better report the
issue at once and then follow up with details later :)

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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/

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

Jesper Juhl napsal(a):
> Since I'm in X when the lockup happens and I don't have enough time
> from clicking the eclipse icon to the box locks up to make a switch to
> a text console I don't know if an Oops or similar is dumped to the
> console (there's nothing in the locks after a reboot) :-(
So why don't just run eclipse from console (DISPLAY=... eclipse), or use atd,
crond... (less common variants)?

regards,
- --
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~ jirislaby@gmail.com ~\-/~
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEBM45MsxVwznUen4RAiABAKCUFCSNKZY44nCs70siadm7DKwIgACfQi8z
QQaYcwZXIsjIvVpWJAfPFog=
=thwP
-----END PGP SIGNATURE-----
-
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/

On 2/28/06, Jiri Slaby <slaby@liberouter.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jesper Juhl napsal(a):
> > Since I'm in X when the lockup happens and I don't have enough time
> > from clicking the eclipse icon to the box locks up to make a switch to
> > a text console I don't know if an Oops or similar is dumped to the
> > console (there's nothing in the locks after a reboot) :-(
> So why don't just run eclipse from console (DISPLAY=... eclipse), or use atd,
> crond... (less common variants)?
>

Good idea, thanks. Dunno why I didn't think of that.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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/

On Tuesday 28 February 2006 13:24, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm1/
>
>
> - A large procfs rework from Eric Biederman.
>
> - The swap prefetching patch is back.

With this kernel something that causes the appended trace to appear happens on
my box (Asus L5D, 1 CPU, x86-64) 100% of the time during boot.

Greetings,
Rafael


usbcore: registered new driver usbserial
usbserial: USB Serial support registered for generic
usbcore: registered new driver usbserial_generic
usbserial: USB Serial Driver core
BUG: warning at kernel/fork.c:113/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:114/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c5d>{__put_task_struct+109}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:113/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:114/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c5d>{__put_task_struct+109}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:113/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:114/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c5d>{__put_task_struct+109}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:113/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:114/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c5d>{__put_task_struct+109}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:113/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:114/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c5d>{__put_task_struct+109}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:113/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:114/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c5d>{__put_task_struct+109}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:113/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:114/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c5d>{__put_task_struct+109}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:113/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
BUG: warning at kernel/fork.c:114/__put_task_struct()

Call Trace: <IRQ> <ffffffff80229c5d>{__put_task_struct+109}
<ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
<ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
general protection fault: 0000 [1] PREEMPT
last sysfs file: /class/vc/vcsa2/dev
CPU 0
Modules linked in: usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device af_packet p
cmcia firmware_class ohci1394 ieee1394 yenta_socket rsrc_nonstatic pcmcia_core usbhid sk98lin snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
pcm ip6t_REJECT xt_tcpudp snd_timer snd ipt_REJECT xt_state soundcore iptable_mangle snd_page_alloc iptable_nat ip_nat iptable_filter i2c_n
force2 ip6table_mangle i2c_core ehci_hcd ohci_hcd ip_conntrack ip_tables ip6table_filter ip6_tables x_tables ipv6 parport_pc lp parport dm_
mod
Pid: 820, comm: kjournald Not tainted 2.6.16-rc5-mm1 #70
RIP: 0010:[<ffffffff8046747c>] <ffffffff8046747c>{schedule+1164}
RSP: 0000:ffff810001c53c38 EFLAGS: 00010007
RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6b RCX: 949494959493a4ca
RDX: ffff810027ce1050 RSI: 0000000000000000 RDI: ffff810027ce1050
RBP: ffff810001c53c98 R08: ffff810001a83040 R09: 0000000000000009
R10: 00000000ffffffff R11: 0000000000000001 R12: ffff81002c8de4c8
R13: ffff81002fdf72f8 R14: ffff810001a83040 R15: 000000000000390b
FS: 00002adb23959b00(0000) GS:ffffffff8068d000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00002b5b92aa91de CR3: 0000000027329000 CR4: 00000000000006e0
Process kjournald (pid: 820, threadinfo ffff810001c52000, task ffff81002fdf7090)
Stack: ffff81002fdf7090 ffff810027ce1050 ffff810001c53d18 ffff810001f2af10
ffff810001c53c78 ffff810001f2af10 ffff810001c53c78 ffff810001c53d08
ffff810001c53d18 0000000000000002
Call Trace: <ffffffff804676df>{io_schedule+15} <ffffffff8027efeb>{sync_buffer+59}
<ffffffff80468015>{__wait_on_bit_lock+69} <ffffffff8027efb0>{sync_buffer+0}
<ffffffff8027efb0>{sync_buffer+0} <ffffffff804680c8>{out_of_line_wait_on_bit_lock+120}
<ffffffff80242690>{wake_bit_function+0} <ffffffff8027e574>{__lock_buffer+36}
<ffffffff8027fdc1>{ll_rw_block+65} <ffffffff8030a3ab>{journal_commit_transaction+1659}
<ffffffff804697d4>{_spin_unlock_irq+20} <ffffffff8046981d>{_spin_unlock_irqrestore+29}
<ffffffff8030e5c3>{kjournald+339} <ffffffff80242520>{autoremove_wake_function+0}
<ffffffff8030e470>{kjournald+0} <ffffffff80242309>{kthread+217}
<ffffffff804697d4>{_spin_unlock_irq+20} <ffffffff80228929>{schedule_tail+73}
<ffffffff8020a85e>{child_rip+8} <ffffffff80242230>{kthread+0}
<ffffffff8020a856>{child_rip+0}

Code: 0f ab 83 d8 02 00 00 48 8b 53 48 48 b8 ff ff ff 7f ff ff ff
RIP <ffffffff8046747c>{schedule+1164} RSP <ffff810001c53c38>
<0>BUG: spinlock recursion on CPU#0, kjournald/820
lock: ffffffff80613400, .magic: dead4ead, .owner: kjournald/820, .owner_cpu: 0

Call Trace: <IRQ> <ffffffff80354555>{spin_bug+165} <ffffffff803547c1>{_raw_spin_lock+81}
<ffffffff80469837>{_spin_unlock_irqrestore+55} <ffffffff804693ee>{_spin_lock+30}
<ffffffff80469837>{_spin_unlock_irqrestore+55} <ffffffff80228367>{try_to_wake_up+55}
<ffffffff8022849d>{default_wake_function+13} <ffffffff80227463>{__wake_up_common+67}
<ffffffff802274e3>{__wake_up+67} <ffffffff8023e900>{delayed_work_timer_fn+0}
<ffffffff8023e42d>{__queue_work+93} <ffffffff8023e929>{delayed_work_timer_fn+41}
<ffffffff80236e39>{run_timer_softirq+361} <ffffffff802322e4>{__do_softirq+84}
<ffffffff8020abae>{call_softirq+30} <ffffffff8020c7d4>{do_softirq+52}
<ffffffff8023215f>{irq_exit+63} <ffffffff8020c781>{do_IRQ+65}
<ffffffff8020a232>{ret_from_intr+0} <EOI> <ffffffff804697cf>{_spin_unlock_irq+15}
<ffffffff804697c9>{_spin_unlock_irq+9} <ffffffff80468df6>{__down_read+54}
<ffffffff8023c2c2>{blocking_notifier_call_chain+34}
<ffffffff8022dae5>{profile_task_exit+21} <ffffffff8022f1e5>{do_exit+37}
<ffffffff8046981d>{_spin_unlock_irqrestore+29} <ffffffff8020b5a4>{die+84}
<ffffffff8020bae0>{do_general_protection+272} <ffffffff8020a6a5>{error_exit+0}
<ffffffff8046747c>{schedule+1164} <ffffffff80467468>{schedule+1144}
<ffffffff804676df>{io_schedule+15} <ffffffff8027efeb>{sync_buffer+59}
<ffffffff80468015>{__wait_on_bit_lock+69} <ffffffff8027efb0>{sync_buffer+0}
<ffffffff8027efb0>{sync_buffer+0} <ffffffff804680c8>{out_of_line_wait_on_bit_lock+120}
<ffffffff80242690>{wake_bit_function+0} <ffffffff8027e574>{__lock_buffer+36}
<ffffffff8027fdc1>{ll_rw_block+65} <ffffffff8030a3ab>{journal_commit_transaction+1659}
<ffffffff804697d4>{_spin_unlock_irq+20} <ffffffff8046981d>{_spin_unlock_irqrestore+29}
<ffffffff8030e5c3>{kjournald+339} <ffffffff80242520>{autoremove_wake_function+0}
<ffffffff8030e470>{kjournald+0} <ffffffff80242309>{kthread+217}
<ffffffff804697d4>{_spin_unlock_irq+20} <ffffffff80228929>{schedule_tail+73}
<ffffffff8020a85e>{child_rip+8} <ffffffff80242230>{kthread+0}
<ffffffff8020a856>{child_rip+0}
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in: usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device af_packet p
cmcia firmware_class ohci1394 ieee1394 yenta_socket rsrc_nonstatic pcmcia_core usbhid sk98lin snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
pcm ip6t_REJECT xt_tcpudp snd_timer snd ipt_REJECT xt_state soundcore iptable_mangle snd_page_alloc iptable_nat ip_nat iptable_filter i2c_n
force2 ip6table_mangle i2c_core ehci_hcd ohci_hcd ip_conntrack ip_tables ip6table_filter ip6_tables x_tables ipv6 parport_pc lp parport dm_
mod
Pid: 820, comm: kjournald Not tainted 2.6.16-rc5-mm1 #70
RIP: 0010:[<ffffffff80354817>] <ffffffff80354817>{_raw_spin_lock+167}
RSP: 0000:ffffffff80606d68 EFLAGS: 00000006
RAX: 000000006b1712ca RBX: ffffffff80613400 RCX: 00000000006da909
RDX: 0000000001b6a424 RSI: ffffffff804a674b RDI: 0000000000000001
RBP: ffffffff80606d88 R08: 0000000000000002 R09: 0000000000000001
R10: 0000000000000000 R11: 000000000000000a R12: 000000001b82fd67
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000086
FS: 00002adb23959b00(0000) GS:ffffffff8068d000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00002b5b92aa91de CR3: 0000000027329000 CR4: 00000000000006e0
Process kjournald (pid: 820, threadinfo ffff810001c52000, task ffff81002fdf7090)
Stack: ffffffff80469837 ffffffff80613400 ffff81002fd2db40 ffff810001c47090
ffffffff80606da8 ffffffff804693ee ffffffff80469837 0000000000000003
ffffffff80606de8 ffffffff80228367
Call Trace: <IRQ> <ffffffff80469837>{_spin_unlock_irqrestore+55}
<ffffffff804693ee>{_spin_lock+30} <ffffffff80469837>{_spin_unlock_irqrestore+55}
<ffffffff80228367>{try_to_wake_up+55} <ffffffff8022849d>{default_wake_function+13}
<ffffffff80227463>{__wake_up_common+67} <ffffffff802274e3>{__wake_up+67}
<ffffffff8023e900>{delayed_work_timer_fn+0} <ffffffff8023e42d>{__queue_work+93}
<ffffffff8023e929>{delayed_work_timer_fn+41} <ffffffff80236e39>{run_timer_softirq+361}
<ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
<ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
<ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
<ffffffff804697cf>{_spin_unlock_irq+15} <ffffffff804697c9>{_spin_unlock_irq+9}
<ffffffff80468df6>{__down_read+54} <ffffffff8023c2c2>{blocking_notifier_call_chain+34}
<ffffffff8022dae5>{profile_task_exit+21} <ffffffff8022f1e5>{do_exit+37}
<ffffffff8046981d>{_spin_unlock_irqrestore+29} <ffffffff8020b5a4>{die+84}
<ffffffff8020bae0>{do_general_protection+272} <ffffffff8020a6a5>{error_exit+0}
<ffffffff8046747c>{schedule+1164} <ffffffff80467468>{schedule+1144}
<ffffffff804676df>{io_schedule+15} <ffffffff8027efeb>{sync_buffer+59}
<ffffffff80468015>{__wait_on_bit_lock+69} <ffffffff8027efb0>{sync_buffer+0}
<ffffffff8027efb0>{sync_buffer+0} <ffffffff804680c8>{out_of_line_wait_on_bit_lock+120}
<ffffffff80242690>{wake_bit_function+0} <ffffffff8027e574>{__lock_buffer+36}
<ffffffff8027fdc1>{ll_rw_block+65} <ffffffff8030a3ab>{journal_commit_transaction+1659}
<ffffffff804697d4>{_spin_unlock_irq+20} <ffffffff8046981d>{_spin_unlock_irqrestore+29}
<ffffffff8030e5c3>{kjournald+339} <ffffffff80242520>{autoremove_wake_function+0}
<ffffffff8030e470>{kjournald+0} <ffffffff80242309>{kthread+217}
<ffffffff804697d4>{_spin_unlock_irq+20} <ffffffff80228929>{schedule_tail+73}
<ffffffff8020a85e>{child_rip+8} <ffffffff80242230>{kthread+0}
<ffffffff8020a856>{child_rip+0}

Code: 8b 03 c7 03 00 00 00 00 84 c0 7f 7d bf 01 00 00 00 49 ff c4
console shuts up ...
-
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/

"Jesper Juhl" <jesper.juhl@gmail.com> wrote:
>
> Since I'm in X when the lockup happens and I don't have enough time
> from clicking the eclipse icon to the box locks up to make a switch to
> a text console I don't know if an Oops or similar is dumped to the
> console (there's nothing in the locks after a reboot) :-(

In a shell, do

sleep 10 ; /path-to-eclipse


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

Le 28.02.2006 23:30, Jesper Juhl a écrit :
> On 2/28/06, Jiri Slaby <slaby@liberouter.org> wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Jesper Juhl napsal(a):
>>
>>>Since I'm in X when the lockup happens and I don't have enough time
>>>from clicking the eclipse icon to the box locks up to make a switch to
>>>a text console I don't know if an Oops or similar is dumped to the
>>>console (there's nothing in the locks after a reboot) :-(
>>
>>So why don't just run eclipse from console (DISPLAY=... eclipse), or use atd,
>>crond... (less common variants)?
>>
>
>
> Good idea, thanks. Dunno why I didn't think of that.
>
> --
> Jesper Juhl <jesper.juhl@gmail.com>

I experienced similar symptoms while launching mozilla 1.7.12. I
found that java was the culprit.

Here is a full dmesg captured by netconsole with the following
scenario:
- boot to runlevel 1 (init 1)
- launch java (type "java[Enter]", no args).

The first oops is :
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000034
printing eip:
*pde = 00000000
Oops: 0002 [#1]
last sysfs file: /block/hdd/removable
Modules linked in: ide_cd cdrom loop aes dm_crypt nls_iso8859_1 nls_cp850 vfat fat reiser4 reiserfs raid1 md_mod via_agp agpgart video joydev usbhid ohci1394 ieee1394 uhci_hcd usbcore dm_mirror dm_mod
CPU: 0
EIP: 0060:[<c014fb8f>] Not tainted VLI
EFLAGS: 00010246 (2.6.16-rc5-mm1 #115)
EIP is at do_coredump+0x6a/0x592
eax: 00000034 ebx: 00000034 ecx: 00000000 edx: ffff0001
esi: dfab5000 edi: 0000000b ebp: dfab5ec4 esp: dfab5e44
ds: 007b es: 007b ss: 0068
Process java (pid: 1192, threadinfo=dfab5000 task=dfe17a90)
Stack: <0>dfab5fbc 0000000b 00000000 c03206a4 00000000 c0122643 dfab5eb0 c031e0c0
00000086 dca10988 dfe17f2c dca109b4 dfab5f34 dfab5e80 c011d8fc dfab5eac
c011dd14 00000000 0000000b 0000000b dca10988 00000000 0000000a dfab5000
Call Trace:
[<c0103a46>] show_stack_log_lvl+0xa0/0xab
[<c0103b7f>] show_registers+0x12e/0x194
[<c0103e5e>] die+0x14e/0x1db
[<c0111666>] do_page_fault+0x468/0x55f
[<c01034db>] error_code+0x4f/0x54
[<c011ea7d>] get_signal_to_deliver+0x32c/0x343
[<c0102361>] do_notify_resume+0x7f/0x636
[<c0102ab2>] work_notifysig+0x13/0x19
Code: 10 00 0f 84 3f 05 00 00 89 d3 b8 af 30 28 c0 ba 42 00 00 00 83 c3 34 e8 56 29 fc ff e8 6b ff 11 00 ba 01 00 ff ff 89 d8 8b 4d 88 <0f> c1 10 85 d2 0f 85 31 13 00 00 8a 81 54 01 00 00 24 03 75 15


Java version (java -version):
java version "1.5.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode, sharing)
This a binary downloaded from Sun.

glibc version (rpm -q glibc): glibc-2.3.5-6mdk

attached files:
- full dmesg
- .config file
~~
laurent

On 3/1/06, Andrew Morton <akpm@osdl.org> wrote:
> "Jesper Juhl" <jesper.juhl@gmail.com> wrote:
> >
> > Since I'm in X when the lockup happens and I don't have enough time
> > from clicking the eclipse icon to the box locks up to make a switch to
> > a text console I don't know if an Oops or similar is dumped to the
> > console (there's nothing in the locks after a reboot) :-(
>
> In a shell, do
>
> sleep 10 ; /path-to-eclipse
>

Yeah, I did (in a plain text console) :

export DISPLAY=:0.0 ; sleep 3 ; eclipse

then switched to tty0 and got the following - written down by hand so
I left out some bits, hope I got the important bits - a few things may
have scrolled off the top of the screen though..
If needed this is completely repproducible, so in a pinch I could
reboot with a higher fb resolution + write down every little bit by
hand, but I hope the following is enough :

EIP is at __wake_up_common+0x15/0x60
...
Process swapper (pid:0, threadinfo=c0454000 task=c03b9ae0)
Stack: ...
...
Call trace:
show_stack_log_lvl show_registers
die do_page_fault
error_code __wake_up
__wake_up_bit wake_up_bit
unlock_buffer end_buffer_read_sync
end_bio_bh_io_sync bio_endio
__end_that_request_first end_that_request_chunk
scsi_end_request scsi_io_completion
sd_rw_intr scsi_finish_command
scsi_softirq_done blk_done_softirq
__do_softirq do_softirq
==============
irq_exit do_IRQ
common_interrupt cpu_idle
rest_init start_kernel
0xc0100210
Code: ...
...
Kernel panic - not syncing: Fatal exception in interrupt
BUG: warning at arch/i386/kernel/smp.c:538/smp_call_function
show_trace dump_stack
smp_call_function smp_send_stop
panic die
do_page_fault error_code
__wake_up __wake_up_bit
wake_up_bit unlock_buffer
end_buffer_read_sync end_bio_bh_io_sync
bio_endio __end_that_request_first
end_that_request_chunk scsi_end_request
scsi_io_completion sd_rw_intr
scsi_finish_command scsi_softirq_done
blk_done_softirq __do_softirq
do_softirq
===========
irq_exit do_IRQ
common_interrupt cpu_idle
rest_init start_kernel
0xc0100210



--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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/

"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> On Tuesday 28 February 2006 13:24, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm1/
> >
> >
> > - A large procfs rework from Eric Biederman.
> >
> > - The swap prefetching patch is back.
>
> With this kernel something that causes the appended trace to appear happens on
> my box (Asus L5D, 1 CPU, x86-64) 100% of the time during boot.
>
> usbcore: registered new driver usbserial
> usbserial: USB Serial support registered for generic
> usbcore: registered new driver usbserial_generic
> usbserial: USB Serial Driver core
> BUG: warning at kernel/fork.c:113/__put_task_struct()
>
> Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
> <ffffffff80226f60>{__put_task_struct_cb+16} <ffffffff8023faa4>{__rcu_process_callbacks+340}
> <ffffffff8023fb47>{rcu_process_callbacks+23} <ffffffff80231fa8>{tasklet_action+72}
> <ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
> <ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
> <ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
> BUG: warning at kernel/fork.c:114/__put_task_struct()
>
> ...
> general protection fault: 0000 [1] PREEMPT
> last sysfs file: /class/vc/vcsa2/dev
> CPU 0
> Modules linked in: usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device af_packet p
> cmcia firmware_class ohci1394 ieee1394 yenta_socket rsrc_nonstatic pcmcia_core usbhid sk98lin snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
> pcm ip6t_REJECT xt_tcpudp snd_timer snd ipt_REJECT xt_state soundcore iptable_mangle snd_page_alloc iptable_nat ip_nat iptable_filter i2c_n
> force2 ip6table_mangle i2c_core ehci_hcd ohci_hcd ip_conntrack ip_tables ip6table_filter ip6_tables x_tables ipv6 parport_pc lp parport dm_
> mod
> Pid: 820, comm: kjournald Not tainted 2.6.16-rc5-mm1 #70
> RIP: 0010:[<ffffffff8046747c>] <ffffffff8046747c>{schedule+1164}
> RSP: 0000:ffff810001c53c38 EFLAGS: 00010007
> RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6b RCX: 949494959493a4ca
> RDX: ffff810027ce1050 RSI: 0000000000000000 RDI: ffff810027ce1050
> RBP: ffff810001c53c98 R08: ffff810001a83040 R09: 0000000000000009
> R10: 00000000ffffffff R11: 0000000000000001 R12: ffff81002c8de4c8
> R13: ffff81002fdf72f8 R14: ffff810001a83040 R15: 000000000000390b
> FS: 00002adb23959b00(0000) GS:ffffffff8068d000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 00002b5b92aa91de CR3: 0000000027329000 CR4: 00000000000006e0
> Process kjournald (pid: 820, threadinfo ffff810001c52000, task ffff81002fdf7090)
> Stack: ffff81002fdf7090 ffff810027ce1050 ffff810001c53d18 ffff810001f2af10
> ffff810001c53c78 ffff810001f2af10 ffff810001c53c78 ffff810001c53d08
> ffff810001c53d18 0000000000000002
> Call Trace: <ffffffff804676df>{io_schedule+15} <ffffffff8027efeb>{sync_buffer+59}
> <ffffffff80468015>{__wait_on_bit_lock+69} <ffffffff8027efb0>{sync_buffer+0}
> <ffffffff8027efb0>{sync_buffer+0} <ffffffff804680c8>{out_of_line_wait_on_bit_lock+120}
> <ffffffff80242690>{wake_bit_function+0} <ffffffff8027e574>{__lock_buffer+36}
> <ffffffff8027fdc1>{ll_rw_block+65} <ffffffff8030a3ab>{journal_commit_transaction+1659}
> <ffffffff804697d4>{_spin_unlock_irq+20} <ffffffff8046981d>{_spin_unlock_irqrestore+29}
> <ffffffff8030e5c3>{kjournald+339} <ffffffff80242520>{autoremove_wake_function+0}
> <ffffffff8030e470>{kjournald+0} <ffffffff80242309>{kthread+217}
> <ffffffff804697d4>{_spin_unlock_irq+20} <ffffffff80228929>{schedule_tail+73}
> <ffffffff8020a85e>{child_rip+8} <ffffffff80242230>{kthread+0}
> <ffffffff8020a856>{child_rip+0}

I'd be suspecting the /proc patches. Can you send the .config please?
-
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/

On Tue, 28 Feb 2006 21:48:50 +0100
Mattia Dongili <malattia@linux.it> wrote:

> in drives/Makefile the line
>
> obj-$(CONFIG_RTC_CLASS) += /rtc
>
> causes the missing symbols
> WARNING: /lib/modules/2.6.16-rc5-mm1-1/kernel/drivers/rtc/rtc-test.ko needs unknown symbol rtc_time_to_tm
> WARNING: /lib/modules/2.6.16-rc5-mm1-1/kernel/drivers/rtc/rtc-core.ko needs unknown symbol rtc_valid_tm
> WARNING: /lib/modules/2.6.16-rc5-mm1-1/kernel/drivers/rtc/rtc-sysfs.ko needs unknown symbol rtc_tm_to_tim
>
> when CONFIG_RTC_*=m. Maybe obj-y is nedded instead?


Hi,

thanks. It is now fixed as a side effect of another patch. I expect
to release the new version in a couple of days.

--

Best regards,

Alessandro Zummo,
Tower Technologies - Turin, Italy

http://www.towertech.it

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

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm1/

New panic on IBM power4 lpar of P690. 2.6.16-rc5-git3 is OK.

(config:
http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/power4)

http://test.kernel.org/24165/debug/console.log


STAFProc version 2.6.2 initialized
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA PSERIES LPAR
Modules linked in:
NIP: C000000000064748 LR: C000000000064764 CTR: C0000000000A8B10
REGS: c00000077dfaad30 TRAP: 0300 Not tainted (2.6.16-rc5-mm1-autokern1)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28000488 XER: 00000000
DAR: 0000000000000000, DSISR: 0000000040000000
TASK = c00000076a1ac720[11058] 'mingetty' THREAD: c00000077dfa8000 CPU: 1
GPR00: 0000000000000007 C00000077DFAAFB0 C000000000644F70 C00000076F303F08
GPR04: C00000076D478E00 0000000000000000 C00000076D478E00 0000000000000001
GPR08: 000000000000000A 0000000000000000 00000000000001AA C00000076F303F08
GPR12: 0000000048000442 C000000000548B80 0000000010060000 0000000010060000
GPR16: 0000000010060000 0000000010080000 0000000010080000 0000000010060000
GPR20: 0000000010010000 0000000000000001 0000000000000000 0000000000000001
GPR24: 0000000010003738 C00000077255F010 0000000000000001 0000000000000000
GPR28: 0000000000000007 0000000000000000 C00000000055F4A8 C0000000041F82A0
NIP [C000000000064748] .__rcu_process_callbacks+0x1fc/0x2f8
LR [C000000000064764] .__rcu_process_callbacks+0x218/0x2f8
Call Trace:
[C00000077DFAAFB0] [C000000000064764]
.__rcu_process_callbacks+0x218/0x2f8 (unreliable)
[C00000077DFAB040] [C000000000064874] .rcu_process_callbacks+0x30/0x58
[C00000077DFAB0C0] [C000000000053848] .tasklet_action+0xe4/0x19c
[C00000077DFAB160] [C000000000053EA8] .__do_softirq+0x9c/0x16c
[C00000077DFAB200] [C00000000000B6C8] .do_softirq+0x74/0xac
[C00000077DFAB280] [C000000000054388] .irq_exit+0x64/0x7c
[C00000077DFAB300] [C00000000001E0AC] .timer_interrupt+0x460/0x48c
[C00000077DFAB3E0] [C0000000000034DC] decrementer_common+0xdc/0x100
--- Exception: 901 at ._atomic_dec_and_lock+0x3c/0xb8
LR = .mntput_no_expire+0x30/0xcc
[C00000077DFAB6D0] [C0000007680CF438] 0xc0000007680cf438 (unreliable)
[C00000077DFAB750] [C0000000000CD6D0] .mntput_no_expire+0x30/0xcc
[C00000077DFAB7E0] [C0000000000B9F40] .path_release+0x44/0x5c
[C00000077DFAB870] [C0000000000ED840] .proc_pid_follow_link+0x34/0xf0
[C00000077DFAB900] [C0000000000BD01C] .__link_path_walk+0xe64/0x1394
[C00000077DFAB9E0] [C0000000000BD5DC] .link_path_walk+0x90/0x168
[C00000077DFABAE0] [C0000000000BDE28] .do_path_lookup+0x2fc/0x364
[C00000077DFABB90] [C0000000000BF4E0] .__user_walk_fd+0x68/0xa8
[C00000077DFABC30] [C0000000000B5578] .vfs_stat_fd+0x24/0x70
[C00000077DFABD30] [C0000000000B56BC] .sys_stat64+0x1c/0x50
[C00000077DFABE30] [C00000000000871C] syscall_exit+0x0/0x40
Instruction dump:
38000000 901d0080 e87f0040 2fa30000 419e00fc 7c6b1b78 3b800000 ebab0000
7d635b78 fbbf0040 60000000 e92b0008 <e8090000> f8410028 60000000 e9690010
<0>Kernel panic - not syncing: Fatal exception in interrupt
smp_call_function on cpu 1: other cpus not responding (1)
-- 0:conmux-control -- time-stamp -- Feb/28/06 5:08:52 --
-
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/

On 3/1/06, Laurent Riffard <laurent.riffard@free.fr> wrote:
> Le 28.02.2006 23:30, Jesper Juhl a écrit :
> > On 2/28/06, Jiri Slaby <slaby@liberouter.org> wrote:
> >
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>Hash: SHA1
> >>
> >>Jesper Juhl napsal(a):
> >>
> >>>Since I'm in X when the lockup happens and I don't have enough time
> >>>from clicking the eclipse icon to the box locks up to make a switch to
> >>>a text console I don't know if an Oops or similar is dumped to the
> >>>console (there's nothing in the locks after a reboot) :-(
> >>
> >>So why don't just run eclipse from console (DISPLAY=... eclipse), or use atd,
> >>crond... (less common variants)?
> >>
> >
> >
> > Good idea, thanks. Dunno why I didn't think of that.
> >
> > --
> > Jesper Juhl <jesper.juhl@gmail.com>
>
> I experienced similar symptoms while launching mozilla 1.7.12. I
> found that java was the culprit.
>

I can confirm that. I just tried visiting a website, that launches a
java applet, with Firefox 1.5.0.1 which resulted in an instant freeze.
So it seems anything Java is a good test case.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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/

Laurent Riffard <laurent.riffard@free.fr> wrote:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000034

I booted that thing on five machines, four architectures :(

Could people please test a couple more patchsets, see if we can isolate it?

http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.16-rc5-mm1.1.gz

is 2.6.16-rc5-mm1 minus:

proc-make-proc_numbuf-the-buffer-size-for-holding-a.patch
tref-implement-task-references.patch
proc-dont-lock-task_structs-indefinitely.patch
proc-dont-lock-task_structs-indefinitely-git-nfs-fix.patch
proc-dont-lock-task_structs-indefinitely-cpuset-fix.patch
proc-optimize-proc_check_dentry_visible.patch

and http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.16-rc5-mm1.2.gz is
2.6.16-rc5-mm1 minus:

trivial-cleanup-to-proc_check_chroot.patch
proc-fix-the-inode-number-on-proc-pid-fd.patch
proc-remove-useless-bkl-in-proc_pid_readlink.patch
proc-remove-unnecessary-and-misleading-assignments.patch
proc-simplify-the-ownership-rules-for-proc.patch
proc-replace-proc_inodetype-with-proc_inodefd.patch
proc-remove-bogus-proc_task_permission.patch
proc-kill-proc_mem_inode_operations.patch
proc-properly-filter-out-files-that-are-not-visible.patch
proc-fix-the-link-count-for-proc-pid-task.patch
proc-move-proc_maps_operations-into-task_mmuc.patch
dcache-add-helper-d_hash_and_lookup.patch
proc-rewrite-the-proc-dentry-flush-on-exit.patch
proc-close-the-race-of-a-process-dying-durning.patch
proc-refactor-reading-directories-of-tasks.patch
#
proc-make-proc_numbuf-the-buffer-size-for-holding-a.patch
tref-implement-task-references.patch
proc-dont-lock-task_structs-indefinitely.patch
proc-dont-lock-task_structs-indefinitely-git-nfs-fix.patch
proc-dont-lock-task_structs-indefinitely-cpuset-fix.patch
proc-optimize-proc_check_dentry_visible.patch


Thanks.
-
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/

On 3/1/06, Andrew Morton <akpm@osdl.org> wrote:
> Laurent Riffard <laurent.riffard@free.fr> wrote:
> >
> > BUG: unable to handle kernel NULL pointer dereference at virtual address 00000034
>
> I booted that thing on five machines, four architectures :(
>
> Could people please test a couple more patchsets, see if we can isolate it?
>
Sure, no problem. But it'll have to wait until tomorrow evening for me
- I have to get some sleep now or I won't ever be able to get up and
get to work tomorrow... But I'll test those as soon as I get home
tomorrow.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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/

Andrew Morton <akpm@osdl.org> writes:

> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>>
>> On Tuesday 28 February 2006 13:24, Andrew Morton wrote:
>>
>> usbcore: registered new driver usbserial
>> usbserial: USB Serial support registered for generic
>> usbcore: registered new driver usbserial_generic
>> usbserial: USB Serial Driver core
>> BUG: warning at kernel/fork.c:113/__put_task_struct()
>>
>> Call Trace: <IRQ> <ffffffff80229c2b>{__put_task_struct+59}
>> <ffffffff80226f60>{__put_task_struct_cb+16}
> <ffffffff8023faa4>{__rcu_process_callbacks+340}
>> <ffffffff8023fb47>{rcu_process_callbacks+23}
> <ffffffff80231fa8>{tasklet_action+72}
>> <ffffffff802322e4>{__do_softirq+84} <ffffffff8020abae>{call_softirq+30}
>> <ffffffff8020c7d4>{do_softirq+52} <ffffffff8023215f>{irq_exit+63}
>> <ffffffff8020c781>{do_IRQ+65} <ffffffff8020a232>{ret_from_intr+0} <EOI>
>> BUG: warning at kernel/fork.c:114/__put_task_struct()
>>
>> ...
> I'd be suspecting the /proc patches. Can you send the .config please?

Yes this does feel like something got the reference counting of task structures
incorrect. And I touched a lot of reference counting. I will look into this
and see if I can find a culprit.


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

Michal Piotrowski wrote:
> On 28/02/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
>
>>Hi,
>>
>>On 28/02/06, Andrew Morton <akpm@osdl.org> wrote:
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm1/
>>>
>>>
>>>- A large procfs rework from Eric Biederman.
>>>
>>>- The swap prefetching patch is back.
>>>
>>
>>[snip]
>>
>>>+inotify-lock-avoidance-with-parent-watch-status-in-dentry.patch
>>>+inotify-lock-avoidance-with-parent-watch-status-in-dentry-fix.patch
>>
>>I have noticed this:
>>Feb 28 15:13:42 ltg01-sid kernel: BUG: warning at
>>/usr/src/linux-mm/fs/inotify.c:533/inotify_d_instantiate()
>>Feb 28 15:13:42 ltg01-sid kernel: [show_trace+13/15] show_trace+0xd/0xf
>>Feb 28 15:13:42 ltg01-sid kernel: [dump_stack+21/23] dump_stack+0x15/0x17
>>Feb 28 15:13:42 ltg01-sid kernel: [inotify_d_instantiate+47/98]
>>inotify_d_instantiate+0x2f/0x62
>>Feb 28 15:13:42 ltg01-sid kernel: [d_instantiate+70/114]
>>d_instantiate+0x46/0x72
>>Feb 28 15:13:42 ltg01-sid kernel: [ext3_add_nondir+44/64]
>>ext3_add_nondir+0x2c/0x40
>>Feb 28 15:13:42 ltg01-sid kernel: [ext3_link+163/217] ext3_link+0xa3/0xd9
>>Feb 28 15:13:42 ltg01-sid kernel: [vfs_link+292/379] vfs_link+0x124/0x17b
>>Feb 28 15:13:42 ltg01-sid kernel: [sys_linkat+157/218] sys_linkat+0x9d/0xda
>>Feb 28 15:13:42 ltg01-sid kernel: [sys_link+20/25] sys_link+0x14/0x19
>>Feb 28 15:13:42 ltg01-sid kernel: [syscall_call+7/11] syscall_call+0x7/0xb
>>
>>Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-dmesg
>>Here is config http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-config
>
>
> This patch is causing that warning
> inotify-lock-avoidance-with-parent-watch-status-in-dentry.patch
>

The warning is harmless really. I guess it can be removed.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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/

Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> >>Feb 28 15:13:42 ltg01-sid kernel: BUG: warning at
> >>/usr/src/linux-mm/fs/inotify.c:533/inotify_d_instantiate()
> >>Feb 28 15:13:42 ltg01-sid kernel: [show_trace+13/15] show_trace+0xd/0xf
> >>Feb 28 15:13:42 ltg01-sid kernel: [dump_stack+21/23] dump_stack+0x15/0x17
> >>Feb 28 15:13:42 ltg01-sid kernel: [inotify_d_instantiate+47/98]
> >>inotify_d_instantiate+0x2f/0x62
> >>Feb 28 15:13:42 ltg01-sid kernel: [d_instantiate+70/114]
> >>d_instantiate+0x46/0x72
> >>Feb 28 15:13:42 ltg01-sid kernel: [ext3_add_nondir+44/64]
> >>ext3_add_nondir+0x2c/0x40
> >>Feb 28 15:13:42 ltg01-sid kernel: [ext3_link+163/217] ext3_link+0xa3/0xd9
> >>Feb 28 15:13:42 ltg01-sid kernel: [vfs_link+292/379] vfs_link+0x124/0x17b
> >>Feb 28 15:13:42 ltg01-sid kernel: [sys_linkat+157/218] sys_linkat+0x9d/0xda
> >>Feb 28 15:13:42 ltg01-sid kernel: [sys_link+20/25] sys_link+0x14/0x19
> >>Feb 28 15:13:42 ltg01-sid kernel: [syscall_call+7/11] syscall_call+0x7/0xb
> >>
> >>Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-dmesg
> >>Here is config http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-config
> >
> >
> > This patch is causing that warning
> > inotify-lock-avoidance-with-parent-watch-status-in-dentry.patch
> >
>
> The warning is harmless really. I guess it can be removed.

? How did DCACHE_INOTIFY_PARENT_WATCHED get set on that dentry?
-
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/

I have popped the patch stack back to including:
> trivial-cleanup-to-proc_check_chroot.patch
> proc-fix-the-inode-number-on-proc-pid-fd.patch

but not past that. It boots now, unlike before with the full patch
stack.

I will continue the hunt.

Meanwhile, on the side, I have a couple of permission problems to
report to Eric Biederman with apps that are complaining about not being
able to access /proc/<pid>/fd/[0-9]* files when before they could:

1) Logged in as root, running "/bin/ls -l /proc/*/fd/*"
causes some complaints. For example:

# /bin/ls -l /proc/2868/fd/?
/bin/ls: cannot read symbolic link /proc/2868/fd/6: Permission denied
/bin/ls: cannot read symbolic link /proc/2868/fd/7: Permission denied
lr-x------ 1 root root 64 Feb 28 18:39 /proc/2868/fd/0 -> /dev/null
lrwx------ 1 root root 64 Feb 28 18:39 /proc/2868/fd/1 -> /dev/pts/10
lrwx------ 1 root root 64 Feb 28 18:39 /proc/2868/fd/2 -> /dev/pts/10
lr-x------ 1 root root 64 Feb 28 18:39 /proc/2868/fd/3 -> /proc/sal/cmc/event
lrwx------ 1 root root 64 Feb 28 18:39 /proc/2868/fd/4 -> /proc/sal/cmc/data
l-wx------ 1 root root 64 Feb 28 18:39 /proc/2868/fd/6
lr-x------ 1 root root 64 Feb 28 18:39 /proc/2868/fd/7

I don't recall seeing any similar complaints before. My first reaction
is "wtf - I'm root - what's this permission denied error ?!?"

2) I have an SGI specific application that runs out of init on boot
that spews out some 50 or so "Permission denied" errors on
various /proc/<pid>/fd/* files, which it never did before that
I can recall.

For example, this app complained:

Cannot stat file /proc/1688/fd/3: Permission denied
Cannot stat file /proc/1688/fd/4: Permission denied
Cannot stat file /proc/1688/fd/5: Permission denied
Cannot stat file /proc/1688/fd/6: Permission denied
Cannot stat file /proc/1688/fd/7: Permission denied
Cannot stat file /proc/2781/fd/3: Permission denied
Cannot stat file /proc/2802/fd/1: Permission denied
Cannot stat file /proc/2802/fd/3: Permission denied
Cannot stat file /proc/2802/fd/4: Permission denied
Cannot stat file /proc/2878/fd/6: Permission denied
Cannot stat file /proc/2878/fd/7: Permission denied

You can see it is not complaining about all the fd's of a task,
but just some.

I might be confused in what patches I'm running, but I believe that
I am getting these permission denied errors with just the patches:

> trivial-cleanup-to-proc_check_chroot.patch
> proc-fix-the-inode-number-on-proc-pid-fd.patch

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
-
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/

Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>>>>Feb 28 15:13:42 ltg01-sid kernel: BUG: warning at
>>>>/usr/src/linux-mm/fs/inotify.c:533/inotify_d_instantiate()
>>>>Feb 28 15:13:42 ltg01-sid kernel: [show_trace+13/15] show_trace+0xd/0xf
>>>>Feb 28 15:13:42 ltg01-sid kernel: [dump_stack+21/23] dump_stack+0x15/0x17
>>>>Feb 28 15:13:42 ltg01-sid kernel: [inotify_d_instantiate+47/98]
>>>>inotify_d_instantiate+0x2f/0x62
>>>>Feb 28 15:13:42 ltg01-sid kernel: [d_instantiate+70/114]
>>>>d_instantiate+0x46/0x72
>>>>Feb 28 15:13:42 ltg01-sid kernel: [ext3_add_nondir+44/64]
>>>>ext3_add_nondir+0x2c/0x40
>>>>Feb 28 15:13:42 ltg01-sid kernel: [ext3_link+163/217] ext3_link+0xa3/0xd9
>>>>Feb 28 15:13:42 ltg01-sid kernel: [vfs_link+292/379] vfs_link+0x124/0x17b
>>>>Feb 28 15:13:42 ltg01-sid kernel: [sys_linkat+157/218] sys_linkat+0x9d/0xda
>>>>Feb 28 15:13:42 ltg01-sid kernel: [sys_link+20/25] sys_link+0x14/0x19
>>>>Feb 28 15:13:42 ltg01-sid kernel: [syscall_call+7/11] syscall_call+0x7/0xb
>>>>
>>>>Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-dmesg
>>>>Here is config http://www.stardust.webpages.pl/files/mm/2.6.16-rc5-mm1/mm-config
>>>
>>>
>>>This patch is causing that warning
>>>inotify-lock-avoidance-with-parent-watch-status-in-dentry.patch
>>>
>>
>>The warning is harmless really. I guess it can be removed.
>
>
> ? How did DCACHE_INOTIFY_PARENT_WATCHED get set on that dentry?
>

I guess it is because I don't clear it on +ve => -ve conversions.
We _could_ do that AFAIKS, by hooking into d_delete, but it would
have to be yet another fsnotify hook there because it will have to
be done under lock.

But there is no real gain in doing that.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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/