Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Jan 2015 11:51:30 +0100
From:      Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
To:        Jack Vogel <jfvogel@gmail.com>
Cc:        FreeBSD Stable <freebsd-stable@freebsd.org>
Subject:   Re: igb(4) watchdog timeout, lagg(4) fails
Message-ID:  <54B10432.8050909@omnilan.de>
In-Reply-To: <CAFOYbcn0F1QXajUZ2XOncSg8z9xjuCQtzC=Siteyrq%2BDkvAw-A@mail.gmail.com>
References:  <54ACC6A2.1050400@omnilan.de> <54AE565D.50208@omnilan.de> <54AE5A6B.7040601@omnilan.de> <54AFA784.6020102@omnilan.de> <CAFOYbcn0F1QXajUZ2XOncSg8z9xjuCQtzC=Siteyrq%2BDkvAw-A@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD1C941E7404D34A3D89F0F8E
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

 Bez=FCglich Jack Vogel's Nachricht vom 09.01.2015 18:46 (localtime):
> The tuneable interrupt rate code is not mine, and looking at it I'm not=

> entirely
> sure it works. Why are you focused on the interrupt rate anyway, do you=
 have
> some reason to tie it to the watchdog?
>
> You could turn AIM off (enable_aim) and see if that changed anything?
>
> It seems most the time problems show up they involve the use of lagg, i=
f you
> take it out of the mix does the problem go away?

Thanks for your attention!

Unfortunately I can't test anything without lagg(4), this machine is in
production (with lagg(4) being parent of lots of vlan-interfaces).
I guess the watchdog timeout is more often reported by people with
lagg(4) in use for the reason that that's where igb(4) really get's some
(peak-)load ;-) Serious, I can't see how lagg(4) should be the culprit
for watchdog timeots, but stuck interrupts was my first guess.
Especially since I'm doing the kld-reload-trick to get msi-x working
inside ESXi (reported 2 years ago that booting FreeBSD initializes the
passthrough device with some kind of wrong device-type-identifier;
warmbooting the guest or simply kld-reloading solves this problem, the
hypervisor then get's the correct device-type-indicator (for using msi-x)=
).
Like mentioned this has been working without any issue for more than one
year with FreeBSD 9.1.
I have another machine with kawela cards and similar setup, but without
load at all. I'll see if I can reproduce the problem there and narrow it
down by removing lagg(4).

Is there a way to reset the interface without rebooting the machine? The
watchdog doesn't really reset the device, it's in non-operating state
afterwards. I need to 'ifconfig down' it for bringin lagg(4) back into
operational state.
Some kind of D3D0-state switch for a single address? kldunloading would
destroy the remaining interface too=85

Thanks,

-Harry


--------------enigD1C941E7404D34A3D89F0F8E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAlSxBDsACgkQLDqVQ9VXb8hfdgCgyWAiS3Cvutnrs5pX073E8AG9
QzEAn1A3pfZDYzb6nCmpSVuoyleMPWnZ
=dxB3
-----END PGP SIGNATURE-----

--------------enigD1C941E7404D34A3D89F0F8E--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54B10432.8050909>