Date: Thu, 21 Feb 2008 15:37:48 +0100 From: Christoph Schug <chris+freebsd-current@schug.net> To: Pyun YongHyeon <pyunyh@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, Robert Backhaus <robbak@robbak.com> Subject: Re: Packet corruption in re0 Message-ID: <20080221143748.GE10726@lega.schug.net> In-Reply-To: <20080221050635.GC26427@cdnetworks.co.kr> References: <d4499580802201703t1dcc3143x96e85cd8e562489@mail.gmail.com> <20080221035014.GB26427@cdnetworks.co.kr> <d4499580802202047g6baec3eag564ed6f59f90d10@mail.gmail.com> <20080221050635.GC26427@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 21, 2008, Pyun YongHyeon wrote: > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > HEAD/RELENG_7 to if_re.c). That would make it build on your box. I am having the very same problem on a rented Hetzner DS8000 root server offering [1]. According to sysutils/dmidecode from the ports the main board is a MSI K9AG Neo2-Digital (MS-7368) [2] with an embedded RTL8168/8111 PCI-E Gigabit Ethernet NIC (re0@pci0:2:0:0: class=0x020000 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00). [1] http://www.hetzner.de/rootserver.html [2] http://www.msicomputer.com/product/p_spec.asp?model=K9AG_Neo2-Digital&class=mb > > Yes, I've been down the heat path, but the problem takes ~36 hours to recur > > both if the system is turned on from cold, or simply rebooted. Mind you, > > North Queensland could do with some cooling! I will take another look at the > > circuitry if moving to HEAD's re doesn't fix it. Interestingly enough, in my case it takes a similar amount of time but I can speed up the problem to show up when doing many disk (!) I/O operations on the 3ware RAID controller. Furthermore calling programs like 'rpm -Uvh' which draw a progress bar by sending many hash ('#') characters in a short period of time are very "helpful" to freeze the session while other SSH sessions during the same time still work flawlessly. 'netstat -an' shows pretty high numbers in the send queue of the freezed session. Will give re(4) of HEAD a try despite the fact that I would be very happy to see a fix in RELENG_7 as I have to bring to machine into production very soon. Thanks for the hint! -cs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080221143748.GE10726>