On Fri, Mar 14, 2008 at 11:05:01AM +0100, Giulio Ferro wrote:
> Pyun YongHyeon wrote:
> > > The latter is if_rlreg.h, I guess...
> >
> >Oops, yes.
> > >
> > > Anyway they don't compile:
> > >
> >
> >Maybe you don't copy if_rlreg.h to /usr/src/sys/pci directory?
> >
>
> I didn't ;-)
Pyun YongHyeon wrote:
> The latter is if_rlreg.h, I guess...
Oops, yes.
>
> Anyway they don't compile:
>
Maybe you don't copy if_rlreg.h to /usr/src/sys/pci directory?
I didn't ;-)
Ok, I compiled and installed it.
The behavior didn't change: the simple ping works all right, but wh
did before, per POLA.
Ok, I am only printing it in case bad padding happens or one gave -v.
The new patch is here:
http://sources.zabbadoz.net/freebsd/patchset/20080314-01-tcpdump-print-tcp-option-padding.diff
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
Softwar
Old Synopsis: in kernel alias_irc nat double panic
New Synopsis: [nat] [panic] in kernel alias_irc nat double panic
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Mar 14 11:18:51 UTC 2008
Responsible-Changed-Why:
Over to mainta
Synopsis: [nat] [panic] in kernel alias_irc nat double panic
Responsible-Changed-From-To: freebsd-net->[EMAIL PROTECTED]
Responsible-Changed-By: piso
Responsible-Changed-When: Fri Mar 14 11:40:28 UTC 2008
Responsible-Changed-Why:
Assign it to me.
http://www.freebsd.org/cgi/query-pr.cgi?pr=12169
Hi!
The issue seems to be reprodusable on 7.0 - see kern/121693.
--
WBR, Vadim Goncharov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Pyun YongHyeon wrote:
> No packet reached the other PC.
Ok, then try disabling hardware VLAN tagging.
(#ifconfig re0 -vlanhwtag)
That's it!
Now seems to work properly, the problem then is with hardware tagging.
My question now is: can I use vlans without htag in a complex system with
heav
The following reply was made to PR kern/121693; it has been noted by GNATS.
From: Vadim Goncharov <[EMAIL PROTECTED]>
To: Gael Roualland <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: kern/121693: in kernel alias_irc nat double panic
Date: Fri, 14 Mar 2008 17:02:47 +0600
Hi Gael Rouallan
The following reply was made to PR kern/121693; it has been noted by GNATS.
From: Vadim Goncharov <[EMAIL PROTECTED]>
To: Gael Roualland <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: kern/121693: in kernel alias_irc nat double panic
Date: Fri, 14 Mar 2008 17:06:39 +0600
Giulio Ferro wrote:
That's it!
Now seems to work properly, the problem then is with hardware tagging.
My question now is: can I use vlans without htag in a complex system with
heavy traffic without a significant performance loss? If not, how much
will it
take to fix the issue with the driver?
On Fri, Mar 14, 2008 at 12:57:34PM +0100, Giulio Ferro wrote:
> Pyun YongHyeon wrote:
> > > No packet reached the other PC.
> >
> >Ok, then try disabling hardware VLAN tagging.
> >(#ifconfig re0 -vlanhwtag)
> >
> >
> That's it!
> Now seems to work properly, the problem then is with hardw
On Fri, Mar 14, 2008 at 01:14:40PM +0100, Giulio Ferro wrote:
> Giulio Ferro wrote:
> >That's it!
> >Now seems to work properly, the problem then is with hardware tagging.
> >
> >My question now is: can I use vlans without htag in a complex system with
> >heavy traffic without a significant p
Benjamin Close wrote:
Sam Leffler wrote:
Yousif Hassan wrote:
On Wed, 2008-03-12 at 08:06 +1030, Benjamin Close wrote:
The slightly wonky:
- As reported by someone else:
wpi0: timeout resetting Tx ring 1
wpi0: timeout resetting Tx ring 3
wpi0: timeout resetting Tx ring 4
appear on st
Pyun YongHyeon wrote:
This hardware really make me crazy. There had been many attempts to
fix checksum offload related issues. But it seems that several users
still suffer from bad checksum or VLAN issues. So I guess the root
cause of hardware bug was not yet known. This means that previous
patch
Hello,
I've been debugging some scripts for the better part of the hour, and
finally figured out what's going on.
On 6.2, `ipfw table 3 list' outputs:
169.229.127.61/32 100127061
But on 7.0, `ipfw table 4 list' outputs:
10.9.156.254/32 11.237.178.84
They're different tables with different value
The same change was made in net/route.c rev 1.120.2.3.
I don't know if all calls to rtfree(rt) should be converted to
RTFREE_LOCKED(rt), but those remaining are in:
net/route.c:367
net/route.c:399
netinet/if_ether.c:808
netinet/if_ether.c:813
netinet/if_ether.c:831
netinet/if_ether.c:834
netine
Hello,
I am having difficulty setting up a SLIP connection between a Debian 4.0 box
and FreeBSD 7.0-STABLE. I have enabled the sl driver in the kernel. I have
tried using slattach on /dev/cuad0 (usually "slattach -s 115200 /dev/cuad0)
only to watch slattach immediately die with no output as to
Kai Lockwood wrote:
Hello,
I am having difficulty setting up a SLIP connection between a Debian 4.0 box
and FreeBSD 7.0-STABLE. I have enabled the sl driver in the kernel. I have
tried using slattach on /dev/cuad0 (usually "slattach -s 115200 /dev/cuad0)
only to watch slattach immediately die
Christopher Cowart wrote:
Hello,
I've been debugging some scripts for the better part of the hour, and
finally figured out what's going on.
On 6.2, `ipfw table 3 list' outputs:
169.229.127.61/32 100127061
But on 7.0, `ipfw table 4 list' outputs:
10.9.156.254/32 11.237.178.84
They're different
19 matches
Mail list logo
