netbsd-4 - ps acting funny ?

Hi *,

I am just testing netbsd-4 (around 200707280600UTC).

ps alxww seem be be a bit funny: most of the times it lists
0:00.00 as time - sometime it lists something plausible.

Anyone else seeing this behavior ?

Frank

Hi,

now that I look at it -current (about twoo weeks ago) shows
the same
symptoms.
Sensible time output seem state dependent. Runnanble or
Stopped
processes show time value that match my expectations more.

Frank

Frank Kardel wrote:

> Hi *,
>
> I am just testing netbsd-4 (around 200707280600UTC).
>
> ps alxww seem be be a bit funny: most of the times it
lists
> 0:00.00 as time - sometime it lists something
plausible.
>
> Anyone else seeing this behavior ?
>
> Frank

2007/7/28, Frank Kardel <kardelnetbsd.org>:
> Hi *,
>
> I am just testing netbsd-4 (around 200707280600UTC).
>
> ps alxww seem be be a bit funny: most of the times it
lists
> 0:00.00 as time - sometime it lists something
plausible.
>
> Anyone else seeing this behavior ?
>
> Frank
>

Somebody else already noticed this a while ago, but I can't
remember who it was.

Zafer Aydogan wrote:
> 2007/7/28, Frank Kardel <kardelnetbsd.org>:
>   
>> Hi *,
>>
>> I am just testing netbsd-4 (around
200707280600UTC).
>>
>> ps alxww seem be be a bit funny: most of the times
it lists
>> 0:00.00 as time - sometime it lists something
plausible.
>>
>> Anyone else seeing this behavior ?
>>
>> Frank
>>
>>     
>
> Somebody else already noticed this a while ago, but I
can't remember who it was.
>   
Since it seems I am not seeing any ghosts - I'd deem that ps
behavior  a 
bug. Thanks for saving me from
digging through the archives.

Found it: PR bin/36295 by Henry Bent.

Frank

On Saturday 28 July 2007 14:24:56 you wrote:
> Hi,
>
> now that I look at it -current (about twoo weeks ago)
shows the same
> symptoms.
> Sensible time output seem state dependent. Runnanble or
Stopped
> processes show time value that match my expectations
more.
>
> Frank
>
> Frank Kardel wrote:
> > Hi *,
> >
> > I am just testing netbsd-4 (around
200707280600UTC).
> >
> > ps alxww seem be be a bit funny: most of the times
it lists
> > 0:00.00 as time - sometime it lists something
plausible.
> >
> > Anyone else seeing this behavior ?
> >
> > Frank

Frank, 
See my post into netbsd-users on 9th July and later to
tech-userlevel.  I 
haven't tracked down the issue yet but am wondering if its a
toolchain 
problem as a ps binary with the same components (from
ident)
from January 2007 seemed to report everything Ok and matched
the output of 
top.

Regards
Dave

-- 
============================================================
=========
Phone: 07772420022
WWW:   http://www.liv.ac.uk/~dt
yson
Open Source O/S: www.netbsd.org
Caving: http://www.wir
ralcavinggroup.uk.eu.org
============================================================
=========

On Sat, Jul 28, 2007 at 03:56:40PM +0000, Michael van Elst
wrote:
> kardelNetBSD.org (Frank Kardel) writes:
> 
> >Sensible time output seem state dependent.
Runnanble or Stopped
> >processes show time value that match my
expectations more.
> 
> The p_stat of a sleeping process is seen as SDYING (3)
because
> the kvm interface overwrites the value with l_stat ==
LSSLEEP (3).
> 
> A 'dying' process has no valid cputime, thus ps prints
0.

This is all fubar... 

When lwps were added (in the nathanw_sa branch) the 'process
state'
needed by ps, had to come from the first/only/random lwp
(since
processes no longer have running/sleeping states). So
fill_kproc2()
got changed to do 'ki->p_stat = l->l_stat', since the
values for
process and lwp status matched this didn't matter.

This all appeared to work until a new 'p->p_stat' flag
SDYING got
added reusing one of the old values (instead of reusing the
value
that used to be SDEAD).

This wouldn't be a problem except that:
1) SDYING also got added to the P_ZOMBIE() #define...
2) and the code in ps decides it can pass a 'struct
kprocinfo2' to
   P_ZOMBIE().
3) Unfortunately this applies P_ZOMBIE() to an lwp l_stat
value, and
   SDYING is LSSLEEP.

Simple fix - remove the check from ps that disbelieves the
time fields
for zombies.
(Committed to head.)

	David

-- 
David Laight: davidl8s.co.uk

Dave Tyson wrote:
> On Saturday 28 July 2007 14:24:56 you wrote:
>   
>> Hi,
>>
>> now that I look at it -current (about twoo weeks
ago) shows the same
>> symptoms.
>> Sensible time output seem state dependent.
Runnanble or Stopped
>> processes show time value that match my
expectations more.
>>
>> Frank
>>
>> Frank Kardel wrote:
>>     
>>> Hi *,
>>>
>>> I am just testing netbsd-4 (around
200707280600UTC).
>>>
>>> ps alxww seem be be a bit funny: most of the
times it lists
>>> 0:00.00 as time - sometime it lists something
plausible.
>>>
>>> Anyone else seeing this behavior ?
>>>
>>> Frank
>>>       
>
> Frank, 
> See my post into netbsd-users on 9th July and later to
tech-userlevel.  I 
> haven't tracked down the issue yet but am wondering if
its a toolchain 
> problem as a ps binary with the same components (from
ident)
>   
That would indeed be strange.
> from January 2007 seemed to report everything Ok and
matched the output of 
> top.
>
> Regards
> Dave
>
>   

Regards,
  Frank

On Sat, Jul 28, 2007 at 06:27:28PM +0100, David Laight
wrote:
> On Sat, Jul 28, 2007 at 03:56:40PM +0000, Michael van
Elst wrote:
> > kardelNetBSD.org (Frank Kardel) writes:
> > 
> > >Sensible time output seem state dependent.
Runnanble or Stopped
> > >processes show time value that match my
expectations more.
> > 
> > The p_stat of a sleeping process is seen as SDYING
(3) because
> > the kvm interface overwrites the value with l_stat
== LSSLEEP (3).
> > 
> > A 'dying' process has no valid cputime, thus ps
prints 0.
> 
> This is all fubar... 
> 
> When lwps were added (in the nathanw_sa branch) the
'process state'
> needed by ps, had to come from the first/only/random
lwp (since
> processes no longer have running/sleeping states). So
fill_kproc2()
> got changed to do 'ki->p_stat = l->l_stat', since
the values for
> process and lwp status matched this didn't matter.
> 
> This all appeared to work until a new 'p->p_stat'
flag SDYING got
> added reusing one of the old values (instead of reusing
the value
> that used to be SDEAD).

Isn't it better to change the definition of SDYING, then?

Pavel