#: 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 . 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. 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 . 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 !>