Make it clearer what each one means in the comments that define them.
IIC_BUSBSY was used in many places to mean two different things, either
"someone else has reserved the bus so you have to wait until they're done"
or "the signal level on the bus was not in the state I expected before/after
issuing some command".
Now IIC_BUSERR is used consistantly to refer to protocol/signaling errors,
and IIC_BUSBSY refers to ownership/reservation of the bus.
one specific problem: the driver didn't check for ACK/NAK after writing a
slave address byte to the bus, and some slaves signal that they are busy
(such as when completing an internal write to flash memory) by sending a
NAK in response to being addressed.
While working on that problem I discovered that the driver's handling of
error conditions in general didn't match the state transition diagram in
the reference manual, and making that right resulted in a lot of code
reorganization.
Along the way various other changes also happened...
- Remove a mutex that wasn't protecting anything.
- Remove some mystery DELAY()s, document the few that remain.
- Use pause_sbt(9) to yield the processor for the bulk of the time it
takes to transfer each byte rather than busy-polling the whole time.
- Disable the controller when no transfers are in progress; since we
don't operate in slave mode, there's no reason to run the hardware.
- Remove a bunch of unecessary code from probe().
Simplifying maintainance and options (only one place to deal with MK_DMAGENT)
This also makes packaging base less intrusive by getting a single point where
to add tags.
with the current behaviour of calling "distribution" in the etc target.
This allows mergemaster/etcupdate to still work when some configuration will be
moved to be handled in the same directories their source code lives in.
perform a stop operation on the bus if there was an error, otherwise the
bus will remain hung forever. Consistantly use 'if (error != 0)' style in
the function.
Enable and fix warnings during the build.
Although CMake adds warning flags, they are ignored in the libc++ headers
because the headers '#pragma system header' themselves.
This patch disables the system header pragma when building libc++ and fixes
the warnings that arose.
The warnings fixed were:
1. <memory> - anonymous structs are a GNU extension
2. <functional> - anonymous structs are a GNU extension.
3. <__hash_table> - Embedded preprocessor directives have undefined behavior.
4. <string> - Definition is missing noexcept from declaration.
5. <__std_stream> - Unused variable.
This should fix building world (in particular libatf-c++) with -std=c++11.
Reported by: Oliver Hartmann <ohartman@zedat.fu-berlin.de>
Without this, the signals are shown seemingly randomly in the output before
the final summary is shown. This is especially noticeable when there is
not much output from the application being traced.
Discussed with: jhb
Relnotes: yes
[SLP] Vectorize for all-constant entries.
This should fix libc++'s iostream initialization SIGBUSing on amd64,
whenever the global cout symbol is not aligned to 16 bytes.
Some further explanation: libc++'s iostream.cpp contains the definitions
of std::cout, std::cerr and so on. These global objects are effectively
declared with an alignment of 8 bytes. When an executable is linked
against libc++.so, it can sometimes get a copy of the global object,
which is then at the same alignment.
However, with clang 3.7.0, the initialization of these global objects
will incorrectly use SSE instructions (e.g. movdqa), whenever the
optimization level is high enough, and SSE is enabled, such as on amd64.
When any of these objects is not aligned to 16 bytes, this will result
in a SIGBUS during iostream initialization. In contrast, clang 3.6.x
and earlier took the 8 byte alignment into consideration, and avoided
SSE for those particular operations.
After bisecting of upstream changes, I found that the above revision
caused the change of this behavior, so I am reverting it now as a
workaround, while a discussion and test case is being prepared for
upstream.
Highlights (not already in the FreeBSD tree):
- addr2line: Fixed multiple memory leaks related to DIE allocation
- readelf: improve sh_link validation
- various man page improvements
Sponsored by: The FreeBSD Foundation
This option tells freebsd-update to act as if it is running a specific
release instead of querying the kernel. In particular, this can be
useful when upgrading jails.
Requested by: EuroBSDCon devsummit jails session
Tested by: allanjude
MFC after: 1 week
Due to an off by one the code would read an entry past the table, as
opposed to the last entry which contains the nosys handler.
Reported by: Pawel Biernacki <pawel.biernacki gmail.com>
locales.
When using a Chinese locale, such as zh_TW.UTF-8 or zh_CN.UTF-8,
nl_langinfo(ABMON_*) only returned numbers. For instance,
nl_langinfo(ABMON_1) returns 1, nl_langinfo(ABMON_2) returns 2, and
so on.
This causes problems in applications that put the short month name
and the day of the month together. For example, 'Apr 14' in English
becomes '414日' in Chinese on the top bar of GNOME Shell.
This problem may be resolved by appending '月' to all short month
names and replacing %b with %_m in date_fmt. ja_JP.UTF-8 already
does this, and this matches the en_US.ISO8859-1 behavior, which
returns 'Oct'. The GNU C Library also returns values with '月'
appended.
PR: 199441
Submitted by: Ting-Wei Lan <lantw44 gmail com>
MFC after: 2 weeks
- Move the required kernel compiler flags from Makefile.arm64 to kern.mk.
- Build arm64 modules as PIC; non-PIC relocations in .o for shared object
output cannot be handled.
- Do not try to install aarch64 symlink.
- A hack for arm64 to avoid ld -r stage. See the comment for the explanation.
Some functionality is lost, like ctf handling, but hopefully will be
restored after newer linker is available.
Reviewed by: andrew, emaste
Tested by: andrew (on real hardware)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3796
It is decided to go with the shared object file format for modules on
arm64, due to the Aarch64 instruction set details. Combination of the
signed 28-bit offset in the branch instructions encoding together with
the supported memory model of compilers makes the relocatable object
support impossible or at least too hard.
Reviewed by: andrew, emaste
Tested by: andrew (on real hardware)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3796
The current Xen console driver is crashing very quickly when using it on
an ARM guest. This is because the console lock is recursive and it may
lead to recursion on the tty lock and/or corrupt the ring pointer.
Furthermore, the console lock is not always taken where it should be and has
to be released too early because of the way the console has been designed.
Over the years, code has been modified to support various new features but
the driver has not been reworked.
This new driver has been rewritten with the idea of only having a small set
of specific function to write either via the shared ring or the hypercall
interface.
Note that HVM support has been left aside for now because it requires
additional features which are not yet supported. A follow-up patch will be
sent with HVM guest support.
List of items that may be good to have but not mandatory:
- Avoid to flush for each character written when using the tty
- Support multiple consoles
Submitted by: Julien Grall <julien.grall@citrix.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D3698
Sponsored by: Citrix Systems R&D
bytes of boot2. Since we're in 16-bit mode, we can't copy all 128kB at
once; instead we loop four times and copy 32 kB each time.
This change was made necessary by an upcoming increase in the size of the
boot2 binary; should it increase further, the COPY_BLKS value can be
adjusted without anyone needing to remember 8086 assembly language again.
Requested by: allanjude
Tested by: allanjude
MFC after: 1 week
struct thread and kernel stack for the thread. Otherwise, a load
similar to a fork bomb would exhaust KVA and possibly kmem, mostly due
to the struct proc being type-stable.
The nprocs counter is changed from being protected by allproc_lock sx
to be an atomic variable. Note that ddb/db_ps.c:db_ps() use of nprocs
was unsafe before, and is still unsafe, but it seems that the only
possible undesired consequence is the harmless warning printed when
allproc linked list length does not match nprocs.
Diagnosed by: Svatopluk Kraus <onwahe@gmail.com>
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
The new mapping will restore binary compatibility with stable_10
but file generated since r283120 are broken.
Reviewed by: jhb
Sponsored by: Stormshield
