From: Nicholas Marriott nicholas.marri...@gmail.com
Date: Tue, Jan 15, 2013 at 4:37 AM
Subject: Re: terminfo entries for rxvt-unicode
To: dco...@gmail.com
Cc: st...@openbsd.org, tech@openbsd.org
Hi
Weren't we going to install it in /usr/local/share/terminfo?
Yes, but there is another
Hi
On Tue, Jan 15, 2013 at 01:59:47AM -0700, David Coppa wrote:
From: Nicholas Marriott nicholas.marri...@gmail.com
Date: Tue, Jan 15, 2013 at 4:37 AM
Subject: Re: terminfo entries for rxvt-unicode
To: dco...@gmail.com
Cc: st...@openbsd.org, tech@openbsd.org
Hi
Weren't we
On 2013/01/15 10:05, Nicholas Marriott wrote:
On Tue, Jan 15, 2013 at 01:59:47AM -0700, David Coppa wrote:
Since rxvt-unicode is becoming increasingly popular as an alternative
to xterm, here's why I'm asking to add its terminfo entries to the
system termcap...
Well, my point is that we
On 2013/01/15 04:54, David Coppa wrote:
From: Stuart Henderson st...@openbsd.org
Date: Tue, Jan 15, 2013 at 11:30 AM
Subject: Re: terminfo entries for rxvt-unicode
To: Nicholas Marriott nicholas.marri...@gmail.com
Cc: dco...@gmail.com, tech@openbsd.org
On 2013/01/15 10:05,
On 15 January 2013 11:34, Alexander Bluhm alexander.bl...@gmx.net 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
Yes this looks good, ok nicm
On Tue, Jan 15, 2013 at 04:54:49AM -0700, David Coppa wrote:
From: Stuart Henderson st...@openbsd.org
Date: Tue, Jan 15, 2013 at 11:30 AM
Subject: Re: terminfo entries for rxvt-unicode
To: Nicholas Marriott nicholas.marri...@gmail.com
Cc:
base64 encoded Mime section invalid - length (0) was wrong.
On Mon, Jan 14, 2013 at 10:10:55PM +1100, Darren Tucker wrote:
On my ALIX, it increase the IP routing throughput from 80Mbit/s to
85Mbit/s while reducing the interrupt CPU usage from 99% to 80%.
It turns out that due to an error on my part, most of this improvment
was due to one of the test
Hi all.
Right now, vr_start() pokes the chip to start transmitting if
vr_cdata.vr_tx_cnt isn't zero. That's the number of used descriptors in
the TX ring, not the number of packets we just added, so we're
needlessly telling the chip to start transmitting in cases where it
already knows.
This
On Mon, Jan 14, 2013 at 02:42:54PM +1100, Darren Tucker wrote:
Resurrecting this, I've now fixed the problem I introduced when I merged
in your changes and have tested it.
Updated diff now incorporating feedback from brad jsing mikeb and
probably others. Having corrected for the mistake of
2013/1/16 Claudio Jeker cje...@diehard.n-r-g.com:
Here is a diff to support the newer Broadcom chips seen in Dell and HP
servers. This was tested against a BCM57765, BCM5721, and BCM5720.
This needs a lot of testing on ANY bge(4). The diff will most probably
only apply to a very current
11 matches
Mail list logo