On 12/25/2012 4:31 AM, Ryan Stone wrote:
I don't believe that this is fixed in later versions of the driver. The
problem is that when the interface loses link the transmit queue can fill
up. Once that happens the driver never gets any more calls from the network
stack to make it send packets. Pin
On 25.12.2012 13:47, Adrian Chadd wrote:
It's like that because TX has allocated/filled the available mbufs,
but the TX doesn't restart when the link comes up.
Adrian
Thanks.
Ryans patch should restart TX when the link comes up?
___
freebsd-net@free
It's like that because TX has allocated/filled the available mbufs,
but the TX doesn't restart when the link comes up.
Adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
On 25.12.2012 07:01, Ryan Stone wrote:
I don't believe that this is fixed in later versions of the driver.
The problem is that when the interface loses link the transmit queue
can fill up. Once that happens the driver never gets any more calls
from the network stack to make it send packets. P
On 24 December 2012 17:59, Mike Karels wrote:
>> [adrian]
>> I think we may need another if_* method which specifically attempts to
>> service the TX queue again; versus just waiting for if_transmit() to
>> make some progress.
> In my opinion, it is wrong of the drivers to queue packets while li
> On 24 December 2012 17:01, Ryan Stone wrote:
> > I don't believe that this is fixed in later versions of the driver. The
> > problem is that when the interface loses link the transmit queue can fill
> > up. Once that happens the driver never gets any more calls from the network
> > stack to make
On 24 December 2012 17:01, Ryan Stone wrote:
> I don't believe that this is fixed in later versions of the driver. The
> problem is that when the interface loses link the transmit queue can fill
> up. Once that happens the driver never gets any more calls from the network
> stack to make it send p
I don't believe that this is fixed in later versions of the driver. The
problem is that when the interface loses link the transmit queue can fill
up. Once that happens the driver never gets any more calls from the network
stack to make it send packets. Pinging the interface fixes it because the
dri
Thank you for answer.
I tried to repeat the situation on a non-prodaction machine, but hadn't
success. I made this steps (from thread
http://freebsd.1045724.n5.nabble.com/ping-sendto-No-buffer-space-available-td5746337.html)
1. Start a ping flood: ping -f
2. Let it run for a few seconds.
3. D
Thank you for answer.
'/etc/rc.d/netif restart' resolves problem. But it takes too much time
to connect to server from local console and execute that command.
On 21.12.2012 20:47, Adrian Chadd wrote:
On 21 December 2012 04:13, Tsaregorodtsev Denis wrote:
Hello,
I maintenance ISP's DNS serve
On Fri, Dec 21, 2012 at 7:13 AM, Tsaregorodtsev Denis wrote:
> Hello,
>
> I maintenance ISP's DNS server which works under FreeBSD 7.3 and BIND
> 9.9.1-P4. The network adapter is Intel(R) PRO/1000 Network Connection,
> driver - em. The server is connected to a Cisco 6500 switch. Sometimes the
> sw
On 21 December 2012 04:13, Tsaregorodtsev Denis wrote:
> Hello,
>
> I maintenance ISP's DNS server which works under FreeBSD 7.3 and BIND
> 9.9.1-P4. The network adapter is Intel(R) PRO/1000 Network Connection,
> driver - em. The server is connected to a Cisco 6500 switch. Sometimes the
> switch g
Hello,
I maintenance ISP's DNS server which works under FreeBSD 7.3 and BIND 9.9.1-P4. The
network adapter is Intel(R) PRO/1000 Network Connection, driver - em. The server is
connected to a Cisco 6500 switch. Sometimes the switch goes down (for maintenance) and is
unavailable for 10 minutes. A
13 matches
Mail list logo
