Okay, I read through your core file and I think I see the problem now.
Let me try to get you a patch later tonight.
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org on behalf of Doug Barton
Sent: Tue 2/23/2010 12:38 PM
To: freebsd-net@freebsd.org
Subject: Apparent IPv6 bu
Hi,
Looks like I may have tracked down this problem.
I noticed that fastforwarding ( net.inet.ip.fastforwarding=1 ) was
turned on. I turned it off to see if that was causing the problem.
Sure enough, 5 hours later and no watchdog timeouts. This is still
running on FreeBSD 7.1 (I'm sti
On Tue, 23 Feb 2010, Bjoern A. Zeeb wrote:
On Tue, 23 Feb 2010, Doug Barton wrote:
Howdy,
I've had the following crash twice now when leaving my system up overnight:
Could it be that some interface goes and comes over night?
A tunnel or some such?
If that's the case you may want to try:
On Tue, 23 Feb 2010, Doug Barton wrote:
Howdy,
I've had the following crash twice now when leaving my system up overnight:
Could it be that some interface goes and comes over night?
A tunnel or some such?
If that's the case you may want to try:
http://people.freebsd.org/~bz/20100215-10-sys
On 24/02/2010 6:02 AM, Patrick Mahan wrote:
[12]
http://caia.swin.edu.au/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch
[13] http://caia.swin.edu.au/newtcp/tools/modularcc-readme-0.9.4.txt
I believe these are incorrect. I find these documents at the following URLs:
[12]
http://caia.
Howdy,
I've had the following crash twice now when leaving my system up overnight:
(kgdb) #0 doadump () at pcpu.h:246
#1 0xc05f64af in boot (howto=260)
at /usr/local/src/sys/kern/kern_shutdown.c:416
#2 0xc05f6792 in panic (fmt=Variable "fmt" is not available.
) at /usr/local/src/sys/kern/k
>
>[12]
>http://caia.swin.edu.au/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch
>
>[13] http://caia.swin.edu.au/newtcp/tools/modularcc-readme-0.9.4.txt
>
I believe these are incorrect. I find these documents at the following URLs:
[12]
http://caia.swin.edu.au/urp/newtcp/tools/caia_modul
> From: owner-freebsd-...@freebsd.org
>
> Jack Vogel wrote on 2010-02-22 20:13:
>
> > 7.2 seems to be a stable base OS and driver, 8 is better in
> some respects,
> > but
> > has not been without its reported problems. I leave the
> choice to you.
>
> Let me sneak into this thread as I am
The driver is static right now. I have another Dell 2950 for backup so
I'm going to split the mirror on the production server and put one of
the drives into the development server. Then I can do the upgrade to 7.2
and test. I don't think I will be able to get a window to switch out
the production
On Tue, 23 Feb 2010, VANHULLEBUS Yvan wrote:
Hi,
On Tue, Feb 23, 2010 at 03:49:42PM +0300, Denis Antrushin wrote:
On 02/23/10 15:21, VANHULLEBUS Yvan wrote:
[]
Taking into account this quote:
On 02/11/10 15:55, Bjoern A. Zeeb wrote:
Him saying it works on linux - has ipsec-tools grown
On Tue, Feb 23, 2010 at 03:49:42PM +0300, Denis Antrushin wrote:
> On 02/23/10 15:21, VANHULLEBUS Yvan wrote:
[]
> Taking into account this quote:
>
> On 02/11/10 15:55, Bjoern A. Zeeb wrote:
> > Him saying it works on linux - has ipsec-tools grown proper OA support
> > these days? If that wou
Jack Vogel wrote on 2010-02-22 20:13:
7.2 seems to be a stable base OS and driver, 8 is better in some respects,
but
has not been without its reported problems. I leave the choice to you.
Let me sneak into this thread as I am also suffering from em watchdog
timeouts. In my case there is a 7.2
On 02/23/10 15:21, VANHULLEBUS Yvan wrote:
On Tue, Feb 23, 2010 at 02:10:23PM +0300, Denis Antrushin wrote:
[...]
ipsec-tools understand NAT-OA payload in IKE exchange, but then simply
discard it and do not send this information to kernel.
In ipsec-tool mailing list archives I found mention that
On Tue, Feb 23, 2010 at 02:10:23PM +0300, Denis Antrushin wrote:
[...]
> ipsec-tools understand NAT-OA payload in IKE exchange, but then simply
> discard it and do not send this information to kernel.
> In ipsec-tool mailing list archives I found mention that linux does not
> need this OA info, bec
The problem is not on the AP side, the client sends with MCS32 because it's
the last MCS in ni_htrates array of AP and the connection is good. AMRR
increases the Tx rate to AP till MCS32 and then the client sends with MCS32.
I changed AMRR a bit so it would skip MCS32 and it works fine now. I had t
On 21 Feb 2010, at 10:35, Alexander Egorenkov wrote:
> This MCS32 HT rate causes problems with AMRR. If the connection between a
> client and an AP is very good and the AP supports MCS32, the client keeps
> increasing the Tx rate upto MCS32 and then the problems begin because the
> client starts t
On 20 Feb 2010, at 21:55, Jake Baillie wrote:
> Hello,
>
> I'm having trouble getting an Xbox 360 to connect to my newly upgraded
> FreeBSD based wireless access point. The Xbox 360 can successfully
> locate the AP in a scan, but when trying to connect it simply fails. If
> you've never used an X
On 02/11/10 15:55, Bjoern A. Zeeb wrote:
On Thu, 11 Feb 2010, VANHULLEBUS Yvan wrote:
How can I further debug this problem?
You can check on responder that you have lots of TCP checksums errors,
which will confirm that you would need support for NAT-OA extension of
NAT-T RFC, as you want to d
Hello all,
i was reading ip_output() code today and stumbled accross this
http://fxr.watson.org/fxr/source/netinet/ip_output.c#L587.
Can anybody shad any light on the check being done ?
(m->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 ||
Shouldn't it be just
(m->m_pkthdr.csum_flags & C
19 matches
Mail list logo
