New: Link state change detection problem on Moschip MCS7832 [mcs7830]
Subsystems (2)
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 33 lines · On Mon, 7 Feb 2011 18:14:56 GMT bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7…
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/[email protected] ReportedBy: [email protected] Regression: NoCreated an attachment (id=46752)
--> (https://bugzilla.kernel.org/attachment.cgi?id=46752)
lsusb -vv outputHi.
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?
Quoted 8 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Quoted 7 lines
Quoted 7 lines
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.
Quoted 4 lines
Quoted 4 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · Andreas Mohr
Hi,
Quoted 7 lines
Quoted 7 lines
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
Quoted 34 lines
.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.
Quoted 4 lines
Quoted 4 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html