On Wed, 2009-03-18 at 11:52 +, Robert Watson wrote:
> On Sun, 15 Mar 2009, Nick Withers wrote:
>
> >> I'll need to think a bit about a proper fix for this, but you'll find the
> >> problem likely goes away if you eliminate all uid/gid/jail rules from your
> >> firewall. You could also tweak
On Sun, 15 Mar 2009, Nick Withers wrote:
I'll need to think a bit about a proper fix for this, but you'll find the
problem likely goes away if you eliminate all uid/gid/jail rules from your
firewall. You could also tweak the syncache logic not to use a retransmit
timer, which might slightly
On Sat, 2009-03-14 at 18:01 +, Robert Watson wrote:
> On Sat, 14 Mar 2009, Nick Withers wrote:
>
> > Right, here we go!
> ...
>
> Turns out that the problem is a lock cycle triggered by the syncache calling,
> indirectly, the firewall during output, and the firewall trying to look up
> the
On Sat, 14 Mar 2009, Nick Withers wrote:
Right, here we go!
...
Turns out that the problem is a lock cycle triggered by the syncache calling,
indirectly, the firewall during output, and the firewall trying to look up the
connection for the packet. Thread one:
Tracing PID 31 tid 100030 t
On Fri, 2009-03-13 at 09:49 +, Robert Watson wrote:
> On Fri, 13 Mar 2009, Robert Watson wrote:
>
> > Sounds like a lock leak -- if you're running INVARIANTS, then "show allocks"
> should read WITNESS
> > and "show allchains" would be usef
On Fri, 13 Mar 2009 20:56:24 +1100 Nick Withers wrote:
> I'm sorry to ask what is probably a very simple question, but is there
> somewhere I should look to get clues on debugging from a manually
> generated dump? I tried "panic" after manually envoking the kernel
> debugger but proved highly inep
On Fri, 13 Mar 2009, Nick Withers wrote:
Sorry for the original double-post, by the way, not quite sure how that
happened...
I can reproduce this problem relatively easily, by the way (every 3 days, on
average). I meant to say this before, too, but it seems to happen a lot more
often on the
On Fri, 2009-03-13 at 09:37 +, Robert Watson wrote:
> On Fri, 13 Mar 2009, Nick Withers wrote:
>
> > I recently installed my first amd64 system (currently running RELENG_7 from
> > 2009-03-11) to replace an aged ppc box and have been having dramas with the
> > network locking up.
> >
> > Bre
On Fri, 13 Mar 2009, Robert Watson wrote:
Sounds like a lock leak -- if you're running INVARIANTS, then "show allocks"
should read WITNESS
and "show allchains" would be useful. I've had a report of a TCP lock leak
possibly in tcp_input(),
On Fri, 13 Mar 2009, Nick Withers wrote:
I recently installed my first amd64 system (currently running RELENG_7 from
2009-03-11) to replace an aged ppc box and have been having dramas with the
network locking up.
Breaking into the debugger manually and ps-ing shows the network card (e.g.,
"
Hello all,
I recently installed my first amd64 system (currently running RELENG_7
from 2009-03-11) to replace an aged ppc box and have been having dramas
with the network locking up.
Breaking into the debugger manually and ps-ing shows the network card
(e.g., "[irq20: fxp0+]") in state "LL" in "
11 matches
Mail list logo
