WD Book not working

[rbri]

Hi Lars, hi Greg,

first of all many thanks for your hard work. I have used all your builds (1-8) in the past. I mainly attach sometimes a WD MyBook external hard drive and had no problems so far. The only difference is that with your driver my backup is much faster.

But yesterday i found out, that there is another problem. Starting with build 7 of the driver my camera is no longer able to connect to the pc. After some minutes, the camera thinks that the connection is established, but i can't use the drive from OS/2. Additionally the boot process has changed. The boot stops for nearly one minute during loading ndfs32.ifs (NetDrive latest available version).

Both problems are gone if switching back to build 6.

I have a dual core AMD machine here with acpi 3.18 running. If i can provide more info, please let me know.

[rbri]

build 9 works again; thanks a lot

[Lars Erdmann]

please also test with latest version 10.175 (usbhcd13.zip)

[rbri]

Hi Lars,

i did the test with 10.175. The camera still works. But now my backup usb drive (WD MyBook) is no longer detected.

Contact me if you need more details.

Many Thanks

[rbri]

Did some more tests:

• usbhcd9.zip works fine
• usbhcd10.zip is again broken, i can't access my MyBook. Also an usb stick is not working.

[Lars Erdmann]

I assume that WD MyBook is a USB 2.0 drive (and not USB 1.x) ?

[Lars Erdmann]

Are you using the USBD.SYS from the 10.175 package ? If yes, revert back to the original IBM 10.162 version and let me know if that fixes the problem.

[rbri]

I assume that WD MyBook? is a USB 2.0 drive (and not USB 1.x) ?

Yes, the box says 'USB 2.0 capable'

Model is WD5000H1U-00 (​http://support.wdc.com/product/install.asp?groupid=110&lang=en)

[rbri]

Replying to erdmann:

Are you using the USBD.SYS from the 10.175 package ? If yes, revert back to the original IBM 10.162 version and let me know if that fixes the problem.

Sorry no difference....

[rbri]

Did one more test with 10.175 package (without usbd.sys)

• It makes no difference if the MyBook is attached during boot or not. In both cases the device is not detected/usable.

• build 9 works in both cases.

[Lars Erdmann]

Is it possible that you have an Intel ICH7 chipset ? Please post output from pci.exe.

[rbri]

The documentation of the board says

• Northbridge: NVIDIA M1695
• Southbridge: NVIDIA nForce3 250

[Lars Erdmann]

In the meantime, I have received the WD MyBook you have sent to me. Many thanks.
I can report that the WD MyBook is properly detected on my system (VIA plug in PCI card with EHCI and UHCI companion controllers). I cannot properly access it, I am currently formatting it with NTFS to do additional checking (I would appreciate instructions on how to create a 465 GB JFS partition on it ...). Nonetheless it is correctly detected and can be seen as a USB device in USBREGMGR (USB Resource manager).In short: it works ok from a low level data transmission point of view.
1.) Is the WD book not usable at all ? Can you check with USBRESMGR if the drive shows up as a USB device or not at all ?
2.) Can you please try the version of USBEHCD.SYS attached to ticket #6 ?
3.) Can you please try to operate your system with the OS2APIC.PSD driver ? Try to run with OS2APIC.PSD /APIC. I can give additional help on additional switches if that won't work.
4.) Can you please try to operate your system with ACPI.PSD /SMP /PIC ?

Note: my system is a single core system. Nonetheless, I am running the SMP kernel with OS2APIC.PSD /APIC as the SMP kernel is the standard eCS configuration.

[rbri]

Found one more maybe interesting thing; with build 9 (the last one that worked) i have this behaviour

• if i attach the device for the first time after booting, the NeoWPS USB Widget detects the device but the display is corrupt (see first.gif)
• the text in the popup menu and the text after detaching the device also
• if i attach the device a second time the display is fine

And here is the output from USB Dock about the device (with build 9)

USB Dock: Unknown device
Identifier: 1058:1100

<<< Device Description >>>
Type			:01
USB Rev			:200
Class			: Reserved (0x00)
Subclass		: Unknown (0x00)
Protocol			: Unknown (0x00)
Device Information is defined at interface Level
Max. packetsize		:64
Vendor  ID		:0x1058
Product ID		:0x1100
Device Release#		:0165
Number of Configurations:1

Configuration: 0
Length			: 32
ConfigurationValue	: 1
Attributes		: 0xC0
MaxPower		: 0x01
NumInterfaces		: 1

Interface: 0
AlternateSetting		: 0
Class			: Mass Storage (0x08)
SubClass		: SCSI (0x06)
Protocol			: Bulk (Zip) (0x50)
Endpoints		: 2

Endpoint: 0
Address		: 0x81
Attributes	: 0x02 (Bulk)
MaxPacketSize	: 512
Interval		: 0

Endpoint: 1
Address		: 0x02
Attributes	: 0x02 (Bulk)
MaxPacketSize	: 512
Interval		: 0

[rbri]

Testing with build 13 results are:

• when i attach the device, there is some sound, the blue light switches on
• no output from the NeoWPS widget, no device listed in the popup menu
• USB Dock device list is empty

[rbri]

Same result with the driver from #6 (same as build 13); the only difference is a strange beep during boot.

[Lars Erdmann]

0.) In the meantime I have formatted the MyBook as one single NTFS partition. I copied files to it (using WinXP). Under OS/2, using the NTFS.IFS driver, I could properly read those files.
1.) NeoWPS widget is corrupt. Use the old USBMSDD tool (the one that was used with eCS 1.2. It still exists, let me know if you don't remember how to set it up).
2.) Read the notes in Ticket #6 about the beep. Can you hear a low beep or a high beep ?

If you hear a high beep, you properly get through the "BIOS handoff" phase which seems to be a problem with other systems.

[Lars Erdmann]

One additional thought: as a test boot your system WITHOUT any PSD driver at all (you can still use the SMP kernel though). You will end up with only using one core. Check if you can then properly use USB.

[rbri]

build 13 without any PSD driver - no change

• when i attach the device, there is some sound, the blue light switches on
• no output from the NeoWPS widget, no device listed in the popup menu
• USB Dock device list is empty

[rbri]

the beep is the high one

[Lars Erdmann]

I updated the driver (see Ticket #6). Please retest

[Lars Erdmann]

Please make sure you use USBMSDD.EXE from the \ecs\boot directory instead of the NeoWPS widget. Test without any PSD loaded.

[rbri]

did the test with the updated driver (usbmsdd and no psd); no change

• the beep is the high one
• USB Dock device list is empty

Maybe it is another option to do some kind of manual delta debugging (​http://de.wikipedia.org/wiki/Delta_Debugging). Because we know that one of the changes between build 9 and 10 introduces the problem, maybe you can build different intermediate versions from the svn. Then i can test this and so we can isolate the change that introduces the problem. What do you think?

[Lars Erdmann]

I think it will be more complicated than that. Changes in the USBOHCD driver might have a repercussion on the correct operation of the USBEHCD driver as the USBOHCD driver is the "companion" to USBEHCD on your system. And I have experienced the same issues on my system. Furthermore, USB is very timing sensitive. I think I will need to release a complete set of drivers and you will need to check with new USBOHCD and USBEHCD.

[rbri]

Bad news; no change with 177. Camera device is still working but the myBook is not detected.

[Lars Erdmann]

Please create a trace (save as formatted). Attach as file here. Instructions, see readme.txt.

[rbri]

(1) trace saved after the boot

[rbri]

(2) after attaching the myBook device

[rbri]

(3) after attaching the camera device

[rbri]

Files attached; hope this helps. Again many thanks for your ongoing support.

[rbri]

nothing changed with 178

[Lars Erdmann]

Can you backlevel USBEHCD.SYS to 10.162 and see if that fixes the problem ?

[rbri]

Yes, after replacing only usbehcd.sys with the one form eCS 2.1 (10.162) the MyBook is detected and a drive letter assigned.

Sorry for the delay, but i was not at home for some days.

[Lars Erdmann]

reworked OHCI, reworked EHCI

[Lars Erdmann]

please try rbri.zip

[rbri]

Sorry, but no change with rbri.zip.

[Lars Erdmann]

1.) Can you unplug and replug the WD book and see if it is then recognized ?
2.) Does the WD book show up in USB dock ?
3.) Does ANY USB 2.0 device (memory stick for example) show up in USB dock or is only WD book affected ?
4.) Can you turn off USB 2.0 in BIOS ? If yes, please do and tell me if then WD book is detected and can be operated. I need to check if there is a general problem in handover between HC (EHCI) and companion HC (OHCI in your case). There will be if 3.) indicates that no USB 2.0 device can be properly operated at all.

[Lars Erdmann]

build 9 = SVN changeset 233 (good), build 10 = SVN changeset 243 (bad)

[Lars Erdmann]

please retry new rbri.zip. Make sure that USBEHCD.SYS comes BEFORE USBOHCD.SYS in config.sys !

[rbri]

I changed the order of the drivers in config.sys; USBEHCD.SYS is now BEFORE USBOHCD.SYS (btw i have two USBOHCD.SYS statements in the config.

Then i tried your latest build. But the myBook is not detected. I also tired two different memory sticks, both are not detected.

Then i have disabled USB 2.0 in the bios. Also without success. Sorry....

Do you like to have new traces?

[rbri]

Replying to erdmann:

1.) Can you unplug and replug the WD book and see if it is then recognized ?

still not recognized

2.) Does the WD book show up in USB dock ?

no

3.) Does ANY USB 2.0 device (memory stick for example) show up in USB dock or is only WD book affected ?

The only device that works is the camera, i tried two usb sticks also but these are also not visible

4.) Can you turn off USB 2.0 in BIOS ? If yes, please do and tell me if then WD book is detected and can be operated. I need to check if there is a general problem in handover between HC (EHCI) and companion HC (OHCI in your case). There will be if 3.) indicates that no USB 2.0 device can be properly operated at all.

Turning off USB 2.0 does not help. But without 2.0 the camera is also not working.

[Lars Erdmann]

Can you just do the opposite: use my latest USBEHCD.SYS and use USBOHCD.SYS 10.162 ?
Yes please take trace (make sure you also use the correct TFF files when you mix drivers).
I am still not clear if it's the USBOHCD.SYS or the USBEHCD.SYS driver that is causing the problem. If you disable USB 2.0 (EHCI) the camera and als WD book should fall back to using USBOHCD.SYS. But that also seems to fail. Is the camera a USB 2.0 device or a USB 1.x device ?

Make sure you are using the USBD.SYS 10.162.

[rbri]

Replying to erdmann:

opposite

My last tests are done with all the driver files from rbri.zip

Can you just do the opposite: use my latest USBEHCD.SYS and use USBOHCD.SYS 10.162 ?

no change; the only detected device is the camera

Yes please take trace (make sure you also use the correct TFF files when you mix drivers).

I do not have the org 10.162 tff files any longer.

I am still not clear if it's the USBOHCD.SYS or the USBEHCD.SYS driver that is causing the problem. If you disable USB 2.0 (EHCI) the camera and als WD book should fall back to using USBOHCD.SYS. But that also seems to fail. Is the camera a USB 2.0 device or a USB 1.x device ?

Have disabled 2.0 in the bios and in a second try also removed the driver from config. In both cases no device was detected (also the camera not).

Make sure you are using the USBD.SYS 10.162.

Verified.

[Lars Erdmann]

Is the log complete ? It ends after the init phase. That would mean that the USBEHCD.SYS does not even remain loaded. Or did this happen after you disabled USB 2.0 in BIOS ?

[rbri]

Trace after boot and attach of WD Book with USBOHCD.SYS 10.162 and latest usbehcd from rbri.zip

[rbri]

Replying to erdmann:

Is the log complete ? It ends after the init phase. That would mean that the USBEHCD.SYS does not even remain loaded. Or did this happen after you disabled USB 2.0 in BIOS ?

Of course you are right, the trace was captured with disabled 2.0. Sorry, i was i bit lost in all this config changes. The right trace is now attached.

[Lars Erdmann]

Do you have something like "EHCI BIOS handoff" in your BIOS settings ? If yes toggle between on and off and see if it makes a difference.

[Lars Erdmann]

retry rbri.zip

[Lars Erdmann]

Is the camera USB 2.0 ?

[rbri]

Replying to erdmann:

retry rbri.zip

No change. Will attach the new traces...

[rbri]

trace after boot and attach of WD Book

[rbri]

trace after attach of TZ3 Camera

[rbri]

Replying to erdmann:

Is the camera USB 2.0 ?

Yes

[rbri]

Replying to erdmann:

Do you have something like "EHCI BIOS handoff" in your BIOS settings ? If yes toggle between on and off and see if it makes a difference.

No, i can only enable/disable usb2.0 support and there is also a switch for legacy usb support.

[Lars Erdmann]

Turn off USB legacy support

[rbri]

Replying to erdmann:

Turn off USB legacy support

Legacy support was always off.

[Lars Erdmann]

try new rbri.zip. It it doesn't work don't send any traces. If it still does not work, I will need to add additional tracepoints to the driver to really add any benefit to tracing for the problem at hand. As far as I understand USB 2.0 camera works but WD book + other memory sticks do not. That is clearly a timing problem.

[Lars Erdmann]

It would also be interesting to see (in trace) and know what happens if you turn USB legacy support ON. The next thing to try once we got the current problem solved.

[Lars Erdmann]

I had to update rbri.zip yet again. Sorry.

[rbri]

Replying to erdmann:

try new rbri.zip. It it doesn't work don't send any traces. If it still does not work, I will need to add additional tracepoints to the driver to really add any benefit to tracing for the problem at hand. As far as I understand USB 2.0 camera works but WD book + other memory sticks do not. That is clearly a timing problem.

No change with the new version :-(

BTW: Can you verify the used driver versions from the traces. After all this changes during the last weeks, sometimes i fear i have a wrong version running (just to be sure)

[rbri]

Replying to erdmann:

I had to update rbri.zip yet again. Sorry.

Same with this build.

Have to leave now, will be back in 2h.

[Lars Erdmann]

The driver currently is not under version control. On the other hand I only have been changing USBEHCD.SYS. Always throw away older versions.
1.) please take a trace for USBEHCD.SYS ONLY. Do not trace USBOHCD.SYS.
2.) only attach USB 2.0 devices. In fact only attach the WD book and nothing else. That will give me a chance to see how the port the WD book attached to behaves: is it powered on ? Does it change to enabled on a port reset ? etc. 3.) as an additional step for you to test if it has an influence: comment out all USBOHCD.SYS from config.sys. See if that changes anything.

Sorry but tracing is the only way for me to gather enough info from your system to really see what's going on. Unfortunately USB HCs from different manufacturers all behave differently. In short: we might need to go additional rounds.

[rbri]

Replying to erdmann:

Sorry but tracing is the only way for me to gather enough info from your system to really see what's going on. Unfortunately USB HCs from different manufacturers all behave differently. In short: we might need to go additional rounds.

For me that is not a problem. My fear is more that it is no fun for you.

New traces attached

[rbri]

trace for detaching and attaching again

[Lars Erdmann]

I am not sure if it will fix the problem but:
can you change config.sys lines to read:
BASEDEV=USBEHCD.SYS /S:1 /V /FS
BASEDEV=USBOHCD.SYS /V /FS
BASEDEV=USBOHCD.SYS /V /FS

In particular the /S:1 is important. You can also vary it from 1,2,4,8,16,32,64 and see if that makes a difference. Also /FS might be necessary so that on shutdown the ports are reset. Just experiment, start off with the lines given above.

[Lars Erdmann]

Your trace output looks like what I would expect and is comparable to what I see on my system therefore device attach/detach as such does not seem to be the problem. I will need to add additional tracing to see if the HC is actually executing or just sitting there doing nothing.
Another cause of problem might be that the ISR is never executed (again, I would need to add tracing to the ISR to see if it fires).
Is it possible that there is an IRQ conflict in your system ?
Your initial pci.exe output shows that the EHCI controller is on the same IRQ as some other device. As a test, try to use no PSD at all (which will leave you with one CPU only), or use OS2APIC.PSD /APIC or use latest ACPI.PSD 3.19.14.

Also, can you completely power down your system and power back up ? I have to do that on my development machine as power down via front button is NOT the same as powering it off and back on via power switch on the rear.

[Lars Erdmann]

By the way: did you change anything about your system ? Installed additional memory and the like ?

[Lars Erdmann]

I still think I screwed up something about root hub handling. Please try with new rbri.zip.
As an additional test: plug in your WD book into a port. Hopefully it'll work. Then unplug the WD book and plug in a USB 1.x device (USB mouse etc.) into the SAME port. It should then also work. You should be able to go back and forth.

[rbri]

Replying to erdmann:

I still think I screwed up something about root hub handling. Please try with new rbri.zip.
As an additional test: plug in your WD book into a port. Hopefully it'll work. Then unplug the WD book and plug in a USB 1.x device (USB mouse etc.) into the SAME port. It should then also work. You should be able to go back and forth.

No change; do you like to have a new trace.

By the way: did you change anything about your system ? Installed additional memory and the like ?

I switched from the acpi 3.18 to ACPI.PSD 3.19.14. But at the moment i have to run this one with some special parameters, because of traps (​http://svn.netlabs.org/acpi/ticket/524). Nothing else changed.

[Lars Erdmann]

To be honest: I am clueless of why it won't work. The camera still works, correct ?
If yes, it cannot be an IRQ problem ...
Have you completely powered off and repowered the system ? Are you using this system with other OSes ?
Also as a test: Please check without any PSD loaded. This works also with SMP kernels (but only 1 processor will be active).
Also, comment out USBOHCD.SYS from config.sys and try with USBEHCD.SYS only.
Also, can you try to plug your WD book into the same port that you plugged the camera ?

[Lars Erdmann]

I now backlevelled the only significant thing for EHCI that changed in between usbhcd9 and usbhcd10. Retry rbri.zip.
If it works I will have a conflict: I had to change EHCI BIOS handover due to ticket #6. I will have to find a solution that satisfies both ...

[Lars Erdmann]

Note: ehcirhub.c: reconsider setting (PORTSC_P_OWNER | | PORTSC_WKDSCNNT_E) instead of just PORTSC_P_OWNER

[rbri]

Replying to erdmann:

To be honest: I am clueless of why it won't work. The camera still works, correct ?

Yes

If yes, it cannot be an IRQ problem ...

Agree

Have you completely powered off and repowered the system ?

Sometimes but not in all cases. Will do it in the future for all my tests.

Are you using this system with other OSes ?

No

I now backlevelled the only significant thing for EHCI that changed in between usbhcd9 and usbhcd10. Retry rbri.zip.

But the problem with the drive was introduced in version usbhcd7 (usbhcd6 was the last working version)

If it works I will have a conflict: I had to change EHCI BIOS handover due to ticket #6. I will have to find a solution that satisfies both ...

So good news, no conflict... ;-)

Have removed acpi.psd from the config. So we have a fixed configuration to start from.

During the last shutdown i got some beeps, is this related to the /FS parameter for the drivers?

[Lars Erdmann]

Yes, beeps stem from using /FS. The beeps have different pitches with increased frequency from USBUHCD.SYS - USBOHCD.SYS - USBEHCD.SYS. In short: USBEHCD.SYS gives a very high beep, USBOHCD.SYS (in your case) a lower beep. There is a beep per driver instance, for you that's 1 high beep from USBEHCD.SYS and 2 lower beeps from USBOHCD.SYS.

In comment 4 you state that usbhcd9 (version 10.171) works ok whereas usbhcd10 (version 10.172) does not. Are you now saying that usbhcd9 did not work ?

1.) Look back at usbhcd6 (10.168, SVN: 93) and usbhcd7 (10.169, SVN: 116):
moved PCIPMPowerUp from INIT_COMPLETE to INIT. It used to be right before EHCIStopBios. Reconsider also for USBUHCD.SYS + USBOHCD.SYS ?
2.) reconsider setting just PORTSC_P_OWNER instead of (PORTSC_P_OWNER | PORTSC_WKDSCNNT_E)
3.) restore EHCI handover, change didn't help

[rbri]

Replying to erdmann:

In comment 4 you state that usbhcd9 (version 10.171) works ok whereas usbhcd10 (version 10.172) does not. Are you now saying that usbhcd9 did not work ?

No, no, i was confused

[rbri]

Anything i can do now?

[Lars Erdmann]

Sorry: did usbhcd9 work ?

[rbri]

Replying to erdmann:

Sorry: did usbhcd9 work ?

Yes, switching back to usbxhcd9.zip make all my test devices work. The MyBook, and the two usb sticks are attached and visible in the usbdock. All listed with 'hohe Geschwindigkeit (2.0)'.

The camera is also detected but shows 'volle Geschwindigkeit (1.1)'.

Made this test without acpi.psd and with

• BASEDEV=USBEHCD.SYS /V
  
• BASEDEV=USBOHCD.SYS /V
  
• BASEDEV=USBOHCD.SYS /V
  

And i have switched off the system for one minute before the boot.

[Lars Erdmann]

For the camera, please save the device report from USB Dock and attach as file. My understanding is that it is NOT a USB 2.0 device but rather a USB 1.x device.

Please also completely power down the whole system and retry with the latest drivers.

[Lars Erdmann]

and yet another update to rbri.zip.

[rbri]

Camera report from USB Dock

[rbri]

Replying to erdmann:

and yet another update to rbri.zip.

But no behavior change. Only the camera is working.
Made this test without acpi.psd and with

BASEDEV=USBEHCD.SYS /V
BASEDEV=USBOHCD.SYS /V
BASEDEV=USBOHCD.SYS /V

[Lars Erdmann]

How much RAM do you have installed ? More than 2GB, correct ? How much ? If it is not too much hassle (and as a test only, a fix will follow): reduce your RAM to <= 2 GB and retry with latest drivers.
I have a suspicion that all this centers around a nasty NVidia chipset EHCI HC related HW bug.
I DID make a change in dynamic memory allocation in between usbhcd9 and usbhcd10. But I thought it wouldn't turn out to be that relevant ...

[Lars Erdmann]

Please retry (forget about disassembling your PC).

0.) please let me know how much RAM your system has. I'd expect it to have at least 4 GB.
1.) send trace in any case (if fixed or not)
2.) reget device report from USB dock for the camera. It should now announce itself as a USB 2.0 device (with a non-functional USBEHCD it announces itself as a USB 1.1 device ...)
3.) let me know if all your USB 2.0 devices now work ok
4.) it should now work with/without ACPI.PSD regardless. The error was somewhere else, see below.

If it works: The error was so fundamental that about everything could have happened, in particular, the EHCI HC DMA engine could overwrite/corrupt memory in the system arena with whatever side effect that can have. You should retry to run ACPI.PSD without any parameters (unless you also had problems with USBEHCD.SYS 10.162). If it now works, report back to the ACPI developer [[BR]] Be aware that your EHCI HC HW has a severe bug and what I did was to work around it. The negative side effect is that more memory <= 16 MB physical address is now used. This could lead to the well known problem that if you have many device drivers loaded (where for historical reasons most of these dynamically allocate below the 16 MB phys. addr. boundary) that some device driver might refuse to load. The USBEHCD.SYS device driver is now behaving like 10.162 in that respect.

[rbri]

Replying to erdmann:

How much RAM do you have installed ? More than 2GB, correct ? How much ? If it is not too much hassle (and as a test only, a fix will follow): reduce your RAM to <= 2 GB and retry with latest drivers.
I have a suspicion that all this centers around a nasty NVidia chipset EHCI HC related HW bug.
I DID make a change in dynamic memory allocation in between usbhcd9 and usbhcd10. But I thought it wouldn't turn out to be that relevant ...

To late, i have disassembled the PC already.
I have 4GB RAM.
What i did:

• back to usbhcd9 -> everything works fine
• remove 2GB -> everything still works fine
• switch to usbhcd10 -> everything (myBook, camera, sticks) works fine !!!!
• switch to usb178 -> everything works fine !!!!

Will do all the other tests with the new rbri.zip later this evening.

[rbri]

Replying to erdmann:

Please retry (forget about disassembling your PC).

0.) please let me know how much RAM your system has. I'd expect it to have at least 4 GB.

4GB

1.) send trace in any case (if fixed or not)

later

2.) reget device report from USB dock for the camera. It should now announce itself as a USB 2.0 device (with a non-functional USBEHCD it announces itself as a USB 1.1 device ...)

No, it is still at 1.1

3.) let me know if all your USB 2.0 devices now work ok

Yes all devices now detected

4.) it should now work with/without ACPI.PSD regardless. The error was somewhere else, see below.

Will try that now.

[rbri]

4.) it should now work with/without ACPI.PSD regardless. The error was somewhere else, see below.

Still the same problems with ACPI.

[Lars Erdmann]

The latest trace you have taken: do I interpret correctly that you have now taken this trace with 2 GB of RAM but with the OLD driver (in other words: not my latest version of rbri.zip) ?
For your info: I am looking at "EHCIResetHost Trace Exit": HCOR.fmListBaseAddr and HCOR.nextAsyncListAddr. For your system with the quirky NVidia chipset, it is essential that these physical addresses are <= 2 GB if you have >= 4 GB of RAM installed (which you normally do as you normally have 4 GB installed). On the next trace (taken with new rbri.zip) you should then see physical addresses <= 16 MB (that is <= 0x1000000). Currently I see 0xc7e3D000 and 0xc7e47000, that is something around >= 3 GB.

[Lars Erdmann]

Error case: ​http://support.microsoft.com/kb/976972/en-us

[rbri]

Replying to erdmann:

The latest trace you have taken: do I interpret correctly that you have now taken this trace with 2 GB of RAM but with the OLD driver (in other words: not my latest version of rbri.zip) ?

No the trace was done with 4GB and the latest rbri.zip

[Lars Erdmann]

But it does not work, does it ? I am confused ...

[rbri]

Replying to erdmann:

But it does not work, does it ? I am confused ...

Yet it is confusing.

1. It works
2. I checked it again; i have your latest zip running

Will do another trace tomorrow (without acpi.psd).

[Lars Erdmann]

I don't pretend to understand it. I will do some quick hack to step through the memory allocation routines. Please check in the next couple of days if everything is working as expected. If something goes bad again just report back. For the time being I leave the bug open. Just let me know when I can close it.

[Lars Erdmann]

Replying to rbri:

Replying to erdmann:

But it does not work, does it ? I am confused ...

Yet it is confusing.

1. It works
2. I checked it again; i have your latest zip running

Will do another trace tomorrow (without acpi.psd).

Make sure that you test with EARLYMEMINIT=TRUE and also without EARLYMEMINIT / EARLYMEMINIT=FALSE

[Lars Erdmann]

The final update to rbri.zip. Please use that for tests. As I said: please also test with EARLYMEMINIT=TRUE, EARLYMEMINIT=FALSE and no EARLYMEMINIT at all in config.sys.

[Lars Erdmann]

Hopefully the final version of USBEHCD.SYS, also updated USBOHCD.SYS

[Lars Erdmann]

I also updated USBOHCD.SYS. Make sure that you also replace and test if everything (in particular, your camera) still works ok.

[rbri]

Replying to erdmann:

I also updated USBOHCD.SYS. Make sure that you also replace and test if everything (in particular, your camera) still works ok.

Did some more tests with different usb devices. Everything looks good so far.

Additionally i have checked "EHCIResetHost Trace Exit": HCOR.fmListBaseAddr and HCOR.nextAsyncListAddr after all reboots and the address was always <= 0x1000000.

Will do some more test and inform you about the results. But so far; thanks a lot for your support.