Re: NetBSD/hpcmips userland crashes (Re: IBM Workpad z50 dmesg collection)
David Brownlee <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.mips.devel |
|---|---|
| Message-ID | <CAGN_6pZjh0kxrbq4Rr_soD7P8rzg=YvbsKv9B0f56jYaSNr+HQ@mail.gmail.com> |
On Sun, 19 Mar 2023, 15:40 Alexander Bochmann, <[email protected]> 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 >