Re: [Bugme-new] [Bug 28532] New: Link state change detection problem on Moschip MCS7832 [mcs7830]

Re: [Bugme-new] [Bug 28532] New: Link state change detection problem on Moschip MCS7832 [mcs7830]

[Andrew Morton]

(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-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.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-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
>         ReportedBy: myxal.mxl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>         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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 28532] New: Link state change detection problem on Moschip MCS7832 [mcs7830]

[Andreas Mohr]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 28532] New: Link state change detection problem on Moschip MCS7832 [mcs7830]

[Dan Williams]

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