cvs commit: src/sys/dev/pci pci.c

[Bill Paul]

wpaul       2005-10-25 06:53:45 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/pci          pci.c 
  Log:
  Add a 1 microsecond delay in pci_add_children(), right before the read
  of the PCIR_HDRTYPE register. It's the value returned from this
  read access that determines whether or not we decide a device is
  present at the current slot index. For some reason that I can't
  adequately explain, this read fails on my machine when probing the
  USB controller on my machine (which happens a multifunction device
  at slot index 3 hung off the PCI-PCI bridge on the AMD8111 (bus
  index 1)). The read will return 0xFF even though it should return
  0x80 to indicate the presence of a multifunction device.
  
  As near as I can tell, there's some timing issue involved with reading
  the 'dead' slot indexes 0 through 2 that causes the read of the actual
  device at slot 3 to fail. I tried a couple of different tricks to
  correct the problem (the patch to amd64/pci/pci_cfgreg.c fixes it
  for the amd64 arch), but adding this delay is the only thing that
  always allows the USB controllers to be correctly probed 100% of the
  time. Whatever the problem is, it's likely confined to the AMD8111
  chipset. However, a simple 1us delay is fairly harmless and should
  have no side effects for other hardware. I consider this to be
  voodoo, but it's fairly benign voodoo and it makes my USB keyboard
  and mouse work again.
  
  Note that this is the second time that I've had to resort to a
  1us delay to fix a PCI-related problem with this AMD8111/Opteron
  system (the first being a fix I made a while back to the NDISulator).
  It's possible the delay really belongs in the cfgreg code itself,
  or that pci_cfgreg needs some custom hackery for an errata in the
  8111. (I checked but couldn't find any documented errata on AMD's
  site that could account for these problems.)
  
  Revision  Changes    Path
  1.300     +1 -0      src/sys/dev/pci/pci.c