compiled with "options VIMAGE".
As it is now, there is still a single instance of the pipes,
and it is only usable from vnet0 (the main instance).
Trying to use a pipe from a different vimage does not crash
the system as it did before, but the traffic coming out from
the pipe goes to the wrong place, and i still need to
figure out where.
Support for per-vimage pipes is almost there (just a matter of
uncommenting the VNET_* definitions for dn_cfg, plus putting into
the structure the remaining static variables), however i need
first to figure out how init/uninit work, and also to understand
where packets are ending up on exit from a pipe.
In summary: vimage support for dummynet is not complete yet,
but we are getting there.
broken atrtc.
Now if you want more correct stats on profhz and stathz it may be
disabled by setting to 0.
Reported by: A. Akephalos <akephalos dot akephalos at gmail dot com>,
Jakub Lach <jakub_lach at mailplus dot pl>
MFC: 1 week
memory with the specified physical attributes. In particular, like
kmem_alloc_contig(), the caller can specify the physical address range
from which the physical pages are allocated and the memory attributes
(i.e., cache behavior) for these physical pages. However, in contrast to
kmem_alloc_contig() or contigmalloc(), the physical pages that are
allocated by kmem_alloc_attr() are not necessarily physically contiguous.
This function is needed by DRM and VirtualBox.
Correct an error in the prototype for kmem_malloc(). The third argument
had the wrong type.
Tested by: rnoland
MFC after: 3 days
due to rounding the buffer's physical address to the beginning of its
page. This fixes a panic in arge(4) when using PPPoE.
Reported by: Jakob van Santen <vansanten at wisc dot edu>
Reviewed by: gonzo
Obtained from: amd64
- add CRC stripping to the RX side, this was handled
by some obscure code in rxeof previously, its easier
to simply have the hardware strip it now.
- Add back an ALTQ change that slipped between the cracks
- Add an update to the watchdog_time in the xmit code, not
doing this in ixgbe caused problems, think its needed here
as well.
VLAN HWFILTER from being used by default, this breaks
stacked pseudo devices, and as it turns out, also breaks
virtual machines that happen to use VLANS (didn't know that
before :). Put the fix back into the em driver, and for good
measure add the same code to the igb driver where it should
have been anyway.
Just relying on status LE ownership of status block seems to cause
poor performance. Always read current status index register first
and then check status ownership as we had before. Accessing status
index register seems to trigger immediate status update if
controller have pending status updates.
MFC after: 1 week
Reported by: Andre Albsmeier <Andre.Albsmeier <> siemens dot com>
Tested by: Andre Albsmeier <Andre.Albsmeier <> siemens dot com>
This framework allows drivers to abstract the rate control algorithm and
just feed the framework with the usable parameters. The rate control
framework will now deal with passing the parameters to the selected
algorithm. Right now we have AMRR (the default) and RSSADAPT but there's
no way to select one with ifconfig, yet.
The objective is to have more rate control algorithms in the net80211
stack so all drivers[0] can use it. Ideally, we'll have the well-known
sample rate control algorithm in the net80211 at some point so all
drivers can use it (not just ath).
[0] all drivers that do rate control in software, that is.
Reviewed by: bschmidt, thompsa, weyongo
MFC after: 1 months
- Added some new debug helper routines to systcl.
- Fixed many of the style(9) violations that have crept into the code
due to my use of a "smart" editor.
MFC after: 2 weeks
killed by OOM. When killed process waits for a page allocation, try to
satisfy the request as fast as possible.
This removes the often encountered deadlock, where OOM continously
selects the same victim process, that sleeps uninterruptibly waiting
for a page. The killed process may still sleep if page cannot be
obtained immediately, but testing has shown that system has much
higher chance to survive in OOM situation with the patch.
In collaboration with: pho
Reviewed by: alc
MFC after: 4 weeks
checks on the length of the client's open/lock owner name. Also,
add free()'s for one case where they were missing and would
have caused a leak if NFSERR_BADXDR had been replied. Probably
never happens, but the leak is now plugged, just in case.
MFC after: 2 weeks
coda.h:
- CodaFid typdef -> struct CodaFid throughout.
- Use unsigned int instead of unsigned long for venus_dirent and other
cosmetic fixes.
- Introduce cuid_t and cgid_t and use instead of uid_t and gid_t in RPCs.
- Synchronize comments and macros.
- Use u_int32_t instead of unsigned long for coda_out_hdr.
With these changes, a 64-bit Coda kernel module now works with
coda6_client, whereas previous userspace and kernel versions of RPCs
differed sufficiently to prevent using the file system. This has been
verified only with casual testing, but /coda is now usable for at least
basic operations on amd64.
MFC after: 1 week
in the readdir functions for non-positive byte count arguments.
For the negative case, set it to the maximum allowable, since it
was actually a large positive value (unsigned) on the wire.
Also, fix up the readdir function comment a bit.
Suggested by: dillon AT apollo.backplane.com
MFC after: 2 weeks
