Sorry, having problems sending attachments as plain text.
Here's virtio_net_3.10.60.patch:
# The netmap 3.10 patch for the virtio_net driver fails to apply. This
# patch is the whole netmap virtio driver patch for 3.10.60 (from
# kernel.org), and it applies correctly.
#
Index: linux-3.10.60/dri
Sorry, having problems sending attachments as plain text.
Here's virtio_netmap.patch:
# This file is a patch to the netmap virtio_net driver include file.
# There is a problem with the initialization, and during read packet with
# control of the indicies .
#
# This problem is easily seen by bui
I know this is the Freebsd mailing list, but
http://info.iet.unipi.it/~luigi/netmap/#85cb indicates that discussion
should be sent to this list.
I recently added netmap to a 3.10 LINUX kernel for use in a KVM guest.
The virtio driver didn't work. There were two problems.
On the 3.10.60 kernel f
Would it be possible for the driver to report how many clusters it calculated
that it needs, whenever it runs into this memory shortage during attach? That
way an administrator might have some idea how much to increase their tunables
in order to meet the driver's requirements.
As it is, it's m
Yes, its strange, the mbuf resources look fine.
Can you show the dmesg record from a boot that
includes the failure please?
Jack
On Fri, Nov 21, 2014 at 9:33 AM, Gerrit Kühn
wrote:
> On Fri, 21 Nov 2014 08:22:31 -0800 Jack Vogel wrote
> about Re: igb Could not setup receive structures (again
The driver does not calculate what it needs, it just keeps taking :) Hmmm,
well it would
be difficult to calculate a real total, as each instance of the driver (one
per port) has no
idea about other instances. I suppose there could be a display of the total
needed per
port?
Jack
On Fri, Nov 21,
On 21 November 2014 07:32, Robert N. M. Watson wrote:
>
> On 21 Nov 2014, at 15:20, Marko Zec wrote:
>
>>> Bjoern and I chatted for the last twenty or so minutes about the
>>> code, and believe that as things stand, it is *not* safe to turn off
>>> UMA_ZONE_NOFREE for TCP due to a teardown race i
On Fri, 21 Nov 2014 08:22:31 -0800 Jack Vogel wrote
about Re: igb Could not setup receive structures (again):
JV> After you get the error do a `netstat -m` and see what the state of the
JV> 9K jumbo pool is, for that is the size you would be using.
Hm...
---
root@mclane:~ # netstat -m
20472/337
The message is pretty straightforward, its only cause is the inability
of the driver to get the necessary clusters to populate the RX rings.
After you get the error do a `netstat -m` and see what the state of the
9K jumbo pool is, for that is the size you would be using.
Depending on the specific
On Fri, Nov 21, 2014 at 10:52:05AM +, Bjoern A. Zeeb wrote:
>
> On 21 Nov 2014, at 08:06 , Craig Rodrigues wrote:
>
> > On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues
> > wrote:
> >
> >> On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote:
> >>
> >>>
> >>> For people to use pf with
On 21 Nov 2014, at 15:20, Marko Zec wrote:
>> Bjoern and I chatted for the last twenty or so minutes about the
>> code, and believe that as things stand, it is *not* safe to turn off
>> UMA_ZONE_NOFREE for TCP due to a teardown race in TCP that has been
>> known about and discussed for several y
On Fri, 21 Nov 2014 15:01:13 +
"Robert N. M. Watson" wrote:
>
> On 21 Nov 2014, at 11:02, Marko Zec wrote:
>
> >> I had convinced myself for UDP many years ago that it was ok to
> >> remove it. People have touched the code however so it’s
> >> definitively worth re-checking again.
> >>
>
On 21 Nov 2014, at 11:02, Marko Zec wrote:
>> I had convinced myself for UDP many years ago that it was ok to
>> remove it. People have touched the code however so it’s definitively
>> worth re-checking again.
>>
>> For TCP we clearly cannot do it (yet, and couldn’t back then). But
>> TCP wa
On 20 Nov 2014, at 21:35 , John-Mark Gurney wrote:
> The first major issue I ran across was transport mode... ae@ has been
> nice enough to get ICMP working in transport mode for IPv4 and IPv6,
> but it looks like TCP is still broken. I haven't tested UDP yet...
> So, IPsec even w/o crypto is f
On 21 Nov 2014, at 11:02, Marko Zec wrote:
> Now that we've found ourselves in this discussion, I'm really
> becoming curious why exactly do we need UMA_ZONE_NOFREE for network
> stack zones at all? Admittedly, I always thought that the primary
> purpose of UMA_ZONE_NOFREE was to prevent uma_r
On Fri, 21 Nov 2014 10:37:25 +
"Bjoern A. Zeeb" wrote:
>
> On 21 Nov 2014, at 08:25 , Robert N. M. Watson
> wrote:
>
> >
> > On 20 Nov 2014, at 23:29, Marko Zec wrote:
> >
> >>> Can folks take a look at this?
> >>>
> >>> https://reviews.freebsd.org/D1201
> >>
> >> All UMA zones used i
Hi all,
I get the error message above when trying to go for jumbo frames (mtu
9000) on a system here. I found a lot of comments on this, but they all
state that this is due to a too low setting for mbufs in FreeBSD8/9
settings.
However, I have 10-stable here, and the settings look rather high to m
Hi,
My IBM System x3250 M5 has IPMI. It shares onboard NIC Broadcom BCM5719.
I'm setup it and IPMI works perfectly.
But when server boots in single user mode IPMI's IP becomes unreachable.
It occures when bge0 init.
Any hints?
Thanks.
Details are:
FreeBSD 10.1-STABLE (r274690) amd64
/boot/lo
On 21 Nov 2014, at 08:06 , Craig Rodrigues wrote:
> On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues
> wrote:
>
>> On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote:
>>
>>>
>>> For people to use pf with VIMAGE we first MUST have the security fix
>>> imported that I pointed out a couple
On 21 Nov 2014, at 08:25 , Robert N. M. Watson wrote:
>
> On 20 Nov 2014, at 23:29, Marko Zec wrote:
>
>>> Can folks take a look at this?
>>>
>>> https://reviews.freebsd.org/D1201
>>
>> All UMA zones used in the network stack have been marked as
>> UMA_ZONE_NOFREE for ages, probably for a r
On 21 Nov 2014, at 10:19, Robert N. M. Watson wrote:
>> The important thing here is not to loose the momentum and energy which
>> Craig is putting in cleaning up VIMAGE, so if we take the route of
>> eliminating the UMA_ZONE_NOFREE flag (or not), that should be decided
>> with rough consensus an
On 21 Nov 2014, at 09:45, Marko Zec wrote:
>> And, to respond to your more general comment: I agree that a decision
>> about removing the NOFREE flag should be made independently of
>> choices about devirtualisation. The former probably should be sorted
>> out at this point, as eliminating NOFRE
On Fri, 21 Nov 2014 09:07:28 +
"Robert N. M. Watson" wrote:
>
> On 21 Nov 2014, at 09:05, Robert N. M. Watson
> wrote:
>
> > To my mind, the only real concern is whether or not you lose access
> > to resource allocation limits that would previously have been
> > present. On the whole, we'v
On 21 Nov 2014, at 09:05, Robert N. M. Watson wrote:
> To my mind, the only real concern is whether or not you lose access to
> resource allocation limits that would previously have been present. On the
> whole, we've tried to centralise resource limitations on kernel memory
> allocation in U
On 21 Nov 2014, at 08:58, Marko Zec wrote:
> Nevertheless, I'd prefer most of network stack UMA zones to be
> de-virtualized, at least those which cannot cause interference between
> VNETs, and that excludes syncache, reassembly, hostcache and the likes.
> De-virtualization doesn't require touch
On Fri, 21 Nov 2014 08:25:48 +
"Robert N. M. Watson" wrote:
>
> On 20 Nov 2014, at 23:29, Marko Zec wrote:
>
> >> Can folks take a look at this?
> >>
> >> https://reviews.freebsd.org/D1201
> >
> > All UMA zones used in the network stack have been marked as
> > UMA_ZONE_NOFREE for ages, p
On 20 Nov 2014, at 23:29, Marko Zec wrote:
>> Can folks take a look at this?
>>
>> https://reviews.freebsd.org/D1201
>
> All UMA zones used in the network stack have been marked as
> UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it might
> not hurt to provide more insight why and
On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues
wrote:
> On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb wrote:
>
>>
>> For people to use pf with VIMAGE we first MUST have the security fix
>> imported that I pointed out a couple of times in the past.
>>
>
> At this link: http://cve.mitre.org/c
28 matches
Mail list logo
