Re: apmd -A induced hangs

2014-09-02 Thread Alexander Bluhm
On Sun, Aug 31, 2014 at 09:44:11PM +0200, Alexander Bluhm wrote: > On Tue, Jul 29, 2014 at 12:19:43AM +0200, Alexander Bluhm wrote: > > Next I will try with this diff and without running apmd. > > I was runnig with the diff and without apmd and used sysctl hw.setperf > manually. In this month my

Re: minphys woes

2014-09-02 Thread Philip Guenther
On Tue, Sep 2, 2014 at 2:07 PM, Stefan Fritsch wrote: > On Tuesday 02 September 2014 13:15:19, Philip Guenther wrote: >> On Tue, Sep 2, 2014 at 12:51 PM, Stefan Fritsch > wrote: >> > On Monday 01 September 2014 22:24:16, David Gwynne wrote: >> > > > i haven't found a controller that does less tha

Re: LibreSSL 2.0.5 released

2014-09-02 Thread mancha
or BSDisms or OpenSSL/LibreSSL for prng seed material. So, I anticipate it should build on many POSIXy systems (tested on Linux and Windows/Cygwin). The latest version was sync'd on 20140902 and includes signify.c rev1.91 and updated support code including tweaks that hopefully make expli

Re: minphys woes

2014-09-02 Thread Stefan Fritsch
On Tuesday 02 September 2014 13:15:19, Philip Guenther wrote: > On Tue, Sep 2, 2014 at 12:51 PM, Stefan Fritsch wrote: > > On Monday 01 September 2014 22:24:16, David Gwynne wrote: > > > > i haven't found a controller that does less than MAXPHYS. > > > > perhaps they meant to improve the situatio

Re: minphys woes

2014-09-02 Thread Philip Guenther
On Tue, Sep 2, 2014 at 12:51 PM, Stefan Fritsch wrote: > > On Monday 01 September 2014 22:24:16, David Gwynne wrote: > > > i haven't found a controller that does less than MAXPHYS. > > > perhaps they meant to improve the situation but stopped short. > > > > if we wanted to raise MAXPHYS, we'd have

Re: minphys woes

2014-09-02 Thread Stefan Fritsch
On Monday 01 September 2014 22:24:16, David Gwynne wrote: > > i haven't found a controller that does less than MAXPHYS. > > perhaps they meant to improve the situation but stopped short. > > if we wanted to raise MAXPHYS, we'd have to support older > controllers that cant do greater than 64k with

Re: re(4) feature flags additions and changes

2014-09-02 Thread Brad Smith
On Tue, Sep 02, 2014 at 09:03:34PM +1000, Jonathan Gray wrote: > On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote: > > Add some feature flags and store in the softc the various max Jumbo frame > > sizes > > for the different generations of chips. No behavioral change. > > > > Tested wit

Re: re(4) feature flags additions and changes

2014-09-02 Thread Brad Smith
On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote: > Add some feature flags and store in the softc the various max Jumbo frame > sizes > for the different generations of chips. No behavioral change. > > Tested with.. > > re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/811

Re: re(4) feature flags additions and changes

2014-09-02 Thread Jonathan Gray
On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote: > Add some feature flags and store in the softc the various max Jumbo frame > sizes > for the different generations of chips. No behavioral change. > > Tested with.. > > re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/811

re(4) feature flags additions and changes

2014-09-02 Thread Brad Smith
Add some feature flags and store in the softc the various max Jumbo frame sizes for the different generations of chips. No behavioral change. Tested with.. re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D (0x2800) re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/

Re: bge(4) Jumbo support for newer chipsets

2014-09-02 Thread Mike Belopuhov
On 2 September 2014 03:54, Brad Smith wrote: > On Wed, Aug 27, 2014 at 02:25:27AM -0400, Brad Smith wrote: >> Looking for some testing of the following diff to add Jumbo support for the >> BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766 >> chipsets. > > Here is an updated d

arp(8) and ndp(8) tweaks

2014-09-02 Thread Martin Pieuchot
Diff below indicates by using a `l' flag which entries are local to the machine. It also skips broadcast entries from the "arp -a" output because even if they are implemented as llinfo entries, they'll never be resolved and can be safely ignored. Finally it change arp(8) to display 'permanent' in