On Oct 4, 2005, at 6:56 PM, Dave+Seddon wrote:
You mention your running at "near" line rate. What are you pushing
or pulling? Whats the rough spec of these machines pushing out
this much data? What setting do you have for the polling? I've
been trying to do near line rate and can't eve
From: Petri Helenius [mailto:[EMAIL PROTECTED]
>
> Darren Pilgrim wrote:
>
>> I'd be interested in finding out the specific chips with which people are
>> (not) having success. As em(4) supports an entire family of products,
>> rather than a single chip, it may be that some chips have quirks or
Darren Pilgrim wrote:
I'd be interested in finding out the specific chips with which people are
(not) having success. As em(4) supports an entire family of products,
rather than a single chip, it may be that some chips have quirks or other
gotchas the driver needs to address. It certainly woul
Under 5.4 this revision of the em card doesn't work: 82546EB
[EMAIL PROTECTED]:1:0: class=0x02 card=0x00db0e11 chip=0x10108086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)'
class= networ
[Reflowed]
From: Benjamin Rosenblum
> Darren Pilgrim wrote:
>>
>> I'd be interested in finding out the specific chips with which people
>> are (not) having success. As em(4) supports an entire family of
>> products, rather than a single chip, it may be that some chips have
>> quirks or other gotc
Benjamin Rosenblum wrote:
> my non working card is 82547EI aka 1000CT.
>
> Darren Pilgrim wrote:
>
>> From: Chuck Swiger
>>
>>
>>> People who have em NICs, and who do not have problems, probably do not
>>> report regularly that their Intel 10/100/1000 NIC works fine, even
>>> though it does,
my non working card is 82547EI aka 1000CT.
Darren Pilgrim wrote:
From: Chuck Swiger
People who have em NICs, and who do not have problems, probably do not
report regularly that their Intel 10/100/1000 NIC works fine, even
though it does, at least for them. I've got a dozen or so machines
w
From: Chuck Swiger
>
> People who have em NICs, and who do not have problems, probably do not
> report regularly that their Intel 10/100/1000 NIC works fine, even
> though it does, at least for them. I've got a dozen or so machines
> with that hardware, and I haven't seen any problems with them.
Jeremie,
Sorry for "top posting". My time machine is broken :)
Kevin,
You mention your running at "near" line rate. What are you pushing or
pulling? Whats the rough spec of these machines pushing out this much data?
What setting do you have for the polling? I've been trying to do near lin
Ragnar Lonn wrote this message on Tue, Oct 04, 2005 at 18:58 +0200:
> Ceri Davies wrote:
>
> >I only call it "wrong" as it didn't agree with Archie's article or my
> >expectations, hence the quotes - I realise that it's subjective.
> >
> >It just seems to me that packets leaving left2right would g
Pertti Kosunen wrote:
What should i do to avoid these messages from MRTG and dhclient? This
happens with some network load on xl0 interface and pf+altq or
ipfw+dummynet+statefull rules enabled, even with simple pass rules.
Increasing kern.ipc.nmbclusters, kern.ipc.nsfbufs, kern.ipc.somaxconn
Ceri Davies wrote:
I only call it "wrong" as it didn't agree with Archie's article or my
expectations, hence the quotes - I realise that it's subjective.
It just seems to me that packets leaving left2right would go to right,
as the name implies. I don't really mind either way, it's simply that
Hi Benjamin, Ferdinant,
(Please avoid top-posting, this reverts the flow of the conversation
and make the whole thread difficult to follow.)
> i have been messing with the em driver now for over a month, ive come to
> the conclusion is a piece of crap. if you watch on this list every
> other d
yea i have been messing with the driver for about a month now to try to
atleast target where the failure is, ive probably put about 25-30 hours
in now modifying the code and recompiling and testing it. best i have
gotten is to figure out its a problem with the cache becoming full and
not sendi
Benjamin Rosenblum wrote:
i have been messing with the em driver now for over a month, ive come to
the conclusion is a piece of crap. if you watch on this list every
other day you have someone saying there em driver is causing some sort
of error, this should not be on a nic from a company like
i have been messing with the em driver now for over a month, ive come to
the conclusion is a piece of crap. if you watch on this list every
other day you have someone saying there em driver is causing some sort
of error, this should not be on a nic from a company like intel. im
saddly contimp
Kevin Day wrote:
This is pretty odd. We've got dozens of servers using various versions
of 5.x, and many different em cards, and have no problem, even when
shoving near line rate speeds out of them.
Maximum transfer rates we see in MRTG were around 320Mbit/s (with polling
disabled)
em0: po
On Tue, 4 Oct 2005 16:37:21 +0400
Andrey Smagin <[EMAIL PROTECTED]> wrote:
> Hello Marcin,
>
> Tuesday, October 4, 2005, 11:35:17 AM, you wrote:
>
>
> MJ> How are you bridging the interfaces? What kind of bridging
> MJ> mechanism are you using?
>
> In FreeBSD:
> kldload ath, ath_hal, bridge
On Oct 4, 2005, at 7:00 AM, Ferdinand Goldmann wrote:
Ok, to followup on this issue:
Today I installed the driver which I had downloaded from the Intel
website (em-3.2.15.tar.gz). This driver does not solve the issue
with Ierrs rising rapidly when polling is enabled (I tried HZ=1000
and
Hello Marcin,
Tuesday, October 4, 2005, 11:35:17 AM, you wrote:
MJ> How are you bridging the interfaces? What kind of bridging mechanism
MJ> are you using?
In FreeBSD:
kldload ath, ath_hal, bridge, fxp
On both host:
ifconfig_ath0="inet ssid 1234 channel 6 mode 11g mediaopt adhoc"
in sysct
Gleb Smirnoff wrote:
On Mon, Oct 03, 2005 at 02:29:35PM +0200, Ferdinand Goldmann wrote:
F> Gleb Smirnoff wrote:
F>
F> >All I can say: I have faced this problem, too. :( This is not problem in
F> >polling, but in em.
F> >
F>
F> Thank you! Just now I downloaded the driver from the Intel website
On Sun, Sep 25, 2005 at 11:08:25PM +0100, Gavin Atkinson wrote:
>
> There's also the issue that the "vlan" and "vlandev" options have to be
> specified in that order, which is counter-intuitive and undocumented.
I've committed a change to ifconfig(8) that makes the order
arbitrary. Please test i
On Sat, Oct 01, 2005 at 08:48:42PM +0100, Gavin Atkinson wrote:
>
> It seems to me that assigning an IP address to a vlan device (parent
> device bge0) isn't enough to get the interface working - I need to
> manually bring the parent interface up.
Yes you need. The UP flag on an interface is adm
On Tue, 4 Oct 2005 10:25:40 +0400
Andrey Smagin <[EMAIL PROTECTED]> wrote:
> Hello Marcin,
>
> MJ> man ifconfig should be the place to start.
> :) re read it 2 year, for information about
> MJ> Anyway, you can connect two PCs when one of them runs in
> MJ> hostap and the other one in ad-hoc mode
24 matches
Mail list logo
