4 Feb
2019
4 Feb
'19
9:13 a.m.
On 2/4/2019 10:20 AM, Jon Elson via cctalk wrote:
On 02/04/2019 04:28 AM, Noel Chiappa via cctalk
wrote:
If he hasn't already, if Fritz has more than one memory board, he might
try swapping them to see if that changes anything.
The issue I'd see with the MMU swapout idea would be finding one that
would be ECO-compatible with the rest of the processor.
This sort of situation, where DEC diagnostics run OK but UNIX has issues
was reported to be not all that uncommon - to the point where the urban
legend was that some DEC FE's would fire up Unix V6 as a sort of system
exerciser.
Other things I might be tempted to try in order to coax more information
out of the situation:
1. Run the DEC system exerciser, if that has not already been done.
2. Make a copy of ls, and see if the copy also fails
(different location on disk would mess with timing just a bit).
3. Use SimH to build a pack image with an instance of ls that is not
pure text (no -n or -i flag)
4. Use SimH to build an ls that does/does not start the data segment
for ls at 0 (has / does not have the -i flag) [I have not looked to
see how ls would normally be built.]
5. Use SimH to gen a pack image with a kernel that is a not split I/D
JRJ
First oddity - the problem is dependent on the location of the command
in main
memory! If Fritz says "sleep 360 &", to run a trivial command in the
background, and _then_ says 'ls' - it works (so we know the binary of
'ls' on
disk is OK)! We _think_ this is because the process executing the 'sleep'
takes up a chunk of main memory, and thus changes the location of the
process
executing the 'ls'.
OK, the classic Heisenbug.? Is this truly a fault given by the memory
management system, or some other kind of fault (Unibus timeout or memory
parity error)?? If really related to MMU, then maybe there is a bad bit
in the MMU that is causing it to reference the wrong segment entry or
somehow thinking the setting of that segment entry is invalid.? Does the
MMU classify what the error condition was, or just assume the trap
handler can figure it out be looking at the registers?
Anyway, is it possible to borrow an MMU from somebody else?? I can
easily imagine that the diags can't test every possible bit combination
while the diags are ALSO running in memory.
So, a somewhat cryptic bug could go undetected.
If this fault could be caused by memory, then it may be a
pattern-sensitive error, and ls is just the perfect pattern to trip it up.
Jon