under bootverbose. Every example I've seen to date has been due to
an ACPI system resource device reserving a range that overlaps with
system memory (which ram0 attempts to reserve) or a local or I/O APIC
(which apic0 attempts to reserve). These are always harmless but look
scary to users.
MFC after: 1 week
no need for them to be this strong, we only need to provide one or the
other.
While here replace atomic_load_acq_* and atomic_store_rel_* with a single
instruction version, and fix the definition of atomic_clear_* to point to
the correct functions.
Sponsored by: The FreeBSD Foundation
ASIZE() was never used, and min() stopped being used in r207812.
Differential Revision: https://reviews.freebsd.org/D2230
Reviewed by: emax
Approved by: emax
MFC after: 1 week
The `nonnull' attribute specifies that some function parameters should be
non-null pointers. This is very useful as it helps the compiler generate
warnings on suspicious code and can also enable some small optimizations.
Also start using 'alloc_size' attribute in the allocator functions.
This is an initial step to better integrate our libc with the compiler:
these attributes are fully supported by clang and they are also useful
for the static analyzer.
Note that due to some bogus internal procedure in the way gcc ports
are built they may require updating if they were built before r280801.
Relnotes: yes
Hinted by: Android's bionic libc
Differential Revision: https://reviews.freebsd.org/D2107
I .. stupidly added code to return HAL_ANI_STATS to HAL_DIAG_ANI_STATS.
I discovered this in a noisy environment when the returned values were
enough to .. well, make everything terrible.
So - restore functionality.
Tested:
* AR5416 (uses the AR5212 HAL), in a /very/ noisy 2GHz environment.
Enough to trigger ANI to get upset and generate useful data.
The MAC addresses were totally wrong. They're like the DIR-625C1 - at
0x1ffe0004 and 0x1ffe0018. They're however stored as text strings.
The ath0 MAC address is also not set, even though the calibration
partition is valid.
So, pick the board address / first MAC as the ath0 MAC, and derive
arge0/arge1 from that. That way they're hopefully unique enough
for people with multiple devices.
Tested:
* DIR-655A1
TODO:
* Do the same for the DIR-625A1 and DIR-625C1.
So far, we were always using HID_USAGE() to determine the Usage ID of a
certain HID report input item. This does not work as intended if a field
is an array and the allowed usages are specified with a usage range, as
HID_USAGE() will return 0. We need to use the field value as an index in
the usage range list in this case instead.
This makes the volume keys in a Microsoft Bluetooth Mobile Keyboard
5000 be properly recognized. The relevant part of the HID report looks
like this:
0xA1, 0x01, // Collection (Application)
0x85, 0x07, // Report ID (7)
0x05, 0x0C, // Usage Page (Consumer)
0x19, 0x00, // Usage Minimum (Unassigned)
0x2A, 0xFF, 0x03, // Usage Maximum (0x03FF)
0x95, 0x01, // Report Count (1)
0x75, 0x10, // Report Size (16)
0x15, 0x00, // Logical Minimum (0)
0x27, 0xFF, 0x03, 0x00, 0x00, // Logical Maximum (1023)
0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred
// State,No Null Position)
When a key such as "volume down" is pressed, the following data is
transferred through Interrupt In:
0x07 0xEA 0x00
Differential Revision: https://reviews.freebsd.org/D2229
Reviewed by: emax
Approved by: emax
MFC after: 1 week
- Remove extranious echo that breaks puppet
- Handle restarts of multiple pflog devices correctly
- Add the ability to perform actions on specific pflog devices.
PR: 199150
Submitted by: jason.unovitch@gmail.com
MFC after: 3 days
This is only an interim fix; MIPS should be using the MI code instead,
which does not have this issue.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D661
unroll the loop in ENTRY(pagezero)
acc' to the submitter this results in a reproducible 1% perf
improvement under buildworld like workload
I validated correctness and run-testing, but not performance impact
Submitted by: lidl@pix.net
Reviewed by: adrian
PR: 199151
MFC After: 1 month
These are similar to the mips24k performance counters - some are
available on perfcnt0/3, some are available on perfcnt1/4.
However, the events aren't all the same.
* Add the events, named the same as from Linux oprofile.
* Verify they're the same as "MIPS32(R) 74KTM Processor Core Family
Software User's Manual"; Document Number: MD00519; Revision 01.05.
* Rename INSTRUCTIONS to something else, so it doesn't clash with
the alias INSTRUCTIONS. I'll try to tidy this up later; there
are a few other aliases to add and shuffle around.
Tested:
* QCA9558 SoC (AP135 board) - MIPS74Kc core (no FPU.)
* make universe; where it didn't fail for other reasons.
TODO:
* It'd be nice to support the four performance counters
in at least this hardware, rather than just two.
Reviewed by: bsdimp ("looks good; don't break world".)
