actual resource values we received from the system rather than the range
we requested. Since we request a range starting at 0, we would record
that number. Later, since this == 0, we'd allocate again. However,
we wouldn't write the new resource into the BAR. This resulted in
a resource leak as well as a BAR that couldn't access the resource at
all since rman_get_start, et al, were wrong.
MFC After: 1 week (assuming RELENG_6 is open for business)
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.)
routing, etc. in a static pci_assign_interrupt() function.
- Add a sledgehammer that allows the user to override the interrupt
assignment of any PCI device via a tunable (e.g. "hw.pci0.7.INTB=5" would
force any functions on the pci device in slot 7 of bus 0 that use B# to
use IRQ 5). This should be used with great caution! Generally, if the
interrupt routing in use provides specific tunables (such as hard-wiring
the IRQ for a given $PIR or ACPI PCI link device), then those should be
used instead. One instance where this tunable might be useful is if a
box has an MPTable with duplicate entries for the same PCI device with
different IRQs.
MFC after: 1 week
the Intel 82371AB PCI-ISA bridge. We now do this all the time for the
!APIC case in the atpic driver. This cuts the raw line count for this
driver by about 40%.
MFC after: 1 week
has been removed. It has been replaced by hw.pci.do_power_nodriver
and hw.pci.do_power_resume. The former defaults to 0 while the latter
defaults to 1.
When do_powerstate was set to 0, it broke suspend/resume for a lot of
people as an unintended consequence. This change will only affect the
areas that were intended to affect. This change will have no effect on
servers, but will help laptops quite a bit.
MFC After: 3 days.
same as today: do no power management. 1 means be conservative about
what you power down (any device class that has caused problems gets
added here). 2 means be agressive about what gets powered down (any
device class that's fundamental to the system is here). 3 means power
them all down, reguardless. The default is 1.
The effect in the default system is to add mass storage devices to the
list that we don't power down. From all the pciconf -l lists that
I've seen for the aac and amr issue, the bad device has been a mass
storage device class.
This is an attempt at a compromise between the very small number of
systems that have extreme issues with powerdown, and the very large
number of systems that gain real benefits from powerdown (I get about
20% more battery life when I attach a minimal set of drivers on my
Sony). Hopefully it will strike the proper balance.
MFC After: 3 days (before next beta)
return the correct bar size if we encountered a 64-bit BAR that had
its resources already assigned. If the resources weren't yet
assigned, we'd bogusly assume it was a 32-bit bar and return 1.
not exsist, do not have ioctl return an error, but instead set -1
in the data returned to the user. This allows the HP bios flash
utilities to work without requiring changes to their code.
Reviewed by: jhb
against 0 in pci_alloc_map, just like we do in pci_add_map. Also,
make sure that we restore the value to the BAR that was there before
if the bar is 0. Chances are that it was 0 before the write too and
that the restoration is a nop, but better safe than sorry.
Notice by: dwhite
we are processing has a base address of zero. Note that this will only
change behavior for devices where all the BARs of a given type have a base
address of 0 since we will enable the appropriate access when we encounter
the first BAR with a base that is not 0. Specifically, this allows certain
Toshiba laptops to no longer require 'hw.pci.enable_io_modes=0' to avoid
hangs during boot.
PR: kern/20040
PR: i386/63776 (possibly)
PR: i386/68900 (possibly)
PR: i386/74532 (possibly)
MFC after: 1 week
theoretically unload pci bridges or pci drivers. It will also allow
detach to work if one needed to detach a subtree.
This is inspired by looking at the p4 commits from bms to his 5.4
tree, but I didn't look at the final results.
for the VGA I/O or memory ranges, when it's not within the default
ranges decoded by the bridge. When allocation for VGA addresses is
attempted, check that the bridge has the VGA Enable bit set before
allowing it.
As such, newbusified VGA drivers can allocate their resources when
the VGA adapter is behind a PCI-to-PCI bridge.
Reviewed by: imp@, jhb@
printf's during a verbose boot is more intuitive (the BAR listings and
interrupt routing info now comes after the config header dump rather than
just before it).
Otherwise, busses that implement the pcib interface that forget to
implement pcib_route_interrupt would return EIO, which the caller
interprets as 'use interrupt 6'. This is likely the cause of much of
the grief that we had when I enabled power modes for the cardbus
bridge, since the card needed to reroute the interrupt to it and it
was getting 6 which was d by the pccbb sanity checks.
last in the list rather than first.
This makes the resouces print in the 4.x order rather than the 5.x order
(eg fdc0 at 0x3f0-0x3f5,0x3f7 is 4.x, but 0x3f7,0x3f0-0x3f5 is 5.x). This
also means that the pci code will once again print the resources in BAR
ascending order.
like a valid range. We already do this in the memory case (although
the code there is somewhat different than the I/o case because we have
to deal with different kinds of memory). Since most laptops don't
have non-subtractive bridges, this wasn't seen in practice.
Evidentally the Compaq R3000 hits this problem with PC Cards.
Some minor style fixes while I'm here.
Submitted by: Jung-uk Kim
suggested by Peter Edwards. This seems to fix my fxp problems and
likely will fix his as well. Use DELAY rather than *sleep because we
can be called from any context.
the PCI bus. We presently have no drivers for these devices, so they
are powered down. This is undesirable behavior since it breaks the
system when the base peripherals go away suddenly in the middle of
boot.
# if we ever get generic drivers for memory and/or base peripherals, then
# we can remove the tests here.
