to add a reference to it; otherwise, we could later access
a freed memory. This is believed to fix panics some users
were observing when running route6d(8), and is similar to
the fix in sys/netinet/if_ether.c,v 1.139 by glebius@.
PR: kern/93910, kern/105437
Testing by: Wojciech Puchar (still ongoing)
- Add rtentry locking to nd6_output() similar to rt_check().
MFC after: 4 days
flags from M_WAITOK to M_NOWAIT. This should not cause any problems
since the calling code appears to properly handle failed allocations.
Discussed with: kmacy
forward cases by converting from unconditional acquisition of Giant
around vnode operations to conditional acquisition:
- Remove nfsrv_access_withgiant(), and cause nfsrv_access() to now
assert that Giant will be held if it is required for the vnode.
- Add nfsrv_fhtovp_locked(), which will drop the NFS server lock if
required, and modify nfsrv_fhtovp() to conditionally acquire
Giant if required.
- In the VOP's not dealing with more than one vnode at a time (i.e.,
not involving a lookup), conditionally acquire Giant.
This removes Giant use for MPSAFE file systems for a number of quite
important RPCs, including getattr, read, write. It leaves
unconditional Giant acquisitions in vnode operations that interact
with the name space or more than one vnode at a time as these
require further work.
Tested by: kris
Reviewed by: kib
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
o Don't delay when checking the done bits. There's no gain other
than a small performance hit.
o calculate the clock divisors better (things are still way slow,
so maybe there's more here?)
o don't always fail reset. Always succeed instead.
o fix inverted logic around at91_twi_wait() return value
o remove debug code
o remove unneeded, unworking junk
switch tsbscratch over to using order of number of pages as opposed to actual number of pages
switch tsb.c over to using wrappers for contig page allocation
