USB2 backport from 2.4.27 to 2.4.4/2.4.18/2.4.20

[burbinator]

On the suggestion of alldeadhomiez I put together a script that compiles the linux-wlan-ng modules within the 2.4.27 backport framework. I have successfully compiled wlan-ng with respect to all 3 kernel versions, and have further confirmed that the newly compiled 2.4.4 modules do work in my dtivo running 3.1.1b. A copy of this script is included with the message, and it pretty much operates on the same assumptions about cross-compilers and kernel source locations as the 2.4.27 usb code.

Note that while wlan-ng only creates 2 kernel modules (p80211.o and prism_usb.o), it also creates a number of binaries, scripts, and user-modifiable configuration files in order to support the prism chipset wireless communcations process. More info on this concept of operations can be found in the documentation for linux-wlan-ng and in the README files accompanying the original prism drivers that I originally posted on these forums.

I do not plan on posting any binaries of these modules or new tpm distributions of the full linux-wlan-ng due to the experimental nature of these latest drivers.

10/21/2004: I re-uploaded the script to correct a bug that was dumping 2.4.4 modules into 2.4.18 and 2.4.20 dirs.

[burbinator]

I had to re-upload the previous script because it was copying 2.4.4 modules into the 2.4.18 and 2.4.20 dirs. Be sure to perform a ``strings'' and fgrep for '2.4' to confirm that the versions are as expected. Sorry for not catching the bug sooner.

[alldeadhomiez]

20041024 version now posted:

2004/10/24 burbinator

 - Merged in linux-wlan-ng v0.2.1pre22 prism2 drivers
 - Created test/setup_wlan.sh script to build linux-wlan-ng in this tree

2004/10/24 alldeadhomiez

 - Updated at76c503 driver to the latest CVS version from berlios.de
 - Changed interface name from wlan%d to eth%d
 - Fixed an unaligned access nag

Notes:

• tested with at76c503-rfmd and at76c503-i3861 adapters under 2.4.20
• possible intermittent kernel panic on i3861 device initialization? I can't recreate this.
• prism2 stuff is untested (but presumably the same as the 0.2.1pre22 objects burbinator has posted)
• 2.4.4 and 2.4.18 are untested, but nothing really changed
• usbdfu has changed its name to at76_usbdfu
• archive is now two .tar.bz2's because the .zip got too big
• looking into ways to provide iw* utilities that work with all three WIRELESS_EXT versions (11, 12, and 14). Unfortunately CONFIG_NET_RADIO is a bool so linux/net/core/wireless.c is compiled into the kernel.

[ronnythunder]

Originally Posted by Jamie

Bottom line: you gain about 20% in throughput by running a kernel that has CONFIG_NET_FILTER and CONFIG_FILTER turned off.

good find, jamie. i can confirm about a 25% increase while pulling from an hd tivo to pc (both tserver and mfs_ftp have similar increases) with these turned off.

quite handy when the show you're extracting is almost 16gb

ronny

[alldeadhomiez]

Changes in 20050104:

2005/01/04 alldeadhomiez

 - Added Series2.5/Gen04/Uma2c support
 - Changed obj/ layout to accommodate Series2.0 and Series2.5 host drivers
 - Stripped ifconfig binary

Also, a few new sections have been added to the README; please familiarize yourself with them.

Here are my Series2.5 benchmarks, performed on a Humax DRT800:

ax8817x, drt800, netfilter disabled, stock ohci drivers, pc->tivo, kernel 2.4.20, Xterasys generic ax8817x (0x7b8/0x420a)

# netperf -t TCP_STREAM -H humax -l 60
TCP STREAM TEST to humax
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    60.02       7.54

ax8817x, drt800, netfilter disabled, stock ohci drivers, tivo->pc, kernel 2.4.20, Xterasys generic ax8817x (0x7b8/0x420a)

# netperf -t TCP_STREAM -H peecee -l 60
TCP STREAM TEST to peecee
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    60.12       5.94

usbnet, drt800, netfilter disabled, new ehci drivers, pc->tivo, kernel 2.4.20, Xterasys generic ax8817x (0x7b8/0x420a)

# netperf -t TCP_STREAM -H humax -l 60
TCP STREAM TEST to humax
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    60.01      29.73

usbnet, drt800, netfilter disabled, new ehci drivers, tivo->pc, kernel 2.4.20, Xterasys generic ax8817x (0x7b8/0x420a)

# netperf -t TCP_STREAM -H peecee -l 60
TCP STREAM TEST to peecee
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    59.99      10.43

The kernel I am running is posted here.

[titusmex]

Thanks Jamie & ADH & NUTKASE et all @ DD

(WAF skyrocketed with these transfer speeds) - Hardware & Drilling for new gigabit network approved!!!!


TCP STREAM TEST to 192.168.1.100
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % N us/KB us/KB

65536 131070 131070 10.00 36.98 98.60 16.12 218.395 71.394
tivo:/var/hack$


USB 200M - Tivo SA 2 4.01b - ptvlb48 Kernel - superpatch 7.0.1

[rc3105]

Originally Posted by ToshTivo

Please excuse me if this reply is a duplicate, I know I wrote a reply to this last night but I was unable to find it on this forum. Maybe I screwed up when pressing the submit reply button...

well, at least you're polite. it was deleted because (drum roll please)

this is a development thread, ask those type of questions in the support thread

[kaneisgr]

I'd like to report the following -in case someone has ever run or runs over the same problem-.

Using the 2.4.18 backported modules for usb2 on my tivo SA Series 2 (running 4.0.1b) with a linksys usb200m doesn't work... To be more precise:

I boot the machine (without loading any usb modules):

$lsmod
Module                  Size  Used by    Not tainted
brcmdrv-rb            769328  24
therm                   1488   0
fan                     2096   0
ideturbo                5232   0 (unused)
router                 66864  24
kfirm                 104320   0 (unused)
tvinput                10640   0 (unused)
irblast                 4112   0
ircatch                16944   1
modemtty                4672   1
fpga                    1904   0
tivoconfig               960   0 (unused)
i2c                    11888   1 [therm fan tvinput]

once I insmod usbcore.o everything looks good:

usb.c: starting integrated EHCI driver
ehci_hcd 00:0d.2: PCI device 1033:00e0
ehci_hcd 00:0d.2: irq 6, pci mem b4002000
usb.c: new USB bus registered, assigned bus number 1
ehci_hcd 00:0d.2: USB 2.0 enabled, EHCI 0.95, driver 2003-Dec-29/2.4
hub.c: USB hub found
hub.c: 5 ports detected
usb.c: EHCI initialization succeeded

then, if the usb200m is plugged in (or as soon as I plug it in) I get:

hub.c: new USB device 00:0d.2-2, assigned address 2
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=2 (error=-145)
hub.c: new USB device 00:0d.2-2, assigned address 3
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=3 (error=-145)

It doesn't matter if the usbnet module is loaded or not. The same stands for the usb-ohci module (which is required only for usb1.1 devices anyway).

I know that my SA2 has a EHCI capable usb controller (some very early versions don't), see bold text below:

$ cat /proc/pci
PCI devices found:
  Bus  0, device  13, function  0:
    Class 0c03: PCI device 1033:0035 (rev 65).
      IRQ 5.
      Master Capable.  Latency=40.  Min Gnt=1.Max Lat=42.
      Non-prefetchable 32 bit memory at 0x14000000 [0x14000fff].
  Bus  0, device  13, function  1:
    Class 0c03: PCI device 1033:0035 (rev 65).
      IRQ 3.
      Master Capable.  Latency=40.  Min Gnt=1.Max Lat=42.
      Non-prefetchable 32 bit memory at 0x14001000 [0x14001fff].
  Bus  0, device  13, function  2:
    Class 0c03: PCI device 1033:00e0 (rev 2).
      IRQ 6.
      Master Capable.  Latency=64.  Min Gnt=16.Max Lat=34.
      Non-prefetchable 32 bit memory at 0x14002000 [0x140020ff].
  Bus  0, device  14, function  0:
    Class ff00: PCI device 1741:0000 (rev 128).
      IRQ 2.
      Master Capable.  Latency=64.
      Non-prefetchable 32 bit memory at 0x14100000 [0x141fffff].
  Bus  0, device  15, function  0:
    Class 0480: PCI device 141f:9000 (rev 0).
      IRQ 40.
      Master Capable.  Latency=64.
      Non-prefetchable 32 bit memory at 0x14200000 [0x14200fff].
      Non-prefetchable 32 bit memory at 0x14220000 [0x1423ffff].
      Prefetchable 32 bit memory at 0x14240000 [0x1425ffff].
      Non-prefetchable 32 bit memory at 0x14260000 [0x1427ffff].

The strange thing is that there are no triggered interrupts on irq 6:

$ cat /proc/interrupts
2:        0 + cascade
 4:   239054 + cascade, + brcm
 6:        0   ehci_hcd
 7:       34 + counter
22:   184462 + timer
23:        0 + illegal cycle
39:        0 + cascade
48:        0 + pci error
49:        0 + pci error
50:        0 + pci error
51:        0 + pci error
52:        0 + pci error
53:        0 + pci error
57:    10759 + ide0
70:        1 + irsuper
73:       10 + irsuper
81:    12533   serial
82:   175399 + i2c
83:        0 + i2c
84:        0 + cascade
85:        0 + cascade
86:        0 + cascade
87:    58976 + ide0
88:        0 + ide0
89:        0 + ide0
96:        0 + i2c
97:        0 + i2c
98:        0 + i2c
99:        0 + i2c
133:       13   parallel modem

usb1.1 devices (like my logitech mouse or the sennheiser headphones) are
recognised just fine with the backported usb2 modules (through usb-ohci).
(Of course there are no modules for those specific devices, but there are no problems assigning addresses to them!)

I've used both the stock 2.4.18 kernel and the one found in:

http://www.dealdatabase.com/forum/sh...967#post202967


The linksys usb200m works perfectly fine with the usb1.1 modules....

Unfortunately I don't have access to any other usb2 devices....
Any ideas/hints?

Best Regards!

[alldeadhomiez]

Originally Posted by kaneisgr

The linksys usb200m works perfectly fine with the usb1.1 modules....

Did you try this usbcore with the parameter: use_ehci=0 ?

Also, what is the vend/prod when you pop it in a PC?

[kaneisgr]

Originally Posted by alldeadhomiez

Did you try this usbcore with the parameter: use_ehci=0 ?

Also, what is the vend/prod when you pop it in a PC?

The vend/prod is 0x77b/0x2226.

with use_ehci=0 (and usb-ohci) it works :

usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xb4000000, IRQ 5
usb-ohci.c: usb-00:0d.0, PCI device 1033:0035
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 3 ports detected
usb-ohci.c: USB OHCI at membase 0xb4001000, IRQ 3
usb-ohci.c: usb-00:0d.1, PCI device 1033:0035
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
hub.c: new USB device 00:0d.1-1, assigned address 2
usb.c: USB device 2 (vend/prod 0x77b/0x2226) is not claimed by any active driver
usb.c: registered new driver usbnet
eth0: register usbnet usb-00:0d.1-1, ASIX AX8817x USB 2.0 Ethernet
eth0: open: enable queueing (rx 4, tx 4) mtu 1500 raw framing

With no EHCI , however, is it really in USB 2.0 (as the log says)?

Thanks

[Jamie]

Originally Posted by kaneisgr

With no EHCI , however, is it really in USB 2.0 (as the log says)?

nope. The short queue length's reported by usbnet.o are one clue.

I very occasionally got the "not accepting new address" error with a usb host-to-host cable when I was plugging and unplugging it frequently. A reboot always helped, but nothing else did, including unloading and reloading all the usb modules.

[kaneisgr]

Originally Posted by Jamie

nope. The short queue length's reported by usbnet.o are one clue.

I very occasionally got the "not accepting new address" error with a usb host-to-host cable when I was plugging and unplugging it frequently. A reboot always helped, but nothing else did, including unloading and reloading all the usb modules.

I tried rebooting tivo numerous times, but nothing changed... Always the same "not accepting new address" error(!).

[Jamie]

Here's a delta against the 20050104 build from alldeadhomiez. This should make it into the next build, but I'm putting it out now for earlier adopters to try. It contains only a source patch, usbcore.o and usbnet.o for each architecture. The changes are:

2005/02/08 Jamie

 - Added ax8817x_reset to usbnet that sets the medium_mode bits.
 - Added usbnet module options to adjust the medium_mode, force half duplex,
   and control tx and rx queue sizes.
 - Set the default value for log2_irq_thresh to 4.

The first change (the medium_mode bits) are the most interesting. Turns out that 802.3x has an optional hardware flow control mechanism for full duplex called "PAUSE" frames. A receiver can send PAUSE frames to tell a sender to slow down so it can keep up. The linux usbnet driver wasn't enabling it. This version of the driver does. I see ~ double the full duplex receive throughput with this enabled (both on x86 and tivo mips). It doesn't seem to help send performance though, and it may even be slightly worse than without flow control. YMMV: it may depend on the switch and/or the adapter on the other end. I'm interested in feedback; please use the "Soapbox derby" thread.

[EvilJack]

Originally Posted by allenflame

Is this needed with 6.2? If I'm using tytools to transfer video, it only runs at like .48 k/s? It takes like an hour to do a 2 hour show.

Not needed.... (as you said it works) but makes things go
faster if you use them. You'd want the 2.4.20 version of
the modules.

jack

[Jamie]

Here's a new build with usbnet support for dongles built around the ASIX ax88178 and ax88772 chips. These are available in devices made by airlink-101 (AGIGAUSB , ASOHOUSB) and sold by Fry's/Outpost. The AGIGAUSB is a GigE device and supports jumbo frames.

Here's some performance data:

device		chip	speed	jumbo?	TXmbps	RXmbps
usb200m		88172	100	n	45	60
ASOHOUSB	88772	"	"	43	50
AGIGAUSB	88178	1000	"	43	46
"		"	"	y	95	78

Observation: GigE is only worth while if you can enable jumbo frames (mtu 9000). This means your switches and PC network adapters also have to support jumbo frames. I use smc switches and intel network adapters. If you can enable jumbo frames, the performance improvement is noticable. I routinely get 5-6MBsec in mfs_ftp extractions now.

If you want to change the mtu, you need to take the interface down and bring it back up. For example,

ifconfig eth0 down; ifconfig eth0 mtu 9000; ifconfig eth0 up

If you do it all on one line, you can do it from a telnet session without losing your connection.

I'm seeing an occasional framing error. I'm writing this off to running GigE over long cat5 runs (not cat5e or cat6), although it could be a problem in the driver.
{Edit: it looks like at least some of the errors I'm seeing are due to usb "babble" (-EOVERFLOW urb status values). Still investigating.}

Thanks to EvilJack and pjin for sending me the dongles. Thanks to Jeff D for driver code from ASIX. I didn't actually use it. The new code is based on the ax88772 support in the 2.6.12-rc6-mm1 tree with some tweaks to the AX framing code to improve performance and fixes for mips byte order/alignment issues.

The usual caveats apply. I've only tested the 2.4.20 versions of the modules on tivo software version 7.1b.