[speedtouch] Re: help needed with testing auto-detect Rev patch
Hi John, thanks for the informative message. It sounds like you get an endpoint stall. Can you please recompile your kernel with USB debugging turned on, and send me the messages when this occurs. This makes some kind of sense because the packet size for the endpoint is 64 bytes with endpoint 1, and 32 bytes with endpoint 2, so buffer over/under-runs in the modem are more likely with endpoint 1. Ciao, Duncan. On Saturday 21 February 2004 21:36, John Hysted wrote: > Duncan > > I requested the reversion to endpoint 2 in modem_run by default for the Rev > green frogs. > > If endpoint 1 is used in modem_run with these modems, pppoa3 fails with > "Error reading usb urb" randomly after a few hours when under heavy load > and this does not happen when endpoint 2 is used in modem_run. > It has been reported by other users in the past as a problem with the new > code in Version 1.2. My solution has been to revert to the Version 1.1 > version of modem_run and pppoa3 where the connection is stable for weeks at > a time. > > I was surprised to trace the problem to modem_run as I assumed it would be > a problem with pppoa3. I have extensively tested various existing versions > and created and tested a patched version of 1.2-beta3 modem_run. The log of > my testing is available by following the "spreadsheet" link from > http://www.hystedjp.pwp.blueyonder.co.uk/history.htm which demonstrates > that the "Error reading usb urb" occurs when modem_run uses alternate > endpoint 1. (Or if you use pppoa3 -e 1 with a green frog which you > shouldn't anyway.) > > For 330 modems I agree that endpoint 1 is required. However in modem_run it > was NOT left at endpoint 2 for older modems. > > John > > > > Liste de diffusion modem ALCATEL SpeedTouch USB > Pour se désinscrire : > mailto:[EMAIL PROTECTED] Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Duncan I requested the reversion to endpoint 2 in modem_run by default for the Rev green frogs. If endpoint 1 is used in modem_run with these modems, pppoa3 fails with "Error reading usb urb" randomly after a few hours when under heavy load and this does not happen when endpoint 2 is used in modem_run. It has been reported by other users in the past as a problem with the new code in Version 1.2. My solution has been to revert to the Version 1.1 version of modem_run and pppoa3 where the connection is stable for weeks at a time. I was surprised to trace the problem to modem_run as I assumed it would be a problem with pppoa3. I have extensively tested various existing versions and created and tested a patched version of 1.2-beta3 modem_run. The log of my testing is available by following the "spreadsheet" link from http://www.hystedjp.pwp.blueyonder.co.uk/history.htm which demonstrates that the "Error reading usb urb" occurs when modem_run uses alternate endpoint 1. (Or if you use pppoa3 -e 1 with a green frog which you shouldn't anyway.) For 330 modems I agree that endpoint 1 is required. However in modem_run it was NOT left at endpoint 2 for older modems. John Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
> It was changed to endpoint 2 to make the 330 working. Hi Gilles, I think you are confusing 1 and 2 :) It used to be endpoint 2, but was changed to endpoint 1 for the 330 because endpoint 2 is an isochronous endpoint for 330 modems (and that doesn't work with the current drivers). However it was left at endpoint 2 for older modems. But in fact endpoint 1 works fine for older modems too (and gives better throughput, at least theoretically). The kernel modem uses endpoint 1 for all modems and that seems to work fine. So again I ask: what it the point of using endpoint 2 at all? All the best, Duncan. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
- Original Message - From: "Duncan Sands" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Gilles Espinasse" <[EMAIL PROTECTED]> Sent: Saturday, February 21, 2004 6:12 PM Subject: [speedtouch] Re: help needed with testing auto-detect Rev patch > > > The reason may be in the change done to support rev2.00 (330 purple) wich > > use endpoint 2. > > I thought the 330 used endpoint 1. My rev (just checked!) modem works fine > using endpoint 1. So what is the use of endpoint 2 (it gives lower bandwidth). > It was changed to endpoint 2 to make the 330 working. Gilles Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
> The reason may be in the change done to support rev2.00 (330 purple) wich > use endpoint 2. I thought the 330 used endpoint 1. My rev (just checked!) modem works fine using endpoint 1. So what is the use of endpoint 2 (it gives lower bandwidth). Ciao, Duncan. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
- Original Message - From: "Duncan Sands" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "John Hysted" <[EMAIL PROTECTED]> Sent: Saturday, February 21, 2004 5:50 PM Subject: [speedtouch] Re: help needed with testing auto-detect Rev patch > What are rev modems? And why do they have a problem with > endpoint 1? > This is original green stingray :-) Some of us find that the same modem on the same machine behave better with V1.1 than V1.2betax. The reason may be in the change done to support rev2.00 (330 purple) wich use endpoint 2. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
> All I need is that for Rev modems the code which in version 1.2 said
>
> if (pusb_set_interface(fdusb, 1, 1) < 0) {
>
> is changed to something that works like this
>
> if (revision == 0) {
>alternate_ep = 2;
> } else {
>alternate_ep =1;
> }
What are rev modems? And why do they have a problem with
endpoint 1?
Thanks,
Duncan.
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
John Hysted ([EMAIL PROTECTED]) wrote:
> I can confirm no problems with Rev modem on Smoothwall / Redhat.
fine
> Sorry I have no knowledge of BSD. All I could find was that the field I
> required was di.udi_releaseNo and grabbed it when I could.
Don't worry, i'm sure some BSD dev will come up with a patch soon.
> I think your version of the code will identify a Rev 0001 ISDN modem
> as revision 0 and try to use it, this is why I coded the known Revs
> explicitly in my code.
I'll have a look at this, i'll try to see the diff between your code
and mine.
> Also after the loop starting
> for(i=0; i you still check for
> if(i == 10) {
> rather than
> if(i==upload_tries) {
Will be fixed toonight
> I am very happy with the code as you have implemented it, it is far
> more future proof than before
Thanks
--
Edouard Gomez
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Latest version of code found in CVS, thanks. Compiled as 1.2-gom38 and now being tested with a KQD6Pboth.eni file. 07:52:49 modem_run[46] modem_run version 1.2-gom38 started by root uid 0 07:52:49 modem_run[46] Found SpeedTouch USB modem 07:52:49 modem_run[46] Modem revision: 0 07:52:49 modem_run[46] Best offset 0 with probability 100% 07:52:49 modem_run[46] Best offset 983 with probability 100% 07:52:49 modem_run[46] Firmware information (CRC:0xd80bf9f7, Size:991, Alcatel/Thomson Boot block (old)) 07:52:49 modem_run[46] Best offset 991 with probability 100% 07:52:50 modem_run[46] Best offset 762642 with probability 100% 07:52:50 modem_run[46] Firmware information (CRC:0x78039fed, Size:762650, 3.0.6 - MacOSX - Win32) 07:52:52 kernel: usb_control/bulk_msg timeout 07:52:52 kernel: usbdevfs USBDEVFS_BULK failed dev 2 ep 0x85 len 512 ret -110 07:52:52 modem_run[46] BLOCK1 : 991 bytes uploaded : OK 07:52:52 modem_run[46] BLOCK2 : 511 bytes downloaded : OK 07:52:55 modem_run[46] BLOCK3 : 762650 bytes uploaded : OK 07:52:55 modem_run[46] BLOCK4 : 511 bytes downloaded : OK 07:52:57 modem_run[46] Modem reference : 3EC18607CDAB03 07:53:10 modem_run[47] [monitoring report] ADSL link went up 07:53:27 modem_run[46] ADSL synchronization has been obtained 07:53:27 modem_run[46] ADSL line is up (576 kbit/s down | 288 kbit/s up) 07:53:34 pppoa3[165] pppoa3 version 1.2-gom38 started by nobody (uid 99) 07:53:34 pppoa3[165] Control thread ready 07:53:34 pppoa3[169] host --> pppoa3 --> modem stream ready 07:53:34 pppoa3[170] modem --> pppoa3 --> host stream ready I can confirm no problems with Rev modem on Smoothwall / Redhat. Sorry I have no knowledge of BSD. All I could find was that the field I required was di.udi_releaseNo and grabbed it when I could. I think your version of the code will identify a Rev 0001 ISDN modem as revision 0 and try to use it, this is why I coded the known Revs explicitly in my code. Also after the loop starting for(i=0; imailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Yes the use of globals in pusb was a hack, but I couldn't see any way to get from fdusb to the Rev of the modem. For kernel mode and Rev 0400 I had implemented a timeout and loop, but had problems with extra messages like 06:33:44 kernel: usb_control/bulk_msg timeout 06:33:44 kernel: usbdevfs USBDEVFS_BULK failed dev 2 ep 0x81 len 6 ret -110 appearing. The code I get from the CVS is timed at 14:48 and seems to be your previous version. I will look again tomorrow. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
- Original Message - From: "John Hysted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 15, 2004 5:59 PM Subject: [speedtouch] Re: help needed with testing auto-detect Rev patch > Smoothwall and IPCOP will have a problem with the extra -a parameter and > will probably settle for > a dos COPY /B ZZZLP1.eni /B + ZZZLP2.eni /B ZZZLboth.eni /B to make one > firmware file (how many /Bs do I really need) > This is a bit complicated for the user. If the firmware is available as a tar, we will try to untar the loaded file and concatenate the 2 files in one inside to make scripts simplier. If it's fail, we will assume the old monolithic file. It is right that loading one file all the time is more easy. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
John Hysted ([EMAIL PROTECTED]) wrote:
> Pick whatever you consider suitable from my patch. I was going to try and
> incorporate your changes this evening, but now my changes are much smaller
> than yours.
> All I need is that for Rev modems the code which in version 1.2 said
>
> if (pusb_set_interface(fdusb, 1, 1) < 0) {
>
> is changed to something that works like this
>
> if (revision == 0) {
>alternate_ep = 2;
> } else {
>alternate_ep =1;
> }
> if (pusb_set_interface(fdusb,1,alternate_ep) < 0) {
>
> and for Rev 0400 modems you need something like
>
> if (!(revision == 4))
>test_sequence(fdusb);
Applied in the following patch. However i have a small request about the
bsd pusb:pusb_get_revision implementation. Could you please code a
reentrant version of this function. I could turn your "set a global var"
hack for the linux version, but i don't know BSD usb stack, so at the
moment the function returns rev 2 all the time.
2004-02-15 21:20:37 GMT Edouard Gomez <[EMAIL PROTECTED]> patch-9
Summary:
Added revision 4 support in modem_run
Revision:
speedtouch--trunk--1.2--patch-9
* Added revision 4 support in modem_run. Appropriate behavior is chosen
according to the device revision or according to a user cmd line
option.
TODO: the pusb_get_revision in pusb-bsd needs to be coded, the version
from John Hysted is simply not right (it's a nasty solution, pusb,
is supposed to be a general usb library, not a single device
binded lib)
modified files:
doc-linux/man/modem_run.1 src/modem_run.c src/pusb-bsd.c
src/pusb-linux.c src/pusb.h
> Users with Rev 0400 modems and kernel mode drivers will have to try your
> version to see how it works.
It doesn't seem to work. Well i get synced.
[modem_run] modem_run version 1.2-beta3 started by edy uid 0
[modem_run] ADSL synchronization has been obtained
[modem_run] ADSL line is up (608 kbit/s down | 160 kbit/s up)
But the monitoring process that usesto communicate the line state to
the module just blocks on read.
DUNCAN, START HACKING ;-P
I suppose we'll have to deal with the module communication inside te
parent process too. Duncan, does the speedtch module forbid traffic if
state is reported as "down" (which is probably the default state) ?
> Smoothwall and IPCOP will have a problem with the extra -a parameter and
> will probably settle for
> a dos COPY /B ZZZLP1.eni /B + ZZZLP2.eni /B ZZZLboth.eni /B to make one
> firmware file (how many /Bs do I really need)
Yes i think that will be the best solution. At least, that's what i used
:-)
The code is CVS commited, so now, it's up to you guys to fix the last
glitches, my week end is over and i would have to have some rest :-)
Cheers
--
Edouard Gomez
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Edouard,
Pick whatever you consider suitable from my patch. I was going to try and
incorporate your changes this evening, but now my changes are much smaller
than yours.
All I need is that for Rev modems the code which in version 1.2 said
if (pusb_set_interface(fdusb, 1, 1) < 0) {
is changed to something that works like this
if (revision == 0) {
alternate_ep = 2;
} else {
alternate_ep =1;
}
if (pusb_set_interface(fdusb,1,alternate_ep) < 0) {
and for Rev 0400 modems you need something like
if (!(revision == 4))
test_sequence(fdusb);
Users with Rev 0400 modems and kernel mode drivers will have to try your
version to see how it works.
Smoothwall and IPCOP will have a problem with the extra -a parameter and
will probably settle for
a dos COPY /B ZZZLP1.eni /B + ZZZLP2.eni /B ZZZLboth.eni /B to make one
firmware file (how many /Bs do I really need)
John
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Hello Edouard, > I commited the changes i was talking about this week. Do you plan to > update your patch to the new CVS or may i pick what i consider suitable > from it myself ? > I'll probably do this on my side this afternoon or this evening. I keep > you informed. > > PS: the below changes are tested on the manta modem, and are known to > work well for me(tm), however feedback from other manta or purple > modems is welcome. Just let us know how the two of you solve this and when this merged version gets moved into CVS. I'll grab and test it after you announce that. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
John Hysted ([EMAIL PROTECTED]) wrote: > patch I commited the changes i was talking about this week. Do you plan to update your patch to the new CVS or may i pick what i consider suitable from it myself ? If you volunteer, then i have a request: - don't put any boot code (data1) inside source, use the -a option to specify the file which contains the boot code. (thus drop the patch chunk adding the data1 code for the rev4 modems) or concatenate bot the boot and firmware bin files, the -f option is enough in this case. The new firmware extracter should be straight forward to use with rev4 firmwares, just set the last argument to 1 when a rev4 modem is detected. I'll probably do this on my side this afternoon or this evening. I keep you informed. PS: the below changes are tested on the manta modem, and are known to work well for me(tm), however feedback from other manta or purple modems is welcome. 2004-02-15 14:31:33 GMT Edouard Gomez <[EMAIL PROTECTED]> patch-5 Summary: Reverted modem_run design to 1.1 version. Revision: speedtouch--trunk--1.2--patch-5 * Reverted modem_run design to 1.1 design: + the child does just monitor the interrupt. When running in kernel mode, it keeps informing the module about line state. + the parent polls the state device from time to time and exits either when the link state is up or when tiemout seconds have passed. In this last case, the child is still reporting further line state changes. * Added -i option to specify the polling state interval. * Added -n option to specify the number of upload tries before considering errors as failure. * Changed -t default to 120s. * Updated the man page. * Changed the timeout message to explicit the fact the monitoring child will keep reporting about state changes. modified files: doc-linux/man/modem_run.1 src/modem_run.c 2004-02-15 13:18:36 GMT Edouard Gomez <[EMAIL PROTECTED]> patch-4 Summary: Better 2.5/2.6 kernel support in example sysv script Revision: speedtouch--trunk--1.2--patch-4 * Cleaned up a bit the standard output redirections in the script. I remember this script was one my first ones, so i was not very skilled. * Newer modutils convert '-' to '_' which cause trouble when trying to test whether a module is loaded or not before trying to load/unload it. The easiest solution is to simply skip the tests and let modprobe deal with probables "double loadings" or "not loaded module unloading". * Insert a kernel revision test in speedtouch.conf so users can specify two default usb host modules to load depending on the kernel version. * Moved PEER variable definition to the spedtouch.conf file. * Added additional modem_run options variable to spedtouch.conf so users can specify more options to modem_run. This improve quite a bit kernel mode support because if -k is detected in this variable, the script (un)loads speedtch. * usbfs/usbdevfs awareness. modified files: doc-linux/speedtouch.conf doc-linux/speedtouch.sh 2004-02-15 01:29:13 GMT Edouard Gomez <[EMAIL PROTECTED]> patch-3 Summary: Removed junk/test code Revision: speedtouch--trunk--1.2--patch-3 Removed junk/test code modified files: src/firmware.c -- Edouard Gomez Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Hi John, > Version 6 now available from the same location > (http://www.hystedjp.pwp.blueyonder.co.uk). Version 6 compiles and seems to run fine with my 330 rev.2 as well. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Version 6 now available from the same location
(http://www.hystedjp.pwp.blueyonder.co.uk). For Rev 0 and 2 modems this
works as before, but for version 4 modems it does a get_state every 12
seconds until it sees that the modem has sync'ed. There is no need for the
timed_out=0 fix anymore and I believe it should work with kernel mode
drivers. I chose 12 seconds as my modem almost always manages to sync within
24 seconds, though on one memorable occasion it took 783 seconds to sync.
The timeout code in the CVS sets a limit of 60 seconds to sync, so I have
kept to that, though I think it is too short.
The patch also fixes some problems with extract.c for newer firmware
versions.
Index: src/extract.c
===
RCS file: /cvsroot/speedtouch/speedtouch/src/extract.c,v
retrieving revision 1.10
diff -u -r1.10 extract.c
--- src/extract.c 6 Aug 2003 01:37:46 - 1.10
+++ src/extract.c 13 Feb 2004 08:16:31 -
@@ -67,6 +67,8 @@
{0x3b4a5854, 671653, "1.6.1 - MacOSX - Win32(1.0.1800)"},
{0xd673923f, 672264, "2.0.0 - Win32(07)"},
{0x5bca7d16, 677641, "2.0.1 - MacOSX - Win32(2.0.0)"},
+ {0x78039fed, 762650, "3.0.6 - MacOSX - Win32"},
+ {0x0223733c, 775509, "1.0.10 - Win32 Rev 0400 SACHU3"},
};
/***
**
@@ -150,7 +152,7 @@
id = firmware_ids[loop].id;
}
- report(1, REPORT_INFO, "Firmware information (CRC:0x%8x, Size:%d, %s)\n",
+ report(1, REPORT_INFO, "Firmware information (CRC:0x%08x, Size:%d,
%s)\n",
~aal5_calc_crc(buf1, *size,~0),
*size,
id);
@@ -340,7 +342,7 @@
return(-1);
}
- printf("Firmware CRC: 0x%8x\n", ~aal5_calc_crc(buf, size,~0));
+ printf("Firmware CRC: 0x%08x\n", ~aal5_calc_crc(buf, size,~0));
printf("Firmware Size: %d\n", size);
free(buf);
Index: src/modem_run.c
===
RCS file: /cvsroot/speedtouch/speedtouch/src/modem_run.c,v
retrieving revision 1.36
diff -u -r1.36 modem_run.c
--- src/modem_run.c 4 Jan 2004 22:44:25 - 1.36
+++ src/modem_run.c 13 Feb 2004 08:16:33 -
@@ -64,6 +64,7 @@
/* Timeout in milliseconds */
#define CTRL_TIMEOUT 2000
#define DATA_TIMEOUT 2000
+#define SYNC_TIMEOUT 12000
#define OFFSET_7 0 /* size 1 */
#define OFFSET_b 1 /* size 8 */
@@ -97,6 +98,8 @@
static int timed_out = 0;/* Used to give a timeout signal inside the
wait loop */
static int sb = 0; /* Software buffering */
static int signal_kernel = 0;/* Kernel driver notification */
+static int alternate_ep = 1; /* historically was 2, speedtouch 330 needs 1
*/
+static int revision = -1;/* 0, 2 or 4. Default to 2 if not deduced or
supplied */
/*
* This array is just ARM code that initializes the speedtouch
@@ -348,6 +351,127 @@
#endif
};
+static unsigned char data1_400[] =
+{
+ 0x88, 0xf8, 0x00, 0x00, 0x00, 0x00, 0xf2, 0x01,
+ 0x0a, 0x00, 0x00, 0xea, 0x09, 0x00, 0x00, 0xea,
+ 0x08, 0x00, 0x00, 0xea, 0x07, 0x00, 0x00, 0xea,
+ 0x06, 0x00, 0x00, 0xea, 0x05, 0x00, 0x00, 0xea,
+ 0x9c, 0x00, 0x00, 0xea, 0x03, 0x00, 0x00, 0xea,
+ 0x18, 0x13, 0x9f, 0xe5, 0x00, 0x00, 0xa0, 0xe3,
+ 0x00, 0x00, 0x81, 0xe5, 0xfb, 0xff, 0xff, 0xea,
+ 0x01, 0x00, 0xa0, 0xe3, 0x08, 0x13, 0x9f, 0xe5,
+ 0x00, 0x00, 0x81, 0xe5, 0xd1, 0x00, 0xa0, 0xe3,
+ 0x00, 0xf0, 0x29, 0xe1, 0xfc, 0xd2, 0x9f, 0xe5,
+ 0xd2, 0x00, 0xa0, 0xe3, 0x00, 0xf0, 0x29, 0xe1,
+ 0xf4, 0xd2, 0x9f, 0xe5, 0xd3, 0x00, 0xa0, 0xe3,
+ 0x00, 0xf0, 0x29, 0xe1, 0xec, 0xd2, 0x9f, 0xe5,
+ 0x00, 0x00, 0xa0, 0xe3, 0x00, 0x10, 0xa0, 0xe3,
+ 0xe4, 0x12, 0x9f, 0xe5, 0x01, 0x22, 0xa0, 0xe3,
+ 0x01, 0x00, 0xa0, 0xe3, 0x00, 0x00, 0x81, 0xe5,
+ 0xd8, 0xa2, 0x9f, 0xe5, 0x15, 0x00, 0x00, 0xeb,
+ 0x00, 0x00, 0x82, 0xe5, 0x7d, 0xaf, 0xa0, 0xe3,
+ 0x12, 0x00, 0x00, 0xeb, 0x10, 0x00, 0x82, 0xe5,
+ 0x08, 0x60, 0xa0, 0xe3, 0x20, 0x00, 0x82, 0xe5,
+ 0x20, 0xa0, 0xa0, 0xe3, 0x0d, 0x00, 0x00, 0xeb,
+ 0x01, 0x60, 0x56, 0xe2, 0xfa, 0xff, 0xff, 0x1a,
+ 0xac, 0x52, 0x9f, 0xe5, 0x00, 0x00, 0x85, 0xe5,
+ 0x00, 0x00, 0xa0, 0xe3, 0x00, 0x00, 0x81, 0xe5,
+ 0x01, 0x02, 0xa0, 0xe3, 0x00, 0x10, 0xa0, 0xe3,
+ 0x98, 0x22, 0x9f, 0xe5, 0x04, 0x30, 0xa0, 0xe3,
+ 0x03, 0x10, 0x80, 0xe6, 0x02, 0x00, 0x50, 0xe1,
+ 0xfc, 0xff, 0xff, 0x1a, 0x02, 0x00, 0x00, 0xea,
+ 0x01, 0xa0, 0x5a, 0xe2, 0xfd, 0xff, 0xff, 0x1a,
+ 0x0e, 0xf0, 0xa0, 0xe1, 0x00, 0x10, 0xa0, 0xe3,
+ 0x01, 0x28, 0xa0, 0xe3, 0x7f, 0x2f, 0x82, 0xe2,
+ 0x02, 0x16, 0x81, 0xe0, 0x12, 0x30, 0xa0, 0xe3,
+ 0x03, 0x3b, 0x83, 0xe2, 0x00, 0x00, 0xa0, 0xe3,
+ 0x00, 0x2a, 0x83, 0xe1, 0x04, 0x20, 0x81, 0xe4,
+ 0x01, 0x00, 0x80, 0xe2, 0x01, 0x0c, 0x50, 0xe3,
+ 0xfa, 0xff, 0xff, 0xba, 0x1e, 0x30, 0xa0, 0xe3,
+ 0x03, 0x3b, 0x83, 0xe2, 0x00, 0x2a, 0x83, 0xe1,
+ 0x04, 0x20, 0x81, 0xe4,
[speedtouch] Re: help needed with testing auto-detect Rev patch
Hello John, > which means the same modem_run works for Rev and Rev 0400. Anyone > willing to test on Rev 0200? Did that and it seems to work. Never mind the version string, I did apply the patch you sent me against current CVS. Feb 11 18:15:40 pentium modem_run[1934]: modem_run version 1.2-beta3 started by root uid 0 Feb 11 18:15:40 pentium modem_run[1934]: Found ALCATEL SpeedTouch USB modem Feb 11 18:15:40 pentium modem_run[1934]: Rev 0200 detected, revision 2 chosen Feb 11 18:15:40 pentium modem_run[1934]: Best offset 0 with probability 100% Feb 11 18:15:40 pentium modem_run[1934]: Best offset 677633 with probability 100% Feb 11 18:15:41 pentium modem_run[1934]: Firmware information (CRC:0x5bca7d16, Size:677641, 2.0.1 - MacOSX - Win32(2.0.0)) Feb 11 18:15:41 pentium modem_run[1934]: BLOCK1 :883 bytes uploaded : OK Feb 11 18:15:41 pentium modem_run[1934]: BLOCK2 :511 bytes downloaded : OK Feb 11 18:15:43 pentium modem_run[1934]: BLOCK3 : 677641 bytes uploaded : OK Feb 11 18:15:43 pentium modem_run[1934]: BLOCK4 :511 bytes downloaded : OK Feb 11 18:15:44 pentium modem_run[1934]: Modem reference : .. Feb 11 18:15:58 pentium modem_run[1943]: Sending a signal to notify the adsl up state Feb 11 18:15:58 pentium modem_run[1934]: ADSL synchronization has been obtained Feb 11 18:15:58 pentium modem_run[1934]: ADSL line is up (1024 kbit/s down | 320 kbit/s up) Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Haven't compiled this yet, but this is the idea. Set a timeout so the
subprocess checks 5 times while the main loop waits. I know get_state works
on rev 4 modems because I get the line speed reported, so it should
eventually see the modem sync and the forked process should die. I probably
still need some counter and limit code for the forked process to die if all
goes wrong or it will sit there logging every 12 seconds forever?
@@ -1083,8 +1262,8 @@
int ret;
unsigned char lbuf[6];
- /* We can try reading the int endpoint */
- ret = pusb_endpoint_read(ep_int, lbuf, sizeof(lbuf), 0);
+ /* We can try reading the int endpoint 5 times */
+ ret = pusb_endpoint_read(ep_int, lbuf, sizeof(lbuf), timeout*200);
/* Ok we failed, perhaps the device has been disconnected */
if(ret < 0 && errno == ENODEV) {
@@ -1093,9 +1272,9 @@
}
/* Just a failure -- report the error and then wait in the waiting loop
*/
- if(ret < 0)
-report(0, REPORT_ERROR, "Error reading interrupts\n");
-
+ /*if(ret < 0) */
+ /* report(0, REPORT_ERROR, "Error reading interrupts\n");*/
+
/*
* Perhaps the reading is a success, in this case the buffer is 6 bytes
* long and the content of the buffer is the line state as described
@@ -1139,6 +1318,7 @@
/* Get the state from the device */
get_state(fdusb, buf);
+print_state(buf);
if(memcmp(buf, prevbuf, TOTAL)) {
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
I read the info on your page and I agree with you and others that my connection behave better with speedtouch driver user mode when I was using V1.1 than V1.2x but many other packages have changed and I use a different hardware in my box so I was not able to know what was the root cause. I know one other guy which have reversed to V1.1 driver on IPCop V1.3 and found the same reliability improvement with the old driver. Because now I can use user and kernel mode driver on IPCop, I saw the same trouble (that I named EMI bug) like you with both drivers so modem_run may be the guilty. This is with a green stingray rev0 and kernel mode driver with rp-pppoe plugin Feb 9 22:02:30 adsl modem_run[4021]: modem_run version 1.2-beta3 started by root uid 0 Feb 9 22:02:30 adsl modem_run[4021]: Found ALCATEL SpeedTouch USB modem Feb 9 22:02:30 adsl modem_run[4021]: Rev detected, revision 0 chosen Feb 9 22:02:30 adsl modem_run[4021]: Best offset 0 with probability 100% Feb 9 22:02:30 adsl modem_run[4021]: Best offset 671645 with probability 100% Feb 9 22:02:31 adsl modem_run[4021]: Firmware information (CRC:0x3b4a5854, Size:671653, 1.6.1 - MacOSX - Win32(1.0.1800)) Feb 9 22:02:33 adsl kernel: usb_control/bulk_msg: timeout Feb 9 22:02:33 adsl kernel: usbdevfs: USBDEVFS_BULK failed dev 3 ep 0x85 len 512 ret -110 Feb 9 22:02:33 adsl modem_run[4021]: BLOCK1 :883 bytes uploaded : OK Feb 9 22:02:33 adsl modem_run[4021]: BLOCK2 :511 bytes downloaded : OK Feb 9 22:02:36 adsl modem_run[4021]: BLOCK3 : 671653 bytes uploaded : OK Feb 9 22:02:36 adsl modem_run[4021]: BLOCK4 :511 bytes downloaded : OK Feb 9 22:02:37 adsl modem_run[4021]: Found kernel mode driver Feb 9 22:02:37 adsl modem_run[4021]: Modem reference : 3EC18607CAAA08 Feb 9 22:02:49 adsl modem_run[4022]: Sending a signal to notify the adsl up state Feb 9 22:02:49 adsl modem_run[4021]: ADSL synchronization has been obtained Feb 9 22:02:49 adsl modem_run[4021]: ADSL line is up (608 kbit/s down | 160 kbit/s up) This is with a purple rev 200 and kernel mode driver with rp-pppoe plugin Feb 9 22:09:09 adsl modem_run[4236]: modem_run version 1.2-beta3 started by root uid 0 Feb 9 22:09:09 adsl modem_run[4236]: Found ALCATEL SpeedTouch USB modem Feb 9 22:09:09 adsl modem_run[4236]: Rev 0200 detected, revision 2 chosen Feb 9 22:09:09 adsl modem_run[4236]: Best offset 0 with probability 100% Feb 9 22:09:10 adsl modem_run[4236]: Best offset 671645 with probability 100% Feb 9 22:09:10 adsl modem_run[4236]: Firmware information (CRC:0x3b4a5854, Size:671653, 1.6.1 - MacOSX - Win32(1.0.1800)) Feb 9 22:09:12 adsl kernel: usb_control/bulk_msg: timeout Feb 9 22:09:12 adsl kernel: usbdevfs: USBDEVFS_BULK failed dev 4 ep 0x85 len 512 ret -110 Feb 9 22:09:12 adsl modem_run[4236]: BLOCK1 :883 bytes uploaded : OK Feb 9 22:09:13 adsl modem_run[4236]: BLOCK2 :511 bytes downloaded : OK Feb 9 22:09:16 adsl modem_run[4236]: BLOCK3 : 671653 bytes uploaded : OK Feb 9 22:09:16 adsl modem_run[4236]: BLOCK4 :511 bytes downloaded : OK Feb 9 22:09:17 adsl modem_run[4236]: Found kernel mode driver Feb 9 22:09:17 adsl modem_run[4236]: Modem reference : 3EC3665601 Feb 9 22:09:29 adsl modem_run[4237]: Sending a signal to notify the adsl up state Feb 9 22:09:29 adsl modem_run[4236]: ADSL synchronization has been obtained Feb 9 22:09:29 adsl modem_run[4236]: ADSL line is up (608 kbit/s down | 160 kbit/s up) This is with a purple rev 200 and user mode driver with pppoa3 in PPPoA mode (I haven't anything for -e switch and it work) Feb 9 22:27:35 adsl ipcop: AlcatelUSB: Uploading firmware to modem Feb 9 22:27:35 adsl modem_run[4524]: modem_run version 1.2-beta3 started by root uid 0 Feb 9 22:27:35 adsl modem_run[4524]: Found ALCATEL SpeedTouch USB modem Feb 9 22:27:35 adsl modem_run[4524]: Rev 0200 detected, revision 2 chosen Feb 9 22:27:35 adsl modem_run[4524]: Best offset 0 with probability 100% Feb 9 22:27:35 adsl modem_run[4524]: Best offset 671645 with probability 100% Feb 9 22:27:36 adsl modem_run[4524]: Firmware information (CRC:0x3b4a5854, Size:671653, 1.6.1 - MacOSX - Win32(1.0.1800)) Feb 9 22:27:38 adsl kernel: usb_control/bulk_msg: timeout Feb 9 22:27:38 adsl kernel: usbdevfs: USBDEVFS_BULK failed dev 6 ep 0x85 len 512 ret -110 Feb 9 22:27:38 adsl modem_run[4524]: BLOCK1 :883 bytes uploaded : OK Feb 9 22:27:38 adsl modem_run[4524]: BLOCK2 :511 bytes downloaded : OK Feb 9 22:27:41 adsl modem_run[4524]: BLOCK3 : 671653 bytes uploaded : OK Feb 9 22:27:41 adsl modem_run[4524]: BLOCK4 :511 bytes downloaded : OK Feb 9 22:27:42 adsl modem_run[4524]: Modem reference : 3EC3665601 Feb 9 22:27:54 adsl modem_run[4525]: Sending a signal to notify the adsl up state Feb 9 22:27:54 adsl modem_run[4524]: ADSL synchronization has been obtained Feb 9 22:27:54 adsl modem_run[4524]: ADSL line is up (608 kbit/s down | 160 kbit/s up) This is with a green stingray rev0 and user mode driver wit
[speedtouch] Re: help needed with testing auto-detect Rev patch
I'm thinking about the timeout for kernel mode. What if I let the subprocess
time out at the same time as the external timeout (which isn't my code, I
just picked it up from the CVS) then there wouldn't be a zombie hanging
around, but neither would there be anything looping with errors.
I have managed to borrow a Rev 0400 modem (thanks Brian) and am posting this
while using it.
What I get is this
20:06:46 modem_run[46] modem_run version 1.2-john5 started by root uid 0
20:06:46 modem_run[46] Found ALCATEL SpeedTouch USB modem
20:06:46 modem_run[46] Rev 0400 detected, revision 4 chosen
20:06:47 modem_run[46] Best offset 0 with probability 75%
20:06:47 modem_run[46] Best offset 775501 with probability 75%
20:06:48 modem_run[46] Firmware information (CRC:0x0223733c, Size:775509,
1.0.10 - Win32 Rev 0400 SACHU3)
20:06:50 kernel: usb_control/bulk_msg timeout
20:06:50 kernel: usbdevfs USBDEVFS_BULK failed dev 2 ep 0x85 len 512
ret -110
20:06:50 modem_run[46] BLOCK1 : 935 bytes uploaded : OK
20:06:50 modem_run[46] BLOCK2 : 511 bytes downloaded : OK
20:06:53 modem_run[46] BLOCK3 : 775509 bytes uploaded : OK
20:06:53 modem_run[46] BLOCK4 : 511 bytes downloaded : OK
20:06:54 modem_run[46] Modem reference : 35720370..
20:07:54 modem_run[46] ADSL synchronization has been obtained
20:07:54 modem_run[46] ADSL line is up (576 kbit/s down | 288 kbit/s up)
20:08:02 pppoa3[166] pppoa3 version 1.2-john5 started by nobody (uid 99)
20:08:02 pppoa3[166] Control thread ready
20:08:02 pppoa3[168] host --> pppoa3 --> modem stream ready
20:08:02 pppoa3[169] modem --> pppoa3 --> host stream ready
which means the same modem_run works for Rev and Rev 0400. Anyone
willing to test on Rev 0200?
As you can see it waits for exactly 60 seconds before announcing sync has
been obtained on Rev 0400, whether it has or not.
A question for people who use usermode pppoa3... Do you use the -e 1
parameter with Rev 0400 silver modems, because I am not setting it and the
modem is working OK.
- Original Message -
From: "Gary Bilkus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 08, 2004 5:55 PM
Subject: [speedtouch] Re: help needed with testing auto-detect Rev patch
> That might work. What I actually did was put a timeout in the subprocess:
> (from line 1090 of original file)
>
> memset(prevbuf, 0, TOTAL);
> static int timeoutfirsttime = 25000;
> while(1) {
>
> int ret;
> unsigned char lbuf[6];
>
> /* We can try reading the int endpoint */
> ret = pusb_endpoint_read(ep_int, lbuf, sizeof(lbuf),
> timeoutfirsttime);
> timeoutfirsttime=0;
>
> /* Ok we failed, perhaps the device has been disconnected */
> if(ret < 0 && errno == ENODEV) {
> report(0, REPORT_INFO, "Device disconnected, shutting
> down");
> break;
> }
>
>
> Your version has the advantage that the timeout is settable rather than
> hard coded, but the disadvantage that the code relating to the first
> read in the child process will be triggered whenever a read does
> eventually occur, and that is probably not a good thing, so you should
> probably also make that entire section of the child process conditional
> on not v4
>
> Gary
>
> John Hysted wrote:
>
> >Would it be likely to work if I replaced
> >
> > if (revision==4)
> > timed_out = 0;
> >
> >which is an arbitrary hack which assumes everything worked for Rev 0400
> >after seconds, with
> >
> > if (revision==4) {
> >if (timed_out) {
> >if(signal_kernel) {
> >pusb_ioctl(fdusb, 1, 1, NULL);
> >}
> >timed_out = 0;
> >}
> >}
> >
> >which does the same thing, but adds the command the subprocess will never
> >run. Or is the subprocess still running and causing trouble?
> >- Original Message -
> >From: "Gary Bilkus" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Sunday, February 08, 2004 4:11 PM
> >Subject: [speedtouch] Re: help needed with testing auto-detect Rev patch
> >
> >
> >
> >
> >>John,
> >>I don't think your patched version will work with a silver rev 4 modem
> >>in kernel driver mode.
> >>As per the thread involving myself and others last week, the v4 software
> >>doesn't report status back after connecting, as a result of which the
> >>subprocess after fork() will not
> >>signal the main process to continue, but, more seriously, it will never
> >>execute the pusb_ioctl(fdusb,1,1,NULL) which is necessary to free the
> >&g
[speedtouch] Re: help needed with testing auto-detect Rev patch
That might work. What I actually did was put a timeout in the subprocess:
(from line 1090 of original file)
memset(prevbuf, 0, TOTAL);
static int timeoutfirsttime = 25000;
while(1) {
int ret;
unsigned char lbuf[6];
/* We can try reading the int endpoint */
ret = pusb_endpoint_read(ep_int, lbuf, sizeof(lbuf),
timeoutfirsttime);
timeoutfirsttime=0;
/* Ok we failed, perhaps the device has been disconnected */
if(ret < 0 && errno == ENODEV) {
report(0, REPORT_INFO, "Device disconnected, shutting
down");
break;
}
Your version has the advantage that the timeout is settable rather than
hard coded, but the disadvantage that the code relating to the first
read in the child process will be triggered whenever a read does
eventually occur, and that is probably not a good thing, so you should
probably also make that entire section of the child process conditional
on not v4
Gary
John Hysted wrote:
>Would it be likely to work if I replaced
>
> if (revision==4)
> timed_out = 0;
>
>which is an arbitrary hack which assumes everything worked for Rev 0400
>after seconds, with
>
> if (revision==4) {
>if (timed_out) {
>if(signal_kernel) {
>pusb_ioctl(fdusb, 1, 1, NULL);
>}
>timed_out = 0;
>}
>}
>
>which does the same thing, but adds the command the subprocess will never
>run. Or is the subprocess still running and causing trouble?
>- Original Message -
>From: "Gary Bilkus" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Sunday, February 08, 2004 4:11 PM
>Subject: [speedtouch] Re: help needed with testing auto-detect Rev patch
>
>
>
>
>>John,
>>I don't think your patched version will work with a silver rev 4 modem
>>in kernel driver mode.
>>As per the thread involving myself and others last week, the v4 software
>>doesn't report status back after connecting, as a result of which the
>>subprocess after fork() will not
>>signal the main process to continue, but, more seriously, it will never
>>execute the pusb_ioctl(fdusb,1,1,NULL) which is necessary to free the
>>driver to attach to the pppoatm code.
>>As I understand it, this doesn't matter if you are using the pppoa
>>userspace code, so many users of the driver won't care. However, for
>>those of us usuing 2.6 kernels, only the kernel space driver currently
>>works.
>>
>>Rgds,
>>Gary
>>
>>
>
>
>
>Liste de diffusion modem ALCATEL SpeedTouch USB
>Pour se désinscrire : mailto:[EMAIL PROTECTED]
>
>
>
>
>
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
Would it be likely to work if I replaced
if (revision==4)
timed_out = 0;
which is an arbitrary hack which assumes everything worked for Rev 0400
after seconds, with
if (revision==4) {
if (timed_out) {
if(signal_kernel) {
pusb_ioctl(fdusb, 1, 1, NULL);
}
timed_out = 0;
}
}
which does the same thing, but adds the command the subprocess will never
run. Or is the subprocess still running and causing trouble?
- Original Message -
From: "Gary Bilkus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 08, 2004 4:11 PM
Subject: [speedtouch] Re: help needed with testing auto-detect Rev patch
> John,
> I don't think your patched version will work with a silver rev 4 modem
> in kernel driver mode.
> As per the thread involving myself and others last week, the v4 software
> doesn't report status back after connecting, as a result of which the
> subprocess after fork() will not
> signal the main process to continue, but, more seriously, it will never
> execute the pusb_ioctl(fdusb,1,1,NULL) which is necessary to free the
> driver to attach to the pppoatm code.
> As I understand it, this doesn't matter if you are using the pppoa
> userspace code, so many users of the driver won't care. However, for
> those of us usuing 2.6 kernels, only the kernel space driver currently
> works.
>
> Rgds,
> Gary
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
John, I don't think your patched version will work with a silver rev 4 modem in kernel driver mode. As per the thread involving myself and others last week, the v4 software doesn't report status back after connecting, as a result of which the subprocess after fork() will not signal the main process to continue, but, more seriously, it will never execute the pusb_ioctl(fdusb,1,1,NULL) which is necessary to free the driver to attach to the pppoatm code. As I understand it, this doesn't matter if you are using the pppoa userspace code, so many users of the driver won't care. However, for those of us usuing 2.6 kernels, only the kernel space driver currently works. Rgds, Gary John Hysted wrote: >I have produced a patch for modem_run which should auto-detect the modem >revision and execute the appropriate code for Rev , 0200 and 0400 >modems, but as I only have a green frog I am unable to test this. >For me, the patch fixes the "Error reading usb urb under heavy load on >version 1.2" problem by reverting to alternate endpoint 2 when a Rev >modem is detected. >As the patch file is 16kb, I have not attached it, but it is available as >john5_patch.patch from http://www.hystedjp.pwp.blueyonder.co.uk/ . >Could you please post the Rev of your modem (P: Vendor=06b9 ProdID=4061 >Rev= 0.00 from /proc/bus/usb/devices ) and the result of running modem_run >with the option -v 1 set. I am interested in the line that says 08:43:40 >modem_run[46] Rev detected, revision 0 chosen. >Thanks > > > >Liste de diffusion modem ALCATEL SpeedTouch USB >Pour se désinscrire : mailto:[EMAIL PROTECTED] > > > > > Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: help needed with testing auto-detect Rev patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 08 February 2004 09:48 am, John Hysted wrote: > I have produced a patch for modem_run which should auto-detect the modem > revision and execute the appropriate code for Rev , 0200 and 0400 > modems, but as I only have a green frog I am unable to test this. > For me, the patch fixes the "Error reading usb urb under heavy load on > version 1.2" problem by reverting to alternate endpoint 2 when a Rev > modem is detected. > As the patch file is 16kb, I have not attached it, but it is available as > john5_patch.patch from http://www.hystedjp.pwp.blueyonder.co.uk/ . > Could you please post the Rev of your modem (P: Vendor=06b9 ProdID=4061 > Rev= 0.00 from /proc/bus/usb/devices ) and the result of running modem_run > with the option -v 1 set. I am interested in the line that says 08:43:40 > modem_run[46] Rev detected, revision 0 chosen. > Thanks > > > > Liste de diffusion modem ALCATEL SpeedTouch USB > Pour se désinscrire : > mailto:[EMAIL PROTECTED] I'll try it just as soon as this large download finishes; about 8 hours from now. Martin - -- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJlvE3bF34WXq1XsRAtmcAJ9hW4D50TMtytWucn2LBWauGkTb+QCeMZA0 EiJlKWih7awc7tsQA8sAEzU= =9tpS -END PGP SIGNATURE- Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
