Re: Frequent network access freeze (in 7.0)
- From: <admin@xxxxxxxxxxx>
- Date: Tue, 26 Feb 2008 15:28:47 +0300
On Tue, 26 Feb 2008 01:57:53 -0800 (PST), Unga <unga888@xxxxxxxxx> wrote:
--- Robert Watson <rwatson@xxxxxxxxxxx> wrote:I have some problem with 7-rc2
On Wed, 20 Feb 2008, Unga wrote:
I'm running 7.0-PRERELEASE (RC2, dated15/02/2008), compiled from sources on
i386 machine (512MB RAM, 3.0GHz, tx0: <SMCEtherPower II 10/100>).
ping to any ip address. The
Network access freezes very frequently. Cannot
only way to get networking working again isreboot.
it from BETA4. I have
I'm having this problem on 7.0 ever since I tried
reported also to this list before but sadly nobodywas interested on it.
problem, I could furnish with
If somebody is interested to look into this
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.
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....
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- References:
- Re: Frequent network access freeze (in 7.0)
- From: Unga
- Re: Frequent network access freeze (in 7.0)
- Prev by Date: Re: ssh_exchange_identification: Connection closed by remote host
- Next by Date: why vimage?
- Previous by thread: Re: Frequent network access freeze (in 7.0)
- Next by thread: Re: Frequent network access freeze (in 7.0)
- Index(es):
Relevant Pages
|
