DOSUHCI crash and hang under QEMU / FreeDOS

[bolle732]

Hello

I tried to load the DOSUHCI[L].COM (Version 0.11) in FreeDOS running under QEMU on a Linux box. I get the following message:

Code: Select all

Another program is currently controlling the USB Bus.
If you continue with the installation, the other program will stop working.

Are you ABSOLUTELY SHUR you want to continue with the installation (Y/N)?

I only load the FDAPM.COM, but even without that, I get the message.

With DOSUHCI, if I say NO, it exits, if YES I get:

Code: Select all

Invalid Opcode at 022B 019D 0002 DE2A 0693 4E51 1D80 9309 9306 9306 9306 9306 9306

Invalid Opcode at 022B 019D 0006 DE2A 0693 19B8 4C00 9399 9306 9306 9306 9306 9306

and it freezes.

With DOSUHCIL, if I say NO, it exits, if YES it hangs.

I have FreeCom version 0.82pl3 XMS_Swap and FreeDOS kernal version 1.1.34.

A little bit strange. Any ideas ? Fault of QEMU, FreeDOS ?

Andreas

[Bret]

Have you tried this on the same machine in "real" DOS rather than a virtual machine?

I know some of the USB host controllers emulated in various virtual machines are not implemented correctly, though I'm not specifically familiar with QEMU. Your problem is probably not FreeDOS, it is QEMU.

[bolle732]

Hello Bret

Thank you for your answer. QEMU is running under Gentoo Linux on a Via Artigo box. This box has only power and network connected and I'm accessing QEMU over its VNC server and it is located in a server room. Therefor, it's not that easy to do that on the HW itself. But it shouldn't matter, because QEMU emulates the whole HW, including the USB devices and there is no virtualization activated (like KQEMU/KVM or how the others do).

Currently, I added "STACKS=0,0" to the "CONFIG.SYS". If I start "USBUHCIL.COM /PD:150", it loads, I mean I see the DOS prompt again without an error message. But after that, the keyboard is dead. If I do this from a batch file, it hangs after "DEBUG: Starting Host" and don't returns to the prompt or start the next line (like USBKEYB and USBMOUSE).

Really strange. Maybe there is some timing issue, QEMU is not cycle accurate for performance reason. And the "IRQ.COM" tells that the "CMOS Clock" is not enabled. But other OSes are running fine with USB support (like Haiku, Linux, ReactOS, even Win$$).

Andreas

[Bret]

Although I haven't done much testing, virtual environments only partially emulate UHCI hosts, usually at the hardware level, and do not properly emulate the PCI BIOS that USBUHCI{L} uses to access the host controller. IOW, the problems I've seen seem to be related to a buggy/incomplete virtual BIOS, not necessarily with the virtualized hardware.

[bolle732]

Hello Bret

As far as I know, QEMU is using the BIOS from Bochs. And there seems to migrate now to SeaBIOS. Will observe that.

Thank you for assistance.
Andreas

[DOS386]

I have FreeCom version 0.82pl3 XMS_Swap

old, but not critical

and FreeDOS kernal version 1.1.34.

Date ? Where did you pirate it ??? Latest version is buggy 2039 from 2009-08-02 so use 2038:-)

A little bit strange. Any ideas ? Fault of QEMU, FreeDOS ?

It works for me in FreeDOS. What about the USB emulation of QEMU ?

This box has only power and network connected and I'm accessing QEMU over its VNC server and it is located in a server room. Therefor, it's not that easy to do that on the HW itself

Get a PC where you can install DOS

including the USB devices and there is no virtualization activated

Good, but not necessarily sufficient.