Bug 219927 - awg0 stops working after a long output under ssh
Summary: awg0 stops working after a long output under ssh
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm64 Any
: --- Affects Only Me
Assignee: Oleksandr Tymoshenko
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2017-06-11 14:23 UTC by Henri Hennebert
Modified: 2019-01-21 19:36 UTC (History)
5 users (show)

See Also:


Attachments
Patch to raise TX_MAX_SEGS from 10 to 20 (1.07 KB, patch)
2017-06-12 13:18 UTC, Tom Vijlbrief
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Henri Hennebert 2017-06-11 14:23:36 UTC
Environment: pine64+ 2GB
FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318945M: Sat Jun 10 11:47:44 CEST 2017     root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY  arm64

If I connect from a wireless computer (FreeBSD 11.1-PRERELEASE #0 r318860) and run a command with a big output (eg `find /`) the awg0 stops working quickly (under 20 seconds of output).

If I do the same with telnet from the same computer, the output is much longer but awg0 stops working.

If I do the same from a wired computer then I must run `find /` 2 or 3 times before awg0 stops working.

I can rsync through ssh 12GB without problem in both directions (from and to the pine64 and the wireless computer).

I have a `tcpdump -w ssh.data port 22`. (8.3 MB)

I can connect with a serial console to the pine64 after awg0 stop working.
ifconfig awg0 down
ifconfig awg0 up
don't restore the connectivity. I must reboot to restore connectvity.

Henri
Comment 1 Tom Vijlbrief 2017-06-12 13:18:10 UTC
Created attachment 183433 [details]
Patch to raise TX_MAX_SEGS from 10 to 20

Raise TX_MAX_SEGS from 10 to 20 for the if_awg.c driver.

In addition add some diagnostic printfs to prevent silent failure in the future.

Raising TX_MAX_SEGS has a modest impact on the kernel stack usage.
Comment 2 Henri Hennebert 2017-06-13 10:54:40 UTC
I can confirm that this patch solves the problem

Henri
Comment 3 commit-hook freebsd_committer freebsd_triage 2017-11-04 23:28:18 UTC
A commit references this bug:

Author: gonzo
Date: Sat Nov  4 23:28:02 UTC 2017
New revision: 325410
URL: https://svnweb.freebsd.org/changeset/base/325410

Log:
  Increase TX_MAX_SEGS from 10 to 20 for the if_awg.c driver

  Under certain traffic pattern awg driver does not recover from TX queue
  full condition. The actual source of the problem is not identified yet
  but jmcneill@ agreed that bumping TX_MAX_SEGS to 20 is OK as a workaround
  for the problem (NetBSD has it set to 128).

  Also add some diagnostic printfs to prevent silent failure of bus_dma
  functions in the future

  PR will be kept open until root cause of the issue is identified and fixed

  PR:		219927
  Submitted by:	Tom Vijlbrief <tvijlbrief@gmail.com>
  Approved by:	jmcneill
  MFC after:	2 weeks

Changes:
  head/sys/arm/allwinner/if_awg.c
Comment 4 commit-hook freebsd_committer freebsd_triage 2018-02-20 18:12:40 UTC
A commit references this bug:

Author: gonzo
Date: Tue Feb 20 18:12:07 UTC 2018
New revision: 329648
URL: https://svnweb.freebsd.org/changeset/base/329648

Log:
  MFC r325410:

  Increase TX_MAX_SEGS from 10 to 20 for the if_awg.c driver

  Under certain traffic pattern awg driver does not recover from TX queue
  full condition. The actual source of the problem is not identified yet
  but jmcneill@ agreed that bumping TX_MAX_SEGS to 20 is OK as a workaround
  for the problem (NetBSD has it set to 128).

  Also add some diagnostic printfs to prevent silent failure of bus_dma
  functions in the future

  PR will be kept open until root cause of the issue is identified and fixed

  PR:		219927
  Submitted by:	Tom Vijlbrief <tvijlbrief@gmail.com>
  Approved by:	jmcneill

Changes:
_U  stable/11/
  stable/11/sys/arm/allwinner/if_awg.c