The first part of the mips pruning has been commited. This part
is uncontested. Fix the date in the UPDATING file to reflect when
I made the commit. The contested parts will be committed (or not)
once those discussions complete.
This is an older broadcom part that implements the mips32 ISA. 32-bit
FreeBSD/mips now requires mips32r2, so retire this config. Most of the
broadcom port is shared with newer ports, so what little code may be
unique to this part has not been GC'd at this time.
Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
This was useful in bring up. However, it causes more issues than the
support is worth (64-bit atomics being chief among them).
Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
gxemul was a nice stop-gap while qemu support for mips was firmed
up. Now MALTA* + qemu is the platform of choice retire gxemul support.
It's unknown when this was last confirmed working.
Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
relevant and is unused. It's also getting in the way of progress in
some admittedly minor ways. Better to retire it to reduce the burden
on the project.
Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
Update the appropriate Makefile to build the new driver
together with the old one.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reported by: kib
Obtained from: Semihalf
Sponsored by: Stormshield
Prior to the change the code would branch on return value and then check
if probes are enabled. Since vast majority of the time they are not, this
is clearly wasteful. Check probes first.
Sponsored by: The FreeBSD Foundation
iBCS2 was disconnected from the build in 2015 (see r291419)
bsdconfig parts submitted by dteske.
Reviewed by: kib (previous version)
Sponsored by: The FreeBSD Foundation
Due to insufficient validation of network-provided data it may have been
possible for a malicious actor to craft a bootp packet which could cause
a stack buffer overflow.
admbugs: 850
Reported by: Reno Robert
Reviewed by: markj
Approved by: so
Security: FreeBSD-SA-18:15.bootpd
Sponsored by: The FreeBSD Foundation
The sbadaddr register was renamed in version 1.10 of the privileged
architecture specification. No functional change intended.
Submitted by: Mitchell Horne <mhorne063@gmail.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18594
This fixes a warning seen when compiling amd64 GENERIC with clang 7.
Also remove the workaround added in r337324. clang 7 and gcc 4.2
generate the same code with or without the code change.
Reviewed by: imp (previous version)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D18603
ieee80211_alloc_node() does not initialize rateset tables; that's not
expected by rate control modules and will result in array access at
index -1 - where ni_essid[] array is located (zeroed at allocation, so
there are no user-visible consequences).
Just delay rate control initialization to the moment, when rateset
tables are initiaziled; nothing will use rates here anyway.
MFC after: 4 days
- Fix PR 227760 by getting the TOE to respond to the SYN after the call
to toe_syncache_add, not during it. The kernel syncache code calls
syncache_respond just before syncache_insert. If the ACK to the
syncache_respond is processed in another thread it may run before the
syncache_insert and won't find the entry. Note that this affects only
t4_tom because it's the only driver trying to insert and expand
syncache entries from different threads.
- Do not leak resources if an embryonic connection terminates at
SYN_RCVD because of L2 lookup failures.
- Retire lctx->synq and associated code because there is never a need to
walk the list of embryonic connections associated with a listener.
The per-tid state is still called a synq entry in the driver even
though the synq itself is now gone.
PR: 227760
MFC after: 2 weeks
Sponsored by: Chelsio Communications
Those should ensure correctness of ichwd_find_ich_lpc_bridge() and
ichwd_find_ich_lpc_bridge() as well as make it easier for both humans
and static analyzers to see the relation between tco_version and ich and
smb variables in ichwd_identify().
Reported by: Coverity
CID: 1396314, 1396317
MFC after: 10 days
The code is unreachable since the entries of radeon_ioctls[] are not
associated with any device: we provide only the KMS entry points.
Moreover, r600_cp_dispatch_texture() contains an integer overflow bug
that can be triggered from userspace.[1]
Reported by: Anonymous of the Shellphish Grill Team[1]
Reviewed by: dumbbell
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18516
This includes removing stray whitespace, adding a line after the
variable declaration block and removing a redundant check.
MFC after: 1 week
X-MFC with: r339754
In testing on a Dell Latitude 7480, having ig4.ko loaded during a
suspend caused the system to hang. It turns out that ig4iic_intr() was
being called after the device entered D3, and entered an infinite loop
because a read of the I2C status register returned all ones, causing us
to attempt to read a byte from the data buffer until one of the status
bits clears. This occured because ig4iic_pci0 shares an interrupt with
the VGA device on this laptop, so ig4iic_intr() gets called even when
there is no work to do. This is exactly the problem fixed by r342170,
which resolves the hang for me and allows suspend/resume to work with
ig4.ko loaded. So, re-enable autoloading of ig4.ko in the hope that
r342170 resolves the problem universally.
Reviewed by: gonzo
MFC after: 1 month (pending an MFC of r342170)
Differential Revision: https://reviews.freebsd.org/D18587
MK_AUDIT already controls auditd(8), praudit(1), etc. It should also control
the audit test suite.
Submitted by: ngie
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd/pull/240
These tests should be skipped if /etc/rc.d/auditd is missing, which could be
the case if world was built with WITHOUT_AUDIT set. Also, one test case
requires /etc/rc.d/accounting.
Submitted by: ngie
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd/pull/240
The goal of this change is to fix a problem with PCI shared interrupts
during suspend and resume.
I have observed a couple of variations of the following scenario.
Devices A and B are on the same PCI bus and share the same interrupt.
Device A's driver is suspended first and the device is powered down.
Device B generates an interrupt. Interrupt handlers of both drivers are
called. Device A's interrupt handler accesses registers of the powered
down device and gets back bogus values (I assume all 0xff). That data is
interpreted as interrupt status bits, etc. So, the interrupt handler
gets confused and may produce some noise or enter an infinite loop, etc.
This change affects only PCI devices. The pci(4) bus driver marks a
child's interrupt handler as suspended after the child's suspend method
is called and before the device is powered down. This is done only for
traditional PCI interrupts, because only they can be shared.
At the moment the change is only for x86.
Notable changes in core subsystems / interfaces:
- BUS_SUSPEND_INTR and BUS_RESUME_INTR methods are added to bus
interface along with convenience functions bus_suspend_intr and
bus_resume_intr;
- rman_set_irq_cookie and rman_get_irq_cookie functions are added to
provide a way to associate an interrupt resource with an interrupt
cookie;
- intr_event_suspend_handler and intr_event_resume_handler functions
are added to the MI interrupt handler interface.
I added two new interrupt handler flags, IH_SUSP and IH_CHANGED, to
implement the new intr_event functions. IH_SUSP marks a suspended
interrupt handler. IH_CHANGED is used to implement a barrier that
ensures that a change to the interrupt handler's state is visible
to future interrupts.
While there, I fixed some whitespace issues in comments and changed a
couple of logically boolean variables to be bool.
MFC after: 1 month (maybe)
Differential Revision: https://reviews.freebsd.org/D15755
It has been reported that on some systems (with real hardware passed
through to a virtual machine) the WP detection causes USB disk probing
failures.
While here, also fix the selection of the next state in the case
of malloc failure in DA_STATE_PROBE_WP. It was DA_STATE_PROBE_RC
unconditionally even when it should have been DA_STATE_PROBE_RC16.
PR: 225794
Reported by: David Boyd <David.Boyd49@twc.com>
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D18496
or the likes. Add new control message types: setdlt and getdlt to switch
from default DLT_RAW (no encapsulation) to DLT_EN10MB (ethernet).
Approved by: glebius
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D18535
With r342151 I did fix the BIOS version of zfs_probe_dev() from accessing
the whole disk, but the fix was not complete - we actually did not check
if the device name was really for whole disk. Since UEFI version
is only calling the zfs_probe_dev() with partitions and not with whole
disk, the UEFI loader was not able to find the zfs pools.
This update does correct the issue by calling archsw.arch_getdev() to
translate the device name back to dev_desc, and we have whole disk when both
partition and slice values are -1.
Reported by: alvisen_gmail.com
Differential Revision: https://reviews.freebsd.org/D18558
