Hi, I have used a couple of days trying to hunt for IrCOMM bugs, and things are looking pretty good so far. Well, I haven't found any bugs in IrCOMM, but I have found several bugs in the rest of the stack. The most important ones: 1) The IrLAP final timer was calculated based on the max_turn_time in the wrong direction (rx instead of tx). This made Linux send out RR frames to early when not hearing from a secondary station if the max turn time was different for both directions. This could cause IrLAP frames to sometimes collide in rare situations. 2) IrTTP annonced wrong maximum data size (one byte to much) to IrCOMM for incomming connections which made IrCOMM sometimes use 1 byte to much when sending out data (the link would definitively go down if there was much IrCOMM traffic). This would make other devices drop the frame, and retransmission would not help, and the link would break! Bug nr. 2 was very hard to find since it only appeared sometimes for incomming connections. But I think this might be _the_ bug which have caused most headache for you. I'm seing another bug as well where the Palm stops responding to RR frames. This bug may happen if I run "cd /;ll -R" from the Palm, and run "ping -f <palm>" from Linux. This generates a _lot_ of traffic ;-) and the link may break after about 10 minutes. The Palm seems to function, but it's IR subsystem is broken. Only way to make it work again is to reset the Palm. So I suspect this has nothing to do with Linux. I'm going to make a new patch as soon as possible so you can try out these latest changes. -- Dag -- / Dag Brattli | The Linux-IrDA Project / // University of Tromsoe, Norway | Infrared communication for Linux // /// http://www.cs.uit.no/~dagb | http://www.cs.uit.no/linux-irda/ /// _______________________________________________ Linux-IrDA mailing list - [EMAIL PROTECTED] http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
