<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 30, 2009, at 7:23 PM, Robin Green wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Vasily,<br>I am sure that the patched code is still not correct. A thread switch could occur between the unlocking of one lock and the locking of another - right?</blockquote><div><br></div><div>Need investigate that. </div><div><br></div><div>But I think root cause of the problem isn't here (race), because earlier or later urgent channel will be waken up, by ICMP message from host and will wakeup Recv thread. But for me problem is located at mbuf zone water line mechanism some basic implementation of rfc 896. Have you tried first today's suggestion? </div><br><blockquote type="cite"> So, you would need to lock the *same* lock that is currently locked by RTSemEventWait (on systems that use semevent-posix.cpp, anyway), so that that lock will be temporarily released while it waits.<br>
<br>However, there is a problem here. With systems like Mac OS X that use semevent-posix.cpp, the implementation of RTSemEventWait in there uses a lock. So, OK, it should be possible to lock that lock (but you might have to prevent locking the same lock twice). But on Linux, semevent-linux.cpp is presumably used, and the implementation of RTSemEventWait in there does *not* use a lock! I think this is wrong - you can't use the code in RTSemEventWait in semevent-linux.cpp to implement a correctly-working condition variable or semaphore for what you're trying to do, because to implement it correctly you need to hold a lock to avoid race conditions, and atomically release the lock while you wait.<br>
<br>I know this stuff can be confusing - I find it confusing myself, and I might have misunderstood it - so please, do not hesitate to ask for further explanation.<br>
<br>-- <br>Robin<br><br><div class="gmail_quote">2009/11/30 Vasily Levchenko <span dir="ltr"><<a href="mailto:Vasily.Levchenko@sun.com" target="_blank">Vasily.Levchenko@sun.com</a>></span><br><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; ">
<div style="word-wrap: break-word;"><div>Hi Robin,</div><div>Could you please check, that patch solves problem for you?</div></div>
<br><div style="word-wrap: break-word;"><br><div><div>On Nov 28, 2009, at 7:30 PM, Robin Green wrote:</div><br><blockquote type="cite">Further to my earlier report on this list of NAT adapters stopping
working with svn and 3.1.0 beta versions, I believe I have identified
the problem.<br>
<br>
r23462 introduced the bug, by introducing a new thread to process
"urgent" packets, the communication of which with the existing thread
isn't properly synchronised. Basically, it's the classic bug of sending a signal to a thread (in this case, the existing, non-urgent thread) without using a critical section to ensure that the target thread is waiting for the signal when it's sent. So occasionally the non-urgent thread misses the signal, and thus (for all practical purposes) never wakes up, because it's waiting indefinitely.<br>
<br>There *is* a lock taken inside RTSemEventSignal and RTSemEventWait, but that doesn't prevent this because it only covers the waiting and signalling itself, and not the real work. This (locking but making the critical section too small) is also a classic bug.<br>
<br>I haven't tried to fix this because I'm not familiar with the code, but this is my best guess at what's going wrong.<br>-- <br>Robin<br><br><div class="gmail_quote">2009/11/26 Robin Green <span dir="ltr"><<a href="mailto:greenrd@gmail.com" target="_blank">greenrd@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think I've found something important. The responses stop appearing in the pcap log file immediately after VirtualBox sends the first ICMP type 4 packet (wireshark says this is "Source quench (flow control)"). The packet is also malformed in the .pcap file, according to wireshark, which says it has a wrong header checksum - not for the overall packet, but in a nested IP header inside the ICMP packet.<br>
<br>-- <br>Robin<br><br><div class="gmail_quote">2009/11/26 Robin Green <span dir="ltr"><<a href="mailto:greenrd@gmail.com" target="_blank">greenrd@gmail.com</a>></span><div><div></div><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
OK, this time I fortunately managed to reproduce the bug very quickly, *and* I got a host log file as well using wireshark. This time I used r24972.<br><br>I had a quick look at both .pcap files in wireshark. If you look for example at my attempt to ping 137.44.1.27, you'll see that the ping is sent and the reply is received on the host, but the reply does *not* appear in VirtualBox's pcap log file. I was trying to ping this IP address (one of our DNS servers) because I could not access <a href="http://twitter.com/" target="_blank">twitter.com</a> in firefox in the guest.<br>
<br>Thanks,<br>-- <br>Robin<br><br><div class="gmail_quote">2009/11/21 Vasily Levchenko <span dir="ltr"><<a href="mailto:Vasily.Levchenko@sun.com" target="_blank">Vasily.Levchenko@sun.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="word-wrap: break-word;"><br><div><div><div><div>On Nov 20, 2009, at 7:43 PM, Robin Green wrote:</div><br></div><div><blockquote type="cite">I've attached the log file. What do you mean by host network file?<br>
<br></blockquote><div><br></div></div></div><div>It's actually output of wireshark or any other traffic dumping tool working on host. Rather useful to check how nat send/modify received from the guest packets to remote host. <br>
<br><blockquote type="cite"><div><div class="gmail_quote">2009/11/19 Vasily Levchenko <span dir="ltr"><<a href="mailto:Vasily.Levchenko@sun.com" target="_blank">Vasily.Levchenko@sun.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;"><div>Hello Robin,</div><div>Thanks for feedback.</div>Could you please attach pcap file NAT<->guest (please see <a href="http://www.virtualbox.org/wiki/Network_tips" target="_blank">http://www.virtualbox.org/wiki/Network_tips</a>) and host network and log file?<br>
<div><div><div></div><div><div>On Nov 19, 2009, at 7:23 PM, Robin Green wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div>Bisection reveals that this bug was introduced at some point between r23223 and r23530 inclusive (I can't be more specific because all of those revisions except r23530 either failed to build or failed to boot).<br>
-- <br>
Robin<br><br><div class="gmail_quote">2009/11/18 Robin Green <span dir="ltr"><<a href="mailto:greenrd@gmail.com" target="_blank">greenrd@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I tried 3.1 beta 1 and the NAT interfaces on both my VMs very quickly stopped working. So I tried building from SVN, and with this (r24735) I can't connect to, or even ping, anything other than the host. Guest is Fedora rawhide (F13), but with Fedora 12 kernel (due to an uninteresting bug in the rawhide kernel).<br>
<br>-- <br><font color="#888888">Robin<br>
</font></blockquote></div><br></div></div>
_______________________________________________<br>vbox-dev mailing list<br><a href="mailto:vbox-dev@virtualbox.org" target="_blank">vbox-dev@virtualbox.org</a><br><a href="http://vbox.innotek.de/mailman/listinfo/vbox-dev" target="_blank">http://vbox.innotek.de/mailman/listinfo/vbox-dev</a><br>
</blockquote></div><br></div>
</blockquote></div><br>
</div><span><VBox.log></span></blockquote></div></div><br></div>
</blockquote></div><br>
</blockquote></div></div></div><br>
</blockquote></div><br>
_______________________________________________<br>vbox-dev mailing list<br><a href="mailto:vbox-dev@virtualbox.org" target="_blank">vbox-dev@virtualbox.org</a><br><a href="http://vbox.innotek.de/mailman/listinfo/vbox-dev" target="_blank">http://vbox.innotek.de/mailman/listinfo/vbox-dev</a><br>
</blockquote></div><br></div>
<br></blockquote></div><br>
</blockquote></div><br></body></html>