Hi!
> # uname -a
> FreeBSD lash.internal 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
See here:
https://www.freebsd.org/security/advisories/FreeBSD-EN-20:09.igb.asc
--
p...@opsec.eu+49 171 3101372Now what ?
first. Is there
more debugging I could collect while the server is in this state?
Physically removing the ethernet cable and plugging it back in does not
bring the interface up. ifconfig down and up also does not help.
What is this watchdog timeout that we are seeing in the logs?
Ari
o sbruno@
I'd like to confirm r294958 fixes multiple em(4) problems I observed up
to r294156, especially EM_MULTIQUEUE support on hartwell (82574)
(haven't filed a bug report since I haven't had time to analyze, seems
199174 and 200221 match well).
Glad to see 10.3 will ship with em(4) able to sus
The connection is fine when working without lagg/lacp. As soon I
configure it, on load it the network devices will have watchdog
timeouts. The switch I use is a HP 1810-24G, PL.1.9
One of the other threads mentioned he used an other router (/switch) and
problems didn't occur anymore
of, do these interfaces watchdog if they
> are not configured with lagg?
>
> Cheers,
>
> Jack
>
>
> On Fri, Oct 2, 2015 at 10:37 AM, Frank de Bot (lists) <li...@searchy.net>
> wrote:
>
>> On a server I have 2 interfaces configured in a lagg. It seemed to be
On a server I have 2 interfaces configured in a lagg. It seemed to be
running stable until now (about a week), both interfaces repeatable go
down after a watchdog timeout.
Output from /var/log/messages
Oct 2 10:15:11 nas kernel: em0: Watchdog timeout Queue[0]-- resetting
Oct 2 10:15:11 nas
You missed the all-important details: OS version, driver version.
And another question I can think of, do these interfaces watchdog if they
are not configured with lagg?
Cheers,
Jack
On Fri, Oct 2, 2015 at 10:37 AM, Frank de Bot (lists) <li...@searchy.net>
wrote:
> On a server
On Thu, Aug 27, 2015 at 11:29:28AM +0200, Johann Hugo wrote:
It's working for me so far and I haven't seen any watchdog timeouts.
With 10.2-RELEASE I got timeouts and lost connectivity in less that a
minute.
Ok, great. Committed in r287238.
Thanks again.
Johann
On Wed, Aug 26, 2015
It's working for me so far and I haven't seen any watchdog timeouts.
With 10.2-RELEASE I got timeouts and lost connectivity in less that a
minute.
Johann
On Wed, Aug 26, 2015 at 10:28 AM, Yonghyeon PYUN pyu...@gmail.com wrote:
On Wed, Aug 26, 2015 at 10:06:29AM +0200, Johann Hugo wrote:
10.2
10.2-RELEASE does not work for me. It works for a very short while and
then it stops with msk0 watchdog timeout errors
I'm not sure what patch Roosevelt was talking about, but the patch in
this thread works for me:
https://lists.freebsd.org/pipermail/freebsd-stable/2015-April/082226.html
I've
On Wed, Aug 26, 2015 at 10:06:29AM +0200, Johann Hugo wrote:
10.2-RELEASE does not work for me. It works for a very short while and
then it stops with msk0 watchdog timeout errors
Thanks a lot for your report. This is the first report for
msk(4) watchdog timeouts on 10.2-RELEASE.
I'm
On Wed, Aug 12, 2015 at 09:44:06AM -0400, Roosevelt Littleton wrote:
Hi,
So, I can confirm with the attached patch. I have a working msk0 that
hasn't failed for the past month. I considered this problem fix for me.
Since, I have went a long time without any problems. Thanks!
I'm not sure
On 08/12/2015 04:44 PM, Roosevelt Littleton wrote:
Hi,
So, I can confirm with the attached patch. I have a working msk0 that
hasn't failed for the past month. I considered this problem fix for me.
Since, I have went a long time without any problems. Thanks!
Roosevelt
Hi,
So, I can confirm with the attached patch. I have a working msk0 that
hasn't failed for the past month. I considered this problem fix for me.
Since, I have went a long time without any problems. Thanks!
Roosevelt
___
freebsd-stable@freebsd.org
On Sat, Jul 25, 2015 at 02:08:10PM +0300, Alnis Morics wrote:
Just tried 10.2-RC1 amd64 GENERIC, and the problem seems to be gone. I
was even able to scp a 500 MB file. Could it be related to this fix in
BETA2, as mentioned in the announcement, The watchdog(4) device has
been fixed
, The watchdog(4) device has
been fixed to print to the correct buffer.?
msk(4) will show watchdog timeouts when it detects driver TX path
is in stuck condition but I believe this has nothing to do with
watchdog(4).
There was no msk(4) code change in 10.2-RC1. If you happen to see
the watchdog
From: owner-freebsd-sta...@freebsd.org [owner-freebsd-sta...@freebsd.org] on
behalf of Yonghyeon PYUN [pyu...@gmail.com]
Sent: 13 April 2015 09:13
To: Gareth Wyn Roberts
Cc: freebsd-stable@freebsd.org
Subject: Re: msk msk0 watchdog timeout freeze hang lock stop problem
On Sun, Apr 12, 2015
(localtime):
tdh and tdt mean the head and tail indices of the ring, and these
values are
obviously severely borked :)
Hello Jack,
could you find some time for having a look at this problem? The reported
values don't bother me, but the watchdog timeout which happens on NICs
that are PCIe-connected via
, r281235, April 7, 2015.
I had gone on to check out a newer stable from subversion, and build a
custom kernel, but when I booted that one I got a bce0 that didn't seem to
work, and kept emitting:
bce0: /usr/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting!
bce0: link
subversion, and
build a custom kernel, but when I booted that one I got a bce0 that
didn't seem to work, and kept emitting:
bce0: /usr/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred,
resetting!
bce0: link state changed to DOWN
bce0: link state changed to UP
So, I fell back
On Apr 21, 2015, at 10:10 , Gareth Wyn Roberts g.w.robe...@glyndwr.ac.uk
wrote:
This may be caused by DMA alignment problems.
See
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=145859+0+archive/2015/freebsd-stable/20150419.freebsd-stable
for a recent thread about the msk driver. The msk
if I see a change.
I guess the alignment issue of msk(4) has nothing to do with bce(4)
watchdog timeouts. It would be more helpful to know details of
your controller(bce(4)/brgphy(4) related dmesg output, pciconf
output etc) and network setup.
If you know a reliable way that triggers
on to check out a newer stable from subversion, and build a custom
kernel, but when I booted that one I got a bce0 that didn't seem to work, and
kept emitting:
bce0: /usr/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting!
bce0: link state changed to DOWN
bce0: link state changed
) related watchdog timeouts.
Index: sys/dev/msk/if_mskreg.h
===
--- sys/dev/msk/if_mskreg.h (revision 281587)
+++ sys/dev/msk/if_mskreg.h (working copy)
@@ -2175,13 +2175,8 @@
#define MSK_ADDR_LO(x) ((uint64_t) (x) 0xUL)
#define
-freebsd-sta...@freebsd.org] on
behalf of Yonghyeon PYUN [pyu...@gmail.com]
Sent: 13 April 2015 09:13
To: Gareth Wyn Roberts
Cc: freebsd-stable@freebsd.org
Subject: Re: msk msk0 watchdog timeout freeze hang lock stop problem
On Sun, Apr 12, 2015 at 05:57:34PM +, Gareth Wyn Roberts wrote:
I've
Hm... I patched if_msk.c with if_msk.c.rev262524.dma.diff
(attachment-001.bin) and if_mskreg.h with if_mskreg.h.rev264442.dma.diff
(attachment-002.bin), and nothing changed: scp'ing 50 MB soon got
stalled and ended up with broken pipe, as it was before.
I have 10.1-RELEASE-p9 amd64
pciconf
On Sun, Apr 12, 2015 at 05:57:34PM +, Gareth Wyn Roberts wrote:
I've run in to problems using the msk device where initially it works well
enough to set DHCP etc. but stops/freezes as soon as any appreciable network
traffic occurs . There are several threads describing similar symptoms
I've run in to problems using the msk device where initially it works well
enough to set DHCP etc. but stops/freezes as soon as any appreciable network
traffic occurs . There are several threads describing similar symptoms over the
past two years or more. I've been following several false
Hi!
I've run in to problems using the msk device [...]
I'm working on 10.1-RELEASE source, i.e. if_msk.c revision 262524 and
if_mskreg.h revision 264442.
Here's the patch to if_mskreg.h
[...]
Thanks for the suggested fix.
There are five PRs, all describe similar things:
Hello, I have a server pfsense in bridge mode to function as transparent
FW, the problem is that once I connect the pfsense between my router core
and my core switch catalyst a few seconds begin to appear several messages
like these:
em2: watchdog timeout - resetting
em2: watchdog timeout
-0xf6bf0xf6be-0xf6be,0xf6bd-0xf6bd irq 32
at device 0.0 on pci3
bge0: APE FW version: NCSI v1.0.80.0
It seems your APE runs slightly newer NC-SI firmware. I was able to
reproduce watchdog timeouts on Dell R820 but I'm not sure you're
also seeing the same
feedbacks but it seems it still has
some issues. Let me know whether it makes any difference on your
box.
I tried these bge source files in 9.1-PRERELEASE this week, and it does
not help. If I try to log in with SSH I get:
Aug 23 17:30:32 login: ROOT LOGIN (root) ON ttyu0
bge0: watchdog timeout
:
Aug 23 17:30:32 login: ROOT LOGIN (root) ON ttyu0
bge0: watchdog timeout -- resetting
Aug 23 17:31:31 kernel: bge0: watchdog timeout -- resetting
Aug 23 17:31:31 kernel: bge0: link state changed to DOWN
Aug 23 17:31:35 kernel: bge0: link state changed to UP
bge0: watchdog timeout
On Thu, 2012-07-12 at 12:06 -0700, Sean Bruno wrote:
On Thu, 2012-07-12 at 14:59 -0700, YongHyeon PYUN wrote:
I grabbed these updates and applied them cleanly to stable/9 on a
Dell
R620 with a quad port BCM5720, I still see watchdog timeouts and
reset
indications. I am able to ping
a machine which was having watchdog timeouts on a bge
which turned out to be a hardware failure.
Not exactly sure exactly what but disabling cores of the second CPU
solved the problem.
Regards
Steve
This e.mail is private and confidential between
/~yongari/bge/brgphy.c
I have a couple of positive feedbacks but it seems it still has
some issues. Let me know whether it makes any difference on your
box.
I grabbed these updates and applied them cleanly to stable/9 on a Dell
R620 with a quad port BCM5720, I still see watchdog timeouts
On Thu, 2012-07-12 at 14:59 -0700, YongHyeon PYUN wrote:
I grabbed these updates and applied them cleanly to stable/9 on a
Dell
R620 with a quad port BCM5720, I still see watchdog timeouts and
reset
indications. I am able to ping out of the box for a short amount of
time before
but it seems it still has
some issues. Let me know whether it makes any difference on your
box.
I grabbed these updates and applied them cleanly to stable/9 on a Dell
R620 with a quad port BCM5720, I still see watchdog timeouts and reset
indications. I am able to ping out of the box for a short
On Tue, Jul 03, 2012 at 08:57:04PM +0200, Anders Nordby wrote:
Hi,
I'm having lots of difficulties with BCM5719, which is the default
network card of HP Proliant DL 360 G8 servers. I can get a few ping
replies before I get a couple of these:
bge0: watchdog timeout -- resetting
Hi,
I'm having lots of difficulties with BCM5719, which is the default
network card of HP Proliant DL 360 G8 servers. I can get a few ping
replies before I get a couple of these:
bge0: watchdog timeout -- resetting
bge0: watchdog timeout -- resetting
of difficulties with BCM5719, which is the default
network card of HP Proliant DL 360 G8 servers. I can get a few ping
replies before I get a couple of these:
bge0: watchdog timeout -- resetting
bge0: watchdog timeout -- resetting
Then everything hangs. Can not log in using ssh.
I'm
: Watchdog timeout -- resetting
Apr 13 08:53:07 san02 kernel: em1: Queue(0) tdh = 232, hw tdt = 190
Apr 13 08:53:07 san02 kernel: em1: TX(0) desc avail = 31,Next TX to
Clean = 221
Apr 13 08:53:07 san02 kernel: em1: Link is Down
Apr 13 08:53:07 san02 kernel: em1: link state changed
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
watchdog timeout expired. Shutdown terminated.
Thu Jul 14 16:24:30 MSD 2011
Killed
PS: I may be mistaken but I think this problem did not exist before
PS2: i have RELENG_8 and HEAD version of FreeBSD
PS3: Thanks in advance
___
freebsd-stable@freebsd.org
On 2011-07-14 11:38, Subbsd wrote:
Tell me please, is it possible to change the behavior of shutdown
sequence to avoid work of kill process (or increase timeout).
To increase the timeout, which is 30 seconds by default, just set
rcshutdown_timeout (in your rc.conf) to a value that works for
of 10 GB.
Waiting for PIDS: 47924
30 second watchdog timeout expired. Shutdown terminated.
Thu Jul 14 16:24:30 MSD 2011
Killed
PS: I may be mistaken but I think this problem did not exist before
PS2: i have RELENG_8 and HEAD version of FreeBSD
PS3: Thanks in advance
I have roughly
.
As result ive have in /var/db/redis dump.tmp.XX - broken DB about ~3
Gb instead of 10 GB.
Waiting for PIDS: 47924
30 second watchdog timeout expired. Shutdown terminated.
Thu Jul 14 16:24:30 MSD 2011
Killed
PS: I may be mistaken but I think this problem did not exist before
PS2: i have
not had these problems on any other version of 8-STABLE
or
7-STABLE, which this box was upgraded from some time ago.
Now, during my weekly scrub, I get the following messages and em0 is
unresponsive:
Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout --
resetting
Jun
, which this box was upgraded from some time ago.
Now, during my weekly scrub, I get the following messages and em0 is
unresponsive:
Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout --
resetting
Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to
DOWN
Jun
:07:58 foghornleghorn kernel: em0: Watchdog timeout -- resetting
Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN
Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP
Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- resetting
Jun 12 03:08:47
, I get the following messages and em0 is
unresponsive:
Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- resetting
Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN
Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP
Jun 12 03:08:47
-STABLE, which this box was upgraded from some time ago.
Now, during my weekly scrub, I get the following messages and em0 is
unresponsive:
Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- resetting
Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN
Jun
ZFS. I have not had these problems on any other version of 8-STABLE or
7-STABLE, which this box was upgraded from some time ago.
Now, during my weekly scrub, I get the following messages and em0 is
unresponsive:
Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout
scrub, I get the following messages and em0 is
unresponsive:
Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout --
resetting
Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN
Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP
Jun 12 03
On Thu, 2011-02-24 at 03:03 -0800, Pete French wrote:
I havent investigated far enough yet to see if this is the same problem, but
I am also seeing hangs on em0 when under heavy load. This is 8-STABLE from
the 17 at around 3pm.
em0@pci0:0:25:0:class=0x02 card=0x281e103c
If you ifconfig down/up the interface does it come back to life?
Nope - has no effect. See another separate post of mine about how
I added another em card, and that works fine.
___
freebsd-stable@freebsd.org mailing list
Hello, Arnaud.
You wrote 2 марта 2011 г., 9:55:50:
I have been running with 7.2.2 and so far so good. However, its hard to
say in my case as the box I would only periodically see the issue.
As I wrote to Jack, my NIC hangs today with 7.2.2
Do you have any detailed error ? What the output of
On Thu, Mar 3, 2011 at 2:10 AM, Lev Serebryakov l...@serebryakov.spb.ru wrote:
Hello, Arnaud.
You wrote 2 марта 2011 г., 9:55:50:
I have been running with 7.2.2 and so far so good. However, its hard to
say in my case as the box I would only periodically see the issue.
As I wrote to Jack,
Hello, Brandon.
You wrote 3 марта 2011 г., 17:08:26:
I see that you have CRC errors:
dev.em.0.mac_stats.crc_errs: 156
and receive errors:
dev.em.0.mac_stats.recv_errs: 147
You probably have a hardware problem. Is this the only machine on
which you're experiencing the problem?
It is only
Hello, Brandon.
You wrote 3 марта 2011 г., 17:08:26:
I see that you have CRC errors:
dev.em.0.mac_stats.crc_errs: 156
and receive errors:
dev.em.0.mac_stats.recv_errs: 147
It (almost) doesn't change. And it hangs again. It seems, that 7.2.2
hangs more often than 7.1.9 on my hardware :(
I have been running with 7.2.2 and so far so good. However, its hard to
say in my case as the box I would only periodically see the issue.
Jan, have you had a chance to try 7.2.2 ? You seemed to hit the issue
the most frequently. There are also some alternate patches in
Hello, Mike.
You wrote 1 марта 2011 г., 17:20:49:
I have been running with 7.2.2 and so far so good. However, its hard to
say in my case as the box I would only periodically see the issue.
As I wrote to Jack, my NIC hangs today with 7.2.2
--
// Black Lion AKA Lev Serebryakov
Hi,
On Tue, Mar 1, 2011 at 2:52 PM, Lev Serebryakov l...@serebryakov.spb.ru wrote:
Hello, Mike.
You wrote 1 марта 2011 г., 17:20:49:
I have been running with 7.2.2 and so far so good. However, its hard to
say in my case as the box I would only periodically see the issue.
As I wrote to
Thank you. I'll test and share my experiences with you.
On Wed, Feb 23, 2011 at 7:47 PM, Jack Vogel jfvo...@gmail.com wrote:
Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put it
into your kernel source tree, it will break that. What you must do is config
the
em driver
I havent investigated far enough yet to see if this is the same problem, but
I am also seeing hangs on em0 when under heavy load. This is 8-STABLE from
the 17 at around 3pm.
em0@pci0:0:25:0:class=0x02 card=0x281e103c chip=0x10bd8086 rev=0x02
hdr=0x00
vendor = 'Intel
Just as an addendum to this - in my case ifconfig down/up does not fix
the problem. I need a reboot for the network to come back normally.
-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To
is VERY BASIC: no polling, no sysctls or
loader.conf tunables AT ALL. No jumbo frames.
nic doesn't show any Watchdog timeout / resetting messages.
Driver from em driver, 82574L chip, and possibly ASPM thread
doesn't help, really: it seems, that it decrease frequincy of hangs,
but doesn't
On 2/23/2011 4:16 AM, Lev Serebryakov wrote:
Driver from em driver, 82574L chip, and possibly ASPM thread
doesn't help, really: it seems, that it decrease frequincy of hangs,
Looking at your sysctl output, you are not using the test drivers posted
in that thread.
sysctl dev.em.0
Hello, Mike.
You wrote 23 февраля 2011 г., 14:16:28:
Driver from em driver, 82574L chip, and possibly ASPM thread
doesn't help, really: it seems, that it decrease frequincy of hangs,
Looking at your sysctl output, you are not using the test drivers posted
in that thread.
Yes, as it
Hi,
How can we get 7.2.2. version of if_em driver ?
I wanna test it.
I can help you for testing changes to em drivers.
Regards,
Ozkan KIRIK
On Wed, Feb 23, 2011 at 1:36 PM, Lev Serebryakov l...@serebryakov.spb.ru
wrote:
Hello, Mike.
You wrote 23 февраля 2011 г., 14:16:28:
Driver from
Anyone in net and stable that wants it, limits blocked it, so send me
personal email and I'll send to you.
Jack
On Wed, Feb 23, 2011 at 9:47 AM, Jack Vogel jfvo...@gmail.com wrote:
Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put it
into your kernel source tree, it
Just updated a box to the 8.2-PREREL as of friday and now when we do any
serious amounts of network traffice we see:-
bge0: watchdog timeout -- resetting
bge0: link state changed to DOWN
bge0: link state changed to UP
The interface never recovers, we have to use remote console to down, wait
30
This may be totally unrelated to bge, investigating a potential failing stick
of ram in the machine in question so until we've ruled this out as the cause
don't want to waste anyone's time.
I did however notice the logic between the two fixes for DMA on 5704's on PCIX
in svn differ so wondering
On Sat, Feb 19, 2011 at 03:59:57PM -, Steven Hartland wrote:
This may be totally unrelated to bge, investigating a potential failing
stick
of ram in the machine in question so until we've ruled this out as the cause
don't want to waste anyone's time.
I did however notice the logic
On 2/6/2011 4:40 PM, Lev Serebryakov wrote:
Hello, Freebsd-stable.
It hangs under load without any output. When it works with POLLING, it
prints Watchdog timeout and reset automatically several times a day,
but without POLLING it simply hangs with same frequency. It is
8.2-PRERELEASE (from
Hello, Mike.
You wrote 7 февраля 2011 г., 15:22:11:
It hangs under load without any output. When it works with POLLING, it
prints Watchdog timeout and reset automatically several times a day,
but without POLLING it simply hangs with same frequency. It is
8.2-PRERELEASE (from RELENG_8
/boot/loader.conf:
hw.em.rxd=4096
hw.em.txd=4096
net.link.ifqmaxlen=16384
/etc/sysctl.conf:
dev.em.0.rx_int_delay=200
dev.em.0.tx_int_delay=200
dev.em.0.rx_abs_int_delay=4000
dev.em.0.tx_abs_int_delay=4000
dev.em.0.rx_processing_limit=4096
I'm trying to run with patch from em
2 supports D0 D3 current D0
cap 05[d0] = MSI supports 1 message, 64 bit
cap 09[e0] = vendor (length 6) Intel cap 2 version 0
It is on-board LAN on Q35-based MoBo (ASUS P5E-VM DO)
It hangs under load without any output. When it works with POLLING, it
prints Watchdog timeout and reset
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
The Tyan S4881 works perfectly with 7.3-RELEASE-p3; I'll be reinstalling
7.4 and providing the requested diagnostics once I have a backup made.
(Broadcom bge watchdog timeouts under moderate (25% max of GigE) load)
Mike Squires
mi...@siralan.org
Problem is watchdog timeouts with a Broadcom GigE interface on a Tyan
S4881 using 7.4-PRERELEASE as of 11/22 and 7.3-STABLE as of 11/11.
I've done the following, with no success:
(1) Tried the second port, bge1, in case the first had gone bad, and
(2) Recompiled samba34 (failure occurs when
On Sun, Nov 28, 2010 at 04:04:34PM -0500, Michael L. Squires wrote:
Problem is watchdog timeouts with a Broadcom GigE interface on a Tyan
S4881 using 7.4-PRERELEASE as of 11/22 and 7.3-STABLE as of 11/11.
I've done the following, with no success:
(1) Tried the second port, bge1, in case
I've been running 7.X on a Tyan S4881 (4 dual-core Opteron CPUs) since
nearly the beginning of the 7.X cycle, and have just started to see
watchdog timeouts on the Broadcom bge0 GigE port.
This occurs with a kernel and world compiled on 11/22, and also with a
kernel compiled on 11/11
:
vpn# uname -a
FreeBSD vpn.auroraalimentos.com.br 7.3-STABLE FreeBSD 7.3-STABLE #0: Sat
Jun 19 18:39:18 BRT 2010
r...@vpn.xxx.com.br:/usr/obj/usr/src/sys/VPN i386
Nov 8 11:53:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts)
-- recovering
Nov 8 12:01:21 vpn kernel: xl0
: watchdog timeout (missed Tx interrupts)
-- recovering
Nov 8 12:01:21 vpn kernel: xl0: watchdog timeout (missed Tx interrupts)
-- recovering
Nov 8 12:21:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts)
-- recovering
Nov 8 16:11:34 vpn kernel: xl0: watchdog timeout (missed Tx interrupts
...@vpn.xxx.com.br:/usr/obj/usr/src/sys/VPN i386
Nov 8 11:53:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts)
-- recovering
Nov 8 12:01:21 vpn kernel: xl0: watchdog timeout (missed Tx interrupts)
-- recovering
Nov 8 12:21:55 vpn kernel: xl0: watchdog timeout (missed Tx interrupts
1 - 100 of 387 matches
Mail list logo
