Bug 125792

Summary: 3c59x driver polls link status too slowly
Product: [Fedora] Fedora Reporter: Dan Williams <dcbw>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-12 00:45:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Williams 2004-06-11 14:31:26 UTC
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 15:22:40 UTC
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 14:27:17 UTC
Arjan's 2.6.6-1.434 seems to work acceptably

Comment 3 Dave Jones 2004-06-15 00:18:46 UTC
is this a dupe of #119965 ?


Comment 4 Dan Williams 2004-09-12 00:45:51 UTC
Dave: not a dupe, different driver AFAICT.  Anyway, its fixed now
upstream, closing.