26 Sep
2003
26 Sep
'03
10:47 p.m.
Markus Weber <jmbw(a)nather.com> wrote:
Stand/copy from tms(0,1) to ra(0,1) fails with a
'disk unlabeled' diagnostic
on a cold disk image.
It should print the unlabeled diagnostic, but then proceed rather than fail. I
just double-checked the standalone driver source, and it does provide a default
label for RA82, as long as the MSCP controller actually returns RA82 as the MSCP
disk ID. Does it give you an error message about disk type (some hex humber)
not supported? If so, SIMH's MSCP emulation must be lacking in quality.
If only ra0 is
configured for simh, it takes the kernel a long time to decide that ra1,
ra2, and ra3 are offline. Having said that, I do not know how long this
takes on actual hardware.
On real HW it takes no noticeable time.
the kernel (and
not simh) subsequently segfaults (trap type 8, code = c0000200, pc =
8003fe16).
Well, obviously this doesn't happen on real HW, since on real HW it works (I'm
typing this message on a MicroVAX 3+ running 4.3BSD-Quasijarus).
But I will grant the possibility that the kernel is not w/o fault either in that
perhaps it's going south (dereferencing a garbage pointer and crashing) when the
MSCP controller (in this case SIMH's poor emulation) is doing something it
doesn't expect. If this is so, it should be fixed, since even w/o emulators
(which I refuse to support on principle) real HW can be broken and return
garbage on reg reads, and the kernel must handle it gracefully. I'll look into
it.
MS
1 Oct
1 Oct
5:33 p.m.
New subject: 4.3 BSD version in the Unix Archive
I found out a bit more.
For any non-OpenVMS OS I tried on simh/vax (read: different flavors of BSD),
disk initialization is a common problem area. NetBSD glitches on mounting
the installation CD/disk, Quasijarus has a hard time deciding which disks
are online and which are not, and finally OpenBSD installs without problem,
but fails when mounting the root filesystem when it boots off ra0a. I can
however boot off the install-time kernel on the floppy disk and access the
partitions on ra0 just fine.
It became apparent that OpenBSD's in-core disk label defaulted to data
matching the c partition where the a partition should have been. After more
digging, it seemed that ra_putonline was called, but rx_putonline must have
failed somehow. To add insult to injury, after adding a few printf
statements to rx_putonline the OpenBSD sort-of-GENERIC kernel now boots.
Here's the relevant block of code:
rx_putonline(rx)
struct rx_softc *rx;
{
struct mscp *mp;
struct mscp_softc *mi = (struct mscp_softc *)rx->ra_dev.dv_parent;
volatile int i;
printf("entered rx_putonline\n");
rx->ra_state = DK_CLOSED;
mp = mscp_getcp(mi, MSCP_WAIT);
mp->mscp_opcode = M_OP_ONLINE;
mp->mscp_unit = rx->ra_hwunit;
mp->mscp_cmdref = 1;
*mp->mscp_addr |= MSCP_OWN | MSCP_INT;
/* Poll away */
i = bus_space_read_2(mi->mi_iot, mi->mi_iph, 0);
if (tsleep(&rx->ra_dev.dv_unit, PRIBIO, "rxonline", 100*100))
rx->ra_state = DK_CLOSED;
printf("rx->ra_state = %d\n",rx->ra_state);
if (rx->ra_state == DK_CLOSED)
return MSCP_FAILED;
printf("rx_putonline returns DONE\n");
return MSCP_DONE;
}
My guess is that the very first printf upsets the emulation timing just
enough to make things work. I'd have to read more code and RQDX3
documentation to take this further, but maybe this is enough to go on to
make it obvious to somebody else why Quasijarus on simh exhibits these
awfully long disk probe timeouts. I hope that once this problem has been
narrowed down a bit more, a fix to simh/vax will make all BSDs happy.
-----Original Message-----
From: Michael Sokolov [mailto:msokolov@ivan.Harhan.ORG]
Sent: Friday, September 26, 2003 3:48 PM
To: jmbw(a)nather.com; tuhs(a)tuhs.org
Subject: RE: [TUHS] Re: 4.3 BSD version in the Unix Archive
[...] If so, SIMH's MSCP emulation must be lacking in quality.
[...]But I will grant the possibility that the kernel is not w/o fault
either in that
perhaps it's going south (dereferencing a garbage pointer and crashing) when
the
MSCP controller (in this case SIMH's poor emulation) is doing something it
doesn't expect.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com)
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003
6:56 p.m.
New subject: 4.3 BSD version in the Unix Archive
--- Markus Weber <jmbw(a)nather.com> wrote:
I found out a bit more.
For any non-OpenVMS OS I tried on simh/vax (read: different flavors of BSD),
disk initialization is a common problem area. NetBSD glitches on mounting
the installation CD/disk, Quasijarus has a hard time deciding which disks
are online and which are not, and finally OpenBSD installs without problem,
but fails when mounting the root filesystem when it boots off ra0a. I can
however boot off the install-time kernel on the floppy disk and access the
partitions on ra0 just fine.
It became apparent that OpenBSD's in-core disk label defaulted to data
matching the c partition where the a partition should have been. After more
digging, it seemed that ra_putonline was called, but rx_putonline must have
failed somehow. To add insult to injury, after adding a few printf
statements to rx_putonline the OpenBSD sort-of-GENERIC kernel now boots.
Here's the relevant block of code:
rx_putonline(rx)
struct rx_softc *rx;
{
struct mscp *mp;
struct mscp_softc *mi = (struct mscp_softc *)rx->ra_dev.dv_parent;
volatile int i;
printf("entered rx_putonline\n");
rx->ra_state = DK_CLOSED;
mp = mscp_getcp(mi, MSCP_WAIT);
mp->mscp_opcode = M_OP_ONLINE;
mp->mscp_unit = rx->ra_hwunit;
mp->mscp_cmdref = 1;
*mp->mscp_addr |= MSCP_OWN | MSCP_INT;
/* Poll away */
i = bus_space_read_2(mi->mi_iot, mi->mi_iph, 0);
if (tsleep(&rx->ra_dev.dv_unit, PRIBIO, "rxonline", 100*100))
rx->ra_state = DK_CLOSED;
printf("rx->ra_state = %d\n",rx->ra_state);
if (rx->ra_state == DK_CLOSED)
return MSCP_FAILED;
printf("rx_putonline returns DONE\n");
return MSCP_DONE;
}
My guess is that the very first printf upsets the emulation timing just
enough to make things work. I'd have to read more code and RQDX3
documentation to take this further, but maybe this is enough to go on to
make it obvious to somebody else why Quasijarus on simh exhibits these
awfully long disk probe timeouts. I hope that once this problem has been
narrowed down a bit more, a fix to simh/vax will make all BSDs happy.
My first guess would be that there should be more "volatile" keywords used. I
think the printf()s cause the compiler to not discard some varibles. Does it
work without the printf()s if you don't use "-O" (or "-O2", etc)
optimization?
I think gcc does not elminitate varibles ever when the code is not optimized.
-----Original Message-----
From: Michael Sokolov [mailto:msokolov@ivan.Harhan.ORG]
Sent: Friday, September 26, 2003 3:48 PM
To: jmbw(a)nather.com; tuhs(a)tuhs.org
Subject: RE: [TUHS] Re: 4.3 BSD version in the Unix Archive
[...] If so, SIMH's MSCP emulation must be lacking in quality.
[...]But I will grant the possibility that the kernel is not w/o fault
either in that
perhaps it's going south (dereferencing a garbage pointer and crashing) when
the
MSCP controller (in this case SIMH's poor emulation) is doing something it
doesn't expect.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com)
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
http://minnie.tuhs.org/mailman/listinfo/tuhs
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
11:07 p.m.
New subject: 4.3 BSD version in the Unix Archive
From: Kenneth Stailey [mailto:kstailey@yahoo.com]
My first guess would be that there should be more
"volatile" keywords used.
I
think the printf()s cause the compiler to not discard
some varibles. Does
it
work without the printf()s if you don't use
"-O" (or "-O2", etc)
optimization?
I think gcc does not elminitate varibles ever when the
code is not
optimized.
Doesn't seem to make a difference, but I'll double-check.
I could be wrong, but I believe the printf will return as soon as the
physical output of the message has started - if so, it can very conceivably
affect the "real-time" behaviour of the code interfacing with the RQDX3.
Just a guess.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com)
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003
7718
days inactive
7723
days old
3 comments
3 participants
participants (3)
-
Kenneth Stailey -
Markus Weber -
msokolov＠ivan.Harhan.ORG