Re: Follow up: 40p boot failure with QEMU

On 31/08/18 11:57, Martin Husemann wrote:

> On Fri, Aug 31, 2018 at 11:45:58AM +0100, Mark Cave-Ayland wrote:
>> Thanks Martin, this is great! Is there a way to track the progress of
>> pull-ups to see when they get merged?
> 
> It has been processed the other day:
> 	http://releng.netbsd.org/cgi-bin/req-8.cgi?show=994

Brilliant! I found a link to the submission process at
https://www.netbsd.org/developers/releng/pullups.html but couldn't quite
work out how to find out the current status...

>> Regarding the "kernel PGM trap @ 0" error, any thoughts on what could be
>> causing that?
> 
> Jump through NULL pointer somewhere?

Here's the QEMU trace output from where the fault occurs:

IN:
0x0027e964:  838a0004  lwz      r28, 4(r10)
0x0027e968:  2f9c0000  cmpwi    cr7, r28, 0
0x0027e96c:  40be000c  bne      cr7, 0x27e978

----------------
IN:
0x0027e970:  3d200058  lis      r9, 0x58
0x0027e974:  8389ae44  lwz      r28, -0x51bc(r9)
0x0027e978:  7f83e378  mr       r3, r28
0x0027e97c:  2d9a0000  cmpwi    cr3, r26, 0
0x0027e980:  4800dd15  bl       0x28c694

----------------
IN:
0x0027e984:  7fe3fb78  mr       r3, r31
0x0027e988:  4800dd0d  bl       0x28c694

----------------
IN:
0x0027e98c:  3c800002  lis      r4, 2
0x0027e990:  60840002  ori      r4, r4, 2
0x0027e994:  7fe3fb78  mr       r3, r31
0x0027e998:  4800f219  bl       0x28dbb0

----------------
IN:
0x00000000:  07f6cd48  .byte    0x07, 0xf6, 0xcd, 0x48


According to netbsd-INSTALL.symbols.gz that places it somewhere around here:

0027e8f8 T dirhash_dir_isempty
0027e910 T getcwd_common
0027edb4 T vn_isunder

So perhaps it is due to a change in how the boot device and/or the root
filesystem is located?


ATB,

Mark.