rminnich@udel.EDU (Ron Minnich) (12/22/87)
I have a very simple question and i think a very simple problem involving internet.device. Here is the scenario: Telnet does a SendIO(Request). internet.device gets the request, and adds the request to a List. Later on, internet.device does the IO. It gets the request, and all looks good. the request is acted on (in this case, a recv_tcp). Then, internet.device does a ReplyMsg(Request). A Message is the first element of the structure, and the structure does conform to all the rules about what has to be in the front and in what order. Telnet gets the news. It does a CheckIO(Request), which returns non-zero value. It also does a WaitIO for grins, and gets a zero back. Then the fun begins. The port in this case is called tcpinp. If i look at tcpinp->MsgList (not the exact name), the lh_Head points to Request, and lh_TailPred points to Request. But a GetMsg(tcpinp) returns a 0! How can this happen? Next, after the GetMsg call, a look at the MsgList structure shows that lh_TailPred points to lh_Head, and lh_Head points to lh_Tail. So it looks like the list got emptied, but ... if i do a CheckIO, it still returns a non-zero value! What conditions cause a CheckIO to return non-zero? Is the Flags element of a request what is looked at by CheckIO? I thought it was the ReplyPort that really mattered. Then, to top it off, if i do a SendIO(Request), the whole machine locks up tight as a drum. Now i am sure i am doing something quite dumb. Can anyone tell me what to look for? -- ron (rminnich@udel.edu)
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (12/23/87)
In article <890@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes: > Telnet gets the news. It does a CheckIO(Request), which returns >non-zero value. It also does a WaitIO for grins, and gets a zero > ^^^^^^ <-- Significant >back. Then the fun begins. The port in this case is called tcpinp. >If i look at tcpinp->MsgList (not the exact name), the lh_Head >points to Request, and lh_TailPred points to Request. But a >GetMsg(tcpinp) returns a 0! How can this happen? It pays to keep the OLD manuals around: Rom Kernel Manual >> V1.0 <<, p. 6-6: "DoIO will internally use the ReplyPort; when the IO is completed, you "know" that your IORequest block is again free for re-use. DoIO puts your task to sleep waiting for the return of the IORequest block at the ReplyPort, then wakes up your task automatically removing the message from the port for you. "...WaitIO, as with DoIO, also internally uses the ReplyPort. If you use WaitIO, it will not be neccesary to use GetMsg after your task awakens." Personally, I too find it curious that your MsgPort's MsgList still still points at IORequest. However, have you checked the entries in your IORequest's io_Message.mn_Node structure to see if they're still pointing to the list header? > Then, to top it off, if i do a SendIO(Request), the whole machine >locks up tight as a drum. Now that *is* weird. I strongly suggest inspecting the io_Message.mn_Node structure to see what it says. It could be that the call to GetMsg() is messing things up. Wild Guess: GetMsg() looks at the header and finds the IORequest. GetMsg() then moves to the IORequest to dequeue it, and finds that the node structure is not linked to the header. GetMsg() gets hopelessly confused, screws something up, and returns a NULL. The next call to SendIO() causes the system to discover GetMsg()'s screw-up, and gets really lost. One thing seems certain, however: If you're using WaitIO() for I/O completion, you shouldn't use GetMsg(), too. And if you're using GetMsg() or WaitPort(), you shouldn't be using WaitIO(). Dale? Jimm? Bart? Could one of you dig up Carl Sassenrath and ask him to comment on this? The operation of the I/O system has never been totally clear. It'd be nice to get Carl's gospel on all aspects of I/O and its relation to the message system. Maybe we should invite him to speak at a BADGE meeting..... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jesup@pawl23.pawl.rpi.edu (Randell E. Jesup) (12/24/87)
In article <890@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes: >I have a very simple question and i think a very simple problem >involving internet.device. Here is the scenario: ... > Telnet gets the news. It does a CheckIO(Request), which returns >non-zero value. It also does a WaitIO for grins, and gets a zero >back. Then the fun begins. The port in this case is called tcpinp. >If i look at tcpinp->MsgList (not the exact name), the lh_Head >points to Request, and lh_TailPred points to Request. But a >GetMsg(tcpinp) returns a 0! How can this happen? Note: while it is not mentioned in the autodocs (people at C/A also might want to note for the next autodocs), WaitIO removes the message from the port, no GetMsg needed (it'll return 0 always). Beyond that, it sounds like many errors I've had: They seem absolutely incomprehensible, to the point of blaming compilers/OS/whatever, until you walk through it or tweak it for the nth time and the light suddenly dawns. A first step: dump the GetMsg and CheckIO, just WaitIO (if you don't mind waiting, and know it'll be sent back.) Next step, if it still doesn't work, triple-check everything, make sure you're not playing with it anywhere you shouldn't, snapshot the list before and after the WaitIO (Note: the message will still have pointers to the list in it). If it still doesn't work, look at any code that uses messages you can find (like vt100 x.x). >ron (rminnich@udel.edu) // 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)