RE: TSO patch for current

Is the TSO patch is checked in to the current? Thanks, ~Siva -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Vogel Sent: Saturday, September 02, 2006 4:21 AM To: freebsd-net; freebsd-current Subject: RFC: TSO patch for current This is a patch for t

IPMI & portrange

Hi, This keeps bitting me every other upgrade, IPMI on some hosts, if enabled, will steal packets to port 623 or 664, so the current solution is either set net.inet.ip.portrange.lowlast to 664, (for some reason this does not seem to work if done via loader.conf) or change it in sys/netinet/

Re: TSO patch for current

[EMAIL PROTECTED] wrote: Is the TSO patch is checked in to the current? Yes, but a different one. -- Andre Thanks, ~Siva -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Vogel Sent: Saturday, September 02, 2006 4:21 AM To: freebsd-net; freebsd-c

Bundled SAs and ESP/IPCOMP support ...

All, I have been working on ipsec-tools development a bit and am currently scratching my head over issues related to esp and ipcomp. Since I do most of my testing with FreeBSD, I tried both the kame ipsec and fast ipsec support but have had no success to date. Here are the SPD entries being

Re: Much improved sendfile(2) kernel implementation

On Friday 22 September 2006 10:44, Andrew Gallatin wrote: > > Between TSO and your sendfile changes, things are looking up! > > Here are some Myri10GbE 1500 byte results from a 1.8GHz UP > FreeBSD/amd64 machine (AMD Athlon(tm) 64 Processor 3000+) sending to a > 2.0GHz SMP Linux/x86_64 machine (A

RE: IPMI & portrange

On 26-Sep-2006 Danny Braniss wrote: > This keeps bitting me every other upgrade, IPMI on some > hosts, if enabled, will steal packets to port 623 or 664, so > the current solution is either set net.inet.ip.portrange.lowlast > to 664, (for some reason this does not seem to work if done via > l

Re: IPMI & portrange

On Tue, Sep 26, 2006 at 01:53:44PM -0700, John Polstra wrote: > On 26-Sep-2006 Danny Braniss wrote: > > This keeps bitting me every other upgrade, IPMI on some > > hosts, if enabled, will steal packets to port 623 or 664, so > > the current solution is either set net.inet.ip.portrange.lowlast

Re: Bundled SAs and ESP/IPCOMP support ...

Matthew Grooms wrote: All, With fast ipsec compiled into the kernel, I can see the outbound esp transport SAD entry increase the current byte count but the ipcomp entry shows nothing to indicate its use. It seems strange that the kernel will send acquire messages via PF_KEY as a pre-requi

Bug or Design limitation??

Our test group just ran into something I hadnt noticed before. Take a system and put in two different multiport NIC boards, one older (PCI-X) and one new PCI-E board. Load a driver that only recognizes the first board. It will show em0, em1, em2, em3, the new ports will be none's. Unload that dr

Re: Bug or Design limitation??

Jack Vogel wrote this message on Tue, Sep 26, 2006 at 16:15 -0700: > Our test group just ran into something I hadnt noticed before. > Take a system and put in two different multiport NIC boards, > one older (PCI-X) and one new PCI-E board. > > Load a driver that only recognizes the first board. It

Re: Bug or Design limitation??

Yes, ifconfig dumps the names correctly. This isnt my machine, so I will have to go get the tester to get me the dmesg, I'll send along when I have it. Jack On 9/26/06, John-Mark Gurney <[EMAIL PROTECTED]> wrote: Jack Vogel wrote this message on Tue, Sep 26, 2006 at 16:15 -0700: > Our test gro

Re: IPMI & portrange

> On Tue, Sep 26, 2006 at 01:53:44PM -0700, John Polstra wrote: > > On 26-Sep-2006 Danny Braniss wrote: > > > This keeps bitting me every other upgrade, IPMI on some > > > hosts, if enabled, will steal packets to port 623 or 664, so > > > the current solution is either set net.inet.ip.portran