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