"Rafael J. Wysocki" <[email protected]> wrote:
>
> On Wednesday, 27 of April 2005 12:19, Andrew Morton wrote:
> > "Rafael J. Wysocki" <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > I'm having a problem with 2.6.12-rc3 and the Java VM (from SuSE 9.2)
> > > on AMD64. Namely, after trying to open a web page containing a Java
> > > applet, my browser starts a java process that takes almost 100% of the CPU
> > > (system load, according to gkrellm) and cannot be killed (even by root,
> > > although it executes with a non-root UID). Apparently, it is in TASK_RUNNING
> > > (according to ps).
> > >
> > > The problem is 100% reproducible (it is enough to visit
> > > http://java.sun.com/docs/books/tutorial/getStarted/index.html to trigger it)
> > > and it does not depend on the web browser used.
> > >
> > > The Java JRE version is:
> > >
> > > java version "1.4.2_06"
> > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> > > Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
> > >
> > > (I guess it's 32-bit, but I'm not quite sure) and I've installed it from the
> > > SuSE 9.2 RPM.
> > >
> > > It really is a show stopper to me, so please advise.
> >
> > Where is it running?
> >
> > You can tell this from a kernel profile, or by using sysrq-P five or ten
> > times then looking at the output.
>
> >From sysrq-P, I get this:
>
> Pid: 11073, comm: java Not tainted 2.6.12-rc3
> RIP: 0010:[<ffffffff8010f675>] <ffffffff8010f675>{retint_signal+20}
> RSP: 0018:ffff810012d6ff58 EFLAGS: 00000282
> RAX: 0000000000020000 RBX: ffff810010868820 RCX: ffff810012d6e000
> RDX: 0000000000020000 RSI: 0000000000000000 RDI: ffff810012d6ff58
> RBP: 000000a30c153a4a R08: ffff810012d6e000 R09: ffffffff804c6068
> R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff804ccd40
> R13: ffff810010868820 R14: ffff81002cff2cf0 R15: ffffffff8010d3a7
> FS: 00002aaaae6389c0(0000) GS:ffffffff8054a600(0063) knlGS:00000000556c9080
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: 00002aaaaabab000 CR3: 0000000012930000 CR4: 00000000000006e0
>
> Call Trace:<ffffffff8010f697>{retint_signal+54}
>
> all the time.
All the time? Exactly the same? If you could do something crude like hit
sysrq-P 100 times then do `dmesg|grep RIP' we could possibly determine
whether things are indeed stuck in that potential infinite loop in there.
I assume you're using CONFIG_PREEMPT?
It'd be interesting to know the interrupt rate and context switch rate
which this is going on.
> I've also found out that in fact the problem is not 100% reproducible, but it is much
> more likely to be reproduced if the CPU is heavily loaded.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
