Author Topic: patched AFINETK.SYS: anyone willing to test ?  (Read 2322 times)

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 76
  • Posts: 817
  • Karma: +23/-0
    • View Profile
Re: patched AFINETK.SYS: anyone willing to test ?
« Reply #15 on: December 01, 2020, 11:56:31 am »
Hallo Dariusz,

thanks for the feedback. Well, looks like my attempts were not sufficient which is perfectly possible.
As to your observations: I had patched in to turn off interrupts (and back on at the end) on the RECEIVELOOKAHEAD and RECEIVECHAIN to rule out some interrupt concurrency issues. But the NDIS specs does not recommend that and possibly that leads to loss of packets (that's why you need to refresh to trigger the resending of packets) and will occur more likely on a multi core system (I am running OS/2 on Virtualbox and as you likely know that only works properly with one CPU).

For the trap I have been trying to solve, I can only say the following: AFINETK is passed on the stack the address of a buffer (containing the ethernet frame) received by the MAC driver (on the RECEIVELOOKAHEAD call) which in your case is MMRE. I added trace info to AFINETK.SYS and I can say that "normally" that address is perfectly ok but I am using a different MAC driver (E1000) but I'd expect the same to hold true for MMRE (otherwise you'd experience traps from the very first minute).
But when the trap happens, that buffer address is complete bogus which means that either the stack has been overwritten (BAD BAD BAD) or that for that instance, MMRE has placed a bogus buffer address on the stack.

For the time, I fear I am out of ideas. I'll have to think about how I can prove that the stack has been modified/overwritten when the trap happens. If the stack is overwritten, AFINETK or the MAC driver could be the culprit, if it is not, it would have to be the MAC driver that is the culprit.

« Last Edit: December 01, 2020, 12:02:50 pm by Lars »