Bug 124225 - [ndis] [patch] ndis network driver sometimes loses network connection
Summary: [ndis] [patch] ndis network driver sometimes loses network connection
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2008-06-03 03:10 UTC by Tor Egge
Modified: 2022-10-17 12:35 UTC (History)
0 users

See Also:


Attachments
file.diff (1.46 KB, patch)
2008-06-03 03:10 UTC, Tor Egge
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tor Egge 2008-06-03 03:10:02 UTC
Normally, when packets are queued to the ndis network interface, ndis_start()
is called to move packets from the interface send queue to the underlying
NDIS driver.

If the network link is down or the underlying driver is busy transmitting data,
ndis_start() just returns.

When the link goes up, ndis_starttask() is supposed to be called after
ndis_ticktask() in order to transmit already queued packets.

After a watchdog timeout, ndis_starttask() is likewise supposed to be called
after ndis_resettask().

Unfortunately, work items used for triggering calls to ndis_ticktask(),
ndis_starttask() and ndis_resettask() are placed on separarate task lists which
are handled by separate kernel processes, thus losing ordering information
about when the tasks should be performed in relation to each other.

If the interface send queue is full after a watchdog timeout or link up event
and the tasks were handled in the wrong order then further attempts to send
packets via the interface results in ENOBUFS ("No buffer space available").

Fix: A proper fix is to ensure that related tasks are handled in the correct order.

The following kludge justs add extra attempts at scheduling calls to
ndis_starttask() as part of the processing of ndis_ticktask() and
ndis_resettask().  It depends on defensive coding in IoQueueWorkItem(),
i.e. that nothing is done if the work item is already queued.
How-To-Repeat: 
Use the ndis driver for a wireless network card in an area with many APs on
nearby channels and on a machine with many active tcp connections, causing link
to temporarily go down every few hours, and the interface send queue to be
filled while the link is temporarily down.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2008-06-03 03:46:09 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 Coleman Kane freebsd_committer freebsd_triage 2008-07-02 15:56:51 UTC
Responsible Changed
From-To: freebsd-net->cokane

PR refers to a recent commit of changes that I made, I will look 
into solving this problem in my development branch.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2010-03-20 02:37:53 UTC
Responsible Changed
From-To: cokane->freebsd-net

returned to the pool by request (some time ago.)
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:29 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 5 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:35:22 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>