In article <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Please read the FAQ at
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
On Wed, 10 Jan 2001, Hacksaw wrote:
> > .nfs00ca40250006
> >
> > 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,
>
On Wed, 10 Jan 2001 [EMAIL PROTECTED] 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
> .nfs00ca40250006
>
> 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
On Wed, 10 Jan 2001, David S. Miller wrote:
>Date: Wed, 10 Jan 2001 16:36:14 -0500
>From: Hacksaw <[EMAIL PROTECTED]>
>
>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
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 :
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
Date:Wed, 10 Jan 2001 16:36:14 -0500
From: Hacksaw <[EMAIL PROTECTED]>
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,
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
>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,
On 10 Jan 2001, Doug McNaught wrote:
> <[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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 = 0639
Jan 10 00:34:15 ddx kernel: current->mm->pgd = f8000c0d2000
Jan 10
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,
> 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
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,
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,
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
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
detected this in kernel log :
Jan 10 00:34:15 ddx kernel: Unable to handle kernel paging request in mna
handler1 at virtual address f7d93ef869a1610c
Jan 10 00:34:15 ddx kernel: current-mm-context = 0639
Jan 10 00:34:15 ddx kernel: current-mm-pgd = f8000c0d2000
Jan 10 00:34:15 ddx
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Please
On 10 Jan 2001, Doug McNaught wrote:
[EMAIL PROTECTED] 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 ?
-
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
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
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
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 :
.nfs00ca40250006
On Wed, 10 Jan 2001 [EMAIL PROTECTED] 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
.nfs00ca40250006
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
On Wed, 10 Jan 2001, Hacksaw wrote:
.nfs00ca40250006
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
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
In article [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Please read the FAQ at
Date:Wed, 10 Jan 2001 16:36:14 -0500
From: Hacksaw [EMAIL PROTECTED]
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,
On Wed, 10 Jan 2001, David S. Miller wrote:
Date: Wed, 10 Jan 2001 16:36:14 -0500
From: Hacksaw [EMAIL PROTECTED]
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
34 matches
Mail list logo
