I have a rather odd problem using the Alcatel Speedtouch USB Modem with the sourceforge USB speedtouch drivers http://sourceforge.net/projects/speedtouch/
Running SuSE 8.0 with the latest (and all previous versions of the drivers) I have a stable connection, until I try and listen to a shoutcast stream using xmms.
In this instance the connection will usually drop within 3 hours and always within 5.
Downloading large files (say an ISO) from a fast mirror presents no problems.
After the connection fails there are no errors reported in any of the syslogs. I am unable to restart the connection until I reboot the machine (even after killing all relevant processes and unmounting USB etc)
I have posted a message on the Speedtouch mailing list, but had no response.
Has anyone experienced this, or got any ideas as to what may be the cause.
The machine also dual boots XP, under XP I have no such problem so I know my DSL line/Service is ok.
Any help you be greatly appreciated
Wayne
Wayne Stallwood wayne.stallwood@btinternet.com wrote:
Running SuSE 8.0 [...]
What kernel, please?
with the latest (and all previous versions of the driver= s) I have a stable connection, until I try and listen to a shoutcast stream=20 using xmms.
What XMMS version? What output plugin, please? (Look at the Preferences dialogue.)
I've had a Speedtouch working fine with Debian testing and kernel 2.4.x since the n_hdlc patch appeared. Before that, I had to reboot to restart ppp, which was a pain.
Occasionally, xmms (Version: 1.2.7-1.1) gets its knickers in a twist when listening to a stream and kills itself or stops doing output, but I've not had it do anything to the modem (and it shouldn't be able to). Sadly, as with all intermittent bugs, it's been hard to track down.
Hope that helps at all,
MJR
Sorry..should have mentioned that.
Kernel is 2.4.18
Xmms is 1.2.6-102
Input is libmpg123 version 1.2.6 Output is OSS Driver 1.2.6
I am trying an experiment whereby mpg123 is playing one of the streams I regularly listen to to see if I get the same problem, as like you I find it unlikely that Xmms is to blame.
On Friday 20 September 2002 10:30, MJ Ray wrote:
Wayne Stallwood wayne.stallwood@btinternet.com wrote:
Running SuSE 8.0 [...]
What kernel, please?
with the latest (and all previous versions of the driver= s) I have a stable connection, until I try and listen to a shoutcast stream=20 using xmms.
What XMMS version? What output plugin, please? (Look at the Preferences dialogue.)
I've had a Speedtouch working fine with Debian testing and kernel 2.4.x since the n_hdlc patch appeared. Before that, I had to reboot to restart ppp, which was a pain.
Occasionally, xmms (Version: 1.2.7-1.1) gets its knickers in a twist when listening to a stream and kills itself or stops doing output, but I've not had it do anything to the modem (and it shouldn't be able to). Sadly, as with all intermittent bugs, it's been hard to track down.
Hope that helps at all,
MJR
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Sat, Sep 21, 2002 at 01:09:34PM +0000, Wayne Stallwood wrote:
Sorry..should have mentioned that.
Kernel is 2.4.18
Xmms is 1.2.6-102
Input is libmpg123 version 1.2.6 Output is OSS Driver 1.2.6
I am trying an experiment whereby mpg123 is playing one of the streams I regularly listen to to see if I get the same problem, as like you I find it unlikely that Xmms is to blame.
Well i /think/ there may be dark magic at work somewhere, as where i used to live my machine had a alcatel modem and we sat behind the nat firewall and used to get disconnected about once a week. I have since moved somewhere else and my connection has now been up for 20days the only things that have changed are
1. the telephone line and exchange 2. the modem (still an alcatel same model etc) 3. one less user behind the firewall
So it may be that there are other things that cause this behaviour, I used to have to reboot the firewall about 50% of the time to get the connection to come back up before which was odd and makes me wonder if its not something at the BT end that could affect this.
Adam
I know what you're saying, I thought that for a while too.
What bothers me is that if this is true what are the conditions met before the dark forces (BT) kick me off.
Under XP it's fine (easy 20 day's +, Yes I have managed to keep XP running for more than 20 days before) Under XP recieving a shoutcast stream using Winamp client, it's fine (the only time XP has lost it's connection was once during a particularly bad storm) Under Linux it's fine (again 20days + not uncommon) Under Linux recieving a shoutcast stream using Xmms, 5 hours max before connection fails, usually about 3
All the above are also true if I plug my system in on the Business ADSL line I have at my Office
It's so odd that at first I thought is was concidence, but it's ONLY ever fails on Linux when I am running a stream
So if BT kick people off that listen to shoutcast for too long, then why doesn't it happen on XP and if BT kicks off Linux users why does it only happen when I am listening to a stream.
Also why is it that I have never read (on Usenet, Speedtouch Mailing lists or Linux Mailing lists) of anyone else having this problem. It must be something specific to my system, I just don't know what.
Incendently what is the difference between usb-uhci and uhci ? Which one should I be using to connect my ADSL Modem. (not that it seems to make any difference to this problem)
Cheers
Wayne
On Saturday 21 September 2002 12:29, Adam Bower wrote:
On Sat, Sep 21, 2002 at 01:09:34PM +0000, Wayne Stallwood wrote:
Sorry..should have mentioned that.
Kernel is 2.4.18
Xmms is 1.2.6-102
Input is libmpg123 version 1.2.6 Output is OSS Driver 1.2.6
I am trying an experiment whereby mpg123 is playing one of the streams I regularly listen to to see if I get the same problem, as like you I find it unlikely that Xmms is to blame.
Well i /think/ there may be dark magic at work somewhere, as where i used to live my machine had a alcatel modem and we sat behind the nat firewall and used to get disconnected about once a week. I have since moved somewhere else and my connection has now been up for 20days the only things that have changed are
- the telephone line and exchange
- the modem (still an alcatel same model etc)
- one less user behind the firewall
So it may be that there are other things that cause this behaviour, I used to have to reboot the firewall about 50% of the time to get the connection to come back up before which was odd and makes me wonder if its not something at the BT end that could affect this.
Adam
On Sat, Sep 21, 2002 at 02:12:45PM +0000, Wayne Stallwood wrote:
Also why is it that I have never read (on Usenet, Speedtouch Mailing lists or Linux Mailing lists) of anyone else having this problem. It must be something specific to my system, I just don't know what.
some people have experienced different connections with different versions of the modem firmware you could try.... thinks.... are you using the same modem firmware with linux as you are with win XP? there are about 6 or 7 versions try using your mgmt.o file from WinXP with modem_run (or whichever bit it is) if not you could try different firmwares. To see if the files are different you can use md5sum under linux. (md5sum mgmt.o) and see if you get different outputs from that)
Incendently what is the difference between usb-uhci and uhci ? Which one should I be using to connect my ADSL Modem. (not that it seems to make any difference to this problem)
well use which one works or works better than the other one, I have to use usb-uhci and the uhci one doesn't work with my modem for some reason although it will work fine with other usb devices.
Adam
Wayne Stallwood wrote:
It's so odd that at first I thought is was concidence, but it's ONLY ever fails on Linux when I am running a stream
If you're using the Benoit/userspace drivers you could try the 'other' ones (ATM in the kernel, kernel module speedtch.o, and enhanced pppd that loads an ATM plugin). They're more hassle to install, but maybe your problem will go away...
I have run that setup for over a year now (maybe I'd have gone with the easier ones if they'd existed when I got ADSL ;-) and its not been too bad. Sometimes I lose the connection for no apparent reason (nothing in logs)... usually a SIGHUP to pppd (in persist mode) fixes it, sometimes I need to rmmod usb (which causes speedmgmt to exit, and sometimes causes a kernel panic :-( ).
If you've gone to the trouble of rmmod usb, you could try unplugging your modem from USB - that might cause it to reset itself 'properly' (?) - then plug it back in and modprobe usb...
Good luck
Neil
That is a really good idea :o)
In fact I seem to remember that the SuSE kernel already has ATM support, so it should be trivial to install the drivers from Alcatel's Website.
I'm trying Adam's suggestion of different firmware, if that does not help then I am going to do this.
But what of those Kernel panics, doesn't sound very nice
Cheers
Wayne
On Saturday 21 September 2002 18:14, Neil Sedger wrote:
Wayne Stallwood wrote:
It's so odd that at first I thought is was concidence, but it's ONLY ever fails on Linux when I am running a stream
If you're using the Benoit/userspace drivers you could try the 'other' ones (ATM in the kernel, kernel module speedtch.o, and enhanced pppd that loads an ATM plugin). They're more hassle to install, but maybe your problem will go away...
I have run that setup for over a year now (maybe I'd have gone with the easier ones if they'd existed when I got ADSL ;-) and its not been too bad. Sometimes I lose the connection for no apparent reason (nothing in logs)... usually a SIGHUP to pppd (in persist mode) fixes it, sometimes I need to rmmod usb (which causes speedmgmt to exit, and sometimes causes a kernel panic :-( ).
If you've gone to the trouble of rmmod usb, you could try unplugging your modem from USB - that might cause it to reset itself 'properly' (?)
- then plug it back in and modprobe usb...
Good luck
Neil
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
If anyone remembers me asking for advice on a problem with my Speedtouch modem while streaming to XMMS ?
The really odd thing is that since adding the USBDNET patch to get my Zaurus syncing the problem has completely vanished.
Note I didn't recompile the kernel, just simply applied the patch, compiled modules and only copied over the USBDNET module to the active modules directory.
How odd ?
Neil Sedger alug@moley.org.uk wrote:
If you're using the Benoit/userspace drivers you could try the 'other' ones (ATM in the kernel, kernel module speedtch.o, and enhanced pppd that loads an ATM plugin). They're more hassle to install, but maybe your problem will go away...
Rearrange to get my experience of that darling: time panic every kernel.
The real pain was then you end up with a pppd that can't actually do normal PPP, so you can't even use the good old modem to get on the net. Hopefully they've fixed that one by now, at least.
MJR
MJ Ray wrote:
Neil Sedger alug@moley.org.uk wrote:
If you're using the Benoit/userspace drivers you could try the 'other' ones (ATM in the kernel, kernel module speedtch.o, and enhanced pppd that loads an ATM plugin). They're more hassle to install, but maybe your problem will go away...
Rearrange to get my experience of that darling: time panic every kernel.
oops. Yes it is particular about which order you do things in. You have to follow the HOWTO to the letter, you should be ok.
Plus you need a patch to kernel's USB if you're running SMP - although that patch is in later kernel versions (I didn't need it for 2.4.19, but did for 2.4.2).
I mostly get kernel panics when speedmgmt - the binary provided by Alcatel with no source - exits. However, if I take care and do things slowly - take down pppd first, wait a bit, modules in the right order, then waiting a bit between each one, its OK. /var/log/messages shows speedmgmt has noticed its module has been removed and it exits nicely with no problem, and I can start it up again OK.
I think I was getting them because I wasn't taking care of it on shutdown, so some part of the shutdown process was killing the wrong thing in the wrong order. I've added a little script into /etc/init.d and linked it into /etc/rc.d/rc3.d with a low 'K' number so hopefully next reboot will be panic-free.
I'll find out sometime soon...
Let me know if you want my scripts, but you're better off having a go yourself first with reference to the HOWTO. Previously I had to modprobe speedtch.o, now it seems to modprobe itself once usb is modprobed... dunno why...
The real pain was then you end up with a pppd that can't actually do normal PPP, so you can't even use the good old modem to get on the net. Hopefully they've fixed that one by now, at least.
Aha. You'd have thought so. Unfortunately the latest version of pppd to be found with a patch to load the atm module is pppd v2.4.0. The chap who wrote it has either disappeared off the internet or is not interested in it any more. For some reason that functionality hasn't made it into the main pppd - which was on 2.4.1 something last time I looked. I last looked a couple of months ago - when I upgraded from 2.4.2 to 2.4.19. Situation might have changed since then.
Still, 2.4.0 seems to work fine here, with upgraded kernel, smp, speedtouch module and speedmgmt binary...
Neil
the only things that have changed are
- the telephone line and exchange
Aren't there problems with the hardware in some exchanges? Don't recall the details but there is more about it on the adslguide website. Could this be the root of the odd behaviour some of you are experiencing? Apologies if this is completely off the ball.
Syd