Hello, Freebsd-stable.
You wrote 1 февраля 2011 г., 10:24:16:
And all connections are reset. Before latest commits to driver
this system paniced in swi_clock. Now it works without panics, but
seems, that problem is not fixed completely.
I forgot to give one last pice of information:
On 01.02.2011 13:58, Lev Serebryakov wrote:
Hello, Freebsd-stable.
You wrote 1 февраля 2011 г., 10:24:16:
And all connections are reset. Before latest commits to driver
this system paniced in swi_clock. Now it works without panics, but
seems, that problem is not fixed completely.
I
I don't test POLLING, sounds like its broken, I don't understand
why you think you need you need it? This hardware supports
MSI why not use it?
Jack
2011/1/31 Lev Serebryakov l...@freebsd.org
Hello, Freebsd-stable.
You wrote 1 февраля 2011 г., 10:24:16:
And all connections are reset.
We have tried POLLING here on Intel cards attached to the igb driver
(see my post entitled High interrupt rate on a PF box + performance
from 27/01/2011.
This broke carp *badly* and we switched back to interrupts.
You say a single thread eats up a full CPU core, can you post a top to
show the
Hello, Eugene Jack.
You wrote 1 февраля 2011 г., 11:23:23:
Eugene wrote:
You could give a try to netisr parallelism of RELENG_8 instead of POLLING
(and tune interrupt throttling) if your box does not have lots of dynamic
interfaces like when using mpd.
Jack wrote:
I don't test POLLING,
On 01.02.2011 18:38, Lev Serebryakov wrote:
= INTR - ISR.DIRECT=1
Real speed (accroding to Windows'7 report) ~101MiB/s.
I've re-created file to flush caches on both sides between trys.
netisr queues help to deal with lots of incoming traffic.
If you bother about outgoing
Hello, Eugene.
You wrote 1 февраля 2011 г., 16:52:57:
= INTR - ISR.DIRECT=1
Real speed (accroding to Windows'7 report) ~101MiB/s.
I've re-created file to flush caches on both sides between trys.
netisr queues help to deal with lots of incoming traffic.
If you bother about
Hello,
Just wanted to send a me too on this issue. Whenever it happends I
can see our Cisco switch reporting the interface going down and up as
well (Line Protocol).
FreeBSD localhost.localdomain 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE
#1: Wed Sep 13 00:10:04 CEST 2006 [EMAIL
I'm also seeing these on a Supermicro PDSMi board with a recent stable.
Please tell me what debugging info that is needed to fix this.
/Martin
FreeBSD mailbox 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sun Sep 10
17:43:15 CEST 2006 [EMAIL PROTECTED]:/usr/obj-local/usr/src/sys/SMP amd64
On Thu, Sep 14, 2006 at 02:27:29AM +0200, Ronald Klop wrote:
Them manual page em(4) mentions trying another cable when the watchdog
timeout happens, so I tried that. But it didn't help.
Is there anything I can test to (help) debug this?
It happens a lot when my machine is under load. (100%
Something with em0 is really wrong. I dont get timeouts, but
Before cvsup I had 6.0-PRERELEASE and didn't have a problem.
Now I have FreeBSD 6.2-PRERELEASE #8: Fri Sep 15 03:44:49 MSD 2006 and the
problem is so:
(On machine I have LARGE_NAT, em0, em1, em2)
on fresh system ping to www.ru from
On 9/14/06, David C. Myers [EMAIL PROTECTED] wrote:
watchdogs mean that the transmit ring is not being cleaned, so the
question is what is your machine doing at 100% cpu, if its that busy
the network watchdogs may just be a side effect and not the real
problem?
I get them with a
On 9/15/06, Martin Nilsson [EMAIL PROTECTED] wrote:
I'm also seeing these on a Supermicro PDSMi board with a recent stable.
Please tell me what debugging info that is needed to fix this.
/Martin
FreeBSD mailbox 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sun Sep 10
17:43:15 CEST 2006 [EMAIL
Jack Vogel wrote:
On 9/13/06, Ronald Klop [EMAIL PROTECTED] wrote:
...
Them manual page em(4) mentions trying another cable when the watchdog
timeout happens, so I tried that. But it didn't help.
Is there anything I can test to (help) debug this?
It happens a lot when my machine is under
watchdogs mean that the transmit ring is not being cleaned, so the
question is what is your machine doing at 100% cpu, if its that busy
the network watchdogs may just be a side effect and not the real
problem?
I get them with a completely idle machine. My home directory is mounted
via NFS
On Fri, 15 Sep 2006 02:06:08 +0200, David C. Myers [EMAIL PROTECTED]
wrote:
watchdogs mean that the transmit ring is not being cleaned, so the
question is what is your machine doing at 100% cpu, if its that busy
the network watchdogs may just be a side effect and not the real
problem?
I
On Tue, 05 Sep 2006 23:52:05 +0200, Ronald Klop
[EMAIL PROTECTED] wrote:
Hello,
I get these errors a lot.
Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting
Sep 5 11:55:12 ronald kernel: em0: link state changed to DOWN
Sep 5 11:55:14 ronald kernel: em0: link state changed
Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting
I got a bazillion of these, and a completely unusable machine, when I
upgraded to 6.1-stable sources as of two days ago. The machine would
simply freeze for minutes at a time. Going back to my previous kernel
(dating from
At 10:20 PM 9/13/2006, David Myers wrote:
Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting
I got a bazillion of these, and a completely unusable machine, when
I upgraded to 6.1-stable sources as of two days ago. The machine
would simply freeze for minutes at a time.
On 9/13/06, Ronald Klop [EMAIL PROTECTED] wrote:
...
Them manual page em(4) mentions trying another cable when the watchdog
timeout happens, so I tried that. But it didn't help.
Is there anything I can test to (help) debug this?
It happens a lot when my machine is under load. (100% CPU)
Is it
On Tuesday 05 September 2006 14:52, Ronald Klop wrote:
Hello,
I get these errors a lot.
Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting
Sep 5 11:55:12 ronald kernel: em0: link state changed to DOWN
Sep 5 11:55:14 ronald kernel: em0: link state changed to UP
Sep 5
21 matches
Mail list logo
