Permalink
Fetching contributors…
Cannot retrieve contributors at this time
110 lines (86 sloc) 5.14 KB

Summary of known issues for w11a CPU and systems

General issues are listed on a separate document README_known_issues.md.

This file descibes issues of the w11 CPU.

###Table of content

Known differences between w11a and KB11-C (11/70)

All four points relate to very 11/70 specific behaviour, no operating system depends on them, therefore they are considered acceptable implementation differences.

Known limitations

  • some programs use timing loops based on the execution speed of the original processors. This can lead to spurious timeouts, especially in old test programs.
    --> a 'CPU throttle mechanism' will be added in a future version to circumvent this for some old test codes.
  • the emulated I/O can lead to apparently slow device reaction times, especially when the server runs as normal user process. This can lead to timeout, again mostly in test programs.
    --> a 'watch dog' mechanism will be added in a future version which suspends the CPU when the server doesn't respond fast enough.

Known bugs

  • TCK-038 pri=H: DL11: output chars lost
    Part of the output can be lost when xxdp test eqkce1 is run on FPGA, also some kernel messages during the 211BSD boot sequence. Most likely cause is that device ready polls timeout before the rlink interface can serve the interrupt.

  • TCK-036 pri=L: RK11: hardware poll not working
    The RK11/RK05 hardware poll logic is probably not reflecting the behaviour of the real drive.

  • TCK-035 pri=L: RK11: no proper NXM check in 18bit systems
    No NXM error is generated when a RK11 read or write reaches the top of memory in 18 bit addressing. Crash dump routines use this to detect end-of-memory.

  • TCK-032 pri=M: RK11: polling on DRY in RKDS doesn't work
    DRY in RKDS goes 1->0 immediately with RDY in RKCS when a function is started. In a real RK05 drive DRY went to 0 after a short delay. Some basic hardware tests are sensitive to this.

  • TCK-030 pri=L: CPU: SSR0 trap bit set when access aborted
    The 'trap bit' (bit 12: 10000) is set even when the access is aborted.

  • TCK-029 pri=L: CPU: AIB A bit set for all accesses
    The MMU trap condition isn't properly decoded

  • TCK-028 pri=H: CPU: interrupt and trap precedence
    In case of multiple trap, fault, or interrupt conditions the precedence isn't implemented correctly.

  • TCK-026 pri=L: CPU: src+dst delta added in SSR1 when same register
    The SSR1 content after a fault is logically correct in w11a, but different from 11/70.

  • TCK-025 pri=L: CPU: no mmu trap when bit9 clearing instruction traps
    In the 11/70 the instruction which affects mmu trap can cause a trap already, in w11a only the next instruction will trap.

  • TCK-014 pri=M: RK11: write protect action too slow
    Some simple RK11 drivers, especially in tests, don't poll for completion of a write protect command. Due to the emulated I/O this can cause errors.

  • The last four issues are caused by an incorrect implementation of the trap logic, which leads to a different precendence when multiple trap, fault, or interrupt occur

    • TCK-007 pri=H: CPU: no trap-4 after emt on odd stack
    • TCK-006 pri=H: CPU: no yel-stack trap after jsr pc,nnn(pc)
    • TCK-004 pri=H: CPU: yel-stack by interrupt causes loop-up
    • TCK-003 pri=H: CPU: yel-stack by IOT pushes two stack frames