RE: CDCether.c

RE: CDCether.c

[Michael Duane]

I have duplicated the problem with a stock Redhat 7.3
installation using a Toshiba PCX2200 cable modem connected
to standard PC hardware via USB


> -----Original Message-----
> From: Michael Duane 
> Sent: Thursday, September 19, 2002 8:23 AM
> To: Brad Hards; linux-kernel@vger.kernel.org
> Subject: RE: CDCether.c
> 
> 
> 
> 
> > -----Original Message-----
> > From: Brad Hards [mailto:bhards@bigpond.net.au]
> > Sent: Wednesday, September 18, 2002 11:21 PM
> > To: Michael Duane; linux-kernel@vger.kernel.org
> > Subject: Re: CDCether.c
> > 
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Thu, 19 Sep 2002 09:49, Michael Duane wrote:
> > > Who is the maintainer of CDCEther.c?  I am having a problem
> > > with packets getting "wedged" somewhere on the way out
> > > and need to know if others have reported this problem.
> > Others have reported probems that normally look something 
> > like "it works fine 
> > for some minutes to days, and then all connectivity stops, 
> > till I reboot or 
> > re-insert the module", but I can't duplicate. Does this match 
> > your problem?
> 
> No, this is quite different. It appears to be a function of packet 
> size. ping -s <size> <host> will generate packet loss up to 100 
> percent with any size of (86+(64*n)).  All other values work fine.
> tcpdump on the linux side sees multiple packet retries with 
> correct back-off timeing, but the network side never sees the
> packet. Now for the odd part - any network activity on another
> session to the same box will free the "wedged" packet and the
> network will recieve the last packet sent in the linux retry
> sequence.
> 
> I don't know that it is in the CDCEther driver, but here are the
> combinations I have tried:
> 
>     linux -> usb -> cdcether -> broadcom modem -> network : FAILS
>     linux -> usb -> pegasus -> linksys adaptor -> 3com DOCSIS 
> -> network : OKAY
>     windows -> usb -> broadcom driver -> broadcom modem -> 
> network : OKAY
> 
> > 
> > > I'm running the 2.4.17 kernel and using a Broadcom DOCSIS
> > > modem based around a 3345.
> > Most people have reported the problem with Via UHCI chipsets, 
> > and usb-uhci 
> > driver. Does this match your configuration?
> 
> I'm using usb-uhci with an Intel 810e2.  I have tried the 2.4.19
> kernel with the same results. This is a proprietary hardware platform
> and I haven't been able to get the 2.5.36 kernel to boot yet.
> 
> > 
> > You might care to upgrade the kernel too.
> > 
> > Brad
> > 
> > - -- 
> > http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. 
> > Birds in Black.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.6 (GNU/Linux)
> > Comment: For info see http://www.gnupg.org
> > 
> > iD8DBQE9iWzJW6pHgIdAuOMRAvXrAJ9JfDSnx25dKI7yXvQC2XjNEydS+wCgpKMe
> > kSP0H8AB5Sj8Ebo6SGAPVNs=
> > =RTI4
> > -----END PGP SIGNATURE-----
> > 
> > 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

RE: CDCether.c

[Michael Duane]

Think I found the problem.  The following patch is generated on the
2.5.36 code base.  Seems that the ^ will only work where skb->len
is <= ether_dev->data_ep_out_size. (ether_dev->data_ep_out_size is
64 on my modem).

Mike

--- linux-2.5.36/drivers/usb/net/cdc-ether.c	Tue Sep 17 17:58:43 2002
+++ patched/drivers/usb/net/cdc-ether.c	Tue Sep 24 14:24:55 2002
@@ -276,7 +276,7 @@
 	// into an integer number of USB packets, we force it to send one 
 	// more byte so the device will get a runt USB packet signalling the 
 	// end of the ethernet frame
-	if ( (skb->len) ^ (ether_dev->data_ep_out_size) ) {
+	if ( (skb->len) % (ether_dev->data_ep_out_size) ) {
 		// It was not an exact multiple
 		// no need to add anything extra
 		count = skb->len;

> -----Original Message-----
> From: Brad Hards [mailto:bhards@bigpond.net.au]
> Sent: Thursday, September 19, 2002 2:12 PM
> To: Michael Duane; linux-kernel@vger.kernel.org
> Subject: Re: CDCether.c
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 20 Sep 2002 01:22, Michael Duane wrote:
> > No, this is quite different. It appears to be a function of packet
> > size. ping -s <size> <host> will generate packet loss up to 100
> > percent with any size of (86+(64*n)).  All other values work fine.
> > tcpdump on the linux side sees multiple packet retries with
> > correct back-off timeing, but the network side never sees the
> > packet. Now for the odd part - any network activity on another
> > session to the same box will free the "wedged" packet and the
> > network will recieve the last packet sent in the linux retry
> > sequence.
> Ahh, maybe a missing zero length packet problem.  I'll take 
> another look.
> 
> Brad
> 
> 
> - -- 
> http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. 
> Birds in Black.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE9ij2RW6pHgIdAuOMRAmgqAJwPPipMhYxO2QQ0L1VB6yXJtbX8GQCdGpvw
> mWRRiqjOTJUmYWsXLyghSgo=
> =LRBZ
> -----END PGP SIGNATURE-----
> 
> 

Re: CDCether.c

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 20 Sep 2002 01:22, Michael Duane wrote:
> No, this is quite different. It appears to be a function of packet
> size. ping -s <size> <host> will generate packet loss up to 100
> percent with any size of (86+(64*n)).  All other values work fine.
> tcpdump on the linux side sees multiple packet retries with
> correct back-off timeing, but the network side never sees the
> packet. Now for the odd part - any network activity on another
> session to the same box will free the "wedged" packet and the
> network will recieve the last packet sent in the linux retry
> sequence.
Ahh, maybe a missing zero length packet problem.  I'll take another look.

Brad


- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ij2RW6pHgIdAuOMRAmgqAJwPPipMhYxO2QQ0L1VB6yXJtbX8GQCdGpvw
mWRRiqjOTJUmYWsXLyghSgo=
=LRBZ
-----END PGP SIGNATURE-----

RE: CDCether.c

[Michael Duane]

> -----Original Message-----
> From: Brad Hards [mailto:bhards@bigpond.net.au]
> Sent: Wednesday, September 18, 2002 11:21 PM
> To: Michael Duane; linux-kernel@vger.kernel.org
> Subject: Re: CDCether.c
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 19 Sep 2002 09:49, Michael Duane wrote:
> > Who is the maintainer of CDCEther.c?  I am having a problem
> > with packets getting "wedged" somewhere on the way out
> > and need to know if others have reported this problem.
> Others have reported probems that normally look something 
> like "it works fine 
> for some minutes to days, and then all connectivity stops, 
> till I reboot or 
> re-insert the module", but I can't duplicate. Does this match 
> your problem?

No, this is quite different. It appears to be a function of packet 
size. ping -s <size> <host> will generate packet loss up to 100 
percent with any size of (86+(64*n)).  All other values work fine.
tcpdump on the linux side sees multiple packet retries with 
correct back-off timeing, but the network side never sees the
packet. Now for the odd part - any network activity on another
session to the same box will free the "wedged" packet and the
network will recieve the last packet sent in the linux retry
sequence.

I don't know that it is in the CDCEther driver, but here are the
combinations I have tried:

    linux -> usb -> cdcether -> broadcom modem -> network : FAILS
    linux -> usb -> pegasus -> linksys adaptor -> 3com DOCSIS -> network : OKAY
    windows -> usb -> broadcom driver -> broadcom modem -> network : OKAY

> 
> > I'm running the 2.4.17 kernel and using a Broadcom DOCSIS
> > modem based around a 3345.
> Most people have reported the problem with Via UHCI chipsets, 
> and usb-uhci 
> driver. Does this match your configuration?

I'm using usb-uhci with an Intel 810e2.  I have tried the 2.4.19
kernel with the same results. This is a proprietary hardware platform
and I haven't been able to get the 2.5.36 kernel to boot yet.

> 
> You might care to upgrade the kernel too.
> 
> Brad
> 
> - -- 
> http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. 
> Birds in Black.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE9iWzJW6pHgIdAuOMRAvXrAJ9JfDSnx25dKI7yXvQC2XjNEydS+wCgpKMe
> kSP0H8AB5Sj8Ebo6SGAPVNs=
> =RTI4
> -----END PGP SIGNATURE-----
> 
> 

Re: CDCether.c

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 19 Sep 2002 09:49, Michael Duane wrote:
> Who is the maintainer of CDCEther.c?  I am having a problem
> with packets getting "wedged" somewhere on the way out
> and need to know if others have reported this problem.
Others have reported probems that normally look something like "it works fine 
for some minutes to days, and then all connectivity stops, till I reboot or 
re-insert the module", but I can't duplicate. Does this match your problem?

There are some races, but I can't explain the problem from them. I do need to 
fix the races, but I only do this when I have some spare time (after work, 
SO, and some other hobbies).

> I'm running the 2.4.17 kernel and using a Broadcom DOCSIS
> modem based around a 3345.
Most people have reported the problem with Via UHCI chipsets, and usb-uhci 
driver. Does this match your configuration?

You might care to upgrade the kernel too.

Brad

- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9iWzJW6pHgIdAuOMRAvXrAJ9JfDSnx25dKI7yXvQC2XjNEydS+wCgpKMe
kSP0H8AB5Sj8Ebo6SGAPVNs=
=RTI4
-----END PGP SIGNATURE-----

Re: CDCether.c

[Greg KH]

On Wed, Sep 18, 2002 at 04:49:52PM -0700, Michael Duane wrote:
> Who is the maintainer of CDCEther.c?  I am having a problem
> with packets getting "wedged" somewhere on the way out
> and need to know if others have reported this problem.

>From the MAINTAINERS file:
	USB CDC ETHERNET DRIVER
	P:      Brad Hards
	M:      bradh@frogmouth.net
	L:      linux-usb-users@lists.sourceforge.net
	L:      linux-usb-devel@lists.sourceforge.net
	S:      Maintained

thanks,

greg k-h

CDCether.c

[Michael Duane]

Who is the maintainer of CDCEther.c?  I am having a problem
with packets getting "wedged" somewhere on the way out
and need to know if others have reported this problem.

I'm running the 2.4.17 kernel and using a Broadcom DOCSIS
modem based around a 3345.

Mike