| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This fixes booting from a ZFS mirror with a unavailable primary device.
PR: kern/148655
Reviewed by: avg
Approved by: delphij (mentor)
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
like memory mapped register access. Typical problem from the issue
was MII access returned unreliable values. I'm not sure this comes
from lack of register flushing in MII access after accessing
STE_PHYCTL register though.
To address the issue, read hints data that controls which type of
memory mapping should be used in driver. ste(4) still prefers
memory mapping to io mapping but honor hints entered by user except
for controllers that have problems with memory mapping.
The hint to use iomapping could be given by adding the following
line to /boot/device.hints file.
hint.ste.0.prefer_iomap="1"
PR: kern/149285
MFC after: 5 days
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
number of CPUs detection.
However, that was not mention at all, the problem was not reported, the
patch has not been MFCed and the fix is mostly improper.
Fix the original overflow (caused when 32 CPUs must be detected) by
just using a different mathematical computation (it also makes more
explicit the size of operands involved, which is good in the moment
waiting for a more complete support for a large number of CPUs).
PR: kern/148698
Submitted by: Joe Landers <jlanders at vmware dot com>
Tested by: gianni
MFC after: 10 days
|
|
|
|
| |
r210974.
|
|
|
|
| |
by the possibility of unintended partially-formed jails.
|
|
|
|
| |
the table elements would just be overwritten twice.
|
|
|
|
|
|
| |
PR: usb/128324
Submitted by: Mike Durian <durian shadetreesoftware.com> (original patch)
MFC after: 2 weeks
|
|
|
|
| |
being used.
|
|
|
|
|
|
| |
Whether POSIX requires these is unclear.
They pass with 8-stable sh as well.
|
|
|
|
|
|
|
|
| |
Correct the login.conf variable name used for obtaining the login prompt.
PR: conf/44717 (indirectly)
Spotted by: gcooper
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
td_critnest > 1 when not already running on the desired CPU read the
TICK counter of the BSP via a direct cross trap request in that case
instead.
- Treat the STICK based timecounter the same way as the TICK based one
regarding its quality and obtaining the counter value from the BSP.
Like the TICK timers the STICK ones also are only synchronized during
their startup (which might not result in good synchronicity in the
first place) but not afterwards and might drift over time, causing
problems when the time is read from different CPUs (see r135972).
|
|
|
|
|
|
| |
managed and we already take pmap lock for PTE operations(see r210922)
Reviewed by: alc
|
|
|
|
|
|
| |
PR: conf/147726
Submitted by: Sterling (Chip) Camden <sterling camdensoftware.com>
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
it into the kernel.
PR: conf/148758
Submitted by: Joe Talbott <josepht at dragonflybsd.org>
MFC after: 3 days
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interface goes to issue LINK_UP, then LINK_DOWN, then LINK_UP at
cold boot. This behavior is not observed when carp(4) interface
is created slightly later, when the underlying interface is fully
up.
Before this change what happen at boot is roughly:
- ifconfig creates em0 interface;
- ifconfig clones a carp device using em0;
(em0's link state is DOWN at this point)
- carp state: INIT -> BACKUP [*]
- carp state: BACKUP -> MASTER
- [Some negotiate between em0 and switch]
- em0 kicks up link state change event
(em0's link state is now up DOWN at this point)
- do_link_state_change() -> carp_carpdev_state()
- carp state: MASTER -> INIT (via carp_set_state(sc, INIT)) [+]
- carp state: INIT -> BACKUP
- carp state: BACKUP -> MASTER
At the [*] stage, em0 did not received any broadcast message from other
node, and assume our node is the master, thus carp(4) sets the link
state to "UP" after becoming a master. At [+], the master status
is forcely set to "INIT", then an election is casted, after which our
node would actually become a master.
We believe that at the [*] stage, the master status should remain as
"INIT" since the underlying parent interface's link state is not up.
Obtained from: iXsystems, Inc.
Reported by: jpaetzel
MFC after: 2 months
|
| |
|
|
|
|
|
| |
The timezone structure acquired by gettimeofday() is not used at all.
Just remove it.
|
|
|
|
|
| |
We can safely call gettimeofday() without passing a struct timezone.
We're not using it at all.
|
|
|
|
| |
WARNS?=3 until that's resolved.
|
|
|
|
|
|
|
|
|
|
| |
uname and gname weren't overwritten, so the
disk restore would use those to lookup the
original uid/gid again. Clearing the uname
and gname prevents this.
Reported by: swell.k
MFC after: 7 days
|
|
|
|
| |
it instead of calling pci_find_extcap().
|
| |
|
|
|
|
|
|
| |
suspend state. Also disable master clock after PHY power down,
this is supposed to save more power. The master clock should be
enabled if WOL is active.
|
|
|
|
|
|
|
|
|
|
| |
to single CPUs more efficiently with Cheetah(-class) and Jalapeno CPUs.
Besides being used to implement the ipi_cpu() introduced in r210939,
cpu_ipi_single() will also be used internally by the sparc64 MD code.
- Factor out the Jalapeno support from the Cheetah IPI send functions
in order to be able to more easily and efficiently implement support
for more than 32 target CPUs as well as a workaround for Cheetah+
erratum 25 for the latter.
|
|
|
|
|
| |
bother doing page coloring. This results in a small but measurable
performance improvement in buildworld times.
|
|
|
|
| |
Note, alc(4) does not use CMB at all due to silicon bug.
|
|
|
|
| |
Limit DMA burst size to be less than or equal to 1024 bytes.
|
| |
|
|
|
|
|
|
|
|
| |
WARNS=6 setting in HEAD (unlike stable/8), so it's best
to remove the line entirely.
Pointed out by: jh
Approved by: des (mentor)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the vfs.read_max default. For most systems this means going from 128 KiB
to 256 KiB, which is still very conservative and lower than what most
other operating systems use, but as a sane default should not
interfere much with existing systems.
For systems with RAID volumes and/or virtualization envirnments, where
read performance is very important, increasing this sysctl tunable to 32
or even more will demonstratively yield additional performance benefits.
If MAXPHYS ever gets bumped up, it will probably be a good idea to slave
read_max to it.
|
|
|
|
|
|
|
|
|
| |
SOCK_DGRAM socket. MSG_TRUNC was only returned when some mbufs could
not be copied to the application. If some data was left in the last
mbuf, it was correctly discarded, but MSG_TRUNC was not set.
Reviewed by: bz
MFC after: 3 weeks
|
|
|
|
|
|
|
| |
PR: conf/139997
Submitted by: Andreas Tobler <andreast fgznet.ch>
MFC after: 2 weeks
Committed from: Bugathon #7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
standard ports, but it can't *receive* them (port 514 is
hardcoded). This commit adds that missing feature.
(NB: I actually needed this feature for a server farm where
multiple jails run with shared IP addresses, and every jail
should have its own syslogd process.)
As a side effect, syslogd now compiles with WARNS=6.
Approved by: des (mentor)
MFC after: 3 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and BeOS. The devices supported by uslcom(4) are now in sync with:
NetBSD src/sys/dev/usb/uslsa.c 1.11
OpenBSD src/sys/dev/usb/uslcom.c 1.20
Linux source/drivers/usb/serial/cp210x.c from kernel 2.6.35
BeOS usb_serial/driver.c 1.32
Two vendor/product IDs from Linux have not been added to uslcom(4):
SILABS SAEL - This device has special code in u3g to support it
SILABS GSM2228 - I suspect this should also be covered by u3g(4).
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
vendor ID in the vendor section, and by symbolic name in the product
section. Products are sorted by product ID. While here, get rid of a
duplicate Microsoft Mouse entry, revealed by sorting.
MFC after: 1 week
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
| |
in the compat32 code. Use sv_usrstack instead of FREEBSD32_USRSTACK as well.
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
to where they belong. Previously they were misplaced,
i.e., swapped.
MFC after: 3 days
|
|
|
|
| |
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Use unsigned rather than signed lengths
2. Bound messages to/from Venus to VC_MAXMSGSIZE
3. Bound messages to/from general user processes to VC_MAXDATASIZE
4. Update comment regarding data limits for pioctl
Without (1) and (3), it may be possible for unprivileged user processes to
read sensitive portions of kernel memory. This issue is only present if
the Coda kernel module is loaded and venus (the userspace Coda daemon) is
running and has /coda mounted.
As Coda is considered experimental and production use is warned against in
the coda(4) man page, and because Coda must be explicitly configured for a
configuration to be vulnerable, we won't be issuing a security advisory.
However, if you are using Coda, then you are advised to apply these fixes.
Reported by: Dan J. Rosenberg <drosenberg at vsecurity.com>
Obtained from: NetBSD (Christos Zoulas)
Security: Kernel memory disclosure; no advisory as feature experimental
MFC after: 3 days
|
|
|
|
| |
spltty() calls while I am here.
|