4 Feb
2019
4 Feb
'19
12:43 p.m.
From: Wayne S
it might be a wonky filesystem. ...
The corruption probably came because the entire disk was going bad.
This theory is contradicted by the fact (mentioned several times, including in
the message you were replying to) that doing a plain 'ls' bombs, but 'sleep
300 &; ls' works fine.
Noel
4 Feb
4 Feb
1:03 p.m.
Yep, I noticed that, but thought it was a idea you might want to explore and it?s simple
enough to do.
Without the full output from the ls command and how it was executed I was just throwing it
out there.
For instance, was the default dir where ls was run, the same dir as when the backgrounded
one was run.
That would make a difference if the filesystem was corrupt. In previous threads, there was
an issue getting the proper image onto the disk, there is the potential for corruption.
There is the assumption, since boards were being worked on, that the problem for a
software is probably due to said hardware, even though diags pass. With that assumption,
shouldn?t you try to eliminate different hardware pieces? I would try running something
that uses memory and doesn?t use disk to narrow the problem down.
Anyway,
Take care and good luck,
Wayne
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
________________________________
From: Noel Chiappa <jnc at mercury.lcs.mit.edu>
Sent: Monday, February 4, 2019 12:43:09 PM
To: cctalk at classiccmp.org
Cc: jnc at mercury.lcs.mit.edu
Subject: RE: PDP-11/45 RSTS/E boot problem
From: Wayne S
it might be a wonky filesystem. ...
The corruption probably came because the entire disk was going bad.
This theory is contradicted by the fact (mentioned several times, including in
the message you were replying to) that doing a plain 'ls' bombs, but 'sleep
300 &; ls' works fine.
Noel
1:15 p.m.
On Feb 4, 2019, at 3:43 PM, Noel Chiappa via cctalk
<cctalk at classiccmp.org> wrote:
That translates into "the problem depends on the physical address of the code being
executed".
The obvious answer is bad memory. Another possibility occurs to me: bad bits in the MMU
(UISAR0 register if I remember correctly). Bad memory is likely to show up with a few
bits wrong; if UISAR0 has a stuck bit so the "plain" case maps incorrectly
you'd expect to come up with execution that looks nothing at all like what was
intended.
paul
From: Wayne S
it might be a wonky filesystem. ...
The corruption probably came because the entire disk was going bad.
This theory is contradicted by the fact (mentioned several times, including in
the message you were replying to) that doing a plain 'ls' bombs, but 'sleep
300 &; ls' works fine. 
2:47 p.m.
On Mon, Feb 4, 2019 at 3:15 PM Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
At the board level, yes. Deeper, it could be bad memory bits or bad
memory decode.
A simple ones-and-zeros test can identify bad DRAMs. It's not as
likely to find bad decoding, which could result in the same chips
tested more than once and other chips not tested at all. I've found
both problems in real MS11-L boards I have for my stack of 11/04 and
11/34s I'm testing.
ISTR in the DEC world, they were good about that. I have multiple
papertapes for the PDP-8, that I think were literally called "ones and
zeros" and "memory address" tests. I would think XXDP has something
similar in terms of progressive tests that expect the previous stage
passed.
-ethan
On Feb 4,
2019, at 3:43 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
That translates into "the problem depends on the physical address of the code being
executed".
The obvious answer is bad memory.
3:18 p.m.
On Feb 4, 2019, at 5:47 PM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
On Mon, Feb 4, 2019 at 3:15 PM Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
At the board level, yes. Deeper, it could be bad memory bits or bad
memory decode.
A simple ones-and-zeros test can identify bad DRAMs. It's not as
likely to find bad decoding, which could result in the same chips
tested more than once and other chips not tested at all. I've found
both problems in real MS11-L boards I have for my stack of 11/04 and
11/34s I'm testing.
ISTR in the DEC world, they were good about that. I have multiple
papertapes for the PDP-8, that I think were literally called "ones and
zeros" and "memory address" tests. I would think XXDP has something
similar in terms of progressive tests that expect the previous stage
passed.
Yes, one of the standard early PDP-11 memory tests is the "no duplicate address
test".
paul
On Feb 4,
2019, at 3:43 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
That translates into "the problem depends on the physical address of the code being
executed".
The obvious answer is bad memory. 
3:27 p.m.
The obvious answer is bad memory.
At the board level, yes. Deeper, it could be bad memory bits or bad
memory decode.
2148
days inactive
2148
days old
5 comments
5 participants
participants (5)
-
ethan.dicks＠gmail.com -
fritzm＠fritzm.org -
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net -
wayne.sudol＠hotmail.com