On Thu, Jun 19, 2003 at 12:37:45PM -0700, Christian Sauer wrote:
> Below the data you asked for as well as the original mail with both dmesg.
> Thanks for your time and help!
> Now to your points:
> > First, I would like to verify which version of the IrDa stack you
> are using (which kernel).
> > You seem to be using a recent version, but just want to check.
> I'm using 2.4.20 with a few patches applied (I think):
Ok. I can't accuse you of not having all the latest fixes ;-)
> > Also, tell me the value of /proc/sys/net/irda/max_tx_window...
> I explicitly set it to '1', since I read somewhere it could lead to problems
> with some devices.
> So I thought I play it save, but it didn't change anything.
Ok, this explains the first thing I say. In your case, you
should be able to use 7 without any issues. *should* ;-)
> *** REVEIVER ***
> # cat /proc/net/irda/irttp
> TSAP 0, stsap_sel: 10, dtsap_sel: 11
> connected: TRUE, avail credit: 0, remote credit: 0, send credit: 15
> tx packets: 1, rx packets: 16, tx_queue len: 0 rx_queue len: 0
> tx_sdu_busy: FALSE, rx_sdu_busy: FALSE
> max_seg_size: 2039, tx_max_sdu_size: 0, rx_max_sdu_size: 0
> Used by (uclinux-simple)
Puzzling. avail and remote should not go together to zero. The
magic piece of code is :
self->avail_credit = (self->initial_credit -
The dmesg tell the same story :-(
Ok, do you want to try the patch attached ?
The first part is a wild stab at the problem. If it fixes it,
you have a bug in your compiler. The second part is extra debug that I
need (that would show up in dmesg of the receiver).
From: Jean Tourrilhes <jt@bo...> - 2003-06-19 23:10:24
On Thu, Jun 19, 2003 at 03:39:59PM -0700, Christian Sauer wrote:
> Sorry but your patch didn't fix it (would have been to easy :-( ... ).
> Here it comes: the new dmesg.
> *** RECEIVER ***
> irttp_run_rx_queue() initial=16,send=15,avail=0,remote=8
> irttp_run_rx_queue() rx_queue len: 1 ; rx_fragment len: 0
At that point, I expect the flow control to kick in, but it
> irlap_do_event(), event = RECV_I_CMD, state = LAP_NRM_S
You will need to debug that one for me by hand.
At the end of the function irttp_run_rx_queue() - the same
where I did the patch - there is the calculation of self->avail_credit
- the snipet I quoted in the previous e-mail. Just after this
calculation, print in the log the value of self->avail_credit (using
the same IRDA_DEBUG() stuff).
Also, put another IRDA_DEBUG() statement to check if the code
goes into the branch and execute irttp_give_credit(self);
I suspect that your kernel source is bogus, so check the
irttp.c file against the one in 2.4.21.