Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#141 Some network card can't work well with ndis-bridge

v0.8.x (devel)
closed-fixed
Henry N.
7
2009-02-10
2008-11-29
Anonymous
No

"Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller", this card is integrated with asus p5q-se motherboard(I have updated to the latest driver), ping between the host and the colinux will hang the host(but arping works well).

I also tested another card "Realtek RTL8168C(P)/8111C(P) PCI-E Gigabit Ethernet NIC", it is integrated with giga ep31 motherboard, but it did not have this problem.

Discussion

  • Henry N.
    Henry N.
    2008-11-30

    What does the problem, if you replace the ndis-bridge with pcap-bridge?
    Today the filter rule for ndis-bridge was changed. Perhaps this solves your problem?

     
  • New snapshot 1130 solve the Non-IP packet problem. This time I meet this bug too, my card is Atheros L2.

     
  • After some research, I think the problem is packet forward loop. Filtering out packets from virtual mac to self/broadcast packets seems fix it.

     
  • The real problem is NdisSend() with dest == hostMac, previous comment is wrong.
    Drop packet with dest == OID_802_3_CURRENT_ADDRESS fix it, but host & guest can't commucation anymore.

     
  • pcap-bridge did not have this problem. I also upgraded to 1130, this problem still existed.

     
  • Henry N.
    Henry N.
    2008-12-07

    Have a host with same problem. - That's good, so I can trace it.

    A ping from coLinux to host freezes the host.
    The card is a Realtek RTL8102E Family PCI-E Fast Ethernet NIC.

     
  • Henry N.
    Henry N.
    2008-12-07

    • assigned_to: nobody --> henryn
     
  • Henry N.
    Henry N.
    2008-12-09

    • priority: 5 --> 7
     
  • Henry N.
    Henry N.
    2008-12-09

    This is hard to debug. I found an error in co_debug now.

    All back call handlers, for example SendCompleteHandler=co_conet_proto_send_complete are in "IRQL: DISPATCH_LEVEL", see Requirements on this article http://msdn.microsoft.com/en-us/library/ms797308.aspx

    If we call a KeWaitForSingleObject from DISPATCH_LEVEL we risk a BSOD Bug Check 0xB8: ATTEMPTED_SWITCH_FROM_DPC (http://msdn.microsoft.com/en-us/library/ms795832.aspx). Exactly that does co_debug(), so I can not use it.

    An interesting article about IRQL I found here: http://ext2fsd.sourceforge.net/documents/irql.htm

    For the NdisSend, I assume any of the completion call backs tries NdisAcquireSpinLock, and that can hang on disabled interrupts (DISPATCH_LEVEL = disabled interrupts). NdisAcquireSpinLock is a macro for KeAcquireSpinLock. Should we use NdisDprAcquireSpinLock (alias KeAcquireSpinLockAtDpcLevel) in this call back routines?

    For better overview have created function flows graphics from ndis driver:
    http://www.henrynestler.com/colinux/codeviz/ndis-bridge/

     
  • Henry N.
    Henry N.
    2009-02-10

    Was a wrong parameter in case of non pending packet after NdisSend.
    Found and committed to SVN as revision r1218.

     
  • Henry N.
    Henry N.
    2009-02-10

    • labels: --> Crash / BSOD
    • status: open --> closed-fixed