OS/2 guest: VirtualBox 4.1.8 change log about USB

[erdmann]

Hallo,

VirtualBox 4.1.8 change log says:
"USB: fixed OS/2 boot hang when using recent USB drivers"

This is very nice. But I would be very interested in more specifics as I am the guy working on the OS/2 USB HC drivers
(I mean anything that goes beyond what IBM had delivered as version 10.162 years ago).

Where could I get more detailed/technical information on this topic ? I want to make sure that I don't change anything that would break it again. I would also be grateful to talk to experts on the matter. USB legacy handoff is a freaking nightmare.

[Perryg]

I would suspect the DEV list. https://www.virtualbox.org/wiki/Community

[michaln]

There's nothing you can do to break this particular fix.

The OHCI spec stipulates that all OHCI MMIO accesses must be dword-sized and dword-aligned. The original IBM OHCI drivers obeyed the spec. At some later point (around 2002, but don't quote me on that), IBM -- or rather SWHT Latvia -- changed the OHCI driver such that it would in some instances perform byte- or word-sized accesses. VirtualBox "failed" such non-standard accesses by returning all bits set. That confused the USBOHCD.SYS driver to such extent that it would hang the guest during boot.

In IBM's OHCI driver, MMIO was supposed to be accessed solely through the GetDWORD() and SetDWORD() routines implemented in ohclong.asm. At some point, someone changed OHCIInit() in ohcinit.c and possibly some other places, too. There are memory accesses through the gVirtHCORAddr pointer which can't possibly follow the OHCI spec, as that code is built with a 16-bit compiler. So the accesses will be word- or byte-sized. In VirtualBox 4.1.8, those non-standard accesses will return what the OHCI driver expects to see.

[erdmann]

Hm,

ok, I updated the OHCI/EHCI drivers to use GetDWORD/SetDWORD not only on the op. regs (I am pretty sure this is done all the way through) but also on TD/QH accesses. But it's possible I didn't catch all places.
In any case, thanks for the information.

[erdmann]

For what it's worth:
maybe your explanation is also the answer and fix to Ticket #2850.