Rob Todd wrote:
>
> Hello all,
>
> I thought I would just pass along my experiences with the new Speedtouch USB
> driver thus far.
Thank you!
It is appreciated.
I have cc'ed marcell for the bridging and michal ostrowski for the pppoe
support.
> In general:
> * Documentation: Umm... so what vpi.vci are we supposed to use? Do we need
> to specify any IP addresses? I grabbed the vpi.vci from the windows driver but
> it'd probably be good to put that in the README somewhere... especially for
> those that don't even use windows at all.
The VP/VC you are supposed to use is not a default value, it depends on your
provider/telco.
There is no IP address that should be used, it should be set up with the ppp
session.
> Using PPPoE:
> * Documentation: well, I realize this driver is brand new but it would have
> been nice to know that to compile the bridging support one would need to
> download and compile the ATM package rather than using the stock ATM headers and
> such that are in the kernel. No biggie... got it all working after a bit of
> playing. There should probably be a bit of a step-by-step on how to do this
> though...
There is a step by step howto on the page of Marcel Gal.
It is called TUTORIAL.
> * Bridging: I couldn't get the configuration to work without assigning a
> generic IP address to the nas0 bridging interface (also in the roaring penguin
> setup you'll want to specify nas0 rather than an ethernet interface).
Strange, I haven't seen this problem with the ip address, is setting the
interface up enough ? Did you turn on the IP kludge thingie option?
It is nescessary to specify nas0 as the ethernet interface to roaring pengiun
pppoe, after all, nas0 *is* the (virtual) ethernet interface you wish to do
pppoe over :).
> * Stability: on my configuration at least, this particular set up (the
> Speedtouch USB driver at the bottom, then the RFC2684 bridging support, then
> PPPoE, then PPP) was VERY unstable. I would get it to come up most of the time
> but as soon as any data started streaming through, some part of this mess would
> cause a kernel panic. Also, I could repeat this behavior by starting up a
> couple of FTPs at the same time...
Some data? I have seen this too, but mostly when using netscape, not ftp, so I
was thinking large packets...
It complains in the panic that a skb is being free which is still on a list.
I have checked a backtrace and the buffer doesn't even reach my code, but
I haven't had time for a full path analysis. I have attached a ksymoops trace,
marcel, could you look at it? To be honest I think it is somewhere in the
pppox/pppoe kernel support. michal, could you look at the trace too, please?
Are you using the roaring penguin pppoe with the kernel pppoe support ?
> Using PPPoA:
> * After a LOT of tweaking I finally got this to work. I used the same kernel
> patches that I did for PPPoE (they seemed to work just fine) but had to compile
> in support for synctty and asynctty, along with the various PPP compression
> schemes. Also, I couldn't manage to get it to work when PPPoA was compiled into
> the kernel rather than as a module.
> * Stability: MUCH more stable than the PPPoE option but definitely a tougher
> task to get it working.
I have not tried this since my provider only supplies me with pppoe.
I used to use pppoa (before my provider switched over) but back then I used a
custom little pppoa tool.
> * Performance: Using PPPoA definitely provided a significant improvement in
> performance although neither one was just mind-boggling fast. Using PPPoE I
> could typically achieve around 50 kB/s using FTP (before it would crash). Using
> PPPoA I can typically get around 80 kB/s. This is compared to the 150-160 kB/s
> I get through the windows driver. I'm not sure if this is the Alcatel driver
> itself or the PPPoX layer but something needs to be looked at nonetheless.
> During my streaming tests, the binary side of the Alcatel package was taking up
> around 40% of my CPU so I would tend to think that if it something else weren't
> restricting the speed of the transfer then it would use more cycles.
Yes. I have seen the performace problem. It has been introduced in about the
same period I switched to the kernel thread for deSARring. (not sure it is
related though), before that I got about 100Kb/s (taking 30% cpu under
interrupt ;). I think performance can be greatly improved with a new SARlib
version which does cell and AAL5 reassembly and CRC checking in a single run.
Also, maybe switching to a tasklet iso a thread to do the processing can help
to reduce latency? I need some advise here! Anyone?
I seriously doubt it was the binary application though that took the processor
time. It should have been the "kSpeedSARd" kernel thread.
regards,
J.
PS: sorry if this reaches you twice. I had a netscape crash so I did a resent.
ksymoops 2.3.5 on i686 2.4.2-3mdk. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2-3mdk/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not
found in System.map. Ignoring ksyms_base entry
Warning: kfree_skb passed an skb still on a list (from c02006eb).
invalid operand: 0000
CPU: 0
EIP: 0010:[<c01c4391>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010292
eax: 00000045 ebx: c4d77200 ecx: c5536c80 edx: 00000000
esi: c2543f20 edi: c2543f20 ebp: c18b2ea2 esp: c45d7df8
ds: 0018 es: 0018 ss: 0018
Process pppoe (pid: 2100, stackpage=c45d7000)
Stack: c02272a0 c02006eb c2543f20 c2543f20 c02006eb c2543f20 c5af1880 c4d77200
c01ccdce c2543f20 c4d77200 00000000 c4d77200 0000003e c01c794a c4d77200
c2543f20 c4d77200 cd074c52 c2543f20 00000005 c45d7ed4 cd074a8c c467f774
Call Trace: [<c02006eb>] [<c02006eb>] [<c01ccdce>] [<c01c794a>] [<cd074c52>]
[<cd074a8c>] [<c01c16cd>]
[<cd074a8c>] [<c01c243c>] [<c0163daa>] [<c0160179>] [<c0162069>] [<c01c247a>]
[<c01c2bf1>] [<c0108f07>]
Code: 0f 0b 83 c4 08 8b 4c 24 0c 8b 51 28 85 d2 74 07 ff 4a 04 8b
>>EIP; c01c4391 <__kfree_skb+1d/128> <=====
Trace; c02006eb <br2684_start_xmit+7b/94>
Trace; c02006eb <br2684_start_xmit+7b/94>
Trace; c01ccdce <qdisc_restart+4e/c8>
Trace; c01c794a <dev_queue_xmit+e2/1dc>
Trace; cd074c52 <END_OF_CODE+13b2f/????>
Trace; cd074a8c <END_OF_CODE+13969/????>
Trace; c01c16cd <sock_sendmsg+81/a4>
Trace; cd074a8c <END_OF_CODE+13969/????>
Trace; c01c243c <sys_sendto+d0/f0>
Trace; c0163daa <pty_unthrottle+3e/4c>
Trace; c0160179 <check_unthrottle+29/30>
Trace; c0162069 <read_chan+659/6c4>
Trace; c01c247a <sys_send+1e/24>
Trace; c01c2bf1 <sys_socketcall+f9/1dc>
Trace; c0108f07 <system_call+33/38>
Code; c01c4391 <__kfree_skb+1d/128>
00000000 <_EIP>:
Code; c01c4391 <__kfree_skb+1d/128> <=====
0: 0f 0b ud2a <=====
Code; c01c4393 <__kfree_skb+1f/128>
2: 83 c4 08 add $0x8,%esp
Code; c01c4396 <__kfree_skb+22/128>
5: 8b 4c 24 0c mov 0xc(%esp,1),%ecx
Code; c01c439a <__kfree_skb+26/128>
9: 8b 51 28 mov 0x28(%ecx),%edx
Code; c01c439d <__kfree_skb+29/128>
c: 85 d2 test %edx,%edx
Code; c01c439f <__kfree_skb+2b/128>
e: 74 07 je 17 <_EIP+0x17> c01c43a8 <__kfree_skb+34/128>
Code; c01c43a1 <__kfree_skb+2d/128>
10: ff 4a 04 decl 0x4(%edx)
Code; c01c43a4 <__kfree_skb+30/128>
13: 8b 00 mov (%eax),%eax
Kernel panic: Aiee, killing interrupt handler!
2 warnings issued. Results may not be reliable.
