a275@mindlink.UUCP (Travers Naran) (07/24/90)
> DrBob@cup.portal.com writes: > > I'm hoping someone out there can enlighten me on the true meaning of > this guru meditation number: 87000004 265F48F1 > > When I look this one up in alerts.h, it tells me the error was detected > by dos.library and means "Unexpected packet received". Unfortunately, > this three-word explanation isn't helping me much. > > My program is a dos handler for tape drives, written in C. It also opens > a CON: window and Write()s messages to it. Three Write()s successfully > execute, then the fourth one prints its message in the window but never > returns to my program; instead I get the "task held" requester, then guru. > To add a bizarre note to this story, it only fails on A2000's and 2500s; > it has never failed on my home A1000+Supra system. > > I can't figure out what I'm doing wrong. Perhaps if I knew more about > what dos thinks is an "unexpected packet" during Write(), and how I could > be creating that situation, I might know where to look. Is there anything > special I have to do to Write() from a process which is not a CLI (the > handler process was created by Mount)? What does 265F48F1 mean? Well, unexpected packet recieved means (I think) the packet that was sent internally was not expected to be recieved from within a device process. Something new in 1.3 I guess. Playing with packets has always been a dangerous business. 265F48F1 is the memory adress the guru happened at. (hex). If you have another Amiga hooked up to your crashed Amiga's Serial Port via null modem, you can then enter the debug mode on the crashed Amiga and check the system out for the problem. -- ------------------------------------------------------------------- Travers "T'aran" Naran (I am male) Simon Fraser University, Computing Science (Burnaby, B.C., Canada) New Westminster, British Columbia, Canada, North America, etc... Whovian, Prober, Treker, Quantum Leaper.... Mailing addresses: Usenet Travers_Naran@mindlink.UUCP or uunet!van-bc!rsoft!mindlink!Travers_Naran ------------------------------------------------------------------
DrBob@cup.portal.com (Robert A Rethemeyer) (07/24/90)
I'm hoping someone out there can enlighten me on the true meaning of
this guru meditation number: 87000004 265F48F1
When I look this one up in alerts.h, it tells me the error was detected
by dos.library and means "Unexpected packet received". Unfortunately,
this three-word explanation isn't helping me much.
My program is a dos handler for tape drives, written in C. It also opens
a CON: window and Write()s messages to it. Three Write()s successfully
execute, then the fourth one prints its message in the window but never
returns to my program; instead I get the "task held" requester, then guru.
To add a bizarre note to this story, it only fails on A2000's and 2500s;
it has never failed on my home A1000+Supra system.
I can't figure out what I'm doing wrong. Perhaps if I knew more about
what dos thinks is an "unexpected packet" during Write(), and how I could
be creating that situation, I might know where to look. Is there anything
special I have to do to Write() from a process which is not a CLI (the
handler process was created by Mount)? What does 265F48F1 mean?
Your knowledgeable replies will be much appreciated!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bob Rethemeyer //"This is obviously some strange
DrBob@cup.portal.com -or- // usage of the word 'safe' that I hadn't
..!sun!portal!cup.portal.com!DrBob // previously been aware of." - A. Dentjesup@cbmvax.commodore.com (Randell Jesup) (07/26/90)
In article <2599@mindlink.UUCP> a275@mindlink.UUCP (Travers Naran) writes: >> DrBob@cup.portal.com writes: >> I'm hoping someone out there can enlighten me on the true meaning of >> this guru meditation number: 87000004 265F48F1 ... >> My program is a dos handler for tape drives, written in C. It also opens >> a CON: window and Write()s messages to it. Three Write()s successfully >> execute, then the fourth one prints its message in the window but never >> returns to my program; instead I get the "task held" requester, then guru. >> To add a bizarre note to this story, it only fails on A2000's and 2500s; >> it has never failed on my home A1000+Supra system. You CANNOT make most dos calls (specifically those that cause packets to be sent) from within a handler. The problem is that you have the process port receiving asynchronous messages while Dos is trying to use it synchronously to handle your dos call. >Well, unexpected packet recieved means (I think) the packet that was sent >internally was not expected to be recieved from within a device process. >Something new in 1.3 I guess. Playing with packets has always been a dangerous >business. Almost everyone who plays with handlers gets AN_AsynchPacket eventually. It's not new in 1.3 - 1.3 was (essentially) a WB release. It's been there since 1.0. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
aaron@madnix.UUCP (Aaron Avery) (07/28/90)
In article <32034@cup.portal.com> DrBob@cup.portal.com (Robert A Rethemeyer) writes: >I can't figure out what I'm doing wrong. Perhaps if I knew more about >what dos thinks is an "unexpected packet" during Write(), and how I could >be creating that situation, I might know where to look. Is there anything Well, basically, you're doing something which is not allowed. It's not well documented, but it's a no-no to call DOS functions from a DOS handler. The problem is that Write() is using the same message port that the handler uses for its input and output. When the packets get inter-mingled, bad things can happen. If you _really_ want to use DOS I/O from your handler, you'll need to create a new message port with a new signal bit and do all of the I/O by packets, all the while handling the incoming packets meant for you. The best low-level debugging option is still a terminal (or computer) hanging off the serial port and kprintf(). - Aaron -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams ARPA: madnix!aaron@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron
DrBob@cup.portal.com (Robert A Rethemeyer) (08/02/90)
In response to my question on guru# 87000004 265F48F1 in my tape handler, Randell Jesup, jesup@cbmvax.cbm.commodore.com writes... > You CANNOT make most dos calls (specifically those that cause packets > to be sent) from within a handler. The problem is that you have the process > port receiving asynchronous messages while Dos is trying to use it synchronou sly > to handle your dos call. and Aaron Avery, madnix!aaron@cs.wisc.edu writes... > Well, basically, you're doing something which is not allowed. It's not well > documented, but it's a no-no to call DOS functions from a DOS handler. > > The problem is that Write() is using the same message port that the handler > uses for its input and output. When the packets get inter-mingled, bad things > can happen. Thanks, this is the information I was looking for. It actually makes sense, once you think about it. I guess it didn't occur to me that Write() would be using the same port. So for Plan B, I will use another process to snoop the handler to find out what it needs to print. I'm learning this stuff as I go along. There is not much in the way of guidelines for writing handlers. The DOS TRM doesn't cut it. I've had to rely completely on example programs, the Transactor articles, and Trial and Error. This guru problem comes under the 'Error' category. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bob Rethemeyer //"This is obviously some strange DrBob@cup.portal.com -or- // usage of the word 'safe' that I hadn't ..!sun!portal!cup.portal.com!DrBob // previously been aware of." - A. Dent