leave a port permanently disabled when a copper cable is unplugged and
then plugged right back in.
lacp_linkstate goes looking for the current ifmedia on a link state
change and it could get stale information from cxgbe(4) on a module
unplug followed by replug. The fix is to process module events before
link-state events within the driver, and to always rebuild the ifmedia
list on a module change event (instead of rebuilding it lazily).
Thanks to asomers@ for the problem report and detailed analysis to go
with it.
MFC after: 1 week
This will allow to attach UART drivers lying directly on the root node
instead of simple-bus compatible bus only.
Obtained from: Semihalf
Sponsored by: The FreeBSD Foundation
Instead of waiting for empty TX FIFO it is more reasonable to
block on full FIFO. As soon as FIFO slot is free the character
can be transmitted.
In case of TX FIFO disabled, TXFF bit indicates that transmit
register is not empty.
Obtained from: Semihalf
Reviewed by: andrew, emaste
Sponsored by: The FreeBSD Foundation
Totally forget deallocated SDNodes in SDDbgInfo.
What would happen before that commit is that the SDDbgValues associated with
a deallocated SDNode would be marked Invalidated, but SDDbgInfo would keep
a map entry keyed by the SDNode pointer pointing to this list of invalidated
SDDbgNodes. As the memory gets reused, the list might get wrongly associated
with another new SDNode. As the SDDbgValues are cloned when they are transfered,
this can lead to an exponential number of SDDbgValues being produced during
DAGCombine like in http://llvm.org/bugs/show_bug.cgi?id=20893
Note that the previous behavior wasn't really buggy as the invalidation made
sure that the SDDbgValues won't be used. This commit can be considered a
memory optimization and as such is really hard to validate in a unit-test.
This should fix abnormally large memory usage and resulting OOM crashes
when compiling certain ports with debug information.
Reported by: Dmitry Marakasov <amdmi3@amdmi3.ru>
Upstream PRs: http://llvm.org/PR19031http://llvm.org/PR20893
MFC after: 1 week
to the loader in a similar way to the ACPI tables.
This will be used on arm64 but is not specific to the architecture.
Sponsored by: The FreeBSD Foundation
underlying file does not have DFLAG_SEEKABLE set [1].
For posix_fallocate(2), simplify error handling logic. Do return when
fp is not yet referenced.
Noted by: bde [1]
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
ext2_print_inode is not really used but it was nice to
have for initial development work. #ifdef it under a
new EXT2FS_DEBUG knob so that we don't spend time
compiling it.
MFC after: 3 days
sb_cc member of struct sockbuf to a couple of inline functions:
sbavail() and sbused()
Right now they are equal, but once notion of "not ready socket buffer data",
will be checked in, they are going to be different.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
I originally overlooked a couple flag bits defined in the fdt binding docs.
One flag suppresses the pad configuration (pullup/pulldown/etc). The other
one requires that the SION (set input on) flag be set in the mux register.
Also, it appears from the data involved that if the input register
address in the config tuple is zero, there is no input configuration. The
old code was writing to register zero, which contains a collection of misc
control bits (having nothing to do with input configuration) that probably
shouldn't get overwritten arbitrarily. The bindings doc doesn't explictly
mention this.
with 128K of random data and truncated to 800K can have SEEK_DATA return -1
when given an offset of 128K. On UFS, the SEEK_DATA returns 800K (the size
of the file). SEEK_HOLE on ZFS seems to behave the same as UFS.
To handle this, map -1 to the size of the file (`end') when lseek returns
this for either SEEK_HOLE or SEEK_DATA. When sparse files are not supported
by the file system both `hole' and `data' will now be equal to `end' and we
will treat the entire file as data. This way, the -1 return for SEEK_DATA
on ZFS will end up doing the right thing.
Reported by: gjb@
MFC after: 3 days
that expose new bugs with HS mode.
When the old code could not do the proper card detection it would boot with
lower defaults (and no HS mode) and this makes some HS cards boots.
Now, with the card always identified as HS capable, the sdhci controller
tries to run the card at HS speeds and makes the boot always fail.
Disable the HS mode for now (which still can be enabled with the tunable)
until it is properly fixed.
MFC with: r273264
Requested by: many
The various structures in the mod_metadata set of a FreeBSD kernel and
modules contain pointers. The FreeBSD loader correctly deals with a
mismatch in loader and kernel pointer size (e.g. 32-bit i386/ppc
loader, loading 64-bit amd64/ppc64 kernels), but wasn't dealing with
the inverse case where a 64-bit loader was loading a 32-bit kernel.
Reported by: ktcallbox@gmail.com with a bhyve/i386 and ZFS root install
Differential Revision: https://reviews.freebsd.org/D1129
Reviewed by: neel, jhb
MFC after: 1 week
ever used. It didn't go into stable/10, neither was documented.
It might be useful, but we collectively decided to remove it, rather
leave it abandoned and unmaintained. It is removed in one single
commit, so restoring it should be easy, if anyone wants to reopen
this idea.
Sponsored by: Netflix
gzip, and split). "Real" filesystems should always be listed first so
that the "bare" filename is tried before alternate filenames. For PXE
booting in particular this can remove a lot of spurious pathname lookups.
While here, move splitfs to the bottom after the bzip and gzip filesystems
as it is the least often used.
Tested by: Prokash Sinha <psinha@panasas.com>
MFC after: 1 week
comparing it with NOCPU, which became -1 recently. While here, avoid
using it for address calculations if it is negative.
Reviewed by: jhb, adrian
MFC after: 1 week
convert a global timer to a per-controller timer. This works much better
with locking and removes the need for several global lookup tables.
Tested by: ambrisko
state said device should go into.
This was a snafu introduced in the ACPI/PCI awareness separation.
When putting a device into a power state, the bus (and thus firmware,
eg ACPI) should be asked before hand to check whether the device
can indeed go into that power state.
There's a set of nodes in ACPI under each device - the _SxD nodes - which
state which ACPI power state to put the device into when the system is
going into power save state 'x'. So when going into S3, the existence
of an _S3D node would override whatever the system was trying to do.
By default the PCI code wants to put devices into D3 before suspending.
I have a laptop here (Asus Zenbook - check the PR) whose EHCI controller
really wants to be in D2 during suspend, not D3. So if we put it into
D3 and then try to enter S3, everything hangs. The device itself
can go into D3 - it just can't be there when the call to ACPI to enter
S3 occurs. The PCI patch fixes this.
jkim@ noticed that the same is needed for the ACPI child device
enumeration.
Thankyou to Matt Dillon (the programmer, not the actor) for buying me
this particular laptop so I could debug the issues with the Atheros
AR9485 that is in it. It's his fault that I ended up with this
laptop and was sufficiently annoyed by the lack of USB suspend
to go down this rabbit hole.
Tested:
* Thinkpad T400
* Thinkpad X230
* Thinkpad T42
* Thinkpad T60
* Asus Zenbook (see PR)
* Asus EEEPC 701
* Asus EEEPC 1001PX
TODO:
* Figure out what we should do about devices we unload drivers for
that want to be in a specific state when entering S3 / S4 -
the "put devices into D3 if they're not bound to a driver" option
may also mess with things.
PR: kern/194884
Reviewed by: jhb, jkim
MFC after: 1 week
Relnotes: yes
Sponsored by: Matt Dillon <dillon@apollo.backplane.com> (hardware)
In vt_efifb_init the framebuffer's physaddr is passed to PHYS_TO_DMAP
before the DMAP is setup. The result is not actually accessed until
after the mapping is setup, though. Loosen the assertion in PHYS_TO_DMAP
for now, to allow use when dmaplimit == 0.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D1142
