[speedtouch] Re: Getting close Was Not your normal Speedtouch Woes!
I know that my comment is not in the subject, but... How can we use the kernel driver ? (compiled as a speedtch.o module ?) ;) KnuX - Original Message - From: "Duncan Sands" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Edouard Gomez" <[EMAIL PROTECTED]> Sent: Monday, November 17, 2003 10:32 PM Subject: [speedtouch] Re: Getting close Was Not your normal Speedtouch Woes! > > On Monday 17 November 2003 22:28, Edouard Gomez wrote: > > Bill Bennett ([EMAIL PROTECTED]) wrote: > > > Is there a good reason NOT to use the kernel driver? > > > > - If you use a BSD > > - If you use an old Linux kernel (<2.4.20 and 2.2.x) > > < 2.4.16 > > > then the userspace driver is only choice you have. You can (safely) use > > the kernel driver with linux >2.4.20 and 2.6. > > Duncan. > > > 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: [CVS commits] Various small things
Hello Edouard, > I guess the sourceforge anonymous cvs is still in a pity state and > lagging way behind the developer cvs access. > > This patch was already applied with the changes I listed. It was not a > patch modification request but a report. Let's blame sourceforge that > made you loose time on this. It's not that bad. Maybe you didn't change the declaration of lbuf to use ATM_CELL_TOTAL_SIZE yet, and there are other changes I mentioned that were not in the patch I submitted to CVS. > The changes may show up in the anonymous cvs soon[1]. Ok. Did you also apply the changes you mentioned yesterday (fe using parameters from atm.h)? Note that the merging of the two if (pti == 1) 's is probably still a good idea, as well as the combination of the nb_cells and num_bytes_new calculation. If you send me a g/bzipped tarball of the current state of CVS I will apply these changes to that. Or you'll have to wait until anonymous CVS gets updated and I can patch against that. If I didn't oversee anything that should wrap up this thread. Bye, Leonard. -- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: [CVS commits] Various small things
Hi, (One man thread :) > Correction. unused_cells is initialised to lbuf at the first loop, and the > value of unused_cells is changed to atm_pointer by the call to > aal5_frame_from_atm_cells. This is probably a way to walk through lbuf. Ie > the use of unused_cells instead of lbuf makes sense. I'll have to look at > this a little closer, but I guess it is correct. > > The lazy mans way to check if it behaves correctly is by using a small > lbuf. Guess I'll have a go at that ;) . Using an lbuf size of 4 * 53 works just fine, so I assume the logic is correct. I do see a "kernel: usb-uhci.c: interrupt, status 3, frame# 123" every few seconds. Probably some congestion due to the excessive amount of calls to pusb_endpoint_read when using such a small buffer. I think the patch I just submitted can not be cleaned up any further, except maybe some stripping of the comments. Bye, Leonard. -- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction. Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: [CVS commits] Various small things
Leonard den Ottolander ([EMAIL PROTECTED]) wrote: > The two checks whether pti == 1 can be merged. Dropping the "idiotic > frame length" check, using the constants from atm.h, renaming n1 to > nb_cells, moving the declaration of nb_cells inside the if (pti == 1) > and simplifiying the payload length calculation renders the following > patch: I guess the sourceforge anonymous cvs is still in a pity state and lagging way behind the developer cvs access. This patch was already applied with the changes I listed. It was not a patch modification request but a report. Let's blame sourceforge that made you loose time on this. The changes may show up in the anonymous cvs soon[1]. [1] soon, being a notion that can vary a lot lately on sourceforge, 24h hours or even a week in worst case. -- Edouard Gomez Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]
[speedtouch] Re: [CVS commits] Various small things
Hi,
I wrote:
> > The lbuf usage is still needed, it's the reading buffer. unused_cell is
> > just a pointer that keeps tracks of pppoa3 progress into the read buffer
> > if there are still ATM cells left in.
>
> Then that should be changed back. The current patch doesn't seem to use
> lbuf at all.
Correction. unused_cells is initialised to lbuf at the first loop, and the
value of unused_cells is changed to atm_pointer by the call to
aal5_frame_from_atm_cells. This is probably a way to walk through lbuf. Ie
the use of unused_cells instead of lbuf makes sense. I'll have to look at this
a little closer, but I guess it is correct.
The lazy mans way to check if it behaves correctly is by using a small lbuf. Guess
I'll have a go at that ;) .
> > I have just a doubt about the case where:
> > - num_bytes_read < 0
> >
> > It seems to me, that this case should be checked and invalidate the
> > unused_cell data.
>
> Isn't unused_cells set to NULL by aal5_frame_from_atm_cell() after the
> whole frame has been processed?
Indeed unused_cells is set to NULL. Also I don't really get your point.
Whenever num_bytes_read is not zero -num_bytes_read will be smaller than 0...
The two checks whether pti == 1 can be merged. Dropping the "idiotic frame
length" check, using the constants from atm.h, renaming n1 to nb_cells,
moving the declaration of nb_cells inside the if (pti == 1) and simplifiying
the payload length calculation renders the following patch:
diff -pruN speedtouch.000/src/pppoa3.c speedtouch/src/pppoa3.c
--- speedtouch.000/src/pppoa3.c Tue Nov 18 10:39:35 2003
+++ speedtouch/src/pppoa3.c Tue Nov 18 12:13:08 2003
@@ -955,7 +955,8 @@ static void *read_from_usb_thread(void*
{
sigset_t signal_set;
- unsigned int pos;
+ int pos;
+ int num_bytes_read = 0;
unsigned char *buffer;
unsigned char *aal5_recv_buf;
unsigned char *destination_buf;
@@ -1002,10 +1003,11 @@ static void *read_from_usb_thread(void*
int n;
int pti;
- unsigned char lbuf[64*53];
+ int num_bytes_new;
+ unsigned char lbuf[64 * ATM_CELL_TOTAL_SIZE];
unsigned char *unused_cells;
- /* Reads 64*53 bytes from usb */
+ /* Reads 64 * ATM_CELL_TOTAL_SIZE bytes from usb */
do {
n = pusb_endpoint_read(ep_data, lbuf, sizeof(lbuf), 0);
} while (n < 0 && (errno == EINTR || errno == ETIMEDOUT));
@@ -1018,55 +1020,62 @@ static void *read_from_usb_thread(void*
/* Debug information */
report(2, REPORT_DEBUG|REPORT_DATE|REPORT_DUMP, "ATM cells read from
USB (%d bytes long)\n", lbuf, n, n);
- /* Accumulates data in the aal5_recv buffer */
- /* pti will be equal to the last cell pti */
- pti = aal5_frame_from_atm_cells(aal5_recv_buf, lbuf, n, my_vpi,
my_vci, &pos, &unused_cells);
-
- /* A buffer overflow has been detected */
- if(pti<0) {
- report(0, REPORT_ERROR|REPORT_DATE, "Buffer overflow, too many
cells for the same aal5 frame\n");
- pti = 0;
- }
+ num_bytes_read += n; /* save total number of bytes to be
processed */
+ num_bytes_new = n;
+ unused_cells = lbuf; /* point at start of lbuf */
+
+ /* Accumulate all cell-data in the aal5_recv buffer */
+ /* Depending on how many cells and what type, we have to loop one or
more times until everything */
+ /* has been dealt with. (for example we read:
cell-cell-cell-'end'cell-cell-cell-cell*/
+ /* Every call to aal5_etc stops after finding an 'end'cell and then
pti = 1 ) 1 cell = 53 bytes */
+ while (unused_cells != NULL) {
+ pti = aal5_frame_from_atm_cells(aal5_recv_buf, unused_cells,
num_bytes_new, my_vpi, my_vci, &pos, &unused_cells);
+
+ /* 'pos' saves the place, where we are in the aal5_recv_buf */
+
+ /* A buffer overflow has been detected */
+ if (pti < 0) {
+ report(0, REPORT_ERROR|REPORT_DATE, "Buffer overflow,
too many cells for the same aal5 frame\n");
+ pti = 0;
+ }
- /* As the last pti is 1, we have to send the aal5_frame data */
- while(pti) {
+ /* pti = 0 (more frames to follow) or pti = 1 (end of
frame-group) */
+ /* When pti is 1, we have to send the aal5_frame data */
- /* Debug information */
- report(2, REPORT_DEBUG|REPORT_DATE|REPORT_DUMP, "AAL5 frame
joined up (%d bytes long)\n", aal5_recv_buf, pos, pos);
+ if (pti == 1) {
-
