Hi again,
bz and I have done a bit of sleuthing. There's a few problems!
Firstly - bridge_pfil() in sys/net/if_bridge.c calls a couple of
functions to check the validity and alignment of ipv4/ipv6 packets
(ie, bridge_ip_checkbasic() and bridge_ip6_checkbasic().) But
bridge_ip6_checkbasic() is onl
That fix on ixgbe would also be great to commit on ixgbe before release.
This fix a crash on high packet load with bpf (mbuf freed behind bpf analysis).
Fabien
patch-ixgbe-bpfcrash
Description: Binary data
>
> On 17.11.2010 23:39, Jack Vogel wrote:
>> Yes, everyone, I plan on updating all the
I just recently re-jigged my main server/workstation so that instead
of just having a single interface that talks to the Internet via a
single static IP, it now has, in addition to that, one other interface
(and card) that's talking to one of those little black&blue Linksys
router thingies to whic
I have been attempting to implment a trivial sort of TFTP client from
scratch, and its been somewhat of a humbling experience so far, and
its taught me that I don't know quite as much about BSD socket programming
as I though I did.
So anyway, maybe some kind soul here would be willing to help me
On 11/23/10 06:53, Ronald F. Guilmette wrote:
I just recently re-jigged my main server/workstation so that instead
of just having a single interface that talks to the Internet via a
single static IP, it now has, in addition to that, one other interface
(and card) that's talking to one of those li
In message <4cebad46.2070...@acm.poly.edu>,
Boris Kochergin wrote:
>Hi. I hypothesize that ntpd is started before your rc.local script is
>run, so it uses the NAT IP and default route. Take a look at the
>dhclient.conf man page for how to ignore certain DHCP-provided
>information for an inte
It looks like I'm unfortunate enough to have to deploy on a machine
which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
apparently has hardware issues, according to this thread:
http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449
One
On 11/23/2010 7:47 AM, Ivan Voras wrote:
> It looks like I'm unfortunate enough to have to deploy on a machine
> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
> apparently has hardware issues, according to this thread:
>
> http://sourceforge.net/tracker/index.php?func=de
On 11/23/10 14:03, Mike Tancsa wrote:
On 11/23/2010 7:47 AM, Ivan Voras wrote:
It looks like I'm unfortunate enough to have to deploy on a machine
which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
apparently has hardware issues, according to this thread:
http://sourceforg
On Tue, Nov 23, 2010 at 04:35:42AM -0800, Ronald F. Guilmette wrote:
> I should say however that even this is going to produce a slightly sub-optimal
> result, because (I guess) the DHCP client is _still_ going to wipe out my
> eisting /etc/resolve.con file and then write its own. Now that will at
On Tue, Nov 23, 2010 at 04:12:49AM -0800, Ronald F. Guilmette wrote:
> I have been attempting to implment a trivial sort of TFTP client from
> scratch, and its been somewhat of a humbling experience so far, and
> its taught me that I don't know quite as much about BSD socket programming
> as I thou
On 23-11-2010 13:47, Ivan Voras wrote:
> It looks like I'm unfortunate enough to have to deploy on a machine
> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
> apparently has hardware issues, according to this thread:
I have a Supermicro X7SPE-HF board with two onboard
On 11/23/2010 8:16 AM, Ivan Voras wrote:
> On 11/23/10 14:03, Mike Tancsa wrote:
>> On 11/23/2010 7:47 AM, Ivan Voras wrote:
>>> It looks like I'm unfortunate enough to have to deploy on a machine
>>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
>>> apparently has hardwa
On Tue, Nov 23, 2010 at 12:35 PM, Ronald F. Guilmette
wrote:
>
> Now that will at
> least have the proper IP address in it _however_ there does not seem to
> be any way to entice the DHCP client to place certain "options" into the
> /etc/resolv.conf file. That's a pity, because I wanted one
On Tue, Nov 23, 2010 at 02:16:35PM +0100, Ivan Voras wrote:
> On 11/23/10 14:03, Mike Tancsa wrote:
> >On 11/23/2010 7:47 AM, Ivan Voras wrote:
> >>It looks like I'm unfortunate enough to have to deploy on a machine
> >>which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
> >>ap
On Tue, Nov 23, 2010 at 02:30:56PM +0800, Adrian Chadd wrote:
> Hi everyone (and Luigi especially!)
>
> I've found that enabling ipfw for bridge interfaces panics my MIPS
> boards. A bit of digging shows that the payload mbuf isn't aligned as
> passed into ipfw_chk(), and this is causing aligned a
Ronald F. Guilmette wrote:
>
> I just recently re-jigged my main server/workstation so that instead
> of just having a single interface that talks to the Internet via a
> single static IP, it now has, in addition to that, one other interface
> (and card) that's talking to one of those little blac
Yes, code freeze starts Saturday, there have been issues with igb in HEAD
which is why I did not just want to MFC it. I have a driver that now has
been
surviving long term stress (48+ hours of pounding) so I think its what we
should go with, its coming to HEAD today and then PRERELEASE barring
any
On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote:
> It looks like I'm unfortunate enough to have to deploy on a machine
> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
> apparently has hardware issues, according to this thread:
>
> http://sourceforge.net/tracker/ind
Those are 82576, not 82574, totally different hardware. Would you please
test the
new driver that will be going into HEAD today, I'd like to see testing on it
as much
as possible for a few days.
Cheers,
Jack
On Tue, Nov 23, 2010 at 9:39 AM, Sean Bruno wrote:
> On Tue, 2010-11-23 at 04:47 -080
On 11/23/2010 12:39 PM, Sean Bruno wrote:
> On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote:
>> It looks like I'm unfortunate enough to have to deploy on a machine
>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
> i...@pci0:5:0:0:class=0x02 card=0x89751
82574 is supposed to be em, not igb :) Its always had this kind of
'in-between'
status, it was targeted as a 'client' or consumer part, but it has MSIX
which
make it almost like 8257[56].
Mike, there are some further 82574 changes to shared code that I'm looking
into today.
Jack
On Tue, Nov 23
On 23 November 2010 18:39, Sean Bruno wrote:
> On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote:
>> It looks like I'm unfortunate enough to have to deploy on a machine
>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
>> apparently has hardware issues, according to thi
Just a "me too" to echo Gabor's request for guidance for checking out
and using new drivers from HEAD.
In my case I'd like to try the new em(4) Jack's been talking about.
I've been running FreeBSD machines for several years, but this is the
first time I've found myself having driver problems
On
please check the netmasks everywhere on the router, on the machine
and on other local machines.
well... "the router" is a actually out of my reach. it's a fios set
up. the netmask for all the machines is 255.255.255.0 so the actual
router is somewhere in the building. i guess. we just got
In message <20101123133820.ga36...@babolo.ru>,
Aleksandr A Babaylov <@babolo.ru> wrote:
>On Tue, Nov 23, 2010 at 04:35:42AM -0800, Ronald F. Guilmette wrote:
>> I should say however that even this is going to produce a slightly sub-optim
>al
>> result, because (I guess) the DHCP client is _s
In message <20101123134254.gb36...@babolo.ru>,
Aleksandr A Babaylov <@babolo.ru> wrote:
>rfg:
>> My guess is that I'm doing multiple things in a substantially Wrong way.
>>
>> Any guidance would be appreciated.
>Try
>ktrace -i tftp
>and look at
>kdump
>to see how it works
Hay! Thanks for
In message <20101123155323.ga51...@laptop.levsha.me>,
Mykola Dzham wrote:
> Ronald F. Guilmette wrote:
>> This is problematic for several reasons. First, as I have learned,
>> having any interface set to "DHCP" in the /etc/rc.conf file causes
>> all sorts of DHCP magic to happen at startup tim
In message ,
Freddie Cash wrote:
>On Tue, Nov 23, 2010 at 12:52 PM, Ronald F. Guilmette
> wrote:
>> I don't want the DHCP stuff to set -no- routes at all... I still do
>> want it to create a route to 192.168.1.0/24. =C2=A0I just don't want it
>> make any change to the default route that would
Ronald F. Guilmette wrote:
>
> In message <20101123155323.ga51...@laptop.levsha.me>,
> Mykola Dzham wrote:
>
> > Ronald F. Guilmette wrote:
> >> This is problematic for several reasons. First, as I have learned,
> >> having any interface set to "DHCP" in the /etc/rc.conf file causes
> >> all
On Tue, Nov 23, 2010 at 12:52 PM, Ronald F. Guilmette
wrote:
> I don't want the DHCP stuff to set -no- routes at all... I still do
> want it to create a route to 192.168.1.0/24. I just don't want it
> make any change to the default route that would otherwise be set,
> you know, as a result of the
While hacking dhclient-script gets you '1337 points, it's generally a
better idea to use dhclient.conf to accomplish the same goals whenever
possible. It's also a really bad idea to chflags /etc/resolv.conf (note,
it's resolv.conf, not resolve.conf) because that can cause
dhclient-script to loo
32 matches
Mail list logo
