Frequent network access freeze (in 7.0)

[admin at lissyara.su]

On Tue, 26 Feb 2008 01:57:53 -0800 (PST), Unga <unga888 at yahoo.com> wrote:
> --- Robert Watson <rwatson at FreeBSD.org> 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: <SMC
>> 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....