Hi Gregor,
I use the same revision than yours :
- "Intel 82583V" rev 0x00: msi
Regards,
Alexis VACHETTE.*
*
On 16/11/2015 10:12, Alexis VACHETTE wrote:
> Hi Gregor,
>
> Thank you for your feedback.
>
> Did you have some timeout on 5.6 ?
>
> On amd64 version, I experienced some on heavy network l
Hi Gregor,
Thank you for your feedback.
Did you have some timeout on 5.6 ?
On amd64 version, I experienced some on heavy network load. Is it related ?
Regards,
Alexis VACHETTE.
On 11/11/2015 21:19, Gregor Best wrote:
Hi Alexis,
On Wed, Nov 11, 2015 at 08:11:15PM +, Alexis VACHETTE wrote:
On Mon, Nov 16, 2015 at 12:05:12AM +1000, David Gwynne wrote:
> On Fri, Nov 13, 2015 at 10:18:51AM -0500, Sonic wrote:
> > On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best wrote:
> > > I've done some further testing and I think I've narrowed it down to the
> > > "Unlocking em(4) a bit further"-patch [
On Fri, Nov 13, 2015 at 10:18:51AM -0500, Sonic wrote:
> On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best wrote:
> > I've done some further testing and I think I've narrowed it down to the
> > "Unlocking em(4) a bit further"-patch [0].
could you try this? its not written with the wdog stuff in mind,
On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best wrote:
> I've done some further testing and I think I've narrowed it down to the
> "Unlocking em(4) a bit further"-patch [0].
That was the start of it for me.
When I could revert to rev 1.305 for if_em.c and rev 1.57 for if_em.h
all was fine. But the
Hi Gregor,
Even with heavy network load ?
Regards,
Alexis.
De : owner-t...@openbsd.org de la part de Gregor Best
Envoyé : mercredi 11 novembre 2015 15:20
À : Mark Kettenis
Cc : t...@openbsd.org; misc@openbsd.org
Objet : Re: em(4) watchdog timeouts
Hi Alexis,
On Wed, Nov 11, 2015 at 08:11:15PM +, Alexis VACHETTE wrote:
> [...]
> Even with heavy network load ?
> [...]
So far, yes. I've saturated the device for about 45 Minutes with
something like this (the other end is my laptop):
## on the router
$ dd if=/dev/zero bs=8k
I've done some further testing and I think I've narrowed it down to the
"Unlocking em(4) a bit further"-patch [0]. With the patch reverted, I
haven't seen any watchdog timeouts yet. I'm currently running the router
with the patch reverted to make sure the timeouts don't happen again.
[0]: https://
On Sun, Nov 08, 2015 at 06:57:23PM +0100, Gregor Best wrote:
> [...]
> If it helps debugging this, I can give SSH access to the router,
> provided that reboots don't happen between 18:00 and 02:00 German time
> too often, since that's when we have larger amounts of visitors in our
> hackerspace.
>
On Mon, Nov 02, 2015 at 09:29:20PM +0100, Gregor Best wrote:
> [...]
> Looks good so far. I've run a few light tests and the usual load that
> caused the timeouts before, haven't seen any yet.
> [...]
I just checked back on the router and it seems that the patch doesn't
help after all :( The numbe
On Wed, Nov 4, 2015 at 2:51 PM, Sonic wrote:
> Is there anything else I can provide to assist in finding a cure for this
> issue?
Not sure this helps at all but the specific error I get is "em0:
watchdog timeout -- resetting". In this case em0 is the nic on the
internal network. I do not see the
On Mon, Nov 2, 2015 at 11:19 PM, Sonic wrote:
> Sorry to report that the diff does not solve the timeout problem here.
>
> All was working fine with the if_em* versions from 2015/09/29 (I
> downgraded to this version per Stuarts post on 10-14):
> "try backing out the last commits to
> if_em.c and
On Mon, Nov 2, 2015 at 2:11 PM, Mark Kettenis wrote:
> Can those that are experiencing watchdog timeouts check if the diff
> below gets rid of them?
Sorry to report that the diff does not solve the timeout problem here.
All was working fine with the if_em* versions from 2015/09/29 (I
downgraded
On 11/02/15 21:23, Sonic wrote:
On Mon, Nov 2, 2015 at 3:29 PM, Gregor Best wrote:
On Mon, Nov 02, 2015 at 08:11:30PM +0100, Mark Kettenis wrote:
Can those that are experiencing watchdog timeouts check if the diff
below gets rid of them?
[...]
Hello,
For whatever reason I see this reply but
On Mon, Nov 2, 2015 at 3:29 PM, Gregor Best wrote:
> On Mon, Nov 02, 2015 at 08:11:30PM +0100, Mark Kettenis wrote:
>> Can those that are experiencing watchdog timeouts check if the diff
>> below gets rid of them?
>> [...]
Hello,
For whatever reason I see this reply but not the original post
con
Can those that are experiencing watchdog timeouts check if the diff
below gets rid of them?
Index: if_em.h
===
RCS file: /home/cvs/src/sys/dev/pci/if_em.h,v
retrieving revision 1.58
diff -u -p -r1.58 if_em.h
--- if_em.h 30 Sep 20
On Mon, Nov 02, 2015 at 08:11:30PM +0100, Mark Kettenis wrote:
> Can those that are experiencing watchdog timeouts check if the diff
> below gets rid of them?
> [...]
Looks good so far. I've run a few light tests and the usual load that
caused the timeouts before, haven't seen any yet.
For the re
Yes, it's much better.
I currently have several 5.2-current (post 5.2-rel ) machines with em(4)
without any problems regarding em(4).
5.0 is EOL.
On 7 mar 2013, at 13:09, Kenneth R Westerback wrote:
> On Thu, Mar 07, 2013 at 12:10:08PM +0100, mxb wrote:
>> What about 5.2? Same issues?
>
>
On Thu, Mar 07, 2013 at 12:10:08PM +0100, mxb wrote:
> What about 5.2? Same issues?
Even better, what about -current or 5.3 snaps?
Ken
On 03/07/2013 01:10 PM, mxb wrote:
What about 5.2? Same issues?
//mxb
I don't know.
This is remote host1 and it holds IPSec with another host2.
When issue come - network behind host2 can't reach resources
behind host1.
What about 5.2? Same issues?
//mxb
On 7 mar 2013, at 11:36, lilit-aibolit wrote:
> On 11/09/2011 10:27 PM, Jussi Peltola wrote:
>> You can ignore the clueless parts in my previous message :)
>>
>> I can set up remote access to one of these machines if needed.
>>
>> This made the ems work agai
On 11/09/2011 10:27 PM, Jussi Peltola wrote:
You can ignore the clueless parts in my previous message :)
I can set up remote access to one of these machines if needed.
This made the ems work again:
--- if_em.c.origWed Nov 9 21:37:39 2011
+++ if_em.c Wed Nov 9 21:39:01 2011
@@ -33
unless there is some special trick for 82571 that isn't necessary for newer
chips,
if (sc->hw.mac_type < em_82572)
...
Jussi Peltola [pe...@pelzi.net] wrote:
> You can ignore the clueless parts in my previous message :)
>
> I can set up remote access to one of these machines if needed.
>
> Th
You can ignore the clueless parts in my previous message :)
I can set up remote access to one of these machines if needed.
This made the ems work again:
--- if_em.c.origWed Nov 9 21:37:39 2011
+++ if_em.c Wed Nov 9 21:39:01 2011
@@ -331,6 +331,2 @@
- /* Only use MSI on the
My em(4)'s stopped working with 5.0 - has anyone seen this on 82571EBs?
I'll try backing out the MSO patch.
Perhaps this is related:
ftp://download.intel.com/design/network/specupdt/82571eb_72ei.pdf
Page 22, Errata 7: Device Transmit Operation Might Halt in TCP
Segmentation Offload (TSO) Mode whe
25 matches
Mail list logo
