On 2011-11-10 23:25, Joshua Boyd wrote:
On Thu, Nov 10, 2011 at 6:51 AM, Willem Jan Withagen w...@digiware.nl
mailto:w...@digiware.nl wrote:
em0@pci0:0:25:0:class=0x02 card=0x10bd15d9
chip=0x10bd8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device
On Sun, Nov 13, 2011 at 10:22 AM, Willem Jan Withagen w...@digiware.nlwrote:
On 2011-11-10 23:25, Joshua Boyd wrote:
On Thu, Nov 10, 2011 at 6:51 AM, Willem Jan Withagen w...@digiware.nl
mailto:w...@digiware.nl wrote:
em0@pci0:0:25:0:class=0x02 card=0x10bd15d9
On 10-11-2011 23:25, Joshua Boyd wrote:
On Thu, Nov 10, 2011 at 6:51 AM, Willem Jan Withagen w...@digiware.nl
mailto:w...@digiware.nl wrote:
em0@pci0:0:25:0:class=0x02 card=0x10bd15d9
chip=0x10bd8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device
Hi
Still running this file server on ZFS, and every now and then em0 goes
down, and is not revivable Nothing goes in or out the box...
Any suggestions as how to (help) fix this?
Regards,
--WjW
---
Nov 10 09:07:41 zfs kernel: em0: Watchdog timeout -- resetting
Nov 10 09:07:41 zfs
provide that too.
Nov 10 09:07:41 zfs kernel: em0: Watchdog timeout -- resetting
Nov 10 09:07:41 zfs kernel: em0: Queue(0) tdh = 187, hw tdt = 189
Nov 10 09:07:41 zfs kernel: em0: TX(0) desc avail = 1022,Next TX to Clean =
187
Nov 10 09:11:32 zfs kernel: em0: Watchdog timeout -- resetting
not afford at the moment is leave this
box in disconnected state.
And note that this problem only raises it nasty head very few weeks...
--WjW
Nov 10 09:07:41 zfs kernel: em0: Watchdog timeout -- resetting
Nov 10 09:07:41 zfs kernel: em0: Queue(0) tdh = 187, hw tdt = 189
Nov 10 09:07:41 zfs kernel
On Thu, Nov 10, 2011 at 6:51 AM, Willem Jan Withagen w...@digiware.nlwrote:
em0@pci0:0:25:0:class=0x02 card=0x10bd15d9 chip=0x10bd8086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)'
class = network
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, Eugene.
You wrote 1 февраля 2011 г., 15:38:33:
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, sounds
this:
em0: Watchdog timeout -- resetting
em0: Queue(0) tdh = 1302, hw tdt = 1265
em0: TX(0) desc avail = 31,Next TX to Clean = 1296
em0: Watchdog timeout -- resetting
em0: Queue(0) tdh = 3999, hw tdt = 3959
em0: TX(0) desc avail = 31,Next TX to Clean = 3990
em0: Watchdog timeout -- resetting
em0: Queue(0
broadcast 192.168.2.255
inet6 fec0::1 prefixlen 64
media: Ethernet autoselect (1000baseTX full-duplex)
status: active
[sobo...@pioneer ~]$ dmesg | grep watchd
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog
-STABLE
amd64 as of 2009.04.19, and also some other more perverse errors.
Twice now in the last 48 hours, this machine has become unreachable via the
network, and connecting to the console shows an endless string of
[...]
em0: watchdog timeout -- resetting
em0: watchdog timeout
On Wed, May 13, 2009 at 06:42:07PM +0200, Greg Byshenk wrote:
As a followup to my own previous message, I continue to have annoying
problems with em?: watchdog timeout on one of my machines (now running
7.2-STABLE as of 2009-05-08).
I have discontinued using the on-board (em, copper) NICs,
as of 2009.04.19, and also some other more perverse errors.
Twice now in the last 48 hours, this machine has become unreachable via the
network, and connecting to the console shows an endless string of
[...]
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0
of
[...]
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
messages. The machine is almost locked up. That is, I can get a login
prompt, but can go no further than typing in a username; after the
username, no password prompt, and nothing
I am having some issues with the em(4) card. I am getting the em0:
watchdog timeout -- resetting error. The box has a DFI KT600-AL mobo
and a Intel Pro/1000 GT nic. I am running 6.2-RELEASE. I have rma'd
the card twice already and get the same error. I've tried different
PCI ports, different
-0x601f mem 0xea40-0xea41 irq 17 at device 0.0 on pci14
em1: Ethernet address: 00:30:48:5c:cc:85
I'm seeing the following entries in my messages log pop up about 2-4
times a day...
May 1 08:29:38 alpha kernel: em0: watchdog timeout -- resetting
May 1 08:29:38 alpha kernel: em0: link state
I've tried to upgrade to 6.x but without any luck because of
the watchdog timeout errors on em0 when using nfs.
Mar 30 11:30:48 large kernel: em0: watchdog timeout -- resetting
Mar 30 11:30:48 large kernel: em0: link state changed to DOWN
Mar 30 11:30:51 large kernel: em0: link state changed
:48:5c:cc:85
I'm seeing the following entries in my messages log pop up about 2-4
times a day...
May 1 08:29:38 alpha kernel: em0: watchdog timeout -- resetting
May 1 08:29:38 alpha kernel: em0: link state changed to DOWN
May 1 08:29:41 alpha kernel: em0: link state changed to UP
I've gone
Hi, Jack,
Jack Vogel wrote:
[EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086
rev=0x02
hdr=0x00
[...]
The driver in 6.2 RELEASE fixed all known problems with
watchdogs, other than REAL issues with the network/hardware.
Have you tried installing that?
A friend of mine
LI Xin wrote:
Hi, Jack,
Jack Vogel wrote:
[EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086
rev=0x02
hdr=0x00
[...]
The driver in 6.2 RELEASE fixed all known problems with
watchdogs, other than REAL issues with the network/hardware.
Have you tried installing that?
LI Xin wrote:
Hi, Jack,
Jack Vogel wrote:
[EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086
rev=0x02
hdr=0x00
[...]
The driver in 6.2 RELEASE fixed all known problems with
watchdogs, other than REAL issues with the network/hardware.
Have you tried installing that?
Hi,
At this moment I'm running FreeBSD 4.11 without any problems. A couple
of times I've tried to upgrade to 6.x but without any luck because of
the watchdog timeout errors on em0 when using nfs.
Mar 30 11:30:48 large kernel: em0: watchdog timeout -- resetting
Mar 30 11:30:48 large
timeout -- resetting
Mar 30 11:30:48 large kernel: em0: link state changed to DOWN
Mar 30 11:30:51 large kernel: em0: link state changed to UP
Mar 30 11:31:01 large kernel: em0: watchdog timeout -- resetting
Mar 30 11:31:01 large kernel: em0: link state changed to DOWN
Mar 30 11:31:03 large kernel: em0
kernel: em0: watchdog timeout -- resetting
Mar 30 11:30:48 large kernel: em0: link state changed to DOWN
Mar 30 11:30:51 large kernel: em0: link state changed to UP
Mar 30 11:31:01 large kernel: em0: watchdog timeout -- resetting
Mar 30 11:31:01 large kernel: em0: link state changed to DOWN
Mar 30
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
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 12:00:37 ronald kernel: em0: watchdog timeout -- resetting
Sep 5
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 12:00
46 matches
Mail list logo
