USBHCD184 fails to operate USB mouse

[Doug Bissett]

When I update to USBHCD184, I have two systems that fail to operate the USB wired (Logitech) mouse (no movement). I also have a wireless Logitech mouse that will not work on those two systems. A very limited test shows that other USB 2.0 devices do work.

I have three other systems where the wireless mouse works fine (I didn't try a wired mouse). The difference is that the two systems where it doesn't work have OHCI adapters. One of the others has only one UHCI adapter, one has UHCI, and EHCI adapters, and the third has only EHCI adapters.

Instructions please...

[Doug Bissett]

UPDATE:

I now have only one system where USBOHCD.SYS fails to work (no mouse movement, and one other USB 1.1 device that cannot connect). I can back out USBOHCD.SYS to the 183 level, and then it works properly. This is my Asus M3A78-EM system, with 5 OHCI, and 2 EHCI adapters. Another symptom is that this problem seems to block all keyboard activity, except Ctrl-Alt-Del (which gets me to CADH), and CADH seems to work okay. Going back to the WPS, no keyboard activity is possible, other than Ctrl-Alt-Del. It is a PS/2 keyboard, not USB.

On the other system (Gigabyte 7IXE motherboard, with generic add in USB card), I discovered that the OHCI adapter (AMD-756 chipset) on the motherboard has managed to get itself enabled. I have had that disabled "forever" because the original IBM drivers cause very serious problems when it is enabled. The good news is, that the new USB driver (183 and 184) runs it properly. The "problem" was that that adapter didn't have a USBOHCD.SYS line in CONFIG.SYS (I didn't know it was there). The other "problem" is that it seems that when you are short of enough CONFIG.SYS entries, that it is not always the same adapter that doesn't get a driver, and the results are not predictable.

[Lars Erdmann]

USBUHCD,USBOHCD,USBEHCD: increased default address timeout

[Lars Erdmann]

try the attached real quick. Note: these drivers will only work with >= Warp4.

[Lars Erdmann]

all drivers: for all IDC calls wait until HC is reset

[Lars Erdmann]

Try the last one.

[Lars Erdmann]

USBEHCD: "Busmaster save" defaults for all TDs, bracket "FreeClaimed?" with global Mutex

[Lars Erdmann]

Go for the last one.

[Doug Bissett]

Okay, I tried Doug.3.zip Nothing has changed.

I don't have the time to try to analyze this any more now. next week should be better.

[Lars Erdmann]

USBEHCD, USBOHCD: changed "default addr. timeout" processing

[Lars Erdmann]

go for doug.4.zip.

[Doug Bissett]

I tried Doug.4.zip. Nothing has changed.

[Lars Erdmann]

Please take trace for USBEHCD.SYS (from doug.4.zip)

[Lars Erdmann]

Also use USBD.SYS 10.162 (original IBM) and tell me if it makes any difference.

[Doug Bissett]

I tried 185 as uploaded to HOBBES. It has the same problem.

I tried the original USBD.SYS 10.162. No change.

If I use the 183 version of USBOHCD.SYS, with the rest of 185, there is no problem.

[Michaelhz]

Also tried 185 (and 184). Mouse does not work also. The 183 Version of USBOHCD.SYS in an 185 environment works well. I am running an MSI 785G-board. Please let me know, if can help bug tracking.

[Doug Bissett]

I also have an old Gigabyte 7IXE motherboard, that has an AMD 756 chipset (including an OHCI adapter). If the original IBM USBOHCD.SYS ever gets loaded when that adapter is enabled, major problems occur (write errors on the hard disk). Somehow, that adapter got enabled, and, surprisingly, it works fine with 183, 184, and 185 (after adding the proper numbers of USBOHCD.SYS statements in CONFIG.SYS).

This machine also has an add in card, with one EHCI, and two OHCI adapters on it. They all work properly with the 183 version of USBOHCD.SYS. If I update to 184, or 185, the two OHCI adapters, on the add in card, quit working, while the one on the motherboard continues to work. The EHCI adapter works with all three versions.

I will upload the output from PCI.EXE for both machines. Perhaps it will help.

[Lars Erdmann]

USBOHCD: critical section change

[Lars Erdmann]

Try doug.6.zip real quick.
Since I also changed something in USBD.SYS you might want to swap back and forth between this version and older version of USBD.SYS.

[Doug Bissett]

I tried doug.6.zip. No change, and USBD.SYS doesn't make any difference.

On the Gigabyte 7IXE board, it is a little easier to look around, because the mouse works on the on board OHCI port. Hardware manager shows all of the adapters as being assigned resources, including an IRQ. I also found out that USB 2.0 devices will work on the EHCI adapter, UNTIL I plug in a USB 1.x device. Then, the ports attached to that OHCI adapter will not work again, until I reboot. USB 2.0 devices will still work on the ports attached to the other OHCI adapter (on the plug in card), until a USB 1.x device is plugged into that one. After that, there is no sign of life on those ports. (Possibly because the port power is off?)

[Lars Erdmann]

I don't understand what you mean with "other" and "those" ports. Can you explicitely say "AMD" and "NEC" OHCI / EHCI ports ?
Please take a formatted trace for OHCI and attach here.

[Doug Bissett]

Let me try again:

On the Gigabyte 7IXE board, it is a little easier to look around, because the mouse works on the on board OHCI port. Hardware manager shows all of the adapters as being assigned resources, including an IRQ. I also found out that USB 2.0 devices will work on the EHCI adapter (NEC EHCI, on the add in card), UNTIL I plug in a USB 1.x device. Then, the ports attached to that NEC OHCI adapter will not work again, until I reboot. USB 2.0 devices will still work on the ports attached to the other OHCI adapter (NEC OHCI/EHCI on the plug in card), until a USB 1.x device is plugged into that one. After that, there is no sign of life on those ports. (Possibly because the port power is off?).

Briefly, the AMD 756 adapter works fine, but has no associated EHCI adapter. The NEC EHCI adapter on the add in card will work fine, until I plug in a USB 1.x device, then nothing works on the NEC OHCI or the NEC EHCI adapter that is attached to the port where I plug in the USB 1.x device. The NEC EHCI adapter still works through the ports controlled by the second NEC OHCI adapter, until I plug in a USB 1.x device, then that too quits working. After plugging in a USB 1.x device to either of the NEC OHCI adapters, the attached ports no longer seem to have any power available (no LEDs light up on the device that is plugged in).

I also tested doug.6.zip on my Lenovo ThinkPad? T510 (2 x EHCI adapters only), and on my IBM ThinkPad? T43 (1871-W8M) with 4x UHCI and 1x EHCI adapters. They both work good.

A trace will have to wait. I have other things that need to be done. I will post when I get it done.

[Lars Erdmann]

By the way: use only the USBOHCD.SYS drivers on the AMD/NEC system(s) (comment out the USBEHCD.SYS drivers) and see if that makes a difference. USBEHCD.SYS might have repercussions on USBOHCD.SYS.

Note: "no lights" does not mean no power (very likely, the ports are permanently powered, this is true for most systems). It just means the device was not detected at all.

[Doug Bissett]

Okay. I could not do a trace on the Gigabyte 7IXE machine. I don't have the trace software installed.

I did a trace (USBOHCD.ftf) on my Asus M3A78-EM motherboard, with 5 x OHCI and 2 x EHCI adapters. I hope it helps...

[Doug Bissett]

Yes, there is power on the ports.

[Doug Bissett]

I missed the request to try with USBEHCD.SYS REMed. It makes no difference (except USB 2.0 devices don't work, as expected).

I also left the contents of doug.6.zip, and only put USBOHCD.SYS back to the 183 level. It all works as expected.

[Lars Erdmann]

Did it work on the M3A78-EM motherboard or didn't it ?

I looked at USBOHCD.FTF
I cannot see any port activity whatsoever on any port: no device connect, no device disconnect, nothing. Did you have devices plugged in on boot ? Did you plug in any devices thereafter ?

It would be helpful if you could have anything attached on boot (mouse, whatever) so that I can see if it fails right from the start or only later.

[Lars Erdmann]

USBEHCD,USBOHCD,USBUHCD: add 100 ms time delay on HC reset

[Lars Erdmann]

try doug.5.zip

[Lars Erdmann]

USBOHCD: changing HC reset

[Lars Erdmann]

go for doug.7.zip

[Doug Bissett]

Tried doug.7.zip. No change, on either system, except I can't get to a command line on the M3A78-EM machine (therefore, no new trace). Every key that I try causes a beep, although CAD does get me to CADH. Both systems still work fine when I use the USBOHCD.SYS driver from 183.

[Lars Erdmann]

USBOHCD: reverting OHCIResetHost back to the 10.183 version

[Lars Erdmann]

try doug.8.zip.

[Lars Erdmann]

USBOHCD: reverting OHCIResetHost back to the 10.183 version, handling ind. power ports

[Lars Erdmann]

go directly for doug.9.zip.
If that works I would like to try out another change.

[Doug Bissett]

I tried doug.9.zip. No change. USBOHCD.SYS from this one only works with the AMD OHCI adapter, and no others. Going back to the 183 version of USBOHCD.SYS (and keeping the rest of doug.9.zip) works good.

[Lars Erdmann]

Please add a trace. Use the /M=NW parameter on TRACEBUF. I need the trace from bootup phase.
For some reason, the ports are not powered on bootup. I want to check if at least that works ok now.
By the way: you only have NEC HC on the Gigabyte_7IXE but not on the M3A78-EM, correct ?
If so, take the trace for the Gigabyte_7IXE board (as far as I understand, for the AMD HC everything works as it should)

You can add the trace tool via the installation: go to "Install/Remove?", go to "Installed Features" and find the "Feature Install Base" install package. Double click to open, select everything with "Serviceability" in its name and install.
If you don't want to do that you might as well just copy over \OS2\TRACEFMT.EXE, \OS2\TRACE.EXE, \OS2\DLL\TRACEDLL.DLL and \OS2\HELP\TRACE.HLP from another system. You will then need to make sure that you place the .TFF files from the zip into the \OS2\SYSTEM\TRACE directory so that TRACEFMT.EXE will be able to locate them for formatting the trace into human readable form. Don't forget to add TRACE (for major code 225) and TRACEBUF statements to config.sys as appropriate

[Lars Erdmann]

USBOHCD: change reset, USBUHCD/USBOHCD: readd mutex for "NonIsoAcc?"

[Lars Erdmann]

please test doug.10.zip on Gigabyte_7IXE. Take trace with /M=NW flag on TRACEBUF.

[Doug Bissett]

Okay, I got the trace software installed on the 7IXE (2 x NEC OHCI and 1 x NEC EHCI on a plugin card, plus an AMD 756 OHCI adapter on the motherboard), and it seems to work. I added /M=NW to the TRACEFMT line, in CONFIG.SYS (I assumed that you want the rest as it was by default).

Then, Installed the contents of doug.10.zip, and rebooted.

I did the TRACEFMT and saved two files: unformatted_7IXE.itf and FORMATTED_7IXE.ftf. Hopefully, one, or both, tell you what is wrong.

Then, I tested, and found that nothing has changed.

[Lars Erdmann]

Ok, I observe the following: you have one USB 1.x low speed device successfully attached to an OHCI controller, probably a USB mouse on the (onboard) AMD 756 OHCI controller, is this correct ?

Then I observe that for some vital register content the NEC OHCI controllers (I strongly assume) are initially (that is: by BIOS) programmed with bogus information which results in that the ports are never powered on:
Has the NEC controller ever worked ok ? I am astonished if it did.
Anyway I now have a good idea of what to fix for the NEC controllers, another quirk hack to put into the drivers ...
If you do some research in the internet you will find that the NEC controllers are a piece of s..t. The Linux sources also indicate that.

By the way: your NEC plug-in card has 5 USB ports overall, is this correct ?
Plus, you have 4 USB ports onboard overall, is this correct ?

[Doug Bissett]

Replying to erdmann:

Ok, I observe the following: you have one USB 1.x low speed device successfully attached to an OHCI controller, probably a USB mouse on the (onboard) AMD 756 OHCI controller, is this correct ?

Yes.

Then I observe that for some vital register content the NEC OHCI controllers (I strongly assume) are initially (that is: by BIOS) programmed with bogus information which results in that the ports are never powered on:

Not true. I have a device that charges from USB, but has no USB capability. It will charge from the NEC ports, as long as the machine is powered on.

I doubt if the BIOS even knows about the NEC controllers. What you call "bogus information" is probably whatever is left over after power on, and it may not always be the same.

Has the NEC controller ever worked ok ? I am astonished if it did.

Yes. They have always worked okay, until your version 184 came along.

Anyway I now have a good idea of what to fix for the NEC controllers, another quirk hack to put into the drivers ...

Hope it works...

If you do some research in the internet you will find that the NEC controllers are a piece of s..t. The Linux sources also indicate that.

I have never had a problem before, and I seem to have the same problem on my Asus M3A78-EM motherboard, with ATI (now AMD) adapters. That puts the problem in your version of USBOHCD.SYS. I do know that the plug in card was cheap (about $10 Canadian, about 10 years ago).

By the way: your NEC plug-in card has 5 USB ports overall, is this correct ?

Yes. There are 5 ports on the plug in card (NEC). One is inside the case, so it is not easily accessible (I had forgotten about that). 3 connect to one of the OHCI adapters, and two to the other. All 5 connect to the EHCI adapter.

Plus, you have 4 USB ports onboard overall, is this correct ?

On the motherboard, there is one OHCI adapter, with two ports to the outside of the case. Apparently, there is a place to connect two more ports, but it is not used. This adapter caused major problems when I enabled it with the IBM version of USBOHCD.SYS. It seems to be working fine with your versions from 183 and up (possibly earlier, I never tried it).

[Doug Bissett]

Sorry, I missed this earlier...

Replying to erdmann:

Did it work on the M3A78-EM motherboard or didn't it ?

No, it didn't.

I looked at USBOHCD.FTF
I cannot see any port activity whatsoever on any port: no device connect, no device disconnect, nothing. Did you have devices plugged in on boot ? Did you plug in any devices thereafter ?

At boot there is a USB mouse, and an APC USB UPS connected. The mouse does nothing, and the UPS software says that the link is broken. There is also a Samsung Story Station USB hard drive attached, but it is not powered on. I did not attempt to attach anything else.

It would be helpful if you could have anything attached on boot (mouse, whatever) so that I can see if it fails right from the start or only later.

It fails right from the start.

[Lars Erdmann]

USBOHCD: force POTPGT value to 1 for the NEC controller

[Lars Erdmann]

try doug.11.zip. Take trace for USBOHCD and USBEHCD for Gigabyte_7IXE and attach trace.
Also take trace for USBOHCD and USBEHCD for M3A78-EM and attach trace.
Please name the files so that I can distinguish them properly.

You also need to trace USBEHCD in both cases so that I can check if the EHCI HC properly hands over control to USBOHCD when a USB 1.x device (like USB mouse / keyboard) is attached to a port. If the handover fails, I need to fix the problem in USBEHCD.SYS.

[Lars Erdmann]

One additional question: does the Gigabyte_7IXE system only have 512 MB RAM ?

[Doug Bissett]

Replying to erdmann:

try doug.11.zip. Take trace for USBOHCD and USBEHCD for Gigabyte_7IXE and attach trace.

The Gigabyte 7IXE will not even boot. It stops at SDDHELP.SYS.

Also take trace for USBOHCD and USBEHCD for M3A78-EM and attach trace.

The M3A78-EM will not allow any keyboard input (PS/2 keyboard), other than CAD , which takes me to CADH. All that I can do there, is reboot.

Please name the files so that I can distinguish them properly.

I would, if I could create the files.

[Doug Bissett]

Replying to erdmann:

One additional question: does the Gigabyte_7IXE system only have 512 MB RAM ?

No. It has 448 meg of RAM.

[Lars Erdmann]

Can you try an USB keyboard on M3A78-EM ? Or any other USB device ? I want to know if USB works ok. A PS/2 keyboard is a completely different pair of shoes.

[Lars Erdmann]

USBOHCD: moving port power up to the very end of OHCIResetHost

[Lars Erdmann]

try doug.12.zip. Trace trace for both boards if possible.

[Lars Erdmann]

Which one of the boards supports legacy USB and if yes, is it enabled ? Which one of the boards uses ACPI.PSD and if yes, what switches are used (/PIC /VM or no switches ...). For the Gigabyte board, please run PCI -D. I need the full dump of PCI config space for each device.

[Lars Erdmann]

USBOHCD: update HC reset

[Lars Erdmann]

go directly for doug.13.zip. Please also revert to USBD.SY 10.162 and try that if it still does not work. Take trace for both boards as described above.

[Lars Erdmann]

USBOHCD,USBUHCD,USBEHCD: moving USB legacy handoff to BASEDEVINIT

[Lars Erdmann]

Also try doug.14.zip. Take trace.

[Doug Bissett]

Replying to erdmann:

Can you try an USB keyboard on M3A78-EM ? Or any other USB device ? I want to know if USB works ok. A PS/2 keyboard is a completely different pair of shoes.

I have a wireless USB keyboard and mouse combination, but it has other problems that we don't need to add to the mix. The M3A78-EM has both a USB mouse, and my UPS attached to USB at boot time. Neither one work after boot.

[Doug Bissett]

Replying to erdmann:

Which one of the boards supports legacy USB and if yes, is it enabled ? Which one of the boards uses ACPI.PSD and if yes, what switches are used (/PIC /VM or no switches ...). For the Gigabyte board, please run PCI -D. I need the full dump of PCI config space for each device.

The M3A78-EM has legacy USB, which is NOT enabled because it causes other problems at BIOS boot time (long before eCS starts to boot). The 7IXE had only the OHCI adapter originally, so the BIOS knows nothing about USB 2.0.

Both machines are using ACPI 3.20.04, with no switches. Note that Windows XP refuses to use ACPI with the 7IXE, for some unknown reason.

7IXE_pci-D.txt will be uploaded shortly.

[Doug Bissett]

Replying to erdmann:

go directly for doug.13.zip. Please also revert to USBD.SY 10.162 and try that if it still does not work. Take trace for both boards as described above.

Okay, on the 7IXE (which is an 800 mhz Athlon 64):

Complete doug.13.zip: Won't boot. Stops at SDDHELP.SYS.

Replace USBD.SYS with 10.162. Boots okay. USB 2.0 works until I plug in a USB 1.0 device. USB 1.0 device is not recognized, and the port quits working.

M3A78-EM to come later.

[Doug Bissett]

Replying to erdmann:

Also try doug.14.zip. Take trace.

On the 7IXE:

doug.14.zip, with USBD.SYS at 10.162: Same as with doug.13.zip. Traces to follow.

Complete doug.13.zip. Won't boot. It stops at SDDHELP.SYS.

[Doug Bissett]

Replying to erdmann:

go directly for doug.13.zip. Please also revert to USBD.SY 10.162 and try that if it still does not work. Take trace for both boards as described above.

Okay. On the M3A78-EM:

Complete doug.13.zip. It boots to the desktop, but every key press causes a beep, and all that I can do is CAD to get to CADH. All I can do there is reboot. I am not able to take a trace.

Doug.13.zip, with USBD.SYS at 10.162. Same as with the new USBD.SYS. I am not able to take a trace.

[Doug Bissett]

Replying to erdmann:

Also try doug.14.zip. Take trace.

On the M3A78-EM:

Doug.14.zip, with USBD at 10.162. Same as with doug.13.zip. Trace not possible.

Complete doug.14.zip: Same as with doug.13.zip. Trace not possible.

[Doug Bissett]

Replying to erdmann:

Which one of the boards supports legacy USB and if yes, is it enabled ? Which one of the boards uses ACPI.PSD and if yes, what switches are used (/PIC /VM or no switches ...). For the Gigabyte board, please run PCI -D. I need the full dump of PCI config space for each device.

M3A78-EM_pci-D.txt uploaded too.

[Lars Erdmann]

Replying to dgbisse:

Replying to erdmann:

Which one of the boards supports legacy USB and if yes, is it enabled ? Which one of the boards uses ACPI.PSD and if yes, what switches are used (/PIC /VM or no switches ...). For the Gigabyte board, please run PCI -D. I need the full dump of PCI config space for each device.

The M3A78-EM has legacy USB, which is NOT enabled because it causes other problems at BIOS boot time (long before eCS starts to boot). The 7IXE had only the OHCI adapter originally, so the BIOS knows nothing about USB 2.0.

Legacy USB has nothing to do with EHCI (USB 2.0). It was already offered with UHCI and OHCI (USB 1.x). Please check for the Gigabyte board if it has legacy USB support. You will find it in the BIOS settings. It would be interesting to toggle it and see if it makes a difference.

Additionally: test the 10.183 drivers with the latest USBD.SYS. Maybe USBD.SYS is broken and not the drivers.

[Lars Erdmann]

Replying to dgbisse:

Replying to erdmann:

go directly for doug.13.zip. Please also revert to USBD.SY 10.162 and try that if it still does not work. Take trace for both boards as described above.

Okay. On the M3A78-EM:

Complete doug.13.zip. It boots to the desktop, but every key press causes a beep, and all that I can do is CAD to get to CADH. All I can do there is reboot. I am not able to take a trace.

You always have to let me know if you were using an USB keyboard/mouse or PS/2 keyboard/mouse. Otherwise I cannot make any good use of this information.

Doug.13.zip, with USBD.SYS at 10.162. Same as with the new USBD.SYS. I am not able to take a trace.

[Lars Erdmann]

I won't have time for the next 2 weeks.

[Lars Erdmann]

I forgot: please tell me which one of the 2 Mobos is a multi-core / multi-cpu system.

[Lars Erdmann]

And something else: take the complete 10.183 package and do a trace for USBOHCD (major code 225) and USBEHCD (major code 226).
Plug a USB 1.x device into the NEC add-on card just like you did for traces 7IXE_doug_13_oldUSBD.zip and 7IXE_doug_14_oldUSBD.zip.
I observe for doug.13.zip and doug.14.zip traces that the EHCI controller does not give away control to the OHCI controller. I now want to compare this to what happens with the 10.183 package.

[Doug Bissett]

Replying to erdmann:

I forgot: please tell me which one of the 2 Mobos is a multi-core / multi-cpu system.

The Asus M3A78-EM has a quad core AMD Phenom processor with 2 GB memory, and 500 GB hard disk. It has two EHCI, and five OHCI USB adapters on the motherboard.

The Gigabyte 7IXE has a single core 800 mhz Athlon 64 with 448 meg of memory, and 3 hard disks (20 GB, 40 GB, and 20 GB). The motherboard has one OHCI adapter (AMD 756 chipset), and it has a plug in card with one EHCI, and two OHCI (NEC) adapters

[Doug Bissett]

Replying to erdmann:

And something else: take the complete 10.183 package and do a trace for USBOHCD (major code 225) and USBEHCD (major code 226).
Plug a USB 1.x device into the NEC add-on card just like you did for traces 7IXE_doug_13_oldUSBD.zip and 7IXE_doug_14_oldUSBD.zip.

Actually, what I did was plug in a USB 2.0 device, then eject it. Then I plugged in a USB 1.0 device. I did the same for 7IXE_183.ftf.

I observe for doug.13.zip and doug.14.zip traces that the EHCI controller does not give away control to the OHCI controller. I now want to compare this to what happens with the 10.183 package.

It appears to try to give away control, but USBOHCD.SYS doesn't take it.

[Doug Bissett]

Replying to erdmann:

I won't have time for the next 2 weeks.

No rush on my part. 183 works fine on both systems.

[Doug Bissett]

Replying to erdmann:

And something else: take the complete 10.183 package and do a trace for USBOHCD (major code 225) and USBEHCD (major code 226).

I did the same for the M3A78-EM. It has a USB mouse, and USB UPS attached. See M3A78-EM_183.ftf.

[Lars Erdmann]

USBOHCD: for SET_FEATURE "power_on" the bitmask was incorrectly computed

[Lars Erdmann]

Damn, I think I found the error. A very subtle programming error.
Try doug.15.zip. In order to rule out the rest, take the 10.183 package and initially only replace USBOHCD.SYS,USBOHCD.SYM,TRC00E1.TFF. If that works ok you can then test all of doug.15.zip.

[Lars Erdmann]

USBOHCD: sent the wrong thing with doug.15.zip ...

[Lars Erdmann]

Forget doug.15.zip (sent the wrong thing). Go for doug.16.zip

[Lars Erdmann]

USBOHCD: fix the very same error in HCReset

[Lars Erdmann]

Forget doug.16.zip. Go for doug.17.zip. I have fixed the very same error at yet another place. Do as described in comment #59. That should fix your problem on both Mobos.

[Doug Bissett]

Replying to erdmann:

Forget doug.16.zip. Go for doug.17.zip. I have fixed the very same error at yet another place. Do as described in comment #59. That should fix your problem on both Mobos.

I think you found the main problem. Well done...

The complete doug.17.zip package seems to work good on the 7IXE.

Doug.17.zip almost works on the M3A78-EM. Most of the time, the mouse works, but no other USB 1.x device will attach to the system (including the UPS, which uses the USBECD.SYS driver from ​http://hobbes.nmsu.edu/download/pub/incoming/usbecd13.zip). Once (out of about 10 tries), it did work properly, and allowed me to attach other USB 1.x devices. However, I have not been able to repeat that. I did try with the USBECD.SYS driver REMED. The mouse seems to be okay, but no other USB 1.x devices will attach.

If I go back to USBD.SYS from 183, it seems to work as it should, every time (about 5 tries). I am not sure which OHCI adapter(s) the permanently attached devices are attached to.

I will use the doug.17.zip package, on the 7IXE, and see what else happens (this is a low usage machine, so it may take a while to get it properly tested).

I will use the doug.17.zip package, with USBD.SYS backed out to the 183 level on the M3A78-EM, and see what else happens.

I will also try the doug.17.zip package on my other systems, and report back.

[Doug Bissett]

Okay, here is the report on the other systems with doug.17.zip:

Lenovo T510. 2 x EHCI adapters. Works fine.

IBM ThinkPad? T43 (1871-W8M). 1 x EHCI adapter, 4 x UHCI adapters. Works fine.

IBM ThinkPad? A22e. 1 x UHCI adapter. Works fine.

The one that I had forgotten about is an Asus A8N-SLI, which has 1 x EHCI, and 1 x OHCI adapters (NVIDIA chipset). Works fine.

[Lars Erdmann]

Seems that I have to backlevel something in USBD.SYS but that's another problem. If your OHCI problems are now fixed I suggest to close this bug.
For the USBD.SYS issues you can then open a new bug if necessary.

[Doug Bissett]

Okay, close it. I will need to do more testing with USBD.SYS to be able to better describe the problem.

[Lars Erdmann]

Testing the bits in the PPCM bitmask of HcRhDescriptorB register was done incorrectly (16-bit compiler issue). Is now fixed.