English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.WinUAE (http://eab.abime.net/forumdisplay.php?f=5)
-   -   68030, 68040 and 68060 MMU support (really!) (http://eab.abime.net/showthread.php?t=46934)

mark_k 21 February 2013 17:38

Quote:

Originally Posted by Toni Wilen (Post 870095)
EDIT: you can easily check if f-line vector is correct, break to debugger after netbsd has booted, type "mmu 5", "i", check address of LINEF EMU, disassemble it, it is wrong if it starts with cmp.w #$202c,something (this is correct if 68040+ or 68881 or 68882 is installed) and correct if it starts with addq.l #1,something.

I tried that after starting the NetBSD 1.6.2 installer and got this for the LINEF EMU code:
Code:

d 022de
000022DE 52b9 001d 64b0          ADD.L #$00000001,$001d64b0
000022E4 42a7                    CLR.L -(A7)
000022E6 48e7 ffff                MOVEM.L D0-D7/A0-A7,-(A7)
000022EA 7010                    MOVE.L #$00000010,D0
000022EC 60ff ffff fd3c          BT .L #$fffffd3c == $0000202a (T)
000022F2 0cb9 ffff fffe 001d 6394 CMP.L #$fffffffe,$001d6394
000022FC 66ff ffff fda0          BNE.L #$fffffda0 == $0000209e (T)
00002302 4ef9 0000 cb88          JMP.L $0000cb88
00002308 42a7                    CLR.L -(A7)
0000230A 48e7 ffff                MOVEM.L D0-D7/A0-A7,-(A7)

[Obviously the NetBSD FPU emulation code isn't coded too tightly; ADD.L could be ADDQ.L, MOVE.L could be MOVEQ, BRA.L could be BRA.W... :)]

Whatever you fixed in the latest winuae.zip definitely improved things. Maybe there are still problems with some other instructions though.

Toni Wilen 21 February 2013 17:40

Quote:

Originally Posted by mark_k (Post 870113)
[Obviously the NetBSD FPU emulation code isn't coded too tightly; ADD.L could be ADDQ.L, MOVE.L could be MOVEQ, BRA.L could be BRA.W... :)]

Do not trust UAE debugger too much, better check the opcode encoding first :)
(Q for example isn't shown)

mark_k 23 February 2013 12:47

strim: Would you be able to build a NetBSD kernel which gives more information than just "Illegal instruction"? Maybe the instruction opcode and address and anything else which might help figure out the problem.

strim 23 February 2013 13:19

Quote:

Originally Posted by mark_k (Post 870575)
strim: Would you be able to build a NetBSD kernel which gives more information than just "Illegal instruction"? Maybe the instruction opcode and address and anything else which might help figure out the problem.

I can try modifying trap hander to print some more information. But I'm not sure when I'll have a few spare minutes to do that.

:guru

If you have some free time and C background you can try doing it yourself. Cross-compiling NetBSD is possible from Linux (or any other UNIX-like) and documented quite well.

Basically what needs to be done is to add a printf inside T_ILLINST|T_USER case that will dump important information from frame.

Toni Wilen 23 February 2013 13:26

Quote:

Originally Posted by mark_k (Post 870575)
strim: Would you be able to build a NetBSD kernel which gives more information than just "Illegal instruction"? Maybe the instruction opcode and address and anything else which might help figure out the problem.

This does not help because trap handler points to original exception handler, not FPU emulation handler! Problem is somewhere in initialization/loader.

strim 23 February 2013 13:37

Quote:

Originally Posted by Toni Wilen (Post 870582)
This does not help because trap handler points to original exception handler, not FPU emulation handler! Problem is somewhere in initialization/loader.

I can't reproduce this on a real FPUless machine (A1200 + ACA1232). And it does not matter if I'm using boot block loader or loadbsd.

Toni Wilen 23 February 2013 17:34

Only 1.3.3 (possible other older versions too) have this problem. 6.x seems to work fine, LINE-F vector is correct and points to FPU emu code.

EDIT: Old versions also have VBR in chip ram.

mark_k 23 February 2013 18:38

So I guess there must be some other problem causing the illegal instruction messages with NetBSD 6.0.1. You can see them either booting the pre-installed HDF, or running the installer when it fails at the creating filesystems stage. Booting the pre-installed HDF, some user programs in the startup sequence crash (/usr/sbin/syslog, awk and something related to fontconfig cache in the screenshot I posted before). Those crashes are not fatal though, and you can get to the login prompt, log in and type halt to shut down.

Could you upload a winuae.zip which doesn't have the limit on B-Trap messages? The normal WinUAE only prints the first 20.

Toni Wilen 23 February 2013 19:30

I thought you meant you get exact same behavior with old and new winuae versions.

winuae.zip updated, no A/F-line log limits.

mark_k 23 February 2013 21:27

1 Attachment(s)
I wonder if the underlying cause is somehow MMU-related? Anyway, I've attached logs from booting the NetBSD 6.0.1 installer (illegal instruction message when it reaches creating filesystems stage), and booting the pre-installed HDF. Some extracts... nothing really caught my eye except maybe the line B-Trap f240 at 4 (04F80004). But then, I wouldn't know what to look for.

Booting the NetBSD 6.0.1 installer, the last few B-Trap lines before illegal instruction message:
Code:

B-Trap f200 at e4bf8 (05064BF8)
B-Trap f22e at 5200a (04FD200A)
B-Trap f23c at 52010 (04FD2010)
B-Trap f22e at 5201c (04FD201C)
B-Trap f227 at 11b05c (0509B05C)
B-Trap f22e at 11b0ea (0509B0EA)
B-Trap f28e at 11b0f4 (0509B0F4)

Booting the pre-installed NetBSD 6.0.1 HDF, last few B-Trap lines before syslog crash message:
Code:

B-Trap f22e at 2ba4 (04F82BA4)
B-Trap f227 at 2a24 (04F82A24)
B-Trap f22e at 2ba4 (04F82BA4)
B-Trap f210 at 8185014 (05F00002)
B-Trap f23c at 8185018 (05F00002)
B-Trap f29b at 8185028 (05F00002)

Last few before fontconfig segmentation fault message:
Code:

B-Trap f23c at 80364fa (05F00002)
B-Trap f29d at 803650a (05F00002)
B-Trap f23c at 8036532 (05F00002)
B-Trap f200 at 803653e (05F00002)
B-Trap f200 at 8036542 (05F00002)
B-Trap f21f at 803697c (05F00002)
B-Trap f21f at 8036984 (05F00002)
B-Trap f200 at 8036988 (05F00002)
B-Trap f240 at 4 (04F80004)

Last few lines before awk illegal instruction message:
Code:

B-Trap f227 at fdfc (04F8FDFC)
B-Trap f22e at fe0c (04F8FE0C)
B-Trap f22a at fec6 (04F8FEC6)
B-Trap f22e at ff48 (04F8FF48)
B-Trap f202 at 9c2e (04F89C2E)
B-Trap f210 at 9c38 (04F89C38)
B-Trap f294 at 9c40 (04F89C40)


Toni Wilen 24 February 2013 08:57

Should work now. FDBcc and FScc had wrong PC address in line-f stack frame.

mark_k 24 February 2013 14:56

3 Attachment(s)
Nice work, NetBSD 6.0.1 now seems to boot fine without FPU. (Can't start X, but that applies with FPU too, so not related to this issue.)

More test results without FPU...
Pre-installed NetBSD 1.3.3 HDF seems to boot fine, can start X.
Pre-installed NetBSD 1.6.2 HDF seems to boot fine to console. However I can't start X. The screen clears then returns to the console with a Segmentation fault - core dumped message. (X does start correctly with FPU.)
Running the NetBSD 1.6.2 installer without FPU gives a similar error to the 2.1 installer below.

There may be one(?) remaining problem which shows up with NetBSD 2.1.
NetBSD 2.1 installed HDF (68.3MB) Multiupload link
NetBSD 2.1 pre-installation HDF (1.5MB) Multiupload link
WinUAE logs for booting installed NetBSD 2.1, and for running the installer (726KB) Multiupload link

I booted the pre-installed NetBSD 2.1 HDF with and without FPU. With FPU it works fine, you can log in and start X. Without FPU, the boot sequence hangs after printing Starting motd.
Looking at the log output, it seems to get into an infinite loop, printing many B-Trap lines, eventually the last two repeating over and over:
Code:

...
B-Trap f200 at c438 (04F8C438)
B-Trap f240 at c43c (04F8C43C)
B-Trap f22a at 105c2 (04F905C2)
B-Trap f200 at c5ca (04F8C5CA)
B-Trap f202 at c5ce (04F8C5CE)
B-Trap f227 at 80d802c (05F00002)
B-Trap f22e at 80d93c2 (05F00002)
B-Trap f227 at 80d802c (05F00002)
B-Trap f22e at 80d93c2 (05F00002)
B-Trap f227 at 80d802c (05F00002)
B-Trap f22e at 80d93c2 (05F00002)
...

Running the NetBSD 2.1 installer, that fails at the creating filesystem stage. NetBSD prints
Code:

Creating filesystems...
uid 0, pid 50, command newfs, on /: file system full

/: write failed, file system is full
[1]  Segmentation fault      newfs /dev/r${_d...

The last few B-Trap lines in the log (which might actually relate to whatever ran after newfs crashed, so you might want to view the full log) were:
Code:

B-Trap f227 at 20274 (04FA0274)
B-Trap f22e at 20ec4 (04FA0EC4)
B-Trap f227 at 29934 (04FA9934)
B-Trap f22e at 2a962 (04FAA962)
B-Trap f227 at 29934 (04FA9934)
B-Trap f22e at 2a962 (04FAA962)
B-Trap f227 at 20274 (04FA0274)
B-Trap f227 at 20274 (04FA0274)


Toni Wilen 24 February 2013 17:55

Either there is bug in this netbsd version or there is some MMU related issue because this can't be caused by (missing) FPU.

CFOU! 28 March 2013 12:43

Hi Tony

thanks for you MMU support.

but since first winuae MMU support there are incompatibility with HRTmon build-in version and whdload when you use MMU features although HRTMON is well recognized by WHDLoad at launch.

Bert (WEPL) has just sent to my an whdload beta version which allow all hrmon read access memory.

but when you enter in hrtmon build-in version it's freeeze inside hrtmon on red screen (it works well without MMU)

I think the crash is due to the fact that the version in build-VBR hrtmon move WHDLoad or do not support the monitor moves the VBR.

Is it possible to add in WinUAE one second build-in version with 'no move VBR' option activated (leaving the choice to the user)?

Regards,

Toni Wilen 28 March 2013 15:00

VBR move is not enabled in hrtmon. Can't do anything without exact instructions and required executable(s).

CFOU! 28 March 2013 15:01

Quote:

Originally Posted by Toni Wilen (Post 878083)
VBR move is not enabled in hrtmon. Can't do anything without exact instructions and required executable(s).

it's really curious i will send you more info tjsi evening

CFOU! 28 March 2013 19:58

1 Attachment(s)
here winuae debugger screen when there are red freeze screen.

i have uploaded in TheZone:
- whdload beta version (with hrtmon build-in version allowed by whdload by MMU)
- winaue config file
- savestate

regards

Toni Wilen 29 March 2013 11:54

Quote:

Originally Posted by CFOU! (Post 878141)
here winuae debugger screen when there are red freeze screen.

Can't duplicate. I only get normal whdload error requester that says a1000c (built-in hrtmon entry point) can't be accessed due mmu access fault.

CFOU! 29 March 2013 12:22

Quote:

Originally Posted by Toni Wilen (Post 878262)
Can't duplicate. I only get normal whdload error requester that says a1000c (built-in hrtmon entry point) can't be accessed due mmu access fault.

Thanks

you cought reproduct red freeze all time but:

- first you must install whdload beta version done by Bert for mmu+hrtmon build-in support test if not whdload crash because hrtmon access memory not allowed....
(include file crashHRTMON.rar in TheZone!)
- The HRTmon built into WinUAE can only be detected if HRTmon has been previousy activated at least one time (press key PgUp). Because on first activation the NMI vector will be set which is used by WHDLoad to locate the monitor. (cf.http://www.whdload.de/docs/en/freezer.html)


so if you launch one time hrtmon build-in version before launch whdload MMU code must allow hrtmon adrress access but it's cause red screen without exit on whdload outbut debug window

Toni Wilen 29 March 2013 15:28

Quote:

MMU: page fault (logical addr=00A9F000 SSW=0345 read=1 size=4 fc=5 pc=00a10ee4 ob=0000003f ins=22D8)
Keeps repeating.

My guess is that A90000-A9FFFF is mapped as invalid. (Built-in HRTMon starts from A10000 and requires full 512k)


All times are GMT +2. The time now is 04:32.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.05800 seconds with 11 queries