* Add a bus_if.m method - get_domain() - returning the VM domain or
ENOENT if the device isn't in a VM domain;
* Add bus methods to print out the domain of the device if appropriate;
* Add code in srat.c to save the PXM -> VM domain mapping that's done and
expose a function to translate VM domain -> PXM;
* Add ACPI and ACPI PCI methods to check if the bus has a _PXM attribute
and if so map it to the VM domain;
* (.. yes, this works recursively.)
* Have the pci bus glue print out the device VM domain if present.
Note: this is just the plumbing to start enumerating information -
it doesn't at all modify behaviour.
Differential Revision: D906
Reviewed by: jhb
Sponsored by: Norse Corp
forced invalidation of the cache range regardless of the presence of
self-snoop feature. Some recent Intel GPUs in some modes are not
coherent, and dirty lines in CPU cache must be flushed before the
pages are transferred to GPU domain.
Reviewed by: alc (previous version)
Tested by: pho (amd64)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
where as there are limited number(32) of mfi commands in the pool.
The mfi command pool is now restricted to 27 simultaneous accesses by using
a counting semaphore while calling the passthru function.
In the mrsas_cam.c source file there was a same function name mrsas_poll(),
which was same as the mrsas_poll() implemented in the mrsas.c file for the
polling interface.
To clearly distinguish the functionality by usage we have renamed the former
as mrsas_cam_poll().
In the passthru function let's say it has got an mfi command from the pool
but it has failed in one of the DMA function call which will lead to leak
an mfi command because in the ERROR case it directly returns and not freeing up
the occupied mfi command.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
It is meant to notify the applications which will be waiting for some
controller events to be occured.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
This Driver will create multiple MSI-x vector depending upon what FW expose.
As of now 12 Gbp/s MR controller (Invader and Fury) expose 96 msix vector.
As of now 6 Gbp/s MR controller (Thunderbolt) expose 16 msix vector.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
snv add, so I have added $FreeBSD$ as comment.
This commit is contininous of last mrsas commit, so that compilation
does not break.
Obtained from: AVAGO Technologies
MFC after: 2 weeks
machine, for which 32bit compatibilty code has been added.
As in linux there is only one device entry that is used to fire IOCTL commands,
a new device entry megaraid_sas_ioctl_node is added for solely this
purpose.
From one dev node i.e mrgaraid_sa_ioctl_node we have to find out the
controller instance in case of multicontroller, for which one management info
structure has been added.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
E.g: If the user wants to create more than 64VD on a controller,
it is not possible on current firmware/driver.
New feature and requirement to support upto 256VD, firmware/driver/apps need changes.
In addition to that, there must be a backward compatibility of the new driver with the
older firmware and vice versa.
RAID map is the interface between Driver and FW to fetch all required
fields(attributes) for each Virtual Drives.
In the earlier design driver was using the FW copy of RAID map where as
in the new design the Driver will keep the RAID map copy of its own; on which
it will operate for any raid map access in fast path.
Local driver raid map copy will provide ease of access through out the code
and provide generic interface for future FW raid map changes.
For the backward compatibility driver will notify FW that it supports 256VD
to the FW in driver capability field.
Based on the controller properly returned by the FW, the Driver will know
whether it supports 256VD or not and will copy the RAID map accordingly.
At any given time, driver will always have old or new Raid map.
Reviewed by : ambrisko
MFC after : 2 weeks
Sponsored by: AVAGO Technologies
These controllers seem to have the same feature of AR813x/AR815x and
improved RSS support(4 TX queues and 8 RX queues). alc(4) supports
all hardware features except RSS. I didn't implement RX checksum
offloading for AR816x/AR817x just because I couldn't get
confirmation from the Vendor whether AR816x/AR817x corrected its
predecessor's RX checksum offloading bug on fragmented packets.
This change adds supports for the following controllers.
o AR8161 PCIe Gigabit Ethernet controller
o AR8162 PCIe Fast Ethernet controller
o AR8171 PCIe Gigabit Ethernet controller
o AR8172 PCIe Fast Ethernet controller
o Killer E2200 Gigabit Ethernet controller
Tested by: Many
Relnotes: yes
MFC after: 2 weeks
HW donated by: Qualcomm Atheros Communications, Inc.
cannot be sent to the chip because a prerequisite L2 resolution
failed.
Submitted by: Hariprasad at chelsio dot com (original version)
MFC after: 2 weeks.
E5372 with different product IDs.
Interestingly, the standard E5372 IDs (12d1:1506) are currently listed in
u3g.c and are the same as the E3131. However, the R215/E5372 is an NCM
device and works well with cdce(4) whereas the E3131 isn't. More work
may be needed to better identify the other device IDs.
MFC after: 1 week
events we have actually counted 'Branch Instruction Retired' when people
asked for 'Unhalted core cycles' using the 'unhalted-core-cycles' event mask
mnemonic.
Reviewed by: jimharris
Discussed with: gnn, rwatson
MFC after: 3 days
Sponsored by: DARPA/AFRL
It was found that VirtualBox' AHCI does not allow nterrupt to be cleared
before the interrupt status register is read, causing interrupt storm.
AHCI specification allows to skip this register use when multi-vector MSI
is enabled and so interrupting port is known. For single-vector MSI that
is not stated explicitly, but if the port is only one, it is obviously
known too.
When the screen size is unknown, it's set to 0x0. We can't use that as
the buffer size, otherwise, functions such as vtbuf_fill() will fail.
This fixes a panic on RaspberryPi, where there's no vt(4) backend
configured early in boot.
PR: 193981
Tested by: danilo@
MFC after: 3 days
ports. The current bitmap array was too small to hold more than 16
bits and would at some point toggle the context size, which then would
trigger an enumeration fault and cause a fallback to the EHCI
companion controller, if any.
MFC after: 3 days
Add new functions to manipulate these mode & state, instead of calling
kbdd_ioctl() everyhere.
This fixes at least two bugs:
1. The state of the Scroll Lock LED and the state of scroll mode
could be out-of-sync. For instance, if one enables scroll mode on
window #1 and switches to window #2, the LED would remain on, but
the window wouldn't be in scroll mode.
Similarily, when switching between a console and an X.Org
session, the LED states could be inconsistent with the real
state.
2. When exiting from an X.Org session, the user could be unable to
type anything. The workaround was to switch to another console
window and come back.
Differential Revision: https://reviews.freebsd.org/D821
Reviewed by: ray@
Approved by: ray@
Tested by: kwm@
MFC after: 3 days
Also increase default for Tx queue get-list limit.
Too small limit results in TCP packets drops especiall when many
streams are running simultaneously.
Put list may be kept small enough since it is just a temporary
location if transmit function can't get Tx queue lock.
Submitted by: Andrew Rybchenko <arybchenko at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
Required size of event queue is calculated now.
Submitted by: Andrew Rybchenko <arybchenko at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
Remove trailing whitespaces and tabs.
Enclose value in return statements in parentheses.
Use tabs after #define.
Do not skip comparison with 0/NULL in boolean expressions.
Submitted by: Andrew Rybchenko <arybchenko at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
Fix a problem where the blockback driver could run out of requests,
despite the fact that we allocate enough request and reqlist
structures to satisfy the maximum possible number of requests.
The problem was that we were sending responses back to the other
end (blockfront) before freeing resources. The Citrix Windows
driver is pretty agressive about queueing, and would queue more I/O
to us immediately after we sent responses to it. We would run into
a resource shortage and stall out I/O until we freed resources.
It isn't clear whether the request shortage condition was an
indirect cause of the I/O hangs we've been seeing between Windows
with the Citrix PV drivers and FreeBSD's blockback, but the above
problem is certainly a bug.
Sponsored by: Spectra Logic
Submitted by: ken
Reviewed by: royger
dev/xen/blkback/blkback.c:
- Break xbb_send_response() into two sub-functions,
xbb_queue_response() and xbb_push_responses().
Remove xbb_send_response(), because it is no longer
used.
- Adjust xbb_complete_reqlist() so that it calls the
two new functions, and holds the mutex around both
calls. The mutex insures that another context
can't come along and push responses before we've
freed our resources.
- Change xbb_release_reqlist() so that it requires
the mutex to be held instead of acquiring the mutex
itself. Both callers could easily hold the mutex
while calling it, and one really needs to hold the
mutex during the call.
- Add two new counters, accessible via sysctl
variables. The first one counts the number of
I/Os that are queued and waiting to be pushed
(reqs_queued_for_completion). The second one
(reqs_completed_with_error) counts the number of
requests we've completed with an error status.
Using realmem on PVH is not realiable, since in this case the realmem value
is computed from Maxmem, which contains the higher memory address found. Use
HYPERVISOR_start_info->nr_pages instead, which is set by the hypervisor and
contains the exact number of memory pages assigned to the domain.
Sponsored by: Citrix Systems R&D
This device is used by the user-space daemon that runs xenstore
(xenstored). It allows xenstored to map the xenstore memory page, and
reports the event channel xenstore is using.
Sponsored by: Citrix Systems R&D
dev/xen/xenstore/xenstored_dev.c:
- Add the xenstored character device that's used to map the xenstore
memory into user-space, and to report the event channel used by
xenstore.
conf/files:
- Add the device to the build process.
Convert the xenstore user-space device (/dev/xen/xenstore) to a device
using the newbus interface. This allows us to make the device
initialization dependant on the initialization of xenstore itself in
the kernel.
Sponsored by: Citrix Systems R&D
dev/xen/xenstore/xenstore.c:
- Convert to a newbus device, this removes the xs_dev_init function.
xen/xenstore/xenstore_internal.h:
- Remove xs_dev_init prototype.
dev/xen/xenstore/xenstore.c:
- Don't call xs_dev_init anymore, the device will attach itself when
xenstore is started.
The xenstore related devices in the kernel cannot be started until
xenstored is running, which will happen later in the Dom0 case. If
start_info_t doesn't contain a valid xenstore event channel, defer all
xenstore related devices attachment to later.
Sponsored by: Citrix Systems R&D
dev/xen/xenstore/xenstore.c:
- Prevent xenstore from trying to attach it's descendant devices if
xenstore is not initialized.
- Add a callback in the xenstore interrupt filter that will trigger
the plug of xenstore descendant devices on the first received
interrupt. This interrupt is generated when xenstored attaches to
the event channel, and serves as a notification that xenstored is
running.
Move xenstore related devices (xenstore.c and xenstore_dev.c) from
xen/xenstore to dev/xen/xenstore. This is just code motion, no
functional changes.
Sponsored by: Citrix Systems R&D
