rminnich@udel.EDU (Ron Minnich) (12/23/87)
After a short mail discussion with Marco Papa (Thanks!) light bulbs are beginning to go on. It is becoming clear that the problem is in internet.device. Since my RKMs are less then forthcoming about such things maybe someone out here will have another idea. Problem is that, for example, if i do a DoIO, internet.device eventually responds, when it is all done, with a ReplyMsg. Then the DoIO returns. All subsequent DoIOs return immediately, i.e. long before the ReplyMsg in the device. So, somehow a bit of state (pun intended- though it may be more than one bit) gets set and is not getting properly cleared somewhere else. The DoIOs always return 0, so it is not as though there is an error occuring. Also, internet.device registers the incoming io requests. But, the telnet program performing the DoIO does not block until the ReplyMsg- DoIO returns immediately (i.e. incorrectly) on the second and succeeding operations. So, one last appeal, any ideas? ron P.S. I note on comp.sys.hypercard (or whatever it is called) the following comment- ' I LOVE multifinder'. Multitasking (or pseudo-) market penetration continues. Next they're gonna say "how come they can't all do work when i'm not lookin' at 'em?" And programs for MAC are going to advertise that they DO do work when you are looking at something else. And, eventually, Atari and others will announce multi-tasking. And this whole discussion will seem a little quaint. -- ron (rminnich@udel.edu)
jesup@pawl23.pawl.rpi.edu (Randell E. Jesup) (12/24/87)
In article <897@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes: > Problem is that, for example, if i do a DoIO, internet.device >eventually responds, when it is all done, with a ReplyMsg. Then >the DoIO returns. All subsequent DoIOs return immediately, i.e. >long before the ReplyMsg in the device. So, somehow a bit of state >(pun intended- though it may be more than one bit) gets set and >is not getting properly cleared somewhere else. The DoIOs always >return 0, so it is not as though there is an error occuring. Also, >internet.device registers the incoming io requests. But, the telnet >program performing the DoIO does not block until the ReplyMsg- DoIO >returns immediately (i.e. incorrectly) on the second and succeeding >operations. Aha! I'll assume you are just using DoIO, no WaitIO's (as in the previous message - I'd assumed you were using SendIO or BeginIO). Note that DoIO always tries Quick IO first, then normal IO if it fails. SendIO never uses QUICK, and BeginIO allows you to play. See the discussion Quick io in the RKM under IO. The device has certain responsibilites when it comes to clearing/whatever the quick bit, depending on how it is processed (quick or not). Note many devices support quick for only a few commands, the rest have to wait for completion. ( Essentially, this is what DoIO does: Set IOF_QUICK bit. Do a BeginIO check to see if quick bit still set, if so, return. else do a SendIO, then a WaitIO, then return. ) // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// lunge!jesup@beowulf.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/24/87)
> Essentially, this is what DoIO does: > Set IOF_QUICK bit. > Do a BeginIO > check to see if quick bit still set, if so, return. > else do a SendIO, then a WaitIO, then return. 'Essentially' is right! But you left out one important fact: DoIO() not only sets the IOF_QUICK bit, but clears all the other bits in the Flags field! Realizing that you are putting it into terms anybody can understand, but still a stickler for accuracy (even if my spelling is a bit odd this early in the morning), DoIO() doesn't actually start up a SendIO()... the Begin() did that when the device driver found it could not do the request syncronously. The reply port is actually supplied by the device driver (I think.. at least it is NOT supplied by the DoIO() function, and NOT by the user, so that leaves the device driver!) -MaWTT er, -Matt
louie@trantor.umd.edu (Louis A. Mamakos) (12/24/87)
In article <8712241144.AA26621@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > The reply port is actually > supplied by the device driver (I think.. at least it is NOT supplied > by the DoIO() function, and NOT by the user, so that leaves the > device driver!) This give me a real uncomfortable feeling inside. I'm not so sure that the use doesn't need to provide a ReplyPort for requests that are started using DoIO(). For all of the sample device drivers I've seen, as well as the diddly drivers that I've written, it sure seems that the user has to provide the port. In fact, the device can't provide its own internal reply port for DoIO() to use. This is because the device doesn't know if he was called by DoIO(), or if the user decided to just do a BeginIO on his own with the QUICKIO flag set. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/25/87)
:In article <8712241144.AA26621@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
:> The reply port is actually
:> supplied by the device driver (I think.. at least it is NOT supplied
:> by the DoIO() function, and NOT by the user, so that leaves the
:> device driver!)
:
:This give me a real uncomfortable feeling inside. I'm not so sure that the
:use doesn't need to provide a ReplyPort for requests that are started using
:DoIO(). For all of the sample device drivers I've seen, as well as the
:diddly drivers that I've written, it sure seems that the user has to provide
:the port.
:
:In fact, the device can't provide its own internal reply port for DoIO() to
:use. This is because the device doesn't know if he was called by DoIO(), or
:if the user decided to just do a BeginIO on his own with the QUICKIO flag
:set.
:
You are right... it looks like DoIO() needs a reply port! The DoIO()
ROM code itself makes an access through the replyport field without checking
to see if it is NULL first:
? DoIO()
move.l a1,-(a7)
move.b #1,1e(a1) set IOF_QUICK
move.l a6,-(a7)
movea.l 14(a1),a6
jsr -1e(a6) call device driver
movea.l (a7)+,a6
movea.l (a7)+,a1
btst #0,1e(a1) check IOF_QUICK
bne.s done2 if still set, DONE
move.l a2,-(a7)
?u
movea.l a1,a2
movea.l e(a2),a0 A0=reply port
move.b f(a0),d1 D1=sig bit
moveq #0,d0
bset d1,d0
Disable()
loop cmpi.b #7,8(a2) nt_Type.. has request been
returned?
beq.s done
Wait() Wait
?u
bra.s loop Loop.
UnLink() Unlink request
Enable() Re-enable
done: movea.l (a7)+,a2
done2: move.b 1f(a1),d0 error field in request
ext.w d0
ext.l d0
rts
P.S. I simplified the disassembly... All the calls except Wait() are actually
in-line code.
-Mattjxc@rayssd.RAY.COM (Jeffrey J. Clesius) (12/30/87)
In article <181@imagine.PAWL.RPI.EDU> beowulf!lunge!jesup@steinmetz.UUCP writes: > > Aha! I'll assume you are just using DoIO, no WaitIO's (as in >the previous message - I'd assumed you were using SendIO or BeginIO). >Note that DoIO always tries Quick IO first, then normal IO if it fails. >SendIO never uses QUICK, and BeginIO allows you to play. See the discussion >Quick io in the RKM under IO. > ... > ( Essentially, this is what DoIO does: > Set IOF_QUICK bit. > Do a BeginIO > check to see if quick bit still set, if so, return. > else do a SendIO, then a WaitIO, then return. > ) Why not use EieIO? ( With a quick bit here, and a quick bit there, here a bit, there a bit... ) Sorry... I couldn't resist. ______________________________________________________________ | Jeffrey Jay Clesius, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4015) | | { allegra | gatech | mirror | raybed2 } -----\ | | { linus | ihnp4 | uiucdcs } --------------->!rayssd!jxc | |______________________________________________________________| -- "I used to know what the first thing to go was, but I forgot..."