On Fri, Nov 11, 2011 at 03:04:28PM +0800, Michael W. Bombardieri wrote:
Sorry, let me try that again... Forgot to clean up file descriptor ifd.
AFAIK, this works without this diff. What problem are you trying to solve?
-Otto
Index: inp.c
On Fri, Nov 11, 2011 at 10:20:19AM +0100, Otto Moerbeek wrote:
On Fri, Nov 11, 2011 at 03:04:28PM +0800, Michael W. Bombardieri wrote:
Sorry, let me try that again... Forgot to clean up file descriptor ifd.
AFAIK, this works without this diff. What problem are you trying to solve?
Some
I have no clue what is wrong here. maybe just the '0' before 'ab3' got
lost?
% sudo smtpd -vd
startup [debug mode]
parent_send_config: configuring smtp
parent_send_config_client_certs: configuring smtp
parent_send_config_ruleset: reloading rules and maps
parent_send_config_ruleset: reloading
Mh,
Did you update OpenSMTPD while your queue was not empty ?
You should just rename the directories by removing the prepended 0, it
should fix your issue.
Gilles
On Fri, Nov 11, 2011 at 04:30:52PM +0100, Christopher Zimmermann wrote:
I have no clue what is wrong here. maybe just the '0'
On an unrelated note, I am almost done with a qwalk rewrite that makes it
more tolerant to errors amongst other things
Gilles
On Fri, Nov 11, 2011 at 04:40:26PM +0100, Gilles Chehade wrote:
Mh,
Did you update OpenSMTPD while your queue was not empty ?
You should just rename the
relayd doesn't verify a config file before it tries to load it, unlike many
of the other daemons (for instance, bgpd). This leads to all of the relays,
etc., being dropped if you forget to manually check the file with 'relayd
-n' before issuing a reload request. It looks to be a trivial change
I don't see any reason to even open the file if the size is 0.
On Fri, Nov 11, 2011, Michael W. Bombardieri wrote:
Sorry, let me try that again... Forgot to clean up file descriptor ifd.
Index: inp.c
===
RCS file:
Is there a reason MAXPHYS (currently = 64 * 1024) should not be raised,
at least on i386/amd64?
It appears that 64K transfers on a 120 MB/sec disk incurs about
1800 interrupts/second. The limit seems low for a modern system
and the interrupt rate is high.
Does anyone see bad consequences from
Increasing MAXPHYS to 256K shows a few places where it's assumed that
there are 16 pages in MAXPHYS.
In dev/ic/ahci.c I had to make this change @307 to make the
scatter-gather table large enough - 1 entry per page + extra
because that's what the previous code had and didn't say why.
I could
its generally hard for the cpu to slow a disk down...
On 12/11/2011, at 8:36 AM, Geoff Steckel wrote:
Increasing MAXPHYS to 256K shows a few places where it's assumed that
there are 16 pages in MAXPHYS.
In dev/ic/ahci.c I had to make this change @307 to make the
scatter-gather table large
10 matches
Mail list logo