17 Mar
2016
17 Mar
'16
4:34 a.m.
I'm not sure where I should start asking, so I'm starting here ;-)
I have a problem reading TK70 (and probably TK50) tapes in NetBSD 3.0 on a
MicroVAX II. There is absolutely no way of reading a single tape block
with a simple read(). All I get is
mt0: unknown opcode 0x80 status 0xc01 ignored
on the console, and then the driver hangs. The output is generated in
/usr/src/sys/dev/mscp/mscp.c
It is my impression that the code has *never* been tested on real hardware
after all that years. BTW the TK70 is working fine otherwise (e.g. I can
boot the MVII diagnostic tape).
Now for something strange: the same procedure works in SimH (with the same
system installation and kernel). So apparently SimH has a "bug", too. It
doesn't behave like the real device.
Background of the story: I want to image TK70 tapes as TAP files.
Has anyone ever encountered the same behaviour?
Christian
17 Mar
17 Mar
10:14 a.m.
Hi Christian,
Have you asked this question on the port-vax netbsd mailing list? Also you're on on
Rel3, which is pretty old - I assume you have a good reason to be at that release level,
Have you tried booting a newer release and see if the behavior is the same? I know, not
exactly a convenient/easy thing to do on uVax II...
cheers
--
alex
18 Mar
18 Mar
2:28 a.m.
New subject: NetBSD TK70 question (solved)
On Thu, 17 Mar 2016, Christian Corti wrote:
simple read(). All I get is
mt0: unknown opcode 0x80 status 0xc01 ignored
[...]
Ok, I was fishing deep in the TMSCP protocol manual, and after fiddling
with the MSCP driver I found out that Opcode 0x80 (OP.END) alone (page
A-2) means MSCP protocol violation (originating from the TQK70), and
status 1 with subcode 0 (page B-3) means invalid message length... aha!
I was issuing a read() with a requested length of 65536 bytes, too much,
maximum is 65535. After I had reduced the length I could read the tape!
So the following is for the records:
1. NetBSD doesn't know how to deal with such an MSCP error
2. SimH (GIT version) improperly ignores invalid buffer lengths
Christian
3:23 a.m.
On 17 March 2016 at 11:34, Christian Corti
<cc at informatik.uni-stuttgart.de> wrote:
I'm not sure where I should start asking, so
I'm starting here ;-)
I have a problem reading TK70 (and probably TK50) tapes in NetBSD 3.0 on a
MicroVAX II. There is absolutely no way of reading a single tape block with
a simple read(). All I get is
mt0: unknown opcode 0x80 status 0xc01 ignored
on the console, and then the driver hangs. The output is generated in
/usr/src/sys/dev/mscp/mscp.c
It is my impression that the code has *never* been tested on real hardware
after all that years. BTW the TK70 is working fine otherwise (e.g. I can
boot the MVII diagnostic tape).
Now for something strange: the same procedure works in SimH (with the same
system installation and kernel). So apparently SimH has a "bug", too. It
doesn't behave like the real device.
Background of the story: I want to image TK70 tapes as TAP files.
Has anyone ever encountered the same behaviour?
I'm pretty sure TK50 tapes definitely worked around 1.6, as I built
and tested releases on them :-p
From my very loose MSCP reading 0x80 would be M_OP_END
and 0xc01 would
be M_ST_INVALCMD (plus the 0xc00).
Hmm, is it possible you're issuing a read for a different blocksize to
that of the tape?
As an aside if you wanted to test a more recent kernel you *should* be
able to drop a new kernel as /netbsd.new or similar and then boot it
directly and keep using the netbsd-3 userland. This may not work if
the new kernel needs a more recent bootblock (which is sometimes
unfortunately the case)
3518
days inactive
3519
days old
3 comments
3 participants
participants (3)
-
abs＠absd.org -
azd30＠telus.net -
cc＠informatik.uni-stuttgart.de