and correct the use of unary minus with an unsigned value. (The unary
minus here is actually being used as a bitwise operation, which is
unusual enough to deserve a clarifying cast.)
Define the xxx_OBJPATHS earlier and then use it in the xxx_make
target because each obj is actually made through that.
This allows the crunch to work with -j32 on sun4v.
The makefile generated is still poor, though. It really shouldn't use
the general 'make all' to do the submakes in the app directories being
crunched because each of those objects is listed as a dependency in
the generated crunch makefile. Doing that really requires a unique rule
to generate them.
wildcard specifications. Earlier the only wildcard syntax
was "-j 0" for "any jail". There were at least
two shortcomings in it: First, jail ID 0 was abused; it
meant "no jail" in other utils, e.g., ps(1). Second, it
was impossible to match processed not in jail, which could
be useful to rc.d developers. Therefore a new syntax is
introduced: "-j any" means any jail while "-j none" means
out of jail. The old syntax is preserved for compatibility,
but now it's deprecated because it's limited and confusing.
Update the respective regression tests. While I'm here,
make the tests more complex but sensitive: Start several
processes, some in jail and some out of jail, so we can
detect that only the right processes are killed by pkill
or matched by pgrep.
Reviewed by: gad, pjd
MFC after: 1 week
at the start of rtalloc1(). This backs out part of revs 1.83 and 1.85.
Profiling on an i386 showed that that for sending tiny packets using
bge, -current takes 7 bzero()s where RELENG_4 takes only 1, and that
bzero()ing is now the dominant overhead (10-12%, up from 1%, but
profiling overestimated this a bit). This commit backs out 2 of the
6 extra bzero()s (1 in each of 2 calls per packet to rtalloc1()). They
were the largest ones by byte count (48 bytes each) but perhaps not
by time (small misaligned ones might take longer).
shall retain its CDDL copyright, and thus likely be removed from GENERIC) I have removed the CDDL
from hcall.S because there is zero flexibility in the implementation of hypercalls as they derive
directly from the hypervisor interface which is not copyrighted (ironically the source for the
hypervisor itself is BSD licensed).
It is best to start any bikeshed about this as soon as possible.
Discussed with: bsdimp
- incorporate csjp's fix for a mishandled endian conversion
- convert PAGE_SIZE to 4096 for PCIe adapter workaround (my page size is not 4k)
- implement em_read_pcie_cap_reg where we set the max read size on pcie to 4k (taken from mxge)
Reviewed by: scottl and jfvogel
listening socket after the pass that cleans those queues. This
results in these connections being orphaned (and leaked). The fix
is to clean up the so queues after detaching the socket from the
protocol. Thanks to ups and jhb for discussions and a thorough code
review.
I have been debugging the usb problems some more. Your were
right in your assumption (thanks for the pointer) about lack
of calls to bus_dmamap_sync(). In usbdi.c bus_dmamap_sync()
does get used for transfers that move data from PC to USB and
it is used for transfers that move data from USB to PC. But
someone forgot that control transfers consist of possibly two
data chunks : the request itself and optionally a buffer of
data that should be transfered to or from the USB device. On
requests to the control endpoint without additional data
bus_dmamap_sync() didn't get called. For some reason my first
tests with umass worked (due to enough cache poisening I
guess). The attached patch adds a call to bus_dmamap_sync()
to usbdi.c and now all devices I have tried work out of the
box. I have successfully transfered large files using the
if_axe driver and I have mounted several different umass
devices.
submitted by: Daan Vreeken
sponsored by: Vitsch Electronics
reviewed by: cognet@
marked INP_DROPPED or INP_TIMEWAIT:
o return ECONNRESET instead of EINVAL for close, disconnect, shutdown,
rcvd, rcvoob, and send operations
o return ECONNABORTED instead of EINVAL for accept
These changes should reduce confusion in applications since EINVAL is
normally interpreted to mean an invalid file descriptor. This change
does not conflict with POSIX or other standards I checked. The return
of EINVAL has always been possible but rare; it's become more common
with recent changes to the socket/inpcb handling and with finer-grained
locking and preemption.
Note: there are other instances of EINVAL for this state that were
left unchanged; they should be reviewed.
Reviewed by: rwatson, andre, ru
MFC after: 1 month
- Fix bug preventing adoption of running firmware
- Set PCIe max read request size to 4KB
- Read PCIe link width from config space
- Assume aligned completions from the southbridge ports
of intel E5000 chips
- Use aligned firmware when link width is x4 or less
- Add hw.mxge.force_firmware tunable to allow user to force
selection of aligned (or unaligned) firmware
