This guys rely on the fact that if.h includes queue.h, but they
shouldn't really since lists are needed by the struct ifnet only.
OK?
diff --git sbin/dhclient/dhcpd.h sbin/dhclient/dhcpd.h
index 53625fb..c03af36 100644
--- sbin/dhclient/dhcpd.h
+++ sbin/dhclient/dhcpd.h
@@ -43,10 +43,11 @@
#inclu
On 18 November 2013 11:24, Martin Pieuchot wrote:
> Since we don't support any FDDI or ATM interfaces anymore, remove some
> special cases for such interface types in our kernel.
>
> ok?
>
OK. looks like there's more stuff that can die in the fire...
On 15 November 2013 15:45, Stefan Sperling wrote:
> On Fri, Nov 15, 2013 at 03:20:48PM +0100, Mike Belopuhov wrote:
>> On 15 November 2013 15:13, Stefan Sperling wrote:
>> > Is this done right?
>> >
>> > Works here with pppoe(4) for both IPv4 and IPv6.
>
On 15 November 2013 15:13, Stefan Sperling wrote:
> Is this done right?
>
> Works here with pppoe(4) for both IPv4 and IPv6.
>
i think this diff might lack task_del's in the detach code.
have you tried destroying your pppoe interface?
On 15 November 2013 15:08, Alexander Bluhm wrote:
> On Thu, Nov 14, 2013 at 05:38:14PM -0700, Theo de Raadt wrote:
>> Beautiful.
>
> I seems there was enough discussion. The Security argument is more
> important than the others. The new diff has no performance impact
> when pf is turned on.
>
>
On 14 November 2013 18:52, Henning Brauer wrote:
> * Theo de Raadt [2013-11-14 18:47]:
>> > it is the status quo *right now*
>>
>> Look, you can't call something the status quo when a commit was made 1
>> month ago, to a REAL status quo that existed for 10 years when itojun
>> made the change...
On Wed, Oct 30, 2013 at 14:58 +0100, Mike Belopuhov wrote:
> Tested on amd64 SP and MP, i386 SP so far. sparc64 MP test
> is in progress. I've also tested the crypto(4) interface
> (doesn't use queue) so softraid should work as well.
>
sparc64 test is done.
on a side n
Tested on amd64 SP and MP, i386 SP so far. sparc64 MP test
is in progress. I've also tested the crypto(4) interface
(doesn't use queue) so softraid should work as well.
ok?
diff --git sys/crypto/crypto.c sys/crypto/crypto.c
index 7df0c435..fbdcd97 100644
--- sys/crypto/crypto.c
+++ sys/crypto/c
On 22 October 2013 15:22, Mark Kettenis wrote:
> Diff below makes bioctl(4) print the cache policy for that's currently
> in effect for RAID volumes. It only prints the state (WB for
> write-back, WT for write-through) if the RAID controller driver fills
> in the details in response to a BIOCVOL
hi,
since mpi's if_index diff is now in, this should probably
go in as well. it has received some testing in the meantime.
original description:
in order to make our life a bit easier and prevent rogue
accesses to the routing table from the hardware interrupt
context violating all kinds of spl
On Fri, Oct 11, 2013 at 12:09 +0200, Gerhard Roth wrote:
> In January bluhm@ introduced 'data_end' to pf.c:tcp_track_full().
> Now this breaks the handling of non-data packets. They may be rejected
> because the SEQ_GEQ(src->seqhi, data_end) check fails.
>
> The patch below should fix this.
>
Ma
On 9 October 2013 19:51, Alexey E. Suslikov wrote:
> * Added AES-XTS support to aesni crypto(4) driver on amd64.
> Allows softraid(4) to benefit from the AES-NI instructions on
> newer Intel CPUs
not at the moment, though.
On 27 September 2013 15:24, Alexander Bluhm wrote:
> Hi,
>
> The error return codes for the enc interface seem quite inconsistent.
> Always return the appropriate errno.
>
> ok?
>
> bluhm
>
OK
On 12 September 2013 18:48, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 06:28:15PM +0200, Mike Belopuhov wrote:
>> > Sure, I do. You're trying to push one thing and you don't want to
>> > hear the concerns about a specific detail of it.
>> >
&
On 12 September 2013 19:07, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 06:59:13PM +0200, Mike Belopuhov wrote:
>> > Ok, let's stop this. I don't think you read what I replied before. I
>> > didn't say that we're static with if_indexes, just that we sh
On 12 September 2013 18:14, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote:
>> looks like you misunderstand the problem we're dealing with here.
>>
>
> Sure, I do. You're trying to push one thing and you don't want to
On 12 September 2013 18:28, Mike Belopuhov wrote:
> On 12 September 2013 18:14, Reyk Floeter wrote:
>> On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote:
>>> looks like you misunderstand the problem we're dealing with here.
>>>
>>
>> Sure
On 12 September 2013 17:31, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 05:18:39PM +0200, Martin Pieuchot wrote:
>> > For example, you have to query the IfIndex via SNMP to get further
>> > information, like the ifName or statistics, and most monitoring
>> > systems would save interface informat
On 12 September 2013 17:18, Martin Pieuchot wrote:
> FWIW it would be interesting to modify tun(4) so that it doesn't
> need to detach/reattach itself when switching between mode, this
> would allow us to stop reusing the last index.
>
this definitely makes a lot of sense.
On 9 September 2013 22:46, STeve Andre' wrote:
> On 09/09/13 07:45, Paul de Weerd wrote:
>>
>> Found a couple of unknown Intel products in a Dell Optiplex 9020:
>>
>> vendor "Intel", unknown product 0x153a (class network subclass ethernet,
>> rev 0x04) at pci0 dev 25 function 0 not configured
>> v
On 9 September 2013 21:44, Brad Smith wrote:
> Since I have been asked to send out these diffs again here is a diff to enable
> the checksum offload support for em(4).
>
> Looking for any testing.
>
>
tx checksum offloading will not work on 75, 76, 80, i350.
On 9 September 2013 21:48, Brad Smith wrote:
> Here is a diff to enable the checksum offload support for ix(4).
>
> Looking for any testing.
>
last time i checked this broke ospf traffic. please make sure at least
ip/tcp, ip/udp, ip/icmp, ip/ip, ip/gre, ip/esp, ip/ah and ip/ospf work fine
with t
On Mon, Aug 26, 2013 at 13:36 +0200, Mike Belopuhov wrote:
> hi,
>
> in order to make our life a bit easier and prevent rogue
> accesses to the routing table from the hardware interrupt
> context violating all kinds of spl assumptions we would
> like if_link_state_change that is
On 27 August 2013 15:58, Martin Pieuchot wrote:
> In order to define a proper API for our routine table, I'd like to turn
> the "struct rt_addrinfo" into a private type (ie: only used in route.c
> and rtsock.c).
>
> This type is used by a lost of code in our network stack to add or delete
> a rout
On 27 August 2013 13:39, Martin Pieuchot wrote:
> I think that's the right approach but the current code generating
> interfaces indexes is too clever from my point of view, it tries
> to reuse the last index if possible. This could lead to some
> funny races if we detach and reattach an interfac
hi,
in order to make our life a bit easier and prevent rogue
accesses to the routing table from the hardware interrupt
context violating all kinds of spl assumptions we would
like if_link_state_change that is called by network device
drivers in their interrupt service routines to defer its
work to
hi,
bge(4) is the last driver in the tree that is willing to call
if_link_state_change whenever, while others do so only when
the link state does change.
there should be no real change in functionality. ok?
diff --git sys/dev/pci/if_bge.c sys/dev/pci/if_bge.c
index 5cd56e2..233ccab 100644
---
On 19 August 2013 12:52, David Coppa wrote:
>
> This misses util.h:
>
> cc -O2 -pipe -fno-pie -Wall -DINET6 -c /usr/src/sbin/ifconfig/ifconfig.c
> /usr/src/sbin/ifconfig/ifconfig.c: In function 'setifwpakey':
> /usr/src/sbin/ifconfig/ifconfig.c:1759: warning: implicit declaration of
> function
On 9 August 2013 11:04, Martin Pieuchot wrote:
> This is the last episode from the first season of the serie, "move
> your variables to the stack". Like in the previous episodes, this
> one will let us execute the various icmp functions in parallel
> without risk of trashing a value.
>
> It also
On 16 August 2013 09:23, Ted Unangst wrote:
> Actually, here's my concern. There's only one timeout for the process.
> What happens when two threads are running on two CPUs? Is there a
> guarantee that cpu0 will both set and execute the timeout before cpu1
> sets it, or is there a race where cpu1
On 15 August 2013 17:34, Alexander Bluhm wrote:
> Hi,
>
> After converting the last user of ioctl(SIOCGDRLST_IN6) to sysctl,
> I would like to remove dead kernel ioctl code.
>
> Is it save to just delete this?
>
> ok?
>
> bluhm
>
if ports are fine with it, i'm fine as well (:
On Thu, Aug 15, 2013 at 02:42 +0200, Alexander Bluhm wrote:
> Hi,
>
> I would like to reduce the warnings when arp, rarp, ndp are compiled
> with WARNINGS=yes. Let's start with this one.
>
> warning: declaration of 'time' shadows a global declaration
>
> No binary change.
>
> ok?
>
OK
On Thu, Aug 15, 2013 at 00:39 +0200, Alexander Bluhm wrote:
> Hi,
>
> I would like to replace the obsolete ioctl(SIOCGDRLST_IN6) interface
> with sysctl(net.inet6.icmp6.nd6_drlist) in rtsold. Code copied
> from ndp.
>
> ok?
>
looks good to me. OK
to make mpi's life a tad easier and also lose some weight,
i'd like to move rat(4) to the attic. mpi, kettenis, jsg
and henning agree. i'll commit the diff if noone objects.
henning has also suggested to remove the pre-wifi era cnw(4).
if there's interest i can cook a diff for that as well, but
On 9 August 2013 09:36, Martin Pieuchot wrote:
> It's me again :) With a freshly updated and tested diff to tedu netatm.
> I got no objection since I raised the issue 5 months ago [0], so I'm now
> looking for oks.
>
> [0] http://marc.info/?l=openbsd-tech&m=136335787207091&w=2
>
i think it should
On 8 August 2013 12:35, Martin Pieuchot wrote:
> arp_rtrequest() uses a default static sockaddr_dl which is only used
> read-only: it is copied by rt_setgate().
>
> I'd like to constify this structure to make it clear no value can be
> trashed if code using it is run in parallel.
>
> Also remove a
On 7 August 2013 15:07, Martin Pieuchot wrote:
> Diff below deduplicate and move the code adding a new address to the
> global list into in_ifinit(), there's no functional change.
>
> While here add a comment about why we always delete addresses from
> the tree during update.
>
> ok?
>
OK mikeb
On 6 August 2013 03:54, Alexander Bluhm wrote:
> Hi,
>
> For an upcoming change in in6_var.h I would like to minimize the
> impact. Most network drivers include netinet/in_var.h, but apparently
> they don't have to. Can we remove these includes?
>
> compiled on amd64 and i386
>
> ok?
>
> bluhm
>
Hi,
The following diff updates most of the ix(4) driver to what
FreeBSD and Intel have today. Most importantly it introduces
support for the Ethernet flow control.
Please test and report. OK's are welcome as well.
http://theapt.org/~mike/ix.diff
http://theapt.org/~mike/ix-w.diff (less whitesp
Hi,
As it was pointed out by dhill there are some rogue splnets in
the tcp_input that shouldn't be there really. The only reason
they're still there is to match overzealous splnets in bridge_
broadcast. bridge_ifenqueue is the only function call in there
that requires splnet protection since it'
On 2 July 2013 17:38, Lawrence Teo wrote:
> This diff fixes two errors on the pf(4) man page:
>
> 1. DIOCSETSTATUSIF has not used struct pfioc_if since pf_ioctl.c rev
>1.234; it now uses struct pfioc_iface. Since the definition of
>pfioc_iface is already listed under DIOCIGETIFACES, I mov
On 27 June 2013 14:39, Rob Sessink wrote:
>>> I've got test report for the BCM5723/BCM5784. It would be
>>> great if someone with a 5703 or 5704 could try this.
>>
>> Hoi Mike,
>>
>> Over the weekend I would be able to test this on a HP DL360 G3 with 5703.
>>
>> Regards Rob
>
> Hello,
>
> I
Hi,
This is a mail I've sent to dlg@ and kettenis@ and didn't
get an objection, but I would like a more widespread testing
to happen with this diff.
Please try it on all bge's you can. Your help is much
appreciated!
8<
I find the transmit path on 5719 here to be of questionable
On 19 June 2013 20:20, Reyk Floeter wrote:
> On Wed, Jun 19, 2013 at 08:00:01PM +0200, Reyk Floeter wrote:
>> OK?
>>
>
> I forgot the in6_pcblookup_listen() case, updated diff below.
>
> Reyk
>
it boils down to the pcb lookup magic as i thought; ok mikeb.
I've got test report for the BCM5723/BCM5784. It would be
great if someone with a 5703 or 5704 could try this.
On Thu, Jun 13, 2013 at 18:09 +0200, Mike Belopuhov wrote:
> Hi,
>
> David Imhoff has found that flow control got broken in bge
> after some recent changes but
Hi,
David Imhoff has found that flow control got broken in bge
after some recent changes but also that simple "ifconfig bge0"
call done by any user can change current flow control settings.
We've tested it on a bunch of recent cards (5719, 5720), one
old-ish card (5715) but would like others to ma
NetBSD and Broadcom docs (5718-PG106-R.pdf and 57XX-PG105-R.pdf)
and even our bnx(4) driver (and it's spec) agree that the mask
should be 0x3ff.
OK?
diff --git sys/dev/pci/if_bgereg.h sys/dev/pci/if_bgereg.h
index 3685f14..c0a28b9 100644
--- sys/dev/pci/if_bgereg.h
+++ sys/dev/pci/if_bgereg.h
@@
Hi,
Could someone with a fiber bge give the diff below a spin.
The code chunk in question should not be run for fiber PHYs.
There's no change in functionality for non-optical transmitters.
http://svnweb.freebsd.org/base/head/sys/dev/mii/brgphy.c?r1=244480&r2=244481
OK's are welcome as well.
di
On 4 June 2013 02:48, Stuart Henderson wrote:
> On 2013/06/04 02:01, Mike Belopuhov wrote:
>> On 4 June 2013 00:49, Stuart Henderson wrote:
>> > On a router running PF and isakmpd, I have a rule like this:
>> >
>> > match out on pppoe0 inet all received-on
On 4 June 2013 00:49, Stuart Henderson wrote:
> On a router running PF and isakmpd, I have a rule like this:
>
> match out on pppoe0 inet all received-on vlan5 nat-to $someip
>
> I was surprised to find this being applied to packets received on vlan5
> and caught by an ipsec flow; the resulting *e
On 29 May 2013 09:35, David Gwynne wrote:
> ive tested this on:
>
> bge0 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x21, BCM5750 C1
> (0x4201): apic 0 int 16, address 00:18:f3:d1:80:64
> brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
>
> bge1 at pci5 dev 0 function 0 "Broadcom
Hi,
While trying to fix the link state bug on BCM5719, David Imhoff
has arrived at conclusion that the chip won't generate proper
link state interrupts which renders auto-polling mode useless.
As it turns out neither Linux nor FreeBSD use auto-polling mode
for anything newer than BCM5705 and rece
On 22 May 2013 19:57, Aaron Stellman wrote:
> On Mon, May 20, 2013 at 08:24:06PM +0100, Stuart Henderson wrote:
>> If you make it a couple of paragraphs past the table, there is this
>> paragraph, which is rather clear:
>>
>> Using AES-GMAC or NULL with ESP will only provide authentication.
On 22 May 2013 18:32, Mike Belopuhov wrote:
> On Wed, May 22, 2013 at 18:08 +0200, Mark Kettenis wrote:
>> > Date: Wed, 22 May 2013 17:59:19 +0200
>> > From: Mike Belopuhov
>> >
>> > On Tue, May 21, 2013 at 17:16 +0200, Mike Belopuhov wrote:
>>
On Wed, May 22, 2013 at 18:08 +0200, Mark Kettenis wrote:
> > Date: Wed, 22 May 2013 17:59:19 +0200
> > From: Mike Belopuhov
> >
> > On Tue, May 21, 2013 at 17:16 +0200, Mike Belopuhov wrote:
> > > from freebsd. ok?
> > >
> >
> > ping!
&g
On Tue, May 21, 2013 at 17:16 +0200, Mike Belopuhov wrote:
> from freebsd. ok?
>
ping!
> diff --git sys/dev/mii/brgphy.c sys/dev/mii/brgphy.c
> index 7f0bae2..461c798 100644
> --- sys/dev/mii/brgphy.c
> +++ sys/dev/mii/brgphy.c
> @@ -412,8 +412,10 @@ setit:
>
On 21 May 2013 17:18, Mark Kettenis wrote:
>> Date: Tue, 21 May 2013 17:10:57 +0200
>> From: Mike Belopuhov
>>
>> prevent the system from spitting loads of splasserts when bge_watchdog
>> fires. ok?
>
> I'd say no. Why is the driver tearing down
from freebsd. ok?
diff --git sys/dev/mii/brgphy.c sys/dev/mii/brgphy.c
index 7f0bae2..461c798 100644
--- sys/dev/mii/brgphy.c
+++ sys/dev/mii/brgphy.c
@@ -412,8 +412,10 @@ setit:
* the BMSR twice in case it's latched.
*/
reg = PHY_READ(sc, MII_BMSR
prevent the system from spitting loads of splasserts when bge_watchdog
fires. ok?
diff --git sys/dev/pci/if_bge.c sys/dev/pci/if_bge.c
index 055ceec..ffad959 100644
--- sys/dev/pci/if_bge.c
+++ sys/dev/pci/if_bge.c
@@ -1226,7 +1226,7 @@ bge_init_rx_ring_std(struct bge_softc *sc)
for (i
On Mon, May 13, 2013 at 17:30 -0400, Ted Unangst wrote:
> On Mon, May 13, 2013 at 20:44, Stuart Henderson wrote:
> > On 2013/05/13 19:32, Mark Lumsden wrote:
> >> I agree. tedu suggest 9 for the number of user rounds and 11 for
> >> root back in 2010. Are these numbers reasonable on most archs?
>
On Fri, May 10, 2013 at 10:35 -0700, Matthew Dempsky wrote:
> On Fri, May 10, 2013 at 6:02 AM, Mike Belopuhov wrote:
> > my intention here is very simple: there's a way you should call
> > device_lookup and everyone has to fulfill it's part of the contract.
> > al
On 10 May 2013 16:43, Chris Cappuccio wrote:
> Stuart Henderson [st...@openbsd.org] wrote:
>> On 2013/02/22 12:30, Stuart Henderson wrote:
>> > I thought we already had something for this after the misc@ thread
>> > a few months ago, but clearly not.
>> >
>> > Adapted from FreeBSD if_lagg.c r17166
On 10 May 2013 14:57, Gerhard Roth wrote:
> Mike,
>
> but it does check in vscsiopen(). Hence no userland program should be
> able to call vscsiioctl() for a non-existant device because the open()
> already failed. At least that's true as long as vscsi devices can't
> disappear during run-time.
>
On Fri, May 03, 2013 at 16:19 +0200, Mike Belopuhov wrote:
> hi,
>
> while looking for the device_unref bugs, i found that
> vscsi doesn't check if device_lookup has returned a
> valid return value.
>
> ok?
>
anyone?
> diff --git sys/dev/vscsi.c sys/dev/vscsi.c
Hi,
I'll commit it then, if there are no objections.
On Sat, May 04, 2013 at 14:09 +0200, Sebastian Reitenbach wrote:
>
> On Friday, May 3, 2013 17:16 CEST, Mike Belopuhov wrote:
>
> > hi,
> >
> > as far as i can tell these functions are not used anymore.
&
On 3 May 2013 20:12, Mark Kettenis wrote:
>> Date: Fri, 3 May 2013 20:04:11 +0200
>> From: Mike Belopuhov
>>
>> hi,
>>
>> not sure if this is anyhow useful, but we can completely ditch
>> DV_TTY since it's not used in any sensible way.
>&
hi,
not sure if this is anyhow useful, but we can completely ditch
DV_TTY since it's not used in any sensible way.
any objections? ok?
diff --git sys/arch/alpha/tc/scc.c sys/arch/alpha/tc/scc.c
index d25901e..ad37605 100644
--- sys/arch/alpha/tc/scc.c
+++ sys/arch/alpha/tc/scc.c
@@ -179,7 +179,7
hi,
as far as i can tell these functions are not used anymore.
ok?
diff --git sys/arch/sparc/dev/z8530kbd.c sys/arch/sparc/dev/z8530kbd.c
index 0a9c364..c746e56 100644
--- sys/arch/sparc/dev/z8530kbd.c
+++ sys/arch/sparc/dev/z8530kbd.c
@@ -213,8 +213,6 @@ static void zs_modem(struct zskbd_softc
On Fri, May 03, 2013 at 15:50 +0200, Mike Belopuhov wrote:
> diff --git sys/dev/pci/cz.c sys/dev/pci/cz.c
> index 9f74393..03b0fb5 100644
> --- sys/dev/pci/cz.c
> +++ sys/dev/pci/cz.c
> @@ -848,23 +848,30 @@ cztty_getttysoftc(dev_t dev)
> {
> int i, j, k, u = minor(dev)
On 3 May 2013 16:28, Florian Obser wrote:
> Chris Ivancic & Colin Ligertwood reported in January that the
> "SolarWinds NetFlow Traffic Analyzer" doesn't like it if the
> ingress/egress interface index is always 0 (v5) or not present at all
> (v9/v10). This keeps track on which interface a packet
hi,
while looking for the device_unref bugs, i found that
vscsi doesn't check if device_lookup has returned a
valid return value.
ok?
diff --git sys/dev/vscsi.c sys/dev/vscsi.c
index 3da371c..db65642 100644
--- sys/dev/vscsi.c
+++ sys/dev/vscsi.c
@@ -296,6 +296,9 @@ vscsiioctl(dev_t dev, u_long
hi,
looks like we're missing some device_unref's that need to be
there after we call device_lookup or disk_lookup or numerous
macros that expand to either of those.
it would be nice if someone with working hibernate and ahci
could test the diff (on either i386 or amd64).
i'm also not 100% sure i
On 12 April 2013 12:26, Martin Pieuchot wrote:
> Simple diff to move all the redundant extern declaration into their
> corresponding header.
>
> ok?
>
looks fine to me.
On Tue, Mar 19, 2013 at 11:50 +0100, Martin Pieuchot wrote:
> Diff below removes 4 global read-only variables "ifqmaxlen", "ipqmaxlen",
> "ip6qmaxlen" and "mplsqmaxlen" that are all set to IFQ_MAXLEN and never
> modified afterward.
>
> ok?
>
OK to reduce bogosity.
On Tue, Mar 19, 2013 at 16:10 +0100, Martin Pelikan wrote:
> Hi!
>
> Yesterday I got sick and tired of guessing what the enormous traffic in our
> default queue was, and filled an item from my wishlist since OpenBSD 4.7.
>
> It works like this:
>
> # tcpdump -Q queuename -ni em0
> tcpdump: liste
On 12 March 2013 19:25, Ted Unangst wrote:
> On Tue, Mar 12, 2013 at 15:30, Martin Pieuchot wrote:
>> Diffs below kill respectively faith(4) and faithd(8) as suggested some
>> weeks ago after a submission by dhill.
>>
>> ok?
>
> I am, of course, implicitly ok will all deletions of obsolete code.
>
On 5 March 2013 11:55, Mark Kettenis wrote:
>> Date: Tue, 5 Mar 2013 11:36:36 +0100
>> From: Martin Pieuchot
>>
>> The ifaddr structure contains a reference counter and two different way
>> to check it before freeing its memory: a macro IFAFREE(), and a function
>> ifafree().
>> Because the forme
On 9 February 2013 16:27, Stuart Henderson wrote:
> So I think the vr(4) diff has had a reasonable amount of testing;
> any objections or ideally OKs to commit it?
>
OK
> I have also tested sis(4) on a PC Engines WRAP now; despite the
> DP83815 datasheet indicating that "Accept Long Packets"
> (
On Thu, Feb 07, 2013 at 17:41 +, Stuart Henderson wrote:
> At least the following vr(4) devices can be configured to permit
> larger MTUs.
>
> vr0 at pci0 dev 18 function 0 "VIA RhineII-2" rev 0x51: irq 11, address
> 00:40:63:c0:5d:27
> vr1 at pci2 dev 0 function 0 "VIA VT6105M RhineIII" rev
On 15 January 2013 11:34, Alexander Bluhm wrote:
> Hi,
>
> Some years ago reyk@ mentioned that the current socket splicing
> semantics is suboptimal. When used with persistent http connections,
> the kernel does not inform user land when the maximum splicing
> lenght has been reached. The file d
On Wed, Dec 05, 2012 at 13:29 +0100, Mike Belopuhov wrote:
> converting mallocs to pools has an advantage of getting rid of
> the malloc in the forwarding path which gives a tiny bit of
> speed up but the main thing is that it makes life easier for
> those who have started working on
On 14 December 2012 13:38, Stuart Henderson wrote:
> Are profiling kernels known to be broken at the moment?
>
profiling has never worked on MP kernels...
On Thu, Dec 13, 2012 at 20:49 +0100, Mike Belopuhov wrote:
> first this allows you to connect the sfp+ cable after boot
> and correctly identify and use it, secondly it allows you
> (supposedly as i've only tested two different types of
> direct attach cables, i.e. differen
first this allows you to connect the sfp+ cable after boot
and correctly identify and use it, secondly it allows you
(supposedly as i've only tested two different types of
direct attach cables, i.e. different phys) to switch between
copper and fiber w/o rebooting.
SDP1 interrupt processing is not
On Fri, Nov 30, 2012 at 20:44 +0100, Mike Belopuhov wrote:
> On Tue, Nov 27, 2012 at 13:50 +0100, mxb wrote:
> > Hi tech@,
> >
> > ix(4) does not detects link then cable is plugged in into already running
> > machine.
> >
> > ix0:
> > flags=28b43
&g
converting mallocs to pools has an advantage of getting rid of
the malloc in the forwarding path which gives a tiny bit of
speed up but the main thing is that it makes life easier for
those who have started working on the locking in the stack.
henning and markus agree that having a single pool for
On Tue, Nov 27, 2012 at 13:50 +0100, mxb wrote:
> Hi tech@,
>
> ix(4) does not detects link then cable is plugged in into already running
> machine.
>
> ix0:
> flags=28b43
> mtu 1500
> lladdr bc:30:5b:f3:60:10
> description: HW_EXT
> priority: 0
> media: Etherne
rote:
>> > > On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote:
>> > > > hi,
>> > > >
>> > > > drivers ex age alc ale jme se vic vte xe upl and octeon/cmac
>> > > > make use of the if_iqdrops counter that is not sho
On 29 November 2012 21:21, Mark Kettenis wrote:
>> Date: Thu, 29 Nov 2012 20:49:00 +0100
>> From: Claudio Jeker
>>
>> On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote:
>> > On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote:
>&g
On 29 November 2012 20:49, Claudio Jeker wrote:
> On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote:
>> On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote:
>> > hi,
>> >
>> > drivers ex age alc ale jme se vic vte xe upl
makes cloned devices line up well with the rest of the output:
_dhcpdhclient 30880 text / 14 -r-xr-xr-x r 283856
_dhcpdhclient 30880 wd /var77953 drwxr-xr-x r 512
_dhcpdhclient 30880 root /var77953 drwxr-xr-x r 512
_dhcpdhclien
hi,
drivers ex age alc ale jme se vic vte xe upl and octeon/cmac
make use of the if_iqdrops counter that is not shown by any of our
tools (like netstat). looks like most of its usage comes from
freebsd where they show it in the "netstat -di" output in a new
column. do we want to do that or just
On Wed, Nov 28, 2012 at 2:25 AM, Brad Smith wrote:
> On Sat, Nov 24, 2012 at 10:24:00PM -0500, Brad Smith wrote:
>> On Fri, Nov 23, 2012 at 11:57:50AM -0200, Gleydson Soares wrote:
>> > set ifp->if_baudrate with IF_Gbps() / IF_Mbps().
>> >
>> > OK ?
>>
>> Although it has already been commited its
On Tue, Nov 27, 2012 at 2:28 PM, mxb wrote:
> There is however, no problem then:
>
> plugged -> boot -> wait -> unplug -> wait -> plug in.
>
> On 27 nov 2012, at 13:50, mxb wrote:
>
>>
>> Hi tech@,
>>
>> ix(4) does not detects link then cable is plugged in into already running
>> machine.
>>
>>
On Wed, Nov 28, 2012 at 12:38 PM, mxb wrote:
> Compiling if_ix.c with IX_DEBUG yields
>
> ../../../../dev/pci/if_ix.c: In function 'ixgbe_print_hw_stats':
> ../../../../dev/pci/if_ix.c:3525: error: 'struct ix_softc' has no member named
> 'mbuf_alloc_failed'
> ../../../../dev/pci/if_ix.c:3526: erro
On Wed, Nov 28, 2012 at 10:42 PM, Mark Kettenis wrote:
>> From: Mike Belopuhov
>> Date: Wed, 28 Nov 2012 22:21:07 +0100
>>
>> On Wed, Nov 28, 2012 at 8:21 PM, Mark Kettenis
>> wrote:
>> >> Date: Wed, 28 Nov 2012 17:39:24 +0100
>> >> From:
On Wed, Nov 28, 2012 at 11:38 PM, Theo de Raadt wrote:
>> there's not supposed to be bpf0,1,2,3...
>
> Unfortunately history argues otherwise.
no, i meant if we move to the clonable bpf, we will need only one node.
sorry for not making it clear.
On Wed, Nov 28, 2012 at 8:21 PM, Mark Kettenis wrote:
>> Date: Wed, 28 Nov 2012 17:39:24 +0100
>> From: Reyk Floeter
>>
>> Hi,
>>
>> inspired by mikeb@'s clonable bpf patch, this slightly more complex
>> diff implements clonable interface support to tun(4).
>>
>> The idea is to split the fixed re
On Wed, Nov 28, 2012 at 12:43 PM, Reyk Floeter wrote:
> On Tue, Nov 27, 2012 at 10:17 PM, Mike Belopuhov wrote:
>> apparently it works just fine. the number of clones is limited
>> by the v_specbitmap which currently allows for 64 clones total
>> (per system, not per pr
On Tue, Nov 27, 2012 at 11:30 PM, Claudio Jeker
wrote:
> Hi,
>
> There are two flags which are not used or only used by the kernel
> (outgoing to userland). When userlands sends rt messages with these flags
> they do no harm but show up in route(8) and netstat(1). IMO we should
> scrub those flags
701 - 800 of 1074 matches
Mail list logo
