On Wed, Nov 22, 2000 at 01:28:09PM +0000, Robert Collier wrote:
> Hi Jean,
>
> In article <[EMAIL PROTECTED]> you write:
> >On Tue, Nov 21, 2000 at 01:40:30PM +0000, Robert Collier wrote:
>
> > A pretty common cause of troubles for IrDA is a botched module
> >configuration.
> [...]
> > Common module problems :
> > o Compiling the IrDA stack static (i.e. non module)
>
> !! This is new. If the irda stack has to be a module - please document
> the fact in big letters somewhere. I have the irda stack compiled into
> my kernel, but with modular fir driver and protocol drivers. This
> worked with 2.4.0-test10 and many previous kernels.
>
> > o Mixing static and module bits in the IrDA stack
>
> Which I am doing - "it worked before"(TM) :)
In both cases, it should work, but I've never tested it, and
I'm not sure how it is supposed to work, so I don't advise people to
try it.
By the way, I was not responsible for the changes in the init
code... And patches are welcomed...
> Thanks for your help.
>
> I will rebuild the stack in a completely modular fashion and try
> again.
>
> - Regards, Robert.
> It appears to get further then before now.
>
> IrDA initialises, and /proc/net/irda/* exists.
>
> Discovery does not appear to work however. irdadump reveals no packets
> being sent or received (with my visor trying to beam at the laptop).
Now, for the discover problems. Since the latest discovery
changes made in the IrDA stack (around test6-irda3), I do also have
sometimes some discovery problems when no discovery do happen at all
and things seem to be deadlocked. By the way, I was not responsible
for those changes.
The solution for me is to restart the IrDA stack with nothing
in front of the IrDA port, check with irdadump that things are ok,
and then go for it. Annoying, but workable.
Pontus Fuchs did report this problem to Dag a couple of days
ago. Dag answer was the patch attached. Could you try this patch and
tell us if it do any good ?
Have fun...
Jean
@@ -551,13 +551,15 @@ static int irlap_state_query(struct irla
* since we want to work even with devices that violate the
* timing requirements.
*/
- if (irda_device_is_receiving(self->netdev)) {
+ if (irda_device_is_receiving(self->netdev) && !self->add_wait) {
IRDA_DEBUG(1, __FUNCTION__
"(), device is slow to answer, "
"waiting some more!\n");
irlap_start_slot_timer(self, MSECS_TO_JIFFIES(10));
+ self->add_wait = TRUE;
return ret;
}
+ self->add_wait = FALSE;
