Date: Tue, 27 Apr 2010 23:54:54 +0200 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-stable@freebsd.org Subject: em WOL_MCAST repowers machine after poweroff [Was: Re: em JumboFrame improovement and PCIe addon-card regression] Message-ID: <4BD75D2E.50302@omnilan.de> 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
On 16.04.2010 22:42, Harald Schmalzbauer 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. Hello Jack, I'd like to report another issue I haven't seen before the RELENG_8 em update: When I 'shutdown -p' the machine, it immediately powers on itself again. After walking the firmware update path I accidentally found that WOL_MCAST cause that behaviour. 'ifconfig em1 -wol_macst' restores old behaviour. Machine stays off after 'shutdown -p' and wake on lan with unicast packet is working. Btw, can you explain me why wake on lan isn't working before the machine once was booted? When the machine first time gets standby power no wake on lan is detected by the nic (no LED activity - when wake on lan is working I can see the nic LED confirming my wol packet). It's a S3200SH Board, but that doesn't play a role. Also S5000PAL and S5400 shows this issue. Best regards, -Harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD75D2E.50302>