Re: Follow up: 40p boot failure with QEMU

[Mark Cave-Ayland <mark.cave-ayland%ilande.co.uk@localhost>]

On 31/08/2018 13:01, Mark Cave-Ayland wrote:

> 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?

Just a heads-up that the latest 40p changes have now been merged into QEMU git master
in time for the 3.1 release, so no need to checkout any custom branches to be able to
reproduce this.

Has anyone had a chance to look back at the CVS log to figure out how this regression
could have been introduced? Note I've tried this with both OpenBIOS and a real 40p
ROM and both panic in the same place, so AFAICT it's not related to the (lack of)
residual data within OpenBIOS.


ATB,

Mark.