Hi,
have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso
sysctl)? That fixed performance issues with some em cards for me.
Lars
On 2010-1-25, at 5:47, Nick Rogers wrote:
> I am having similar em interface problems with some of my production
> machines running older intel 2-
Hi,
have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso
sysctl)? That fixed performance issues with some em cards for me.
Lars
On 2010-1-25, at 5:47, Nick Rogers wrote:
> I am having similar em interface problems with some of my production
> machines running older intel 2-
Hi,
On 2010-1-25, at 19:38, Nick Rogers wrote:
>> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon wrote:
>> I'm not sure you're seeing a checksum offload bug of em(4) but the
>> bug is easily reproducible in VLAN environments. If the issue is
>> gone when you disable TX checksum offloading, see
On 2009-4-7, at 14:21, Julian Stacey wrote:
Perhaps some SOC student might like to develop some extension to
fetch, or a new tool to intelligently save net bandwidth & human
time (if not this year if SOC bids are in, then next) :
Intelligently & automatically sniff fetch list to see where
On 2009-4-7, at 15:59, Andrei Kolu wrote:
What about this:
# cd /usr/ports/sysutils/fastest_cvsup && make install clean && rehash
# fastest_cvsup -c us,ee,ru,eu,uk,de,no,se
RTT != throughput, and not all files are available via cvsup
Lars
On 2009-4-7, at 17:55, Kevin Oberman wrote:
Use BitTorrent for all file distribution, it does all that. Yes, I'm
half serious.
Why only half? I have pulled FreeBSD ISOs via torrent and it was
stunning to see the performance.
Half, because getting a BitTorrent infrastructure in place for the
Hi,
I'm doing encrypted nightly dumps over the network to an NFS file
system, i.e., dump | bzip2 | bdes > nfs.
Since about a week ago, I see occasional errors from bdes ("bdes:
fwrite error at 8"). Anyone have a hunch what's going on here? I'm
wondering if this is something that started w
On 2009-4-8, at 17:46, Dan Nelson wrote:
bdes -k asd < /boot/kernel/kernel | dd of=/dev/null count=1
# bdes -k asd < /boot/kernel/kernel | dd of=/dev/null count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000860 secs (595366 bytes/sec)
bdes: fwrite error at 8: Broken pipe
Lars
Hi,
I've been seeing similar issues ("IP bad-len 0" packets in tcpdump
traces") since 7.2-STABLE and em interfaces. Turning off TSO seems to
do the trick here, too. So at least from where I'm sitting, this is
not only an fxp problem.
Lars
Hi,
On 2009-5-14, at 11:27, Pyun YongHyeon wrote:
Then you're seeing different problem on em(4). Last time I checked
em(4) TSO code in em(4) didn't use m_pullup and just returned
ENXIO to caller. I'm not sure that is related with your issue but
would you tell us your network configuration?
thi
In my case, it's a
e...@pci0:12:0:0: class=0x02 card=0x135e8086 chip=0x105e8086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'PRO/1000 PT'
class = network
subclass = ethernet
Lars
On 2009-5-14, at 11:46, Lev Serebryakov wrote:
Hello, Lars.
You w
Hi,
just a quick update: I still need to run with TSO off on RELENG_7
build Sep 1, because otherwise throughput via em interfaces is
sometimes very poor.
Lars
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Lars Eggert writes:
> : We're getting very bad TCP throughput from a Linksys PCMPC100 card. I'm
> : wondering if anybody can confirm this or has seen a similar problem with
> : the Linksys card. It looks lik
2000 when
> > I installed FreeBSD 4.0 until now.
> >
> > If you need more specific information tell me how to get it
> > and I will (maybe some sort of kernel log or something). I'm stumped.
> >
> > --
> > Sincerely,
> > Caleb Land
> > ([EM
rintf("%s%d: %u/%u/%u bytes tx/rx/total card memory\n",
+ ifp->if_name, ifp->if_unit,
+ sc->txb_cnt * ED_PAGE_SIZE * ED_TXBUF_SIZE,
+ (sc->rec_page_stop - sc->rec_page_start) * ED_PAGE_SIZE,
+ sc->mem_size);
+#endi
card memory.
Thanks,
Lars
--
Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
http://www.isi.edu/larse/University of Southern California
S/MIME Cryptographic Signature
ith both CPUs turned on. I'm trying to figure out which entry in my config
file breaks things; I'll post when I have it.
Lars
--
Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
http://www.isi.edu/larse/University of Southern California
S/MIME Cryptographic Signature
28.9.112.174 netmask 0xf000 broadcast 128.9.127.255
ether 00:03:47:07:e8:10
media: 1000baseSX (autoselect ) status:
active
supported media: 1000baseSX 1000baseSX
Please let me know how I can help to track this down!
Lars
--
Lars Eggert <[EMAIL PROTECTED]>
Lars Eggert wrote:
> The Intel PRO/1000F NIC does not seem to be fully supported by the wx
> driver.
Sorry for not mentioning this in the original post: This card uses the
Intel 82543GC chip.
--
Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
http:/
ing spurious signal 11's with
apm on SMP machines several years ago, and the mailing list consensus
back then was "apm is not for SMP".
So either it's something else, or my BIOS is lacking an option.
Lars
--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
ing messed up again.
Lars
____
Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
http://www.isi.edu/~larse/ University of Southern California
To Unsubscribe: send mail to [EMAIL
me for 4.1.
Thanks,
Lars
PS: There's also the KAME kernel option MAX_GIF_NEST that should probably
go into the "undocumented" section of LINT.
--
Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
http://www.isi.edu/larse/University of
Kent Stewart wrote:
> I just finish cvsup'ing and have completed a buildworld and
> buildkernel without any problems. Did you cvsup'ed such that you have
> the crypto files since they are part of src-all now days.
Of course this was the problem. Thanks, Kent!
--
Lars Egger
800-0xe8ff mem
0xfaffe000-0xfaffefff irq 11 at device 10.1 on pci3
ahc1: aic7899 Wide Channel B, SCSI Id=7, 16/255 SCBs
csa0: mem 0xfae0-0xfaef,0xfaffe000-0xfaffefff irq 5 at
device 6.0 on pci2
pcm0: on csa0
--
Lars Eggert <[EMAIL PROTECTED]> Info
pts to
> do the chown before it has access to any user/group information.
We have a similar problem with the combination of NIS and ipfw. The details
(and a patch) are in conf/18521:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18521 - nobody has touched it
since its submission in May.
--
Lars
25 matches
Mail list logo
