textfiles/messages/ALANWESTON/1993/CIS05_30.txt

#: 18193 S1/General Interest
    27-May-93  03:05:24
Sb: BUS ERRORS
Fm: Chris Hann (Mass UK) 100064,1431
To: all

I have a Radstone 68040 based system with a load of purpose built VME cards in
a 19" rack. Fine so far... but sometimes, possibly due to hardware
'irregularities (bugs but not wanting to hurt feelings)' the blessed things
fail to respond quickly (we have a third party card that sometimes refuses to
let go of it's VSB access to a RAM card for example, this eventually causes the
processor to fail when it tries to read the VME end) and an access error trap
occurs.

I am not having a lot fun with this and the following is what I think I know! I
originally posted this as an answer to my own question on the OSK section,
however I got no replies to the original so I thought I would put it in here as
well!

Cheers chapps!

After this is all inclusion of other reply>

When an access error occurs on the '040 it creates a type 7 stack
frame on the supervisor stack, this contains the PC at the error,
the CCR, the effective address, the 'broken pipe' information
(pending accesses in the pipeline at the error) and some other
stuff.

The processor then disables tracing and vectors to the access error
according to the vector in the vector table which is located
according to the VBR (since you need to be in supervisor state to
see this I can't tell exactly where it goes yet). OS-9 then finds
some space puts it's address in a5 and stacks the registers. It then
does some other stuff including overwriting the stack frame with the
register set (already stored at a5 remember) and some other stuff.

In the process it overwrites the really interesting bit ( the
effective address, at tleast I presume that is the access address
that went wrong ). It then drops you back into user mode and jumps
to your service routine leaving only the register set to work from
and without supervisor mode access.

I find this a little irritating (given that I'm correct). I'd like
to think I am wrong, however I cant reconcile the contents of the
supervisor stack with the '040 manual. There is too much data there
for it to be any other trap stack frame and all the registers have
changed, the manual says nothing about copying them to (a5)+ so I am
left to presume that OS-9 has deliberately hamstrung my ability to
find out which bit of hardware has temporarily bitten the dust.


AAAAAGH...

Obviously I could be more pleased, especially since this is a
specific port to the '040. Radstone say that they ship it in and
ship it out. Microware say not us mate we supply it to Radstone and
it's their lookout from then on.

Am I wrong or what??

Got any suggestions?

Thanks people.

Chann (mister slightly irritated 1993).
 

#: 18180 S5/OS9 Users Group
    25-May-93  00:07:53
Sb: #0s9/msdos
Fm: Paul Thomson 100250,165
To: all

Does anyone know of any utilities to read\write OS9 disks on MSDOS systems? I
have a floppy disk from an OS9 system which is 80 Track 26 sectors per track,
256 bytes per sector.  I can sucessfully read the raw sector data by
reprogramming the DOS drive table but as yet I know nothing of the dic

Paul Thomson

There is 1 Reply.

#: 18206 S5/OS9 Users Group
    30-May-93  03:30:31
Sb: #18180-#0s9/msdos
Fm: ole hansen 100016,3417
To: Paul Thomson 100250,165

Hello Paul

Try to look in lib12 for a demoprogram called OS9MAX. The 'real thing' will do
want you want. There should be an address for the supplier also. if you need
more help, please contact me.

ole@danlec.dk

There is 1 Reply.

#: 18207 S5/OS9 Users Group
    30-May-93  11:40:13
Sb: #18206-0s9/msdos
Fm: Bud Hamblen 72466,256
To: ole hansen 100016,3417

Bear in mind that you need an 80286 or better to run OS9MAX.  It wouldn't work
on my 8086.


#: 18185 S7/Telecommunications
    25-May-93  22:19:11
Sb: #18139-Sterm for OS-9000
Fm: Bill Dickhaus 70325,523
To: Timothy J. Martin 71541,3611 (X)

Yes, it is! Thanks for the upload. I'll download it tomorrow from work.

        -Bill-

#: 18198 S11/OS9/6809 (Non-CoCo)
    28-May-93  17:59:31
Sb: Msg 18054 and Smoke
Fm: Ken Drexler 75126,3427
To: Doug, 72667,1433

Doug

I saw your message asking about Smoke Signal Broadcasting and Xmode.  SSB never
offered Xmode. I have a copy which I got out of the CoCo Level II utility set.
It seems to run properly on my SSB system although I do not use it a lot so
have not given it a through test.

SSB was around at least through Fall 1985 when I met its president at a
Microware seminar.  I tried to call it a year or so later and found the phone
had been disconnected.  That is the last I heard of the company.  It was never
very big and got rolled over by Big Blue.  (Before it left, it flirted with a
68000 system running Regulus, a UNIX knock off.)

I have two SSB Level II machines. One has died with some mysterious memory
problem. The other I use daily at my law office for two users. We use it for
work processing and legal time accounting.  It continues to be solid as a rock
and about as heavy.

It is good to know there are a other SSB users around. I figured we must be an
extinct breed.  (There are, however, several ex-users on here from time to
time.)

Ken


#: 18175 S12/OS9/68000 (OSK)
    24-May-93  19:22:55
Sb: #18170-login
Fm: Bob van der Poel 76510,2203
To: Carl Kreider 71076,76 (X)

Thanks Carl. I'll nab it later and hopefully get all those files printed!

#: 18183 S12/OS9/68000 (OSK)
    25-May-93  18:00:47
Sb: #18158-#new unzip
Fm: Ernest Withers Jr. 71545,1117
To: Zack Sessions 71532,1555 (X)

Thanks, Zack. I'd appreciate it. By the way, are you planning on attending the
Atlanta fest in October? I got my ACS newsletter and it says there will
definitely be one.

Ernie.


There is 1 Reply.

#: 18184 S12/OS9/68000 (OSK)
    25-May-93  19:10:23
Sb: #18183-new unzip
Fm: Zack Sessions 71532,1555
To: Ernest Withers Jr. 71545,1117 (X)

 > Thanks, Zack. I'd appreciate it. By the way, are you planning on attending
the
 > Atlanta fest in October? I got my ACS newsletter and it says there will
 > definitely be one.

If there is a fest in Atlanta, I will be there. I haven't heard from the ACS
yet.

------------------------------------
 Zack C Sessions
 ColorSystems

 via InfoXpress/OSK by Bill Dickhaus

#: 18177 S12/OS9/68000 (OSK)
    24-May-93  19:22:59
Sb: #18173-new unzip
Fm: Bob van der Poel 76510,2203
To: Zack Sessions 71532,1555 (X)

I talked to Gary Lathum a while back when I was still trying to get the boot
roms on the mm/1 to work (I've sort of given up for now) and he suggested that
he was going to talk to Kevin or Mark and see if they could get a rotation
service (rotating patched i/o boards between users) so that we could all get on
the 9meg bandwagon. Never heard anything more from him...guess this is not a
'user mode'?

#: 18181 S12/OS9/68000 (OSK)
    25-May-93  00:17:38
Sb: #18171-#Printcap info needed
Fm: Mike Haaland 72300,1433
To: Carl Kreider 71076,76 (X)

Hi Carl,  I'm not quite sure what you mean by 'at' or '@' traps, but I did add
the nroff style expansion in headers.  So you can:

 .de h0 "Manual"
 .de h1 ""
 .de h2 "Best in the west"

 .he /\*h0/\*h1/\*h2/

Also dump titles anywhere on the page you want:

 .tl 'Left'Center'Right'

I'll grab cawf...  Thanks for uploading it.

There is 1 Reply.

#: 18186 S12/OS9/68000 (OSK)
    25-May-93  22:34:55
Sb: #18181-#Printcap info needed
Fm: Carl Kreider 71076,76
To: Mike Haaland 72300,1433 (X)

Well, I'm probably a bit fuzzy anymore, but as I recall, you would set a trap
at a line, for instance, with .at 5 tl - which would spring the trap at line 5,
executing the macro 'tl'.  It could execute arbitrary commands, but the most
useful is a macro.  I think .at was the TSC syntax and nroff is '.wh' maybe.
Anyway, it is a much more general and useful mechanism than the simplified
.h[0-3] that K&P used in software tools and everyone (myself included) snarfed
for their text processor.

You (and Bob) are welcome for cawf.

Carl

There are 2 Replies.

#: 18187 S12/OS9/68000 (OSK)
    26-May-93  02:26:06
Sb: #18186-Printcap info needed
Fm: Bob Taylor 73270,3124
To: Carl Kreider 71076,76

Carl,
  You are right. Nroff uses .wh (when) for traps. It is used in the beginning
page and end of page macros. I have Holub's work-a-like nroff, nr. I need
to do more work on it. He didn't have proportional working at all. When I
have time I intend to finish it.

Bob

#: 18204 S12/OS9/68000 (OSK)
    29-May-93  00:56:08
Sb: #18186-Printcap info needed
Fm: Mike Haaland 72300,1433
To: Carl Kreider 71076,76

I see what you mean now.  Nice trap. :)

I noticed that cawf can't handle .if/.ie commands, I tried searching thru the
groff source for any clue how they handle those.  Any ideas?

#: 18203 S12/OS9/68000 (OSK)
    29-May-93  00:56:01
Sb: #18171-Printcap info needed
Fm: Mike Haaland 72300,1433
To: Carl Kreider 71076,76

Thanks for the offer Carl,  It seems that printcap only specifies the device or
spoolfile and tells you what kind of print filter should be used.

Not really what I'm after, guess it's better to just use TCap and define needed
stuff.!  Oh well...

#: 18178 S12/OS9/68000 (OSK)
    24-May-93  19:23:04
Sb: #18152-InfoXpress idea
Fm: Bob van der Poel 76510,2203
To: Steve Wegert 76703,4255 (X)

Of course, if all users use VED as their editor, then you wouldn't need the
SPELL_CHECK env. variable...just couldn't resist getting this plug in.

#: 18179 S12/OS9/68000 (OSK)
    24-May-93  20:39:06
Sb: #Terminals
Fm: Bob van der Poel 76510,2203
To: all

I have a terminal hooked up to my mm/1 on /t3. I have reconfigured the rs-232
cable so that proper hardware handshaking (at least from the computer to the
terminal). I have type=80 in the /t3 desc.

It appears that the handshaking is working properly...If listing a very large
file, etc. I do see the 'busy' message on the terminal blinking. Same happens
during editor screen refreshes. I don't appear to lose any data...most of the
time. I have a 6 foot sheilded cable connecting the computer/terminal.

At 19200 this works perfectly. However, at 38400 I get occasional junk on the
screen. Now the question is there any way I can tell if this is a software
problem (ie. the mm/1 serial driver), a hardware problem (maybe the terminal
isn't as fast as it thinks), or if it is bitrot on the cable?

Guess the easiest solution is to use 19200 (I really can't tell the
difference)...but my curiousity has been raised.

There is 1 Reply.

#: 18188 S12/OS9/68000 (OSK)
    26-May-93  04:07:53
Sb: #18179-#Terminals
Fm: Mark Griffith 76070,41
To: Bob van der Poel 76510,2203 (X)

Bob,

 > Now the question is there any way I can tell if this is a software
 > problem (ie. the mm/1 serial driver), a hardware problem (maybe the terminal
 > isn't as fast as it thinks), or if it is bitrot on the cable?

Not too easy to do.  You could try a ribbon cable, and if it gets significantly
worse, then you could suspect the cable.  It is more probably due to a
combination of everything you mentioned.  BTW: I've never seen a terminal that
worked perfectly at 38.4kbaud.  At least not so far.  Maybe the newer ones
will.


                  /************* /\/\ark ************/

There is 1 Reply.

#: 18190 S12/OS9/68000 (OSK)
    26-May-93  21:19:24
Sb: #18188-Terminals
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)

Figured as much. Guess the bandwidth at that rate is pretty narrow and any
timing irregularities would show up. I'll just reset things to 19200.

#: 18182 S12/OS9/68000 (OSK)
    25-May-93  02:20:55
Sb: #68k bus errors
Fm: Chris Hann (Mass UK) 100064,1431
To: all

I am developing a realtime image processing system using OS9 on a 68040 VME
rack. Unfortunately some of the hardware doesn't always respond correctly
giving rise to bus errors.

I have written a trap handler which gives me execution address and registers,
however I cannot reliably and quickly find the access address that caused the
error. Running in the debugger takes 30+ minutes to finish initialisation and
realtime execution is not possible.

Does anyone have a trap handler that can find the access address which caused
the error.

Is my trap handler worth posting in the library??

Thanks in advance.

Chris Hann 

There is 1 Reply.

#: 18192 S12/OS9/68000 (OSK)
    27-May-93  02:54:31
Sb: #18182-#68k bus errors
Fm: Chris Hann (Mass UK) 100064,1431
To: Chris Hann (Mass UK) 100064,1431 (X)

OK... I'll have a go at answering this myself (having read the '040
manuals and run a few tests).

When an access error occurs on the '040 it creates a type 7 stack
frame on the supervisor stack, this contains the PC at the error,
the CCR, the effective address, the 'broken pipe' information
(pending accesses in the pipeline at the error) and some other
stuff.

The processor then disables tracing and vectors to the access error
according to the vector in the vector table which is located
according to the VBR (since you need to be in supervisor state to
see this I can't tell exactly where it goes yet). OS-9 then finds
some space puts it's address in a5 and stacks the registers. It then
does some other stuff including overwriting the stack frame with the
register set (already stored at a5 remember) and some other stuff.

In the process it overwrites the really interesting bit ( the
effective address, at tleast I presume that is the access address
that went wrong ). It then drops you back into user mode and jumps
to your service routine leaving only the register set to work from
and without supervisor mode access.

I find this a little irritating (given that I'm correct). I'd like
to think I am wrong, however I cant reconcile the contents of the
supervisor stack with the '040 manual. There is too much data there
for it to be any other trap stack frame and all the registers have
changed, the manual says nothing about copying them to (a5)+ so I am
left to presume that OS-9 has deliberately hamstrung my ability to
find out which bit of hardware has temporarily bitten the dust.


AAAAAGH...

Obviously I could be more pleased, especially since this is a
specific port to the '040. Radstone say that they ship it in and
ship it out. Microware say not us mate we supply it to Radstone and
it's their lookout from then on.

Am I wrong or what??

Got any suggestions?

Thanks people.

Chann (mister slightly irritated 1993).
 

There is 1 Reply.

#: 18195 S12/OS9/68000 (OSK)
    27-May-93  19:32:39
Sb: #18192-#68k bus errors
Fm: Bob van der Poel 76510,2203
To: Chris Hann (Mass UK) 100064,1431 (X)

Is it possible, for the purpose of finding the bug, to run your program in
system mode? That way when the bug hit, the conversion stuff should not be
done. You could also use sysdbg to monitor things.

There is 1 Reply.

#: 18197 S12/OS9/68000 (OSK)
    28-May-93  03:12:58
Sb: #18195-#68k bus errors
Fm: Chris Hann (Mass UK) 100064,1431
To: Bob van der Poel 76510,2203 (X)

Pardon my ignorance but how exactly do I run something in system mode? If there
is a way I can always run in system mode then fine I'll do it!

What I have been able to do after talking to Radstone is interrupt the system
to get to the ROM debugger and type the command 'ov2' which traps bus errors to
the rom monitor. This lets me find a particular hard error more quickly.
However the thing I really need is a software fix that I can leave in the
system permanently which will trap all bus errors. Part of my problem is that
the customer is keen to point the finger at our system for any failure as the
unit under test is more than a year late and they desperately need excuses, if
I can add a facility which will point to the problem directly then so much the
better. I should add that the system contains seven third party boards, three
Mass boards and five customer supplied boards ( three of which are
modifications of previous designs supplied by ourselves ), all but one of the
reported faults have been in the customer supplied boards (generally in their
two homebuilt boards but occasionally in the modified boards and then always in
the modifications). Sorry that's a load of political stuff but my backside is
getting singed every time they have a fault and I am getting a little tired of
having to break the news to them.

In general the OS-9 error messages "000:102" are very poor, almost all other
opperating systems will give an execution and access address.

If I find a good solution I'll let you know.

Chann 

There are 2 Replies.

#: 18199 S12/OS9/68000 (OSK)
    28-May-93  19:50:28
Sb: #18197-68k bus errors
Fm: Bob van der Poel 76510,2203
To: Chris Hann (Mass UK) 100064,1431

Have a re-read of section 2, The Kernel, in the OS9 Tech. Ref. Manual. It tells
you why not to run user stuff in system mode...and tells how to do it <g>.

Sounds like you have quite a witch's brew of potential faults. Good luck in
tracking down the culprit(s).

#: 18205 S12/OS9/68000 (OSK)
    29-May-93  17:33:40
Sb: #18197-68k bus errors
Fm: Bob van der Poel 76510,2203
To: Chris Hann (Mass UK) 100064,1431

If you haven't already, have a look at "The OS9 Guru". There is an excellent
section on trapping bus errors, etc. in it. It is avail from Galatic Industrial
Ltd.

#: 18191 S12/OS9/68000 (OSK)
    26-May-93  21:46:24
Sb: #strange happening?!?
Fm: Zack Sessions 71532,1555
To:  ALL

Tonight I wanted to load up some stuff to one of my hard drives. Since it was a
large directory, I wanted to put it to the disk which had the most space
available. I was logged into UID 100.1 and the disks were formatted by user
0.0. When I did a free on /h0, I got the normal output. But when I tried a free
command on /h1 (from the 100.1 account) it displayed the first line of the the
output which contains the volume label and creation date, but it then says,
"free: can't read bitmap.". I thought I had trashed /h1, but a directory of /h1
worked fine.

So I logged in the superuser account, UID 0.0, and tried the free command on
/h1 and it worked! Then I ran a dcheck on /h1 and it reported no errors. Well,
I hadn't trashed my disk, but what IS the problem running a free command from a
non-superuser account? And why is this just now happening when it didn't happen
before?

I thought it was the device attributes. I first tried to look with ded. But a
ded of /h1@ showed NO data! A ded on /h0@ worked just fine. (Now, these are
from the superuser account, now!). I was able to dump the super block on both
drives finally with dump on /h0@ and then /h1@, and both drives are owned by
0.0 and have an attributes mask of $FF.

Anybody got any ideas?

------------------------------------
 Zack C Sessions
 ColorSystems

 via InfoXpress/OSK by Bill Dickhaus

There are 2 Replies.

#: 18194 S12/OS9/68000 (OSK)
    27-May-93  19:32:35
Sb: #18191-#strange happening?!?
Fm: Bob van der Poel 76510,2203
To: Zack Sessions 71532,1555 (X)

This really sounds just like the problem I had when I first got my 2nd HD! But,
I find it hard to believe that it is only hitting you now...must be another
problem. But, just in case it isn't (and for others too), when I got my 2nd HD
I followed the instructions in the mm/1 tech manual to create a descriptor for
H1. Kids--don't do this at home; it doesn't work!

Each descriptor for a HD on a SCSI bus must have a different controller ID AND
it must have a different PORT. To check, do a DMODE -p /h1 and then /h0. Make
sure the port=xxx is different. This is easy to do if you use the desc.
supplied with the upgrade stuff.

From my understanding (which could be WRONG) the least significant byte in the
port address is ignored as far as finding the scsi port is concerned; but it is
used by the driver to determine that /h1 and /h0 are different devices. I'm not
sure why it just doesn't use the controller ID, but it doesn't.

BTW, as a matter of interest I have the attributes on /h1 set to super-only
access. If I logon as user 3.3 I CAN do a free /h1; but not a dir /h1.

Hope this helps...

There is 1 Reply.

#: 18196 S12/OS9/68000 (OSK)
    27-May-93  21:56:08
Sb: #18194-#strange happening?!?
Fm: Zack Sessions 71532,1555
To: Bob van der Poel 76510,2203 (X)

 >
 > Hope this helps...
 >

Well, no, it didn't. <g>

I had a second hard drive on my system for several weeks with no problem. Then
I had to remove the second HD when I took my system to the fest. When I got
back home and hooked it back up, I reformatted it and loaded it back up from
tape backups. I haven't noticed the free problem until just yesterday.

I can remember doing free commands on both HDs from the 100.1 account many
times before the fest.

------------------------------------
 Zack C Sessions
 ColorSystems

 via InfoXpress/OSK by Bill Dickhaus

There is 1 Reply.

#: 18200 S12/OS9/68000 (OSK)
    28-May-93  19:50:31
Sb: #18196-#strange happening?!?
Fm: Bob van der Poel 76510,2203
To: Zack Sessions 71532,1555 (X)

Since you said "it didn't help", I do assume that you did check the port
addresses on the descriptors <g>.

Since it apparently did work before...have you checked the cables, etc?

Just checked my startup file and I do an "iniz /dd /h1". I don't believe this
should be necessary...but you might want to play with the possibility.

There is 1 Reply.

#: 18201 S12/OS9/68000 (OSK)
    28-May-93  21:39:54
Sb: #18200-strange happening?!?
Fm: Zack Sessions 71532,1555
To: Bob van der Poel 76510,2203 (X)

Bob, you seem to be a little confused. The drive works just fine. There are
only two things I cannot appear to do.

1) do a "free /h1" command from a non-superuser account.

2) do a "ded /h1@" command from a superuser account.

------------------------------------
 Zack C Sessions
 ColorSystems

 via InfoXpress/OSK by Bill Dickhaus

#: 18202 S12/OS9/68000 (OSK)
    29-May-93  00:55:52
Sb: #18191-strange happening?!?
Fm: Mike Haaland 72300,1433
To: Zack Sessions 71532,1555 (X)

Hmmm.  I can't duplicate the problem here, so it must have something to do with
your device descriptor or something, maybe the free attr?  100.1 works just
fine here.  Wish I could be of more help.


#: 18189 S14/misc/info/Soapbox
    26-May-93  19:25:04
Sb: OS9 Underground
Fm: Bob van der Poel 76510,2203
To: all

Strange things are not always bad... Opened my post office box today and was
shocked to find a copy of the OS9 UnderGround! The editorial has a detailed
exp. of why it's late, etc.

Good thing it was published. Remember my 'battle' with MG about the malloc.h
thing... well, the article I promised ya all on this is in this issue (the
reason that is good is that I lost my copy of the ms.)

And MG has an article in there too. All in all, it is a good little issue. Hope
that Alan can keep up his promises.

Press <CR> !>