Bug 9269
Summary: | (net sunhme) cannot enslave ethernet devices | ||
---|---|---|---|
Product: | Drivers | Reporter: | Chris Poon (dev-null) |
Component: | Network | Assignee: | Jeff Garzik (jgarzik) |
Status: | REJECTED DOCUMENTED | ||
Severity: | normal | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.18-3 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | Patch to call netif_carrier_on/netif_carrier_off |
Description
Chris Poon
2007-10-31 14:35:56 UTC
Had a custom patch to call netif_carrier_on in happy_meal_timer (if hp->sw_bmsr & BMSR_LSTATUS is true) and call netif_carrier_off first thing in happy_meal_begin_auto_negotiation - that seems to make sunhme usable as a slave to a bond Created attachment 13362 [details]
Patch to call netif_carrier_on/netif_carrier_off
Reply-To: akpm@linux-foundation.org On Wed, 31 Oct 2007 14:35:56 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9269 > > Summary: bonding module cannot enslave ethernet devices provided > by sunhme > Product: Drivers > Version: 2.5 > KernelVersion: 2.6.18-3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Network > AssignedTo: jgarzik@pobox.com > ReportedBy: dev-null@telus.net > > > Most recent kernel where this bug did not occur: N/A > Distribution: Debian 4.0r1/stable (Etch) > Hardware Environment: Sun Netra T1 105 (sparc64) > Software Environment: > Problem Description: > bonding module cannot enslave ethernet devices provided by sunhme - link > status is never reported via netif_carrier_on/netif_carrier_off which makes > sunhme not usable as a slave to the bonding module > > Steps to reproduce: > modprobe sunhme > modprobe bonding > ifconfig bond0 up > ifconfig eth0 up > # wait for link to be up > ifenslave bond0 eth0 > # bond0 never comes up and keeps waiting for link > It looks like sunhme supports link status queries via ethtool, so specifying use_carrier=0 to bonding may also resolve the problem. bonding driver must doing something special to check the link as use_carrier=0 doesn't seem to work for me as that was the first thing I tried IIRC. The bonding driver with use_carrier=0 will try (a) a driver ioctl SIOCGMIIPHY/REG, then (b) a slave_dev->ethtool_ops->get_link and lastly (c) a driver ioctl SIOCETHTOOL ETHTOOL_GLINK. It looks like sunhme.c has an ethtool_ops->get_link (and no ioctl at all, so those would be skipped), so it seems odd that it wouldn't work. I managed to test it last night, and use_carrier=0 will work (The option for the module must not be effective when I last tested it). Although setting use_carrier=0 will work, I feel that adding the netif_carrier calls will make it work under the bonding driver with default settings |