Have the early USB takeover enabled for i386 and amd64
by default.
This also avoids a panic on PowerPC where the resource
isn't released properly and we find a busy resource
when the USB host controller wants to allocate it...
- Do not map entire real mode memory (1MB). Instead, we map IVT/BDA and
ROM area separately. Most notably, ROM area is mapped as device memory
(uncacheable) as it should be. User memory is dynamically allocated and
free'ed with contigmalloc(9) and contigfree(9). Remove now redundant and
potentially dangerous x86bios_alloc.c. If this emulator ever grows to
support non-PC hardware, we may implement it with rman(9) later.
- Move all host-specific initializations from x86emu_util.c to x86bios.c and
remove now unnecessary x86emu_util.c. Currently, non-PC hardware is not
supported. We may use bus_space(9) later when the KPI is fixed.
- Replace all bzero() calls for emulated registers with more obviously named
x86bios_init_regs(). This function also initializes DS and SS properly.
- Add x86bios_get_intr(). This function checks if the interrupt vector is
available for the platform. It is not necessary for PC-compatible hardware
but it may be needed later. ;-)
- Do not try turning off monitor if DPMS does not support the state.
- Allocate stable memory for VESA OEM strings instead of just holding
pointers to them. They may or may not be accessible always. Fix a memory
leak of video mode table while I am here.
- Add (experimental) BIOS POST call for vesa(4). This function calls VGA
BIOS POST code from the current VGA option ROM. Some video controllers
cannot save and restore the state properly even if it is claimed to be
supported. Usually the symptom is blank display after resuming from suspend
state. If the video mode does not match the previous mode after restoring,
we try BIOS POST and force the known good initial state. Some magic was
taken from NetBSD (and it was taken from vbetool, I believe.)
- Add a loader tunable for vgapci(4) to give a hint to dpms(4) and vesa(4)
to identify who owns the VESA BIOS. This is very useful for multi-display
adapter setup. By default, the POST video controller is automatically
probed and the tunable "hw.pci.default_vgapci_unit" is set to corresponding
vgapci unit number. You may override it from loader but it is very unlikely
to be necessary. Unfortunately only AGP/PCI/PCI-E controllers can be
matched because ISA controller does not have necessary device IDs.
- Fix a long standing bug in state save/restore function. The state buffer
pointer should be ES:BX, not ES:DI according to VBE 3.0. If it ever worked,
that's because BX was always zero. :-)
- Clean up register initializations more clearer per VBE 3.0.
- Fix a lot of style issues with vesa(4).
all host controllers at the same time, we avoid problems where the BIOS will
actually write to the USB registers of all the USB host controllers every time
we handover one of them, and consequently reset the OS programmed values.
Submitted by: avg
Reviewed by: jhb
o introduce PCIE_REGMAX and use it instead of ad-hoc constant
o where 'reg' parameter/variable is not already unsigned, cast it to
unsigned before comparison with maximum value to cut off negative
values
o use PCI_SLOTMAX in several places where 31 or 32 were explicitly used
o drop redundant check of 'bytes' in i386 pciereg_cfgread() - valid
values are already checked in the subsequent switch
Reviewed by: jhb
MFC after: 1 week
decoding "took". Other OS's that I checked do not do this and it breaks
some amdpm(4) devices. Prior to 7.2 we did not honor the error returned
when this failed anyway, so this in effect restores previous behavior.
PR: kern/137668
Tested by: Aurelien Mere aurelien.mere amc-os.com
MFC after: 3 days
Different sub-kinds of PCI buses may have different rules and
thus it is up for the bus backends to do proper input checks.
For example, PCIe allows configuration register numbers < 0x1000,
while for PCI proper the limit is 0x100.
And, in fact, the buses already do the checks.
Reviewed by: jhb
MFC after: 1 week
X-ToDo: add check for negative value to bus backends
X-ToDo: use named constant for maximum PCIe register
actually specify valid bases that should be treated just as normal.
The PCI specifications have no indication that 0 would be a magic value
indicating a disabled BAR as commonly used on at least amd64 and i386
but not sparc64. It's unclear what to do in pci_delete_resource()
instead of writing 0 to a BAR though as there's no (other) way do
disable individual BARs so its decoding is left enabled in case of
__PCI_BAR_ZERO_VALID for now.
Approved by: re (kib), jhb
MFC after: 1 week
registers.
- Cleanup PCI-X capability printf to not leave a dangling "supports" for
some PCI-X bridges.
- Display additional PCI express details including the negotiated and max
link width and the actual and maximum supported max payload.
MFC after: 1 month
addresses to BARs into new pci_read_bar() and pci_write_bar() routines.
pci_add_map(), pci_alloc_map(), and pci_delete_resource() now use these
routines to work with BARs.
- Just pass the device_t for the new PCI device to various routines instead
of passing the device, bus, slot, and function.
Reviewed by: imp
(1) Fix pcib_read/write_config prototypes.
(2) When contrainting a resource request for a 'subtractive' bridge,
it is important to select a range outside the base/limit
registers, since those are the only values known to not
possibly work. On my HP laptop, the base bridge excludes I/O
ports 0xa000-0xafff, however that was the range we were passing
up the tree. Instead, when a range spans the "hole" we now
arbitrarily pick the range just above the hole to allocate from.
All of my rl and xl cards, at a minimum, started working again on this
laptop with those fixes.
when determining the size of a BAR by writing all 1's to the BAR and
reading back the result, always operate on the full 64-bit size.
Reviewed by: imp
MFC after: 1 month
flag when calling bus_alloc_resource() to allocate resources from a parent
PCI bridge. For PCI-PCI bridges this asks the bridge to satisfy the
request using the prefetchable memory range rather than the normal
memory range.
Reviewed by: imp
Reported by: scottl
MFC after: 1 week
BAR could be allocated twice by different children of a vgapci0 device.
To fix this, change the vgapci0 device to track references on its associated
resources so that they are only allocated once from the parent PCI bus and
released when no children are using them. Previously this leaked a small
amount of KVA on at least some architectures.
We now explicitly enable INTx during bus_setup_intr() if it is needed.
Several of the ata drivers were managing this bit internally. This is
better handled in pci and it should work for all drivers now.
We also mask INTx during bus_teardown_intr() by setting this bit.
Reviewed by: jhb
MFC after: 3 days
A while back, Warner changed the PCI bus code to reserve resources when
enumerating devices and simply give devices the previously allocated
resources when they call bus_alloc_resource(). This ensures that address
ranges being decoded by a BAR are always allocated in the nexus0 device
(or whatever device the PCI bus gets its address space from) even if a
device driver is not attached to the device. This patch extends this
behavior further:
- To let the PCI bus distinguish between a resource being allocated by
a device driver vs. merely being allocated by the bus, use
rman_set_device() to assign the device to the bus when it is owned
by the bus and to the child device when it is allocated by the child
device's driver. We can now prevent a device driver from allocating
the same device twice. Doing so could result in odd things like
allocating duplicate virtual memory to map the resource on some
archs and leaking the original mapping.
- When a PCI device driver releases a resource, don't pass the request
all the way up the tree and release it in the nexus (or similar device)
since the BAR is still active and decoding. Otherwise, another device
could later allocate the same range even though it is still in use.
Instead, deactivate the resource and assign it back to the PCI bus
using rman_set_device().
- pci_delete_resource() will actually completely free a BAR including
attemping to disable it.
- Disable BAR decoding via the command register when sizing a BAR in
pci_alloc_map() which is used to allocate resources for a BAR when
the BIOS/firmware did not assign a usable resource range during boot.
This mirrors an earlier fix to pci_add_map() which is used when to
size BARs during boot.
- Move the activation of I/O decoding in the PCI command register into
pci_activate_resource() instead of doing it in pci_alloc_resource().
Previously we could actually enable decoding before a BAR was
initialized via pci_alloc_map().
Glanced at by: bsdimp
This addresses interrupt storms that were noticed after enabling MSI
in drm. I think this is due to a loose interpretation of the PCI 2.3
spec, which states that a function using MSI is prohibitted from using
INTx. It appears that some vendors interpretted that to mean that they
should handle it in hardware, while others felt it was the drivers
responsibility.
This fix will also likely resolve interrupt storm related issues with
devices other than drm.
Reviewed by: jhb@
MFC after: 3 days
device. The details include the current value of the BAR (including all
the flag bits and the current base address), its length, and whether or not
it is enabled. Since this operation is not invasive, non-root users are
allowed to use it (unlike manual config register access which requires
root). The intention is that userland apps (such as Xorg) will use this
interface rather than dangerously frobbing the BARs from userland to
obtain this information.
- Add a new sub-mode to the 'list' mode of pciconf. The -b flag when used
with -l will now list all the active BARs for each device.
MFC after: 1 month
by writing all 1's to it to determine its length. This fixes issues with
MCFG on at least some machines where a trashed BAR claimed subsequent
attempts at PCI config transactions because the addresses in the MCFG
window fell in the decoding range of the BAR.
In general it is a bad idea to leave the BARs enabled while we are
frobbing with them in this manner.
Sleuthing by: tegge
MFC after: 1 week
to vga_pci.c to request on behalf of it's children. This causes vgapci to show
up as the interrupt owner in vmstat -i, rather than the child device.
Approved by: jhb(mentor)
only in low memory situations, so the error fork of these fixes is
lightly tested, but they should do the least-wrong thing...
Submitted by: Hans Petter Selasky
memory area's base and limit are optional. The low 4-bits of the "low"
prefetchable registers indicates whether or not a 32-bit or 64-bit
region is supported. The PCI-PCI driver had been assuming that all bridges
supported a 64-bit region (and thus the two upper 32-bit registers). Fix
the driver to only use those registers if the low 4-bits of the "low"
registers indicate that a 64-bit region is supported. The PCI-PCI bridge
in the XBox happens to be a bridge that only supports a 32-bit region.
Reported by: rink
MFC after: 1 week
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.
This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.
pci_add_map(). First, this condition is already handled earlier in
the function. Second, as written the check would never fire as the
'start' value was overwritten with a long value (rman_get_start() returns
long) before the comparison was done.
Discussed with: imp
MFC after: 2 weeks
for a PCI device during the boot-time probe of the parent PCI bus, then
zero the BAR and clear the resource list entry for that BAR. This forces
the PCI bus driver to request a valid resource range from the parent bridge
driver when the device driver tries to allocate the BAR. Similarly, if the
initial value of a BAR is a valid range but it is > 4GB and the current OS
only has 32-bit longs, then do a full teardown of the initial value of the
BAR to force a reallocation.
Reviewed by: imp
MFC after: 1 week
