Apologies for getting lost in the dust storm, but where does this
leave this patch? Sounds like there's a real failure caused by it?
-Evan
On Thu, Jun 7, 2018 at 9:43 AM Richard Henderson
wrote:
>
> On 06/07/2018 01:01 AM, Laurent Vivier wrote:
> >> Your script doesn't work outside debian, lacking
On Thu, May 31, 2018 at 9:44 AM Peter Maydell wrote:
>
> On 31 May 2018 at 17:32, Richard Henderson
> wrote:
> > On 05/31/2018 08:26 AM, Peter Maydell wrote:
> >> On 30 May 2018 at 21:50, Richard Henderson
> >> wrote:
> >>> On 05/29/2018 04:44 PM
mine.
[1] https://patchwork.kernel.org/patch/9512083/
Signed-off-by: Evan Green
---
Since the path() function returns a final path, I used a thread-local
global to contain the glued-together path. From my examination of the
callers of path(), this is sufficient. The thread-localness of
The following patch gets things moving again for me. It only reports
that the poll was satisfied if there was data that could be written to
the destination. While it successfully opens up a window where the I/O
thread is unlocked (previously there was no such window, hence the
hang), it's far from
Some food for thought:
* os_host_main_loop_wait quickly calls "unlock IO thread", poll, "lock IO
thread".
* win_chr_pipe_poll calls PeekNamedPipe, which would report data available,
satisfying the poll.
* win_chr_read_poll calls qemu_chr_be_can_write, which I think calls
serial_can_receive1,
Public bug reported:
I'm using Windows, I'm not sure if this happens on Linux, but for all I
know it does. To repro, fire up any image (ideally one that does almost
nothing, and doesn't read the serial port), and use the option "-serial
pipe:mypipe". Then use Putty or something else to connect to
