Not sure if this is the correct list, but I am working as part of
a kernel team that is using FreeBSD 8.0 for it's base OS.
We have had a ongoing issue with our bootloader (u-boot) with it
being unable to tftp from the tftp server running on our FreeBSD
server. We traced the issue down to the tf
Luigi Rizzo wrote:
On Wed, Dec 30, 2009 at 03:55:07PM -0800, Julian Elischer wrote:
Luigi Rizzo wrote:
...
Which is what happens now, right? Same behaviour on tee reinjection as
divert does seem consistent. So if there is a problem, it's only with
the original packet continuing with the nex
On Wed, Dec 30, 2009 at 03:55:07PM -0800, Julian Elischer wrote:
> Luigi Rizzo wrote:
...
> >>>Which is what happens now, right? Same behaviour on tee reinjection as
> >>>divert does seem consistent. So if there is a problem, it's only with
> >>>the original packet continuing with the next rule
Luigi Rizzo wrote:
On Wed, Dec 30, 2009 at 01:30:01PM -0800, Julian Elischer wrote:
Ian Smith wrote:
On Tue, 29 Dec 2009, Julian Elischer wrote:
Luigi Rizzo wrote:
There a difference between the documented and actual behaviour of
"ipfw tee" which occurs when there are multiple rules with the
On Wed, Dec 30, 2009 at 01:30:01PM -0800, Julian Elischer wrote:
> Ian Smith wrote:
> >On Tue, 29 Dec 2009, Julian Elischer wrote:
> > > Luigi Rizzo wrote:
> > > > There a difference between the documented and actual behaviour of
> > > > "ipfw tee" which occurs when there are multiple rules with th
On Thu, Dec 24, 2009 at 10:25:46PM +0100, Lhunath (Maarten B.) wrote:
> >> e1000phy0: PHY 0 on miibus0
> >> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> >> 1000baseT-FDX, auto
> >
> > I guess you hit known msk(4) issue for 88E8056/88E1149 PHY. Some
> > users have no p
Ian Smith wrote:
On Tue, 29 Dec 2009, Julian Elischer wrote:
> Luigi Rizzo wrote:
> > There a difference between the documented and actual behaviour of
> > "ipfw tee" which occurs when there are multiple rules with the same
> > number, e.g.
> >
> > rule_id number body
> > r1
issue of em(4).
The issue was not I initially thought though. It seems the checksum
offload context configured in em(4) was incorrectly reused even if
a frame requires a new context as IP/TCP header length, checksum
offload offset was changed. Setting up new context put more burden
to hardware
The following reply was made to PR kern/140796; it has been noted by GNATS.
From: Rui Paulo
To: bug-follo...@freebsd.org,
dalibor.gud...@gmail.com
Cc:
Subject: Re: kern/140796: [ath] [panic] privileged instruction fault
Date: Wed, 30 Dec 2009 15:59:18 +
Are you sure this card works prope
I can reproduce this case.
server1 has nic nfe0
trouble server2 has nic em0 and em1
e...@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel Corporation 82573E Gigabit Ethernet Controller
(Copper) (825
On Tue, 29 Dec 2009, Julian Elischer wrote:
> Luigi Rizzo wrote:
> > There a difference between the documented and actual behaviour of
> > "ipfw tee" which occurs when there are multiple rules with the same
> > number, e.g.
> >
> >rule_id number body
> >r1 500 tee port1 ds
The following reply was made to PR kern/141843; it has been noted by GNATS.
From: Dennis Yusupoff
To: pyu...@gmail.com
Cc: bug-follo...@freebsd.org
Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke
wrong dst MAC in TCP packets
Date: Wed, 30 Dec 2009 13:34:30 +0300
Thi
The following reply was made to PR kern/140796; it has been noted by GNATS.
From: Dalibor Gudzic
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/140796: [ath] [panic] privileged instruction fault
Date: Wed, 30 Dec 2009 09:58:09 +0100
A small followup, I tried the new FreeBSD 8-RELEASE and
The following reply was made to PR kern/142052; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/142052: commit references a PR
Date: Wed, 30 Dec 2009 08:52:27 + (UTC)
Author: syrinx
Date: Wed Dec 30 08:52:13 2009
14 matches
Mail list logo
