Re: unexplained high load

Re: unexplained high load

[Hacksaw]

Ahh, a D state.

D means disk wait, which the only thing that can postpone a -9. Basic, the 
process is stuck in a loop inside a routine that needs to be atomic.

You'll have to reboot to clear it. I believe this is a kernel bug. Try going 
back to 2.2.14, or maybe up to 2.2.19pre2.


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

Re: unexplained high load

[David S. Miller]

   Date: 	Wed, 10 Jan 2001 16:36:14 -0500
   From: Hacksaw <hacksaw@hacksaw.org>

   You'll have to reboot to clear it. I believe this is a kernel
   bug. Try going back to 2.2.14, or maybe up to 2.2.19pre2.

He needs to go up if anything.  His sparc64 OOPS had strings in the
kernel stack, which is indicative of a sparc64 specific bug I only
fixed very late in the 2.2.18 patches.

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: unexplained high load

[kernel]

On Wed, 10 Jan 2001, Hacksaw wrote:

> Ahh, a D state.
>
> D means disk wait, which the only thing that can postpone a -9. Basic, the
> process is stuck in a loop inside a routine that needs to be atomic.
looked at the dir created with the last ftp login
and found :

.nfs0000000000ca402500000006

so i think there is some lock from the nfs server or client

will try to restart nfs client
and see if this fixes it.

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

Re: unexplained high load

[kernel]

On Wed, 10 Jan 2001, David S. Miller wrote:

>    Date: 	Wed, 10 Jan 2001 16:36:14 -0500
>    From: Hacksaw <hacksaw@hacksaw.org>
>
>    You'll have to reboot to clear it. I believe this is a kernel
>    bug. Try going back to 2.2.14, or maybe up to 2.2.19pre2.
>
> He needs to go up if anything.  His sparc64 OOPS had strings in the
> kernel stack, which is indicative of a sparc64 specific bug I only
> fixed very late in the 2.2.18 patches.
don't think i want 2.2.14 (which had some security bugs i remember)
so i should move up i think
before i go download and compile the latest 2.2.19pre7 (latest pre
version)
and reboot:

are there any bugs at the moment for sparc64 ?
and should i wait for the finale 2.2.19 ?
(don't think i can go download and use 2.4.0 since machine is still based
on redhat 6.1)


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

Re: unexplained high load

[Hacksaw]

> .nfs0000000000ca402500000006
> 
> so i think there is some lock from the nfs server or client
> 
> will try to restart nfs client
> and see if this fixes it.
> 

Most likely you will have to restart the nfs server on the other side as well, 
but it's worth a try.

Tripwire watches the checksum of the binaries you deem important, and 
complains if they change. There are a few things like it.

See http://freshmeat.net/search/?q=tripwire



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

Re: unexplained high load

[kernel]

On Wed, 10 Jan 2001 kernel@ddx.a2000.nu wrote:
> so i think there is some lock from the nfs server or client
>
> will try to restart nfs client
> and see if this fixes it.
didn't fix it
(file is gone now)

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

Re: unexplained high load

[kernel]

On Wed, 10 Jan 2001, Hacksaw wrote:

> > .nfs0000000000ca402500000006
> >
> > so i think there is some lock from the nfs server or client
> >
> > will try to restart nfs client
> > and see if this fixes it.
> >
>
> Most likely you will have to restart the nfs server on the other side as well,
> but it's worth a try.
tried it, didn't fix it
so i'll have to upgrade kernel and reboot
will do this this weekend, think the box can survive a few days (it has
112 days uptime now)

>
> Tripwire watches the checksum of the binaries you deem important, and
> complains if they change. There are a few things like it.
ah ok
have heard about it yeah

>
> See http://freshmeat.net/search/?q=tripwire
>
>
>

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

Re: unexplained high load

[Bob Lorenzini]

On Wed, 10 Jan 2001, Hacksaw wrote:

> Ahh, a D state.
> 
> D means disk wait, which the only thing that can postpone a -9. Basic, the 
> process is stuck in a loop inside a routine that needs to be atomic.
> 
> You'll have to reboot to clear it. I believe this is a kernel bug. Try going 
> back to 2.2.14, or maybe up to 2.2.19pre2.

FYI at this moment I have a failing scsi tape format on a machine (2.2.18)
that has the same symtom (hung in D state, load=1).

Bob 










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

Re: unexplained high load

[Bernd Eckenfels]

In article <Pine.LNX.4.30.0101102159470.4377-100000@ddx.a2000.nu> you wrote:
> 91 processes, only 1 running (think top)

1 Running Process -> Load 1.0... no?

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

Re: unexplained high load

[kernel]

On Wed, 10 Jan 2001, Hacksaw wrote:

> >don't think
> >w,uptime,top give the same value
>
> The fact that they all give the same value does not indicate that you have not
> been cracked. Obviously, part of the hacking is to cover trails; it'd be a
> pretty poor job if they reported different values.
i also checked the files, they are not replaced last few months

>
> The mm stuff from your other message is, I think, an indication that you might
> be being hit by a memory management bug that was corrected in 2.2.19pre2.
>
> It is my sincere belief that you will need to upgrade your kernel, but
> you are in no serious danger.
ok so i'll have to upgrade
2.2.19pre7 is the latest i saw, is this one running stable ?
or should i better wait some time
(the 1.00 load doesn't really botter me, if i don't get any other errors
because of this bug)


>
> If it's a firewall box, you should be running tripwire or some free variation,
> to help eliminate the possibility that cracking would go undetected.
it's my homebox, connected to a cable modem
so it's not mission critical

what exactly is that tripwire you talk about ?
(never heard of it)

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

Re: unexplained high load

[Hacksaw]

>don't think
>w,uptime,top give the same value

The fact that they all give the same value does not indicate that you have not 
been cracked. Obviously, part of the hacking is to cover trails; it'd be a 
pretty poor job if they reported different values.

The mm stuff from your other message is, I think, an indication that you might 
be being hit by a memory management bug that was corrected in 2.2.19pre2.

It is my sincere belief that you will need to upgrade your kernel, but you are 
in no serious danger.

If it's a firewall box, you should be running tripwire or some free variation, 
to help eliminate the possibility that cracking would go undetected.


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

Re: unexplained high load

[kernel]

On 10 Jan 2001, Doug McNaught wrote:

> <kernel@ddx.a2000.nu> writes:
>
> > think this, but problem, machine is running ok
> > no slow response, only load 1.00 (it's not getting lower)
>
> Process stuck in D state?
yes found it, proftpd
can't kill it (also tried -9)
why is this giving me a high load ?



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

Re: unexplained high load

[kernel]

detected this in kernel log :

Jan 10 00:34:15 ddx kernel: Unable to handle kernel paging request in mna
handler<1> at virtual address f7d93ef869a1610c
Jan 10 00:34:15 ddx kernel: current->mm->context = 0000000000000639
Jan 10 00:34:15 ddx kernel: current->mm->pgd = fffff8000c0d2000
Jan 10 00:34:15 ddx kernel:               \|/ ____ \|/
Jan 10 00:34:15 ddx kernel:               "@'/ .. \`@"
Jan 10 00:34:15 ddx kernel:               /_| \__/ |_\
Jan 10 00:34:15 ddx kernel:                  \__U_/
Jan 10 00:34:15 ddx kernel: proftpd(27129): Oops
Jan 10 00:34:15 ddx kernel: TSTATE: 0000000080009602 TPC: 000000000044f8ac
TNPC: 000000000044f8b0 Y: 00000000
Jan 10 00:34:15 ddx kernel: g0: 0000000000000000 g1: 0000000000000001 g2:
0000000000c34000 g3: ffffffffffffe000
Jan 10 00:34:15 ddx kernel: g4: fffff80000000000 g5: 0000000000000000 g6:
fffff8000d8b8000 g7: 0000000000000001
Jan 10 00:34:15 ddx kernel: o0: f7d93ef869a16104 o1: 0000000000000104 o2:
0000000000358d60 o3: fffff80000334000
Jan 10 00:34:15 ddx kernel: o4: fffff8001fe00000 o5: fffff8001fe77c68 sp:
fffff8000d8bb491 ret_pc: 000000000044f828
Jan 10 00:34:15 ddx kernel: l0: fffff8000068cd60 l1: 0000000000000346 l2:
fffff80019d2e600 l3: 0000000000000000
Jan 10 00:34:15 ddx kernel: l4: fffff800156bc000 l5: 0000000000c34000 l6:
fffff8000068cde0 l7: 000000000000026e
Jan 10 00:34:15 ddx kernel: i0: 000000000000026e i1: 0000000070228286 i2:
0000000000000346 i3: 0000000000605c00
Jan 10 00:34:15 ddx kernel: i4: fffff8001fc8b9e0 i5: 0000000000605c00 i6:
fffff8000d8bb561 i7: 000000000049b7ec
Jan 10 00:34:15 ddx kernel: Caller[000000000049b7ec]
Jan 10 00:34:15 ddx kernel: Caller[000000000045954c]
Jan 10 00:34:15 ddx kernel: Caller[0000000000410114]
Jan 10 00:34:15 ddx kernel: Caller[0000000000022bb0]
Jan 10 00:34:15 ddx kernel: Instruction DUMP: d05ca0e0  02c20003  d072c00a
<e0722008> e074a0e0  d05f6100  90022001  d0776100  d25b40



On Wed, 10 Jan 2001 kernel@ddx.a2000.nu wrote:

> On Wed, 10 Jan 2001, Hacksaw wrote:
>
> > > Could someone maybe explain this ?
> > > (top output, but same load is given with 'uptime')
> > > there is no cpu or disk activity
> > > kernel is 2.2.18pre9 on sun ultra10-300 (ultrasparc IIi)
> > >
> > >    9:25pm  up 112 days,  1:52,  1 user,  load average: 1.24, 1.05, 1.02
> > >  91 processes: 90 sleeping, 1 running, 0 zombie, 0 stopped
> > >  CPU states:  2.5% user,  2.3% system,  0.0% nice, 95.1% idle
> > >  Mem:  515144K av, 506752K used,   8392K free,  73464K shrd,  58472K buff
> > >  Swap: 131528K av,  15968K used, 115560K free                358904K cached
> >
> > You have no processes??? My gosh, that is a problem. :-)
> 91 processes, only 1 running (think top)
>
> >
> > The load average is how many processes are runnable, therefore you have
> > runnable processes.
> >
> > If you have Netscape or Mozilla running on your box, it may be in a
> > permanently runnable state.
> it's a firewall/gateway/mail box, so no X or netscape
>
> > Another amusing possibility is that you have a hacked box, and top is
> > reporting the stupid IRC bot that is running, but not showing you the actuall
> > process, because it too is hacked.
> don't think
> w,uptime,top give the same value
>
> >
> > Replace ps and top, and have a look. Don't believe ls, either.
> >
> > If none of these things are true, you might have another problem.
> think this, but problem, machine is running ok
> no slow response, only load 1.00 (it's not getting lower)
>
>

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

Re: unexplained high load

[Doug McNaught]

<kernel@ddx.a2000.nu> writes:

> think this, but problem, machine is running ok
> no slow response, only load 1.00 (it's not getting lower)

Process stuck in D state?

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

Re: unexplained high load

[kernel]

On Wed, 10 Jan 2001, Hacksaw wrote:

> > Could someone maybe explain this ?
> > (top output, but same load is given with 'uptime')
> > there is no cpu or disk activity
> > kernel is 2.2.18pre9 on sun ultra10-300 (ultrasparc IIi)
> >
> >    9:25pm  up 112 days,  1:52,  1 user,  load average: 1.24, 1.05, 1.02
> >  91 processes: 90 sleeping, 1 running, 0 zombie, 0 stopped
> >  CPU states:  2.5% user,  2.3% system,  0.0% nice, 95.1% idle
> >  Mem:  515144K av, 506752K used,   8392K free,  73464K shrd,  58472K buff
> >  Swap: 131528K av,  15968K used, 115560K free                358904K cached
>
> You have no processes??? My gosh, that is a problem. :-)
91 processes, only 1 running (think top)

>
> The load average is how many processes are runnable, therefore you have
> runnable processes.
>
> If you have Netscape or Mozilla running on your box, it may be in a
> permanently runnable state.
it's a firewall/gateway/mail box, so no X or netscape

> Another amusing possibility is that you have a hacked box, and top is
> reporting the stupid IRC bot that is running, but not showing you the actuall
> process, because it too is hacked.
don't think
w,uptime,top give the same value

>
> Replace ps and top, and have a look. Don't believe ls, either.
>
> If none of these things are true, you might have another problem.
think this, but problem, machine is running ok
no slow response, only load 1.00 (it's not getting lower)

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

Re: unexplained high load

[Hacksaw]

> Could someone maybe explain this ?
> (top output, but same load is given with 'uptime')
> there is no cpu or disk activity
> kernel is 2.2.18pre9 on sun ultra10-300 (ultrasparc IIi)
> 
>    9:25pm  up 112 days,  1:52,  1 user,  load average: 1.24, 1.05, 1.02
>  91 processes: 90 sleeping, 1 running, 0 zombie, 0 stopped
>  CPU states:  2.5% user,  2.3% system,  0.0% nice, 95.1% idle
>  Mem:  515144K av, 506752K used,   8392K free,  73464K shrd,  58472K buff
>  Swap: 131528K av,  15968K used, 115560K free                358904K cached

You have no processes??? My gosh, that is a problem. :-)

The load average is how many processes are runnable, therefore you have 
runnable processes.

If you have Netscape or Mozilla running on your box, it may be in a 
permanently runnable state.

Another amusing possibility is that you have a hacked box, and top is 
reporting the stupid IRC bot that is running, but not showing you the actuall 
process, because it too is hacked.

Replace ps and top, and have a look. Don't believe ls, either. 

If none of these things are true, you might have another problem.



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

unexplained high load

[kernel]

Could someone maybe explain this ?
(top output, but same load is given with 'uptime')
there is no cpu or disk activity
kernel is 2.2.18pre9 on sun ultra10-300 (ultrasparc IIi)

   9:25pm  up 112 days,  1:52,  1 user,  load average: 1.24, 1.05, 1.02
 91 processes: 90 sleeping, 1 running, 0 zombie, 0 stopped
 CPU states:  2.5% user,  2.3% system,  0.0% nice, 95.1% idle
 Mem:  515144K av, 506752K used,   8392K free,  73464K shrd,  58472K buff
 Swap: 131528K av,  15968K used, 115560K free                358904K cached



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