From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 12:53:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 619A1106566B for ; Tue, 26 Feb 2008 12:53:51 +0000 (UTC) (envelope-from hosting@hosting.lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 336E313C4D1 for ; Tue, 26 Feb 2008 12:53:51 +0000 (UTC) (envelope-from hosting@hosting.lissyara.su) Received: from hosting by hosting.lissyara.su with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JTyvP-000JYh-DT; Tue, 26 Feb 2008 15:28:47 +0300 To: Unga X-PHP-Script: hosting.lissyara.su/roundcube/index.php for 213.234.218.67 MIME-Version: 1.0 Date: Tue, 26 Feb 2008 15:28:47 +0300 From: In-Reply-To: <840364.15353.qm@web57003.mail.re3.yahoo.com> References: <840364.15353.qm@web57003.mail.re3.yahoo.com> Message-ID: <318482e6609d6237ee011cc60e1f57c1@lissyara.su> X-Sender: admin@lissyara.su Received: from lina.fors.com [213.234.218.67] with HTTP/1.0 (POST); Tue, 26 Feb 2008 15:28:47 +0300 User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: Hosting User X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: Frequent network access freeze (in 7.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 12:53:51 -0000 On Tue, 26 Feb 2008 01:57:53 -0800 (PST), Unga wrote: > --- Robert Watson wrote: > >> >> On Wed, 20 Feb 2008, Unga wrote: >> >> > I'm running 7.0-PRERELEASE (RC2, dated >> 15/02/2008), compiled from sources on >> > i386 machine (512MB RAM, 3.0GHz, tx0: > EtherPower II 10/100>). >> > >> > Network access freezes very frequently. Cannot >> ping to any ip address. The >> > only way to get networking working again is >> reboot. >> > >> > I'm having this problem on 7.0 ever since I tried >> it from BETA4. I have >> > reported also to this list before but sadly nobody >> was interested on it. >> > >> > If somebody is interested to look into this >> problem, I could furnish with >> > more detail and participate in testing. >> >> This sort of problem frequently turns out to be a >> bug in a device driver or a >> problem with interrupt probing/configuration, so my >> first guess would be a >> problem with the if_tx driver. The usual starting >> diagnostics when ping fails >> are to try to use tcpdump to determine whether it's >> receive or transmit >> failing (or both). Quiet the network between two >> endpoints as much as you can >> so you can avoid noise from making the dumps more >> complex, and dump arp and >> icmp at both endpoints. Now try to ping from each >> end point to the other. >> One potential source of confusion is that ping >> requires ARP to work, and ARP >> can be a slightly confusing protocol as it usually >> resolves actively (query, >> response) but sometimes it receives passive updates >> or extends existing >> entries. >> >> What you want to look for is a packet sent by one >> side that isn't received by >> the other. You might find, for example, that your >> host receives packets fine, >> but the packets it transmits are never received. >> This would be indicative of a >> driver bug in which it fails to properly handle (for >> example) transmit queues >> filling, and might only trigger under very high >> load. Or, you might find that >> your host never receives anything the other side >> transmits, but can send fine. >> This might be indicative of a driver bug involving >> the receive code, or a >> problem with how interrupts are being handled more >> generally. >> >> It looks like the last non-routine maintenance to >> the driver was done by >> Maxime in about 2003; the more recent changes have >> all been updates to >> newbus/busdma infrastructure, ifnet changes, locking >> changes, etc. I've CC'd >> him as it sounds like he may have hardware... My >> advice would be to do the >> above tests and see if you can narrow down whether >> it's transmit, receive, or >> both failing. >> > I have some problem with 7-rc2 interface - rl0, some time it work correct - (5 hour (minimum) - 3 day (maximum)), then, short period (30-50 min.) packet loss up from 0% to 25%. up/down, network restart - cannot help. Only reboot... more than 25% - i not see. It up to 25% and freese on this number. ======== 2 day ago i change interface to fxp0... i stay - today - 3 day from change....