Bug 28532

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Mon, 7 Feb 2011 18:14:56 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=28532
> 
>            Summary: Link state change detection problem on Moschip MCS7832
>                     [mcs7830]
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 2.6.38-rc2
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Network
>         AssignedTo: drivers_network@kernel-bugs.osdl.org
>         ReportedBy: myxal.mxl@gmail.com
>         Regression: No
> 
> 
> Created an attachment (id=46752)
>  --> (https://bugzilla.kernel.org/attachment.cgi?id=46752)
> lsusb -vv output
> 
> Hi.
> 
> I have a network adapter which uses the aforementioned driver and while
> checking for the link state via ethtool reports the correct state, many
> networking userspace utilities seem to have no clue about it (NM 0.8.1 starts
> dhclient BEFORE any cable is plugged) - and more importantly, don't notice
> when
> the cable is (dis)connected. Since there's not even a kernel message when
> (dis)connecting the cable, I suspect the driver does not implement Link state
> change detection at all. Is this accurate?
> 
> LSCD works in Windows, where it's apparently implemented through periodic
> polling (judging by virtualbox's blinking USB icon).
> How is this situation normally handled? Is it kernel's job to do the polling?
> Or are userspace utilities expected to do this?
> 
> Docs to the chip are available here:
> http://www.moschip.com/data/products/MCS7830/Data%20Sheet_7830.pdf
>

Hi,

> > I have a network adapter which uses the aforementioned driver and while
> > checking for the link state via ethtool reports the correct state, many
> > networking userspace utilities seem to have no clue about it (NM 0.8.1
> starts
> > dhclient BEFORE any cable is plugged) - and more importantly, don't notice
> when
> > the cable is (dis)connected. Since there's not even a kernel message when
> > (dis)connecting the cable, I suspect the driver does not implement Link
> state
> > change detection at all. Is this accurate?

Ah, perhaps that is why as long as network-mangler is running, my
.resume_reset() handler improvements (managing to keep an active interface
even directly after resume) actually do _not_ work (since it seems it simply
down:s the iface and that's it).
I know that there is link info functionality in other drivers yet not
as much in mcs7830.

Note that the mcs7830 driver still has a rather stubby appearance
(many more "advanced" features are either weak or not available at all).

I've got a patch series sitting here to improve several parts
(and waiting to cook a bit more), but I hadn't even identified the link issue.
It appears that this would need fixing, presto.

> > LSCD works in Windows, where it's apparently implemented through periodic
> > polling (judging by virtualbox's blinking USB icon).
> > How is this situation normally handled? Is it kernel's job to do the
> polling?
> > Or are userspace utilities expected to do this?

I'm afraid a painful solution would be to activate the .status callback
for periodic USB status descriptor polling. I've got a
half-implementation of that, however it's very painful in terms of
obscene amounts of CPU wakeups.
There _has_ to be a better solution...

Thank you for your (the OP's) report (and for my extra notification!),
this seems very helpful!
(I am determined to post related useful patches soon,
especially since this card is in active use here)

Andreas Mohr

On Tue, 2011-02-08 at 21:52 +0100, Andreas Mohr wrote:
> Hi,
> 
> > > I have a network adapter which uses the aforementioned driver and while
> > > checking for the link state via ethtool reports the correct state, many
> > > networking userspace utilities seem to have no clue about it (NM 0.8.1
> starts
> > > dhclient BEFORE any cable is plugged) - and more importantly, don't
> notice when
> > > the cable is (dis)connected. Since there's not even a kernel message when
> > > (dis)connecting the cable, I suspect the driver does not implement Link
> state
> > > change detection at all. Is this accurate?
> 
> Ah, perhaps that is why as long as network-mangler is running, my

If the driver does not support link detection, NM can only assume that
the device always has a carrier.  NM actually just uses the 'carrier'
flag from netlink, and since drivers that don't support link detection
never set the carrier flag to 0, carrier is always 1 as seen by NM.  If
the device says it has a carrier, that means stuff that listens for that
(ie, NM, ifplugd, whatever) will try to configure IP on the device.

Drivers should really, really support link detection.

Dan

> .resume_reset() handler improvements (managing to keep an active interface
> even directly after resume) actually do _not_ work (since it seems it simply
> down:s the iface and that's it).
> I know that there is link info functionality in other drivers yet not
> as much in mcs7830.
> 
> Note that the mcs7830 driver still has a rather stubby appearance
> (many more "advanced" features are either weak or not available at all).
> 
> I've got a patch series sitting here to improve several parts
> (and waiting to cook a bit more), but I hadn't even identified the link
> issue.
> It appears that this would need fixing, presto.
> 
> > > LSCD works in Windows, where it's apparently implemented through periodic
> > > polling (judging by virtualbox's blinking USB icon).
> > > How is this situation normally handled? Is it kernel's job to do the
> polling?
> > > Or are userspace utilities expected to do this?
> 
> I'm afraid a painful solution would be to activate the .status callback
> for periodic USB status descriptor polling. I've got a
> half-implementation of that, however it's very painful in terms of
> obscene amounts of CPU wakeups.
> There _has_ to be a better solution...
> 
> Thank you for your (the OP's) report (and for my extra notification!),
> this seems very helpful!
> (I am determined to post related useful patches soon,
> especially since this card is in active use here)
> 
> Andreas Mohr
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

A patch referencing this bug report has been merged in Linux v3.5-rc1:

commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113
Author: Ondrej Zary <linux@rainbow-software.org>
Date:   Fri Jun 1 10:29:08 2012 +0000

    mcs7830: Implement link state detection