home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / tcpip / ibmpc / 7201 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  2.8 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!ogicse!das-news.harvard.edu!husc-news.harvard.edu!burrhus!ddl
  2. From: ddl@burrhus.harvard.edu (Dan Lanciani)
  3. Newsgroups: comp.protocols.tcp-ip.ibmpc
  4. Subject: new dis_pkt
  5. Message-ID: <1992Dec31.070922.19010@burrhus.harvard.edu>
  6. Date: 31 Dec 92 07:09:22 GMT
  7. Article-I.D.: burrhus.1992Dec31.070922.19010
  8. Organization: Harvard University, Cambridge, MA
  9. Lines: 43
  10.  
  11. A new version of the NDIS/packet driver converter is now available for
  12. anonymous ftp from hsdndev.harvard.edu in pub/dis_pkt.  It attempts to
  13. work around (but does not solve) the problem discussed below:
  14.  
  15. The Packet Driver spec's send_pkt call requires that the driver be
  16. finished with the passed buffer when the send function completes.  The
  17. NDIS Transmit function can return a status indicating that the request
  18. is queued, with the memory buffer still ``owned'' by the driver.  An
  19. obvious solution is for dis_pkt's send_pkt routine to loop until the
  20. send operation is actually complete.  Unfortunately, some NDIS drivers
  21. will queue but never complete a send request if called at certain ``bad''
  22. times.  Looping would therefore cause deadlock.
  23.  
  24. Until now, dis_pkt has simply returned from send_pkt even if the underlying
  25. driver indicates that the request is queued.  Because of the structure of
  26. protocol stacks and the relative speed of the network and cpu, things have
  27. worked most of the time:  the protocol stack does not scribble on the buffer
  28. before it gets sent on the network.  Recently, though, I've been able
  29. to see the problem manifest itself (as expected) with duplicate/missing
  30. packet pairs.
  31.  
  32. As a first step to reducing the impact of the problem, I added a loop
  33. with timeout to the send_pkt routine.  This helps, but for certain
  34. drivers the loop fails too regularly because of an interaction with
  35. the IndicationComplete/chainvec logic.  In particular, the WD/SMC
  36. driver never completes a send request from within an IndicationComplete
  37. routine.  Any protocol that runs on the tail of the chainvec and tries
  38. to send multiple packets can therefore run into problems.
  39.  
  40. The best work-around appears to be to avoid the IndicationComplete
  41. code and instead advertise the adapter's true interrupt vector
  42. to the packet driver application.  To this end, the chainvec
  43. setting in protocol.ini now accepts arbitrary values.  If the value
  44. is less than 16 it is assumed to be the true interrupt and dis_pkt
  45. never actually calls the vector.  It is necessary to manually
  46. specify the correct vector (i.e., 8+irq) for chainvec.  (Use with
  47. irqs 9-15 is not yet supported.)  When more NDIS v2 drivers become
  48. available, this process may be automated since v2 provides the irq
  49. in a characteristics table.  Extracting the information from protocol.ini
  50. is another possibility but it would require knowing all the defaults...
  51.  
  52.                 Dan Lanciani
  53.                 ddl@harvard.*
  54.