Re: [PATCH] target/m68k: implement fmove.l #<data>,FPCR

[Laurent Vivier <laurent@vivier.eu>]

Le 31/05/2020 à 13:23, John Paul Adrian Glaubitz a écrit :
> Hi Laurent!
> 
> On 5/31/20 1:02 PM, Laurent Vivier wrote:
>> The immediate value mode was ignored and instruction execution
>> ends to an invalid access mode.
>>
>> This was found running 'R' that set FPSR to 0 at startup with
>> a 'fmove.l #0,FPSR' in qemu-system-m68k emulation and triggers a
>> kernel crash:
>> (...)
>> Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
>> ---
>>  target/m68k/translate.c | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
> Thanks for the fix.
> 
> I applied the patch, but I'm getting a lock-up now as you previously reported
> in the other discussion on the Linux/m68k mailing list:
> 
> root@pacman:~# R
> [   68.420000] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [R:650]
> [   68.420000] Modules linked in: sg evdev mac_hid ip_tables x_tables sha1_generic hmac ipv6 nf_defrag_ipv6 autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif sr_mod cdrom crct10dif_generic crct10dif_common mac_esp macsonic esp_scsi
> [   68.420000] Format 00  Vector: 0064  PC: 0002df9c  Status: 2008    Not tainted
> [   68.420000] ORIG_D0: ffffffff  D0: 00000000  A2: c02e239a  A1: ffa10000
> [   68.420000] A0: 3c9adf29  D5: 0000000d  D4: 8002ce30
> [   68.420000] D3: 8002b418  D2: 8002b4b4  D1: 00000000
> 
> Is this related or a different bug?
> 
> I have not seen these lockups on real hardware.
I guess you are using my q800-dev branch?

In this branch, there is an attempt to manage unnormalized numbers that
seems to trigger this lock up.

You can either use master + this patch or update your q800-dev branch
from my repo.

Thanks,
Laurent