| 1 |
4 |
wfjm |
# $ $Id: w11a_known_issues.txt 316 2010-07-16 19:07:47Z mueller $
|
| 2 |
|
|
|
| 3 |
|
|
1. Known differences between w11a and KB-11C (11/70)
|
| 4 |
|
|
|
| 5 |
|
|
- the SPL instruction in the 11/70 always fetched the next instruction
|
| 6 |
|
|
regardless of pending device or even console interrupts. This is known
|
| 7 |
|
|
as the 'spl bug', see
|
| 8 |
|
|
http://minnie.tuhs.org/pipermail/pups/2006-September/001082.html
|
| 9 |
|
|
http://minnie.tuhs.org/pipermail/pups/2006-October/001083.html
|
| 10 |
|
|
In the w11a the SPL has 11/70 semantics in kernel mode, thus next no
|
| 11 |
|
|
traps or interrupts, but in supervisor and user mode SPL really acts as
|
| 12 |
|
|
nop, so traps and interrupts are taken as for all other instructions.
|
| 13 |
|
|
--> The w11a isn't bug compatible with the 11/70.
|
| 14 |
|
|
|
| 15 |
|
|
- A 'red stack violation' looses PSW, a 0 is pushed in stack.
|
| 16 |
|
|
|
| 17 |
|
|
- The 'instrution complete flag' in SSR0 is not implemented, it is
|
| 18 |
|
|
permanently '0', SSR2 will not record vector addresses in case of a
|
| 19 |
|
|
vector fetch fault. Recovery of vector fetch faults is therefore not
|
| 20 |
|
|
possible, but only 11/45 and 11/70 supported this, no OS used that, and
|
| 21 |
|
|
it's even unclear whether it can be practically used.
|
| 22 |
|
|
|
| 23 |
|
|
- the 11/70 maps the 18 bit UNIBUS address space into the upper part of
|
| 24 |
|
|
the 22bit extended mode address space. With UNIBUS mapping enabled, this
|
| 25 |
|
|
allowed to access via 17000000:17757777 the memory exactly as a UNIBUS
|
| 26 |
|
|
device would see it. The w11a doesn't implement this remapping, an access
|
| 27 |
|
|
in the range 17000000:17757777 causes a NXM fault.
|
| 28 |
|
|
|
| 29 |
|
|
All four points relate to very 11/70 specific behaviour, not operating system
|
| 30 |
|
|
depends on them, therefore they are considered acceptable implementation
|
| 31 |
|
|
differences
|
| 32 |
|
|
|
| 33 |
|
|
2. Known limitations
|
| 34 |
|
|
|
| 35 |
|
|
- some programs use timing loops based on the execution speed of the
|
| 36 |
|
|
original processors. This can lead to spurious timeouts, especially
|
| 37 |
|
|
in old test programs.
|
| 38 |
|
|
--> a 'CPU throttle mechanism' will be added in a future version to
|
| 39 |
|
|
circumvent this for some old test codes.
|
| 40 |
|
|
|
| 41 |
|
|
- the emulated I/O can lead to apparently slow device reaction times,
|
| 42 |
|
|
especially when the server runs as normal user process. This can lead
|
| 43 |
|
|
to timeout, again mostly in test programs.
|
| 44 |
|
|
--> a 'watch dog' mechanism will be added in a future version which
|
| 45 |
|
|
suspends the CPU when the server doesn't respond fast enough.
|
| 46 |
|
|
|
| 47 |
|
|
3. Known bugs
|
| 48 |
|
|
|
| 49 |
|
|
- TCK-036 pri=L: RK11: hardware poll not working
|
| 50 |
|
|
The RK11/RK05 hardware poll logic is probably no reflecting the
|
| 51 |
|
|
behaviour of the real drive.
|
| 52 |
|
|
|
| 53 |
|
|
- TCK-035 pri=L: RK11: no proper NXM check in 18bit systems
|
| 54 |
|
|
No NXM error is generated when a RK11 read or write reaches the top
|
| 55 |
|
|
of memory in 18 bit addressing. Crash dump routines use this to detect
|
| 56 |
|
|
end-of-memory.
|
| 57 |
|
|
|
| 58 |
|
|
- TCK-032 pri=M: RK11: polling on DRY in RKDS doesn't work
|
| 59 |
|
|
DRY in RKDS goes 1->0 immediately with RDY in RKCS when a function is
|
| 60 |
|
|
started. In a real RK05 drive DRY went to 0 after a short delay. Some
|
| 61 |
|
|
basic hardware tests are sensitive to this.
|
| 62 |
|
|
|
| 63 |
|
|
- TCK-030 pri=L: CPU: SSR0 trap bit set when access aborted
|
| 64 |
|
|
The 'trap bit' (bit 12: 10000) is set even when the access is aborted.
|
| 65 |
|
|
|
| 66 |
|
|
- TCK-029 pri=L: CPU: AIB A bit set for all accesses
|
| 67 |
|
|
The MMU trap condition isn't properly decoded
|
| 68 |
|
|
|
| 69 |
|
|
- TCK-028 pri=H: CPU: interrupt and trap precedence
|
| 70 |
|
|
In case of multiple trap, fault, or interrupt conditions the precedence
|
| 71 |
|
|
isn't implemented correctly.
|
| 72 |
|
|
|
| 73 |
|
|
- TCK-026 pri=L: CPU: src+dst delta added in ssr1 when same register
|
| 74 |
|
|
The ssr1 content after a fault is logically correct in w11a, but
|
| 75 |
|
|
different from 11/70.
|
| 76 |
|
|
|
| 77 |
|
|
- TCK-025 pri=L: CPU: no mmu trap when bit9 clearing instruction traps
|
| 78 |
|
|
In the 11/70 the instruction which affects mmu trap can cause a trap
|
| 79 |
|
|
already, in w11a only the next instruction will trap.
|
| 80 |
|
|
|
| 81 |
|
|
- TCK-014 pri=M: RK11: write protect action too slow
|
| 82 |
|
|
Some simple RK11 drivers, especially in tests, don't poll for completion
|
| 83 |
|
|
of a write protect command. Due to the emulated I/O this can cause errors.
|
| 84 |
|
|
|
| 85 |
|
|
- TCK-007 pri=H: CPU: no trap-4 after emt on odd stack
|
| 86 |
|
|
- TCK-006 pri=H: CPU: no yel-stack trap after jsr pc,nnn(pc)
|
| 87 |
|
|
- TCK-004 pri=H: CPU: yel-stack by interrupt causes loop-up
|
| 88 |
|
|
- TCK-003 pri=H: CPU: yel-stack by iot pushes two stack frames
|
| 89 |
|
|
All four issues are caused by an incorrect implementation of the trap
|
| 90 |
|
|
logic, which leads to a different precendence when multiple trap, fault,
|
| 91 |
|
|
or interrupt occur.
|
| 92 |
|
|
|
