Bug 125792 - 3c59x driver polls link status too slowly
3c59x driver polls link status too slowly
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-06-11 10:31 EDT by Dan Williams
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-11 20:45:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dan Williams 2004-06-11 10:31:26 EDT
Kernel 2.6.6-1.422, Dell Latitude LS PP01S (PIII 500)

Onboard 3Com 3c905c-TX/TX-M [Tornado] (rev 78)
PCCard 3Com 3cCFE575CT (also used 3c59x driver)

Neither of these cards get their link status reported by netlink
sockets.  Using ifplugd as a test (and a specialized test program), a
netlink socket is created and select()-ed on in the main loop. 
However, the file descriptor of the netlink socket only had readable
data once, during the first select (or soon thereafter).  Subsequent
cable connects/disconnects from the onboard card have no effect and
the file descriptor no longer ever has any data waiting.

mii-tool correctly reports link status for these cards, so they
definitely have mii registers which are readable and correct, but
netlink never notifies the user-space program that the socket has any
data waiting.
Comment 1 Dan Williams 2004-06-11 11:22:40 EDT
Ok, the problem is not that it never gets called, but that it only
gets called every minute.  The vortex_timer() function has the line

mod_timer(&vp->timer, RUN_AT(next_tick));

Which arjan says is 1 minute (next_tick = 60 * HZ).  That's really too
long of a wait...
Comment 2 Dan Williams 2004-06-14 10:27:17 EDT
Arjan's 2.6.6-1.434 seems to work acceptably
Comment 3 Dave Jones 2004-06-14 20:18:46 EDT
is this a dupe of #119965 ?
Comment 4 Dan Williams 2004-09-11 20:45:51 EDT
Dave: not a dupe, different driver AFAICT.  Anyway, its fixed now
upstream, closing.

Note You need to log in before you can comment on or make changes to this bug.