This change adds support for a UBS<->RS232 adapter based on CH340 (or an
analogue) that I own. The device seems to have a newer internal version
(0x30) and the existing code incorrectly configures line control for it
resulting in garbled transmission. The changes are based on what I
learned in Linux drivers for the same hardware.
Additional changes:
- use UCHCOM_REG_LCR1 / UCHCOM_REG_LCR2 instead of explicit 0x18 and
0x25
- use NULL instead of 0 where a pointer is expected
Reviewed by: hselasky
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D15498
Also, add definitions for more bits of UCHCOM_REG_LCR1 as seen in the
Linux driver. UCHCOM_LCR1_PARENB definition was different from that in
the Linux driver and clashed with newly added UCHCOM_LCR1_RX. I took a
liberty to change UCHCOM_LCR1_PARENB to the Linux definition as it was
unused in the driver anyway. This change should make
uchcom_cfg_set_break() easier to understand.
Approved by: hselasky
MFC after: 2 weeks
Product IDs are specified in vendor documents. The previously used
device ID is not. This is a cosmetic change. No functionality depends
on those IDs.
Reviewed by: hselasky
MFC after: 2 weeks
I have a system that is very unstable after resuming from suspend-to-RAM
but only if HPET is used as the event timer. The theory is that SMM
code / firmware could be enabling HPET for its own uses and unexpected
interrupts cause a trouble for it. Originally I wanted to solve the
problem in hpet_suspend() method, but that was insufficient as the event
timer could get reprogrammed again.
So, it's better, for my case and in general, to stop the event timer(s)
before entering the hardware suspend.
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D15413
When we issue shootdown IPIs, we first assign zero to pm_gens to
indicate the need to flush on the next context switch in case our IPI
misses the context, next we read pm_active. On context switch we set
our bit in pm_active, then we read pm_gen. It is crucial that both
threads see the memory in the program order, otherwise invalidation
thread might read pm_active bit as zero and the context switching
thread might read pm_gen as zero.
IA32 allows CPU for both reads to see zero. We must use the barriers
between write and read. The pm_active bit set is already locked, so
only the invalidation functions need it.
I never saw it in real life, or at least I do not have a good
reproduction case. I found this during code inspection when hunting
for the Xen TLB issue reported by cperciva.
Reviewed by: alc, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D15506
dyn_lookup_ipv[46]_state_locked(). These checks are remnants of not
ready to be committed code, and they are there by accident.
Due to the race these checks can lead to creating of duplicate states
when concurrent threads in the same time will try to add state for two
packets of the same flow, but in reverse directions and matched by
different parent rules.
Reported by: lev
MFC after: 3 days
They're only useful when multiple threads may share an epoch record,
and that can't happen with non-preemptible sections.
Reviewed by: mmacy
Differential Revision: https://reviews.freebsd.org/D15507
Per vnet(9), CURVNET_SET and CURVNET_RESTORE cannot be used as a single
statement for a conditional and CURVNET_RESTORE must be in the same
block as CURVNET_SET (or a subblock).
Reviewed by: andrew
Sponsored by: The FreeBSD Foundation
The escape sequence (e.g. `^[[2 q`) was unsupported before and the
letter `q` was displayed as a typed character. The sequence is used by
Neovim for instance.
Now, it is properly parsed. However, it is ignored, so it won't change
the cursor style.
Because the escape sequence contains a space character, the
`gensequences` script had to be modified to support that. In the
`sequences` file, a space is represented as the string `SP`.
The interlock pointer is non-NULL by definition and the compiler see through
that and eliminates the NULL checks. Just remove them from the code as they
play no role.
No difference in generated assembly.
in_pcbfree will remove the incpb from the list and release the rtentry
while the vnet is set, but the actual destruction will be deferred
until any threads in a (not yet used) epoch section, no longer potentially
have references.
Summary:
POWER9 systems use a new interrupt controller, XIVE, managed through OPAL
firmware calls. The OPAL firmware includes support for emulating the previous
generation XICS presentation layer in addition to a new "XIVE Exploitation"
mode. As a stopgap until we have XIVE exploitation mode, enable XICS emulation
mode so that we at least have an interrupt controller.
Since the CPPR is local to the current CPU, it cannot be updated for APs when
initializing on the BSP. This adds a new function, directly called by the
powernv platform code, to initialize the CPPR on AP bringup.
Reviewed by: nwhitehorn
Differential Revision: https://reviews.freebsd.org/D15492
Avoid the ugly unlock / lock of the inpcbinfo where we need to
figure out what kind of lock we hold by simply deferring the
operation to another context. (Also a small dependency for
converting the pcbinfo read lock to epoch)
MMU is disabled.
This expands some earlier logic and avoids a number of potential problems:
1. The CPU may not be able to access the framebuffer in real mode (real
mode does not necessarily encompass all available memory, especially
under a hypervisor).
2. Real mode accesses generally assume cacheability, so it might not
even have worked.
3. The difference in cacheability between real mode and later (and
potentially earlier) points in the boot with the MMU on may cause
ERAT parity problems, resulting in a machine check.
This fixes real-mode (usefdt=1) early boot on the G5 iMac, which was
previously broken as a result of issue #3. Late boot will require some
other fixups.
