Re: NetBSD 10.0 - configure test process hang

[Riccardo Mottola <riccardo.mottola%libero.it@localhost>]

Hi,
Robert Elz wrote:
> You didn't send HTML format (and please don't!) and the lines did
> wrap, but that's OK, it is obvious, and easy to deal with (no more
> than a minor annoyance - nothing like as bad as HTML would be, which
> I wouldn't attempt to read at all).

Ah fine then... the intent was to. I hate HTML too, but I really hate 80 
lines email. It really dates back to terminal times, we moved on. I want 
text, but with line wrapping. Makes things so much easier to read and 
lets us use our displays. Ditto for CVS, SVN or GIT logs, let the output 
decide and wrap.

>    | Seems the two emacs processes are "parked"
>
> Yes.

apparently processes aren't always in the same state.. sometimes select, 
sometimes parked... I wonder if it is of interest..
>    | I tried attaching with gdb
>    | sudo gdb --pid=01107
>    |
>    | but it didn't find the process.
>
> Sorry, can't help with that, I am a gdb novice (once used much
> better debuggers, and could never really fathom gdb for more than
> fairly trivial stuff) - certainly I've never even attempted to use
> gdb that way to attach to a running process.   But even if it did,
> unless everything was compiled with -g (which it almost certainly
> isn't - everything in this case means emacs, and all the libraries
> it uses) the help it would offer would probably not be all that
> much.

It usually works. I wanted to see if the process is hang on a system 
call and wich. Granted, emacs bootstrap is a bit special, will try again 
when it happens. Still to finish emacs and then I have other stuff.
> But you didn't do what I asked, run
>
> 	ps -ls -p 1107
> 	ps -ls -p 4180
>
> and find out what threads exist in each process, and the state of
> all of the threads, that might reveal more to someone.

Sorry, did't understand, now I got it. proctree made ancestors easier though

> But if what Martin said is correct, and it almost certainly is, this
> is an ancient sparc multi-cpu problem, that no-one has been able to
> find so far, so the best option might simply be to kill things once
> they have reached this state and start again (without cleaning anything).

I don't know. As I wrote him... On the same SS20 2 years ago (but with 
HyperSparc CPUs) I don't remember hangs or at  least not as many while 
building packages! Now it is really frequent.
Also, I swapped CPUs between SS10 and SS20 and these same CPUs on the 
SS10 compiled dozen of packages for 9.4 with no hang issues.
I will stress the SS10 with 9.4 a little more then (now it has the HS 
CPUs.).

The two SuperSparc and HyperSarc cpus are quite similar in actual 
performance (albeit different in clock speed and cache size). About the 
swap my observations in another mil though.

Riccardo