[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue
From: |
Ely Soto |
Subject: |
Re: [Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue |
Date: |
Mon, 9 Apr 2007 15:42:59 -0400 |
Ok this is the fix I came up with.
Basically it will check all the other
objects that could potentially be waiting for service. This will prevent
one high priority object from starving the rest.
I'm not certain what the intention for
the timeout > 0 check but this completely prevented any wait object
servicing on my machine.
The Tap interface now works smoothly
without issue.
Diff/patch for 0.9.0 release version
of vl.c
==================================
5840c5840
< int ret, nfds;
---
> int ret, ret2, nfds,
i;
5851c5851
< if (ret == 0 &&
timeout > 0) {
---
> if (ret == 0) {
5858a5859,5873
>
>
/* Check for additional signaled events */
>
for(i = (ret - WAIT_OBJECT_0 + 1); i < w->num; i++) {
>
>
/* Check if event is signaled */
>
ret2 = WaitForSingleObject(w->events[i], 0);
>
if(ret2 == WAIT_OBJECT_0) {
>
if (w->func[i])
>
w->func[i](w->opaque[i]);
>
} else if (ret2 == WAIT_TIMEOUT) {
>
} else {
>
err = GetLastError();
>
fprintf(stderr, "WaitForSingleObject
error %d %d\n", i, err);
>
}
>
}
5862c5877
<
fprintf(stderr, "Wait error %d %d\n", ret, err);
---
>
fprintf(stderr, "WaitForMultipleObjects error %d %d\n",
ret, err);
==================================
Diff/patch for version 1.279 of vl.c
==================================
6146c6146
< int ret, nfds;
---
> int ret, ret2, nfds,
i;
6157c6157
< if (ret == 0 &&
timeout > 0) {
---
> if (ret == 0) {
6164a6165,6179
>
>
/* Check for additional signaled events */
>
for(i = (ret - WAIT_OBJECT_0 + 1); i < w->num; i++) {
>
>
/* Check if event is signaled */
>
ret2 = WaitForSingleObject(w->events[i], 0);
>
if(ret2 == WAIT_OBJECT_0) {
>
if (w->func[i])
>
w->func[i](w->opaque[i]);
>
} else if (ret2 == WAIT_TIMEOUT) {
>
} else {
>
err = GetLastError();
>
fprintf(stderr, "WaitForSingleObject
error %d %d\n", i, err);
>
}
>
}
6168c6183
<
fprintf(stderr, "Wait error %d %d\n", ret, err);
---
>
fprintf(stderr, "WaitForMultipleObjects error %d %d\n",
ret, err);
==================================
Ely Soto
Ely Soto <address@hidden>
Sent by: address@hidden
04/09/2007 01:54 PM
Please respond to
address@hidden |
|
To
| address@hidden
|
cc
|
|
Subject
| Re: [Qemu-devel] 0.9.0 Win32 Tap inferface
PPC Guest issue |
|
Ok I located the source of the problem.
The code in main_loop_wait()
that uses WaitForMultipleObjects
will only service one object that woke it up.
What is occuring is that the host_alarm timer is being serviced anytime
the tap_semaphore is also signaled, therefore the tap callback function
is
never called while at the same time the tap_semaphore count is decremented.
This guarantees that the callback function will never get services if that
particular timing continues.
This is likely something that won't occur on every system because of the
nature of the timing, but it is a problem.
I'm working on a better fix as right now my solution is to poll all the
objects after a wakeup to see who really is signaled.
In order to do that you must use an Event Object in Manual Reset Mode.
vl.c
void main_loop_wait(int
timeout)
...
WaitObjects *w = &wait_objects;
ret = WaitForMultipleObjects(w->num, w->events,
FALSE, timeout);
if (WAIT_OBJECT_0 + 0 <= ret &&
ret <= WAIT_OBJECT_0 + w->num - 1) {
if (w->func[ret - WAIT_OBJECT_0])
w->func[ret
- WAIT_OBJECT_0](w->opaque[ret - WAIT_OBJECT_0]);
} else if (ret == WAIT_TIMEOUT) {
} else {
err = GetLastError();
fprintf(stderr, "Wait error
%d %d\n", ret, err);
}
...
Ely Soto
Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you.