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.schmalzba...@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 > > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
