New: g_ether no carrier while it is

Bugme-new Andrew Morton 3 participants 4 messages Aug 24, 2010 – Aug 25, 2010 4 messages not in the archive

Subsystems (2)

Share & tools

A message that is not in the archive (sent off-list or not yet received): [email protected]/

A message that is not in the archive (sent off-list or not yet received): bug-16821-10286-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/

Andrew Morton

author

2010-08-24 23:40 UTC #2 lore raw

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

Quoted 18 lines · On Mon, 23 Aug 2010 06:24:16 GMT bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq…

https://bugzilla.kernel.org/show_bug.cgi?id=16821

           Summary: g_ether no carrier while it is
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.3(2 - ok, 3?, 4-6 - fail)
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: blocking
          Priority: P1
         Component: Other
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: Yes

Quoted 6 lines

After successfully loaded g_ether module (with use_eem=0) usb device appears. If I configure it at host as ifconfig usb0 blah bah, than network present, all ok.
In windows (with RNDIS config), and in linux with bridge it looks to CARRIER state. I get in ip addr state DOWN, NO-CARRIER. That's why g_ether usb device in bridge and windows don't work at all.

So g_ether broke after 2.6.32?

Nobody really seems to do much with that USB driver. I wonder if some changes in core networking could have triggered this?

--
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

A message that is not in the archive (sent off-list or not yet received): 20100824164006.0bd7b7e8.akpm-de/[email protected]

David Brownell

2010-08-25 05:38 UTC #4 lore raw

Quoted 47 lines · Andrew Morton

From: Andrew Morton <akpm-de/[email protected]>
Subject: Re: [Bugme-new] [Bug 16821] New: g_ether no carrier while it is
To: [email protected], [email protected]
Cc: bugzilla-daemon-590EEB7GvNiWaY/[email protected], [email protected], "Greg KH" <[email protected]>, "David Brownell" <[email protected]>, [email protected]
Date: Tuesday, August 24, 2010, 4:40 PM
(switched to email. Please respond via emailed
reply-to-all, not via the
bugzilla web interface).
Quoted 3 lines · On Mon, 23 Aug 2010 06:24:16 GMT bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq…
https://bugzilla.kernel.org/show_bug.cgi?id=16821
Summary:
g_ether no carrier while it is
Quoted 1 line
Product:
Networking
Quoted 2 lines
Version: 2.5
   Kernel Version: 2.6.3(2 - ok,
3?, 4-6 - fail)
Quoted 1 line
   Platform:
All
Quoted 1 line
   OS/Version:
Linux
Quoted 1 line
   Tree: Mainline
Quoted 1 line
   Status: NEW
Quoted 1 line
   Severity:
blocking
Quoted 1 line
   Priority:
P1
Quoted 7 lines
Component: Other
   AssignedTo: [email protected]
   ReportedBy: [email protected]
   Regression: Yes
After successfully loaded g_ether module (with
use_eem=0) usb device appears.
Quoted 1 line
If I configure it at host as ifconfig usb0 blah bah,
than network present, all
Quoted 2 lines
ok.
In windows (with RNDIS config), and in linux with

Quoted 8 lines

bridge it looks to CARRIER
Quoted 1 line
state. I get in ip addr state DOWN, NO-CARRIER. That's
why g_ether usb device
Quoted 1 line
in bridge and windows don't work at all.
So g_ether broke after 2.6.32?
Nobody really seems to do much with that USB driver.

That's changed then. There used to be boxes that
relied on it for their network connectivity...

Adding EEM support was something... I think the
issue might be driver changes since last it was
seriously tested in bridge configs (for which
the link state, such as carrier, matters LOTS.)

Quoted 2 lines

I wonder if some
changes in core networking could have triggered this?

Wouldn't be my first thought; but might be.

ISTR getting link/carrier state to behave in
the first place (with just CDC and RNDIS) was
complex. If it wasn't carefully re-tested after
EEM was added, breakage may have been overlooked.

- Dave

--
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

A message that is not in the archive (sent off-list or not yet received): 559294.8951.qm-g47maUHHHF+ZZBmlwP4mLPu2YVrzzGjVVpNB7YpNyf8@public.gmane.org

Andrew Morton

author

2010-08-25 06:44 UTC #6 lore raw

Quoted 54 lines · On Tue, 24 Aug 2010 22:38:39 -0700 (PDT) David Brownell…

Quoted 50 lines · Andrew Morton
From: Andrew Morton <akpm-de/[email protected]>
Subject: Re: [Bugme-new] [Bug 16821] New: g ether no carrier while it is
To: [email protected], [email protected]
Cc: bugzilla-daemon-590EEB7GvNiWaY/[email protected], bugme-daemon-590EEB7GvNiWaY/[email protected], "Greg KH" <[email protected]>, "David Brownell" <david-b-yBeKhBN/[email protected]>, [email protected]
Date: Tuesday, August 24, 2010, 4:40 PM
(switched to email. Please respond via emailed
reply-to-all, not via the
bugzilla web interface).
Quoted 3 lines · On Mon, 23 Aug 2010 06:24:16 GMT bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq…
https://bugzilla.kernel.org/show bug.cgi?id=16821
Summary:
g ether no carrier while it is
Quoted 1 line
Product:
Networking
Quoted 2 lines
                 Version: 2.5
        Kernel Version: 2.6.3(2 - ok,
3?, 4-6 - fail)
Quoted 1 line
Platform:
All
Quoted 1 line
OS/Version:
Linux
Quoted 1 line
Tree: Mainline
Quoted 1 line
Status: NEW
Quoted 1 line
Severity:
blocking
Quoted 1 line
Priority:
P1
Quoted 7 lines
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: Yes
After successfully loaded g ether module (with
use eem=0) usb device appears.
Quoted 1 line
If I configure it at host as ifconfig usb0 blah bah,
than network present, all
Quoted 2 lines
ok.
In windows (with RNDIS config), and in linux with
bridge it looks to CARRIER
Quoted 1 line
state. I get in ip addr state DOWN, NO-CARRIER. That's
why g ether usb device

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
in bridge and windows don't work at all.
So g ether broke after 2.6.32?
Nobody really seems to do much with that USB driver.
That's changed then. There used to be boxes that relied on it for their network connectivity...

I meant not much development happens there.

Quoted 4 lines

Adding EEM support was something... I think the issue might be driver changes since last it was seriously tested in bridge configs (for which the link state, such as carrier, matters LOTS.)

Thanks. Let's cc Brian.

Quoted 4 lines

Quoted 3 lines
I wonder if some
changes in core networking could have triggered this?

Quoted 9 lines

Wouldn't be my first thought; but might be.
ISTR getting link/carrier state to behave in the first place (with just CDC and RNDIS) was complex. If it wasn't carefully re-tested after EEM was added, breakage may have been overlooked.
- Dave

--
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

Brian Niebuhr

2010-08-25 14:42 UTC #7 lore raw

Quoted 83 lines

-----Original Message-----
From: Andrew Morton [mailto:[email protected]]
Sent: Wednesday, August 25, 2010 1:44 AM
To: David Brownell
Cc: [email protected]; [email protected]; [email protected]; [email protected]; Greg KH; [email protected]; Brian Niebuhr
Subject: Re: [Bugme-new] [Bug 16821] New: g_ether no carrier while it is
Quoted 3 lines · On Tue, 24 Aug 2010 22:38:39 -0700 (PDT) David Brownell <[email protected]>…
--- On Tue, 8/24/10, Andrew Morton
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
From: Andrew Morton <[email protected]>
Subject: Re: [Bugme-new] [Bug 16821] New: g ether no
carrier while it is
Quoted 2 lines
Quoted 2 lines
To: [email protected], [email protected]
Cc: [email protected],
[email protected], "Greg KH" <[email protected]>, "David Brownell" <[email protected]>, [email protected]
Quoted 46 lines
Quoted 46 lines
Date: Tuesday, August 24, 2010, 4:40 PM
(switched to email. Please respond via emailed
reply-to-all, not via the
bugzilla web interface).
Quoted 3 lines · On Mon, 23 Aug 2010 06:24:16 GMT [email protected] wrote:
https://bugzilla.kernel.org/show bug.cgi?id=16821
Summary:
g ether no carrier while it is
Quoted 1 line
Product:
Networking
Quoted 2 lines
                 Version: 2.5
        Kernel Version: 2.6.3(2 - ok,
3?, 4-6 - fail)
Quoted 1 line
Platform:
All
Quoted 1 line
OS/Version:
Linux
Quoted 1 line
Tree: Mainline
Quoted 1 line
Status: NEW
Quoted 1 line
Severity:
blocking
Quoted 1 line
Priority:
P1
Quoted 7 lines
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: Yes
After successfully loaded g ether module (with
use eem=0) usb device appears.
Quoted 1 line
If I configure it at host as ifconfig usb0 blah bah,
than network present, all
Quoted 2 lines
ok.
In windows (with RNDIS config), and in linux with
bridge it looks to CARRIER
Quoted 1 line
state. I get in ip addr state DOWN, NO-CARRIER. That's
why g ether usb device
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
in bridge and windows don't work at all.
So g ether broke after 2.6.32?
Nobody really seems to do much with that USB driver.
That's changed then. There used to be boxes that relied on it for their network connectivity...

Quoted 8 lines

I meant not much development happens there.
Quoted 4 lines
Adding EEM support was something... I think the issue might be driver changes since last it was seriously tested in bridge configs (for which the link state, such as carrier, matters LOTS.)
Thanks. Let's cc Brian.

It is possible that I broke something. Most of the changes for EEM were isolated, but I did make a couple of changes to the core ethernet code to make wrap() and unwrap() work correctly for EEM. I don't fully understand the issue being described here, but when I originally submitted the patch I had a couple of concerns I noted that might be related. I'll quote them here:

Issue 1. I changed the semantics of the wrap/unwrap callbacks in struct gether as follows. This change necessitated a modification of the rndis gadget.

wrap():
old semantics: Always copies the sk_buff. Caller is
responsible
for freeing original sk_buff.
new semantics: Only copies if necessary. For EEM it will often
not
be necessary since the 2-byte EEM header should fit within
the
reserved space. wrap() is responsible for freeing the
original
sk_buff, if necessary.

unwrap():
old semantics: sk_buff that comes out is the same is the one
that
went in, only with extra protocol trimmed off.
new semantics: An sk_buff list is returned since one USB request
could have multiple ethernet frames. The sk_buff that was passed in is consumed by unwrap() (or placed on the queue).

Issue 2. The wrap/unwrap callbacks now use port_usb from struct eth_dev, so the appropriate spinlock is held with irqs disabled for the duration of the wrap() or unwrap() callback. I'm thinking that might not be the best idea.

Related to the above issues, there are a couple pieces of code in my patch that may have caused the bug:

- The problem could be in rndis_add_header or rndis_rm_hdr, but I really doubt it. These functions didn't functionally change in any way - the only thing that changed was how the sk_buffs were passed and who was responsible for cleaning them up.

- The most likely source of the issue is in rx_complete() or eth_start_xmit() in u_ether.c where I made the change to use the new wrap/unwrap semantics that were required for EEM. However since I don't totally understand the bug being reported, I'm not sure exactly what the problem could be. I'm willing to help out in any way, but many of you have more experience with this code than I do and may be able to spot some issue that I missed.

Quoted 10 lines

Quoted 10 lines
Quoted 3 lines
I wonder if some
changes in core networking could have triggered this?
Wouldn't be my first thought; but might be.
ISTR getting link/carrier state to behave in the first place (with just CDC and RNDIS) was complex. If it wasn't carefully re-tested after EEM was added, breakage may have been overlooked.

I did not test that particular case, so it is quite possible that I broke something.