Add the needed hardcoded gem5 attachments for the UART there, re-using all
the other bits.
In collaboration with: andrew
Sponsored by: DARPA/AFRL
Reviewed by: andrew
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6204
In case we do not have an interrupt assignment for the virtual timer,
force the physical timer.
Also skip resource allocation for any timer we do not have an interrupt
assignment for.
In collaboration with: andrew
Submitted by: br ([1] from his gem5 arm64 work)
Sponsored by: DARPA/AFRL
Reviewed by: andrew
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6203
In case of updating it with a very low value it might expire again
after writing the tval but before updating ctrl. In that case we do
lose the status bit saying that the timer expired and we will consequently
not get an interrupt for it, leaving the timer in a "dead" state.
In order to solve this increase the minimum period with what the timer
can be loaded to something higher.
Found & analysed with: gem5
Debugged with: andrew
Sponsored by: DARPA/AFRL
Reviewed by: andrew
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6202
The Xen PV clock has a resolution of 1ns, so set the resolution to the
highest one that FreeBSD supports, which is 1us.
MFC after: 2 weeks
Sponsored by: Citrix Systems R&D
The current code in clock_register checks if the newly added clock has a
resolution value higher than the current one in order to make it the
default, which is wrong. Clocks with a lower resolution value should be
better than ones with a higher resolution value, in fact with the current
code FreeBSD is always selecting the worse clock.
Reviewed by: kib jhb jkim
Sponsored by: Citrix Systems R&D
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D6185
* Add a debug print for the xmit completion status fields.
Yes, I like staring at a stream of DWORDS.
* Set the retrycnt to the number of full frame retries for now;
I'll figure out how to factor rts/cts failures into it when
I figure out what the difference is.
It's -1 because it's not "retries", it's "tries".
It now passes the youtube test.
Tested:
* BCM4312, STA mode
I noticed that it'd associate fine, but it'd quickly stop exchanging traffic.
Receive was okay, but transmit just failed.
Then I went "wlandebug +rate". I discovered it started at 36M OFDM, and then
quickly rose to 54M, which then showed 0% transmit success.
Then, I dug into how the completion path works. We are reading 'ack=0'
in the TX status side, so .. then I discovered we were only processing the
TX completion status /if/ ack=1. So, we'd only ever count successes;
we'd never count failures, and thus the rate control code thought
everything was a-ok.
We also have to set retrycnt to something non-zero so it indeed does
bring the rate down upon failure.
So:
* Delete the rate control completion code from the tx completion
routine, it's just duplicate and never worked. Putting it behind
'if (status->ack) was pointless.
* Move it to the PIO and DMA completion routines which actually
do free the node reference and mbuf. We know at that point
what the status is, so do it there.
* Fake a retrycnt of 1 for now, so we at least count failures.
Also:
* Start adding comments about weird stuff I find with rate selection.
In this instance, we shouldn't be selecting a fallback rate that
doesn't match the currently configured mode (11a, 11b, 11g, etc.)
This isn't perfect - AMRR does try 54mbit and takes a few packets
before it figures out it's a bad idea - but it's better than nothing.
This makes the bwn(4) driver actually useful for the first time since
I've tried using it - and that dates back to 2011. I've resisted
successfully until now.
Tested:
* Broadcom BCM4312 802.11b/g Wireless, STA mode
WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO (manuf 0x17f ver 0x2062 rev 2)
TODO:
* See if the fallback rate actually /is/ working
* Question my own sanity over touching this driver in the first place.
Falling back from 6MB OFDM to 5MB CCK (a) may not work well in the
11bg PHYs, (b) won't work at all if you're 11g only, and (c) plainly
won't work for the 11a PHY.
So, don't do that!
Tested:
* BCM4312 802.11b/g Wireless, STA mode
WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO (manuf 0x17f ver 0x2062 rev 2)
Instead of panicking when parsing an invalid ACPI SRAT table,
just ignore it, effectively disabling NUMA.
https://lists.freebsd.org/pipermail/freebsd-current/2016-May/060984.html
Reported and tested by: Bill O'Hanlon (bill.ohanlon at gmail.com)
Reviewed by: jhb
MFC after: 1 week
Relnotes: If dmesg shows "SRAT: Duplicate local APIC ID",
try updating your BIOS to fix NUMA support.
Sponsored by: Dell Inc.
Save the value of the IOV control and page size registers and restore
them (along with the VF count) in pci_cfg_save/pci_cfg_restore. This
ensures ARI remains enabled if a PF driver resets itself during the
PCI_IOV_INIT callback. This might also properly restore SRIOV state
across suspend/resume.
Reviewed by: rstone, vangyzen
Differential Revision: https://reviews.freebsd.org/D6192
While here, check if ARI was enabled by re-reading the config register
after writing it and return an error if the write fails.
Reviewed by: rstone, vangyzen
Add CRC/MOVECRC operations, as well as the TEST and STORE variants.
With these operations, a CRC32C can be computed over one or more
descriptors' source data. When the STORE operation is encountered, the
accumulated CRC32C is emitted to memory. A TEST operations triggers an
IOAT channel error if the accumulated CRC32C does not match one in
memory.
These operations are not exposed through any API yet.
Sponsored by: EMC / Isilon Storage Division
The IOAT engine can only address the low 40 bits (1 TB) of physmem via
the 'next descriptor' pointer. Restrict acceptable range given to
bus_dma_tag_create to match.
Sponsored by: EMC / Isilon Storage Division
While there, order EVFILT_VNODE notes descriptions alphabetically.
Based on submission, and tested by: Vladimir Kondratyev <wulf@cicgroup.ru>
MFC after: 2 weeks
Ease more work concerning active list, e.g. hash table etc.
Reviewed by: gallatin, rrs (earlier version)
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D6137
Not sure why the platform hypercall was disabled on i386, just enable it in
order to fix compilation of the PV timer on i386.
Sponsored by: Citrix Systems R&D
It will be used for the upcoming LRO hash table initialization.
And probably will be useful in other cases, when M_WAITOK can't
be used.
Reviewed by: jhb, kib
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D6138
