Opened 3 years ago

Closed 3 years ago

#11 closed defect (fixed)

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

Reported by: darcio Owned by: erdmann
Priority: minor Milestone:
Component: basedrv Version:
Keywords: USB 177 Cc:

Description

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.

Attachments (4)

USB_177_debug2.zip (14.8 KB) - added by darcio 3 years ago.
Debug2 tracefmt output
USB_177_debug3.zip (13.5 KB) - added by darcio 3 years ago.
Debug3 tracefmt result
pci_info (54.6 KB) - added by darcio 3 years ago.
PCI dump
INFO (2.7 KB) - added by darcio 3 years ago.
DEBUG Session Summary

Download all attachments as: .zip

Change History (17)

Changed 3 years ago by darcio

Debug2 tracefmt output

Changed 3 years ago by darcio

Debug3 tracefmt result

Changed 3 years ago by darcio

PCI dump

Changed 3 years ago by darcio

DEBUG Session Summary

comment:1 follow-up: Changed 3 years ago by 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 ?

Last edited 3 years ago by erdmann (previous) (diff)

comment:2 Changed 3 years ago by 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

Last edited 3 years ago by erdmann (previous) (diff)

comment:3 follow-up: Changed 3 years ago by erdmann

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

comment:4 in reply to: ↑ 1 Changed 3 years ago by 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.

comment:5 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by erdmann

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

comment:8 Changed 3 years ago by erdmann

  • Owner changed from somebody to erdmann
  • Status changed from new to accepted

comment:9 Changed 3 years ago by 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...

comment:10 Changed 3 years ago by 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?

comment:11 Changed 3 years ago by 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.

Last edited 3 years ago by erdmann (previous) (diff)

comment:12 Changed 3 years ago by 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!

comment:13 Changed 3 years ago by erdmann

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.