177 release showing delays during boot for USBE & USBO drivers.

[darcio]

The latest working version was 10_168, since then none until 10_177 were able to boot. 177 however allows the machine to boot, but there is a long delay right before the WPS comes up.

System is configured to run in SMP mode (4 core configuration) using Warp 4.52 (CP2) level, FP6 configuration but 20050811 kernel.

[darcio]

Debug2 tracefmt output

[darcio]

Debug3 tracefmt result

[darcio]

PCI dump

[darcio]

DEBUG Session Summary

[Lars Erdmann]

What's the difference between debug2 and debug 3 ?
I can say from the trace timestamps (this is true for both: debug2 and debug3) that the delay (about 5 minutes) occurs in between end of init of USBEHCD.SYS driver and start of init complete of USBEHCD.SYS driver.
There is no obvious reason why this delay should be caused by the USB HC drivers as the drivers don't execute during that time, not even a HW interrupt.
Other drivers execute their init and init complete sections during that time span so it could be about any driver causing that delay.
Do the drivers properly work when the system finally goes operational ?

[Lars Erdmann]

​http://old.nabble.com/USB-troubles-with-SB600-SB700-chipsets-td23587677.html

Might need a change in EHCI: in pci config space set (1<<27) in pci reg 0x50 for dev 0x4396 and SMBus revisions 3a and 3b (here we have SMBus revision 3c but nonetheless ...)

​http://lxr.linux.no/linux+v3.1.5/drivers/usb/host/ehci-pci.c (line 110)

EHCI dev 0x4396: frame list link pointer always needs to point to valid QH

[Lars Erdmann]

If you back out the USBEHCD.SYS driver to 10.162, does that fix the hang ?

[darcio]

Replying to erdmann:

What's the difference between debug2 and debug 3 ?
I can say from the trace timestamps (this is true for both: debug2 and debug3) that the delay (about 5 minutes) occurs in between end of init of USBEHCD.SYS driver and start of init complete of USBEHCD.SYS driver.
There is no obvious reason why this delay should be caused by the USB HC drivers as the drivers don't execute during that time, not even a HW interrupt.
Other drivers execute their init and init complete sections during that time span so it could be about any driver causing that delay.
Do the drivers properly work when the system finally goes operational ?

Oh boy...my mistake, I realized now that my debug INFO file description was wrong. Here they are: debug2 = using /S:1 option, debug3 = using /S:1 /FS options. I did the dubug for both because in a separate Usenet post you had asked for a comparison of a normal run versus the /FS parameter run.

Once the system boots they work just fine. I only use the USB to connect to my Pentax K5 DSLR camera, the typical xfer rates are: 10 M bytes/s, or a thumb-drive, both work great.

[darcio]

Replying to erdmann:

If you back out the USBEHCD.SYS driver to 10.162, does that fix the hang ?

The last good/working version of your USB driver on my system is 168...so with 168 that is correct, no delay is encountered assuming ALL USB drivers are 168 version. I will back out to 168 for USBEHCD.SYS only and will test this out next. Give me about 1 hr to report back on this.

[darcio]

Replying to darcio:

Replying to erdmann:

If you back out the USBEHCD.SYS driver to 10.162, does that fix the hang ?

The last good/working version of your USB driver on my system is 168...so with 168 that is correct, no delay is encountered assuming ALL USB drivers are 168 version. I will back out to 168 for USBEHCD.SYS only and will test this out next. Give me about 1 hr to report back on this.

OK, sorry, it took a little longer. Here are the results:

1) reverting to 168 of USBEHCD kept the delay in boot sequence 2) restoring to 177 of USBEHCD and reverting back to 168 of USBOHCD removed the delay in the boot sequence

So it would appear to me that somehow USBOHCD has some type of a bearing on this situation. Do you want me to check speific BIOS settings? I'm thinking stuff like 'legacy USB' support, etc?

I can also boot USBEH & USBOH separately from each other and see if the delay is due to some kind of an interaction between these drivers and the hardware itself...let me know what to try next.

[Lars Erdmann]

Try the very latest "grimus.zip" from ticket #9. It contains an updated USBOHCD.SYS where I also tried to fix bootup issues.

[darcio]

Lars, I tested the 'grimus.zip' and had a complete TRAP on boot...I'm back to testing again, this time I pulled the 178 off of Hobbes and re-orderd my CONFIG.SYS to pull USBEH before USBOH...will report back as soon as I'm done here! Thanks again...

[darcio]

OK, booted with 178, no TRAP, boot went fine, but still seeing the same delay as previously.

Do you want me to re-do the TRACE?

[Lars Erdmann]

Get latest rbri.zip from ticket #2 and try that. Make sure you get the newest one. There are 2 files with about the same name. Then take a new trace.

If you have a trap: please take a picture of the trap screen ! I need the register dump to locate the point of the trap.

[darcio]

OK, couple of updates.

1) tried rbri.zip from ticket #2, but that trapped 2) had a major hardware failure on my PC, old motherboard died, replaced with a new motherboard, same brand, but different model, still using the same AMD SB chipset, AMD710 (so apparently that should be the same USB controller, obviously BIOS will impact this) 3) tried the latest driver release #179, that works great, but my platform has changed (as described above), basically:

• OLD => was MSI 790X-G45 mb
• NEW => is MSI 880G-E45, 2 USBEH, 5 USBOH controllers

The latest drop is working quite successfully with the NEW board, therefore I currently no longer have an issue that needs resolution.

Thanks very much for the great work supporting the driver, it is greatly appreciated!

Let me know please if you need anything from me, including boot LOG, even if for reference only. Otherwise, please go ahead and CLOSE the ticket.

Thanks!