Serial broken on Windows

[HoRnEyDvL]

Bug Description

Xemu freezes (Not Responding) when WinDbg is open & listening to COM ports

Unable to debug any Kernels

Steps:
Install Virtual Com Ports I used (https://www.virtual-serial-port.org/) 14 day trial

Open VSPD & create a new pair in my case COM1 & COM 2

Open WinDbg & Connect to COM Port 2

• Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
• Copyright (c) Microsoft Corporation. All rights reserved.
• Opened \.\com2
• Waiting to reconnect...

Launch Xemu Using D:\Xemu\xemu.exe -device lpc47m157 -serial COM1

Pop up appears for COM port settings but Xemu locks up.

Expected Behavior

Xemu Should output Kernel debug to WindDbg Via Com Port specified

xemu Version

Version: 0.6.1-22-g5622af4981
Branch: master
Commit: 5622af4
Date: Wed Oct 13 23:54:07 UTC 2021

System Information

Win 10
AMD 5950X
GTX 980

Additional Context

No response

[HoRnEyDvL]

Just did further testing & can confirm that this also causes crash when using Putty.

This eliminates WinDbg been the issue.

[GXTX]

This is a known issue. See: #86. I believe it's an issue with QEMU itself.

You should keep this issue open for documentation. And rename to "Serial broken on Windows".

[HoRnEyDvL]

This is a known issue. See: #86. I believe it's an issue with QEMU itself.

You should keep this issue open for documentation. And rename to "Serial broken on Windows".

Renamed.

Thanks

[mborgerson]

Does it hang when you use a physical COM port? Have you tried other chardev backends, tcp/stdio for instance? Is it only when you're using this virtual COM port that xemu hangs? Does QEMU work with your virtual COM port?

Can you help investigate the issue

[GXTX]

It does hang with physical COM ports, I have a Digi Edgeport/4 (USB 4 port) and motherboard. I don't remember if I ever tried to attach WinDBG to a Windows guest in QEMU.

[HoRnEyDvL]

Does it hang when you use a physical COM port? Have you tried other chardev backends, tcp/stdio for instance? Is it only when you're using this virtual COM port that xemu hangs? Does QEMU work with your virtual COM port?

Can you help investigate the issue

I haven't been able to get it to output to TCP.

Using Virtual Com Output to Putty I can sometimes get it to output this before it crashes (-device lpc47m157 -serial COM1)
▒▒▒▒▒▒▒▒▒0▒▒▒▒▒▒k)▒▒▒▒▒

Using Stdio to output to console works however Kernel output is gibberish (-device lpc47m157 -serial stdio) Some applications do output readable text such as evox.

☺Ç        Φ‼¶ÇÇ‼≡☼  ♦►☺╠ëE°╔Φ⌠↨ä└►► é+☺ ►►`@Ç☺Çl√♦Çÿ√♦Ç♥\√♦Çk)♥éT√♦Ç►xboxkrnl.exe¬0000┼ÇÇe110♠☺╜♦Ç    k)♥Ç  

@GXTX are you able to try this one out please, (Does QEMU work with your virtual COM port?)

[mborgerson]

Using Stdio to output to console works however Kernel output is gibberish

What were you expecting to see? This is binary data from the debug stub that your desktop debugger would consume

[HoRnEyDvL]

Using Stdio to output to console works however Kernel output is gibberish

What were you expecting to see? This is binary data from the debug stub that your desktop debugger would consume

That is what was expected using STDIO, its matches the output i get when using real hardware with a superio & putty.

But when using XEMU & putty the output is different to that when using real hardware. Perhaps what XEMU is outputting to COM is causing it to lock up as Putty / WINDBG do not know how to respond to it?

[GXTX]

It's an issue with QEMU. Real ports. Someone should report upstream, been an issue for a while, at least 3 years or something.

[HoRnEyDvL]

It's an issue with QEMU. Real ports. Someone should report upstream, been an issue for a while, at least 3 years or something.

I wouldnt know how to do that :( hopefully someone can do it on behalf of this ticket. Unless its something that can be fixed just for xemu ?

[GXTX]

Got bored so I reported it. Seems they allow reports on GitLab now instead of a ML thankfully. Could go +1 it if you want, not sure it matters at all. Like I said it's been an issue for quite some time so not sure anyone really cares, doesn't really seem like something too out there to try to do?

https://gitlab.com/qemu-project/qemu/-/issues/675

[HoRnEyDvL]

Got bored so I reported it. Seems they allow reports on GitLab now instead of a ML thankfully. Could go +1 it if you want, not sure it matters at all. Like I said it's been an issue for quite some time so not sure anyone really cares, doesn't really seem like something too out there to try to do?

https://gitlab.com/qemu-project/qemu/-/issues/675

Thank you so much. Much appreciated.

[GXTX]

• Using pipe hangs before even attaching.
• Using tcp causes any version of WinDbg to report The client is not using the same version of the remoting protocol as the server, tried with ~10 different versions.
• kd has a similar issue with remote DebugConnect failed, HRESULT 0x80010110 The version of OLE on the client and server machines does not match..

ngl I've said all of these things in XboxDev (probably also on IRC?) with XQEMU years ago, too much noise tho and little interest. I did try briefly to debug it with gdb but couldn't get it to break once it was hung, and attaching after it's hung I couldn't figure out how to get any useful info from the backtrace (not my cup of tea). It's very unlikely this will be fixed upstream anytime soon.

You could perhaps use windpl.pl found in espes' original fork of XQEMU, but iirc this doesn't have many features?

[HoRnEyDvL]

• Using pipe hangs before even attaching.
• Using tcp causes any version of WinDbg to report The client is not using the same version of the remoting protocol as the server, tried with ~10 different versions.
• kd has a similar issue with remote DebugConnect failed, HRESULT 0x80010110 The version of OLE on the client and server machines does not match..

ngl I've said all of these things in XboxDev (probably also on IRC?) with XQEMU years ago, too much noise tho and little interest. I did try briefly to debug it with gdb but couldn't get it to break once it was hung, and attaching after it's hung I couldn't figure out how to get any useful info from the backtrace (not my cup of tea). It's very unlikely this will be fixed upstream anytime soon.

You could perhaps use windpl.pl found in espes' original fork of XQEMU, but iirc this doesn't have many features?

It's a shame as could desperately use it right about now. My superio simply refuses to work on my 1.0 and 1.1

[mborgerson]

Should be fixed now