Re: NetBSD/hpcmips userland crashes (Re: IBM Workpad z50 dmesg collection)

[David Brownlee <abs%absd.org@localhost>]

On Sun, 19 Mar 2023, 15:40 Alexander Bochmann, <ab%lists.gxis.de@localhost> wrote:

> Hi -
>
> I'm aware it's been almost two years, but I've finally put in a
> couple of hours to go through a number of the test kernels you
> compiled back then...
>
> ...on 2021-05-25 23:38:55, David Brownlee wrote:
>
>  > 3) userland random crashes: in -8 & -9 (unknown if fixed in HEAD?)
>  > This one is the big unknown - if it's fixed in HEAD we're in a very
>  > good place, otherwise we have more fun ahead :)
>
> This seems to have started pretty early on after the 2016-07-01
> kernel: That's the last one i tried that shows no problem.
>
> Both 2016-07-01 and 2016-08-01 hang after this message in the boot
> process:
>

Sorry - could you confirm if 2016-07-01 works or hangs?

>
 > pid 1(init): ABI set to O32 (e_flags=0x1007)
>

> 2016-10-01 boots to multiuser, but ntpdate is the first program
> to crash:
>
>  > Setting date via ntp.
>  > [1]   Segmentation fault (core dumped) ${command} ${rc_...
>
> Later, virecover has to be stopped with ^C to reach a login prompt.
>
> 2016-11-01 and 2016-12-01 are missing, and then 2017-01-01 errors
> out immediately and drops to a single-user shell.
>
>  > pid 1(init): ABI set to O32 (e_flags=0x1007)
>  > Sun Mar 19 14:22:04 GMT 2023
>  > rcorder: could not open /etc/rcd/mrouted: No such file or directory
>  > rcorder: could not open /e: No such file or directory
>  > rcorder: requirement `ypbind' in file `/etc/rc.d/mountall' has no
> providers.
>  > rcorder: requirement `ypbind' in file `/etc/rc.d/amd' has no providers.
>  > [1]   Bus error               (stty status "^T...
>  > Enter pathname of shell or RETURN for /bin/sh:
>
> I can provide dmesg / boot logs if it helps any, but also I' fully
> understand if you don't want to put any more work into this after
> I didn't do anything for all this time.
>

Hey, if I made comments about other people coming back to something after a
year or so (looks up at huge expanse of greenhouse panes above :)

It feels like progress - if can can identify the last working/first
failing, we can run down the intervening commits and either build another
kernel ot two, or point at a candidate change.

(Crosses fingers about it not being a gcc version update)

David

>