Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Apr 2010 13:53:34 -0700
From:      Jack Vogel <jfvogel@gmail.com>
To:        Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
Cc:        Brandon Gooch <jamesbrandongooch@gmail.com>, freebsd-stable@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com>, John Baldwin <jhb@freebsd.org>
Subject:   Re: em JumboFrame improovement and PCIe addon-card regression [Was: Re: em regression, UDP LOR followed by ssh stall]
Message-ID:  <t2t2a41acea1004161353q7359f877jde1445e07dc59396@mail.gmail.com>
In-Reply-To: <4BC8CB9E.8060802@omnilan.de>
References:  <4BC82B80.3070108@omnilan.de> <20100416092803.GA17526@icarus.home.lan> <4BC82FF7.1030700@omnilan.de> <201004160822.09359.jhb@freebsd.org> <p2i2a41acea1004160829i53efa312k3ebec61cc2d9d251@mail.gmail.com> <u2s179b97fb1004160832u69175c8bi1c5a069cf872ef5b@mail.gmail.com> <4BC8A76A.6000107@omnilan.de> <s2q2a41acea1004161302k9e1261adx45efb4c9b0eebabd@mail.gmail.com> <4BC8CB9E.8060802@omnilan.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Why are you using ZERO_COPY_SOCKETS?  And is this LOR happening on STABLE or
CURRENT?

Jack


On Fri, Apr 16, 2010 at 1:42 PM, Harald Schmalzbauer <
h.schmalzbauer@omnilan.de> wrote:

> Jack Vogel schrieb am 16.04.2010 22:02 (localtime):
>
>  Glad things are better. On the Hartwell, the 0x10D3 adapter, what is the
>> problem you are seeing?
>> I just did an MFC, would ask that you try that code, see if it changes
>> anything.
>>
>
>
> With latest MFCs I see em0: <Intel(R) PRO/1000 Network Connection 7.0.5>
>  but still this LOR:
> login: lock order reversal:
>  1st 0xffffff00015d4418 em0:rx(1) (em0:rx(1)) @
> /usr/src/sys/dev/e1000/if_em.c:1514
>  2nd 0xffffffff8093f108 udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:474
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x49
> witness_checkorder() at witness_checkorder+0x7ea
> _rw_rlock() at _rw_rlock+0x58
> udp_input() at udp_input+0x1cd
> ip_input() at ip_input+0xb3
> netisr_dispatch_src() at netisr_dispatch_src+0x9e
> ether_demux() at ether_demux+0x176
> ether_input() at ether_input+0x176
> em_rxeof() at em_rxeof+0x166
> em_msix_rx() at em_msix_rx+0x42
> intr_event_execute_handlers() at intr_event_execute_handlers+0x67
> ithread_loop() at ithread_loop+0xae
> fork_exit() at fork_exit+0x12a
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff8075504d30, rbp = 0 ---
>
> Is it worth mentioning that I compiled in ZERO_COPY_SOCKETS?
>
> So far I couldn't see any SSH session stall anymore. That was my proplem
> after updating today, before the latest 7.0.0->7.0.5 change.
>
> I'll come back if I can see anything going suboptimal regarding "hartwell"
>
> Also the em1 (PRO/1000 Legacy Network Connection 1.0.1, pciconf device
> 82541EI):
> em1: Watchdog timeout -- resetting
> is solved/gone/vanished :)
>
> Thanks! (why doesn't 'pciconf -lv' show a "device" entry for Hartwell?)
>
>
> But I also have to tell that enabling jumbo frames is a big performance
> degradation with SMB downloads. Uploads completely hang. With RELENG_8, 6
> weeks ago, I could manage to get 75MB/s transfers to my windows SR2600
> servers, MTU9014 and FreeBSD MTU1500, untuned Samba 3.3.10.
>
> Today, after updating RELENG_8 with unchanged samba, jumbo frames enabled
> (mtu 9000 on FreeBSD), downloading via CIFS was half the transfer rate and
> uploading almost completely stalled.
> Will see to track down the "upload" problem. So far, jumbo frames at least
> work with ICMP payloads up to 8972 bytes, but enabling still is a tranfer
> rate regression.
>
> Thanks,
>
> -Harry
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?t2t2a41acea1004161353q7359f877jde1445e07dc59396>