3.4. Troubleshooting, Mailing List

3.4.1. General Information

If you encounter problems. Try the following:

Read the FAQ section below.
Look at /var/log/messages and/or /var/log/kern.
Do a dmesg.
Look at the different files in /proc/irda.
Look at the mailing list archivs, whether your problem is already known. Since August 1999 it the archiv is located at Linux-IrDA mailing list archiv. All mails before are archived at http://www.ita.chalmers.se/~svinto/hypermail/irda/ .
As a last ressort ask in the Linux-IrDA mailing list. You may subscribe at Linux-IrDA mailing list . You are welcome to use this mailing list for posting questions, answers, bug-reports, patches, suggestions and comments. It would be much easier to help you if you provide some information. Please include:
uname -a cat /proc/net/irda/irlan cat /proc/net/irda/irlap irdadump
There is also a new IrDA related mailing-list. This list is driven by Dag Brattli and the Pasta project, and is intended for discussion about IrDA protcols, setups, configurations, devices, and problems that users and developers might have and want to discuss with others. So this is ment to be a much more general list than the Linux-IrDA list. You can find the list at: Linux-IrDA list. Archives can be found at: Linux-IrDA list archiv . From Dag Brattlis announcement: Though "IrDA is already running a public (but web-only) mailing-list, and I hope it's OK that we run these two lists in parallel. I'm not trying to have any competition ;-) but my intentions are purely to make it easier for users and developers to publicly discuss IrDA related (and non-Linux specific) issues with each other. I have named the list IrDA <irda@pasta.cs.uit.no> since it's about IrDA, so I hope this is OK for IrDA. If you visit the list, you will see that I have choosen to call it: IrDA -- The Pasta Projects Unofficial IrDA Forum.

3.4.2. Troubleshooting Techniques

Although I'm not much of a hacker I collected some tricks to track errors or bugs in the Linux/IrDA software.

You may set the debug level in /proc/sys/net/irda/debug to 1, 2, 3, 4.

Use the files in /proc/sys/net/irda to try different parameters like echo 0 > /proc/sys/net/irda/discovery. The /proc/*/irda files are:
root@duckman:~# ls /proc/sys/net/irda/* /proc/net/irda/* /proc/net/irda/discovery /proc/net/irda/irlmp /proc/sys/net/irda/devname /proc/net/irda/irda_device /proc/net/irda/irttp /proc/sys/net/irda/discovery /proc/net/irda/irias /proc/sys/net/irda/compression /proc/net/irda/irlap /proc/sys/net/irda/debug

It is also possible to debug the code. But I don't know how to do this. If you want to use SKB debug code, you may edit irda.h and change /include/linux/skbuff.h (see revision history of snapshot 10-2-98).
For problems with the irda module a utility from the modules package kdstat might be helpful. But I was not able to try this.
"You can now alter the number of discovery packets used (1, 6, 8 or 16) and the timeout between sending them (2-8 * 10 ms) in /proc/sys/net/irda. Please experiment if you have problems discovering your device. My Palm III seems to like 16 discovery_slots and 8 (*10 ms) for slot_timeout. " ... "The absolute minimum for reliable discovery of the IR-610 seems to be 9."
Another statement: ... the Palm III does not like 8 discovery frames in a row, but 6 is OK. With 8 it will answer 1 out of 6-10 times, with 6 it answers every time. I really don't know if this is a problem with Linux-IrDA or the Palm III. One solution to this problem, is to cycle though some different discovery methods for each discovery like this:

Disocvery 1: send 8 xid frames with 80 ms separation

If answer, keep the same config, if no answer, try next config

Discovery 2: send 6 xid frames with 80 ms separation

Discovery 3: send 8 xid frames with 90 ms separation

Discovery 4: send 6 xid frames with 90 ms separation

Discovery 5. Go back to 1.

or some other pattern and maybe more combinations.

Maybe this is sometimes implemented, so it would be enabled if /proc/sys/net/irda/discovery_slots is set to 0 .
If anybody gets a kernel Oops, then please feed it to the ../linux/scripts/ksymoops/ksymoops program, so that we can find out where it went wrong. Just cut out the Oops lines from the syslog, save them to a file, and then run ksymoops <file>
Dag Brattli wrote: I found out that the cs4232 sound card was giving me several hundred interrupts per second! I removed the sound stuff from my kernel, and the machine is now generally about 4 times faster! Linux/IrDA may get problems if you are running the esound server (esd) on your machine. Both my machines, a 166Mhz Pentium laptop and a 200Mhz Pentium Pro cannot run Linux/IrDA when esd is running. The reason is that esd makes the soundcard give interrups over 300 times/second which makes the serial driver overrun when receiving. This is because the serial driver now uses slow interrupts in Linux-2.2 (everything is slow interrupts in 2.2), so the interrupt-handler schedules on its way out. The good thing about slow interrupts is that packets are delivered much faster, since you don't need to wait for the next timer-tick. The only exception for this is the pc87108 driver which works fine since it uses DMA and will only give a couple of interrupts per packet.
There are also some userspace tools irdaping and irdadump to check Linux/IrDA connections.
AFAIK it is possible to use IrCOMM either with an infrared device or via serial cable. Maybe this give some debugging possibilities, too.
1) You may edit /etc/conf.modules, adding the following lines:
option irda irda_debug=3 option irlpt_client_debug=3 irlpt_common_debug=3
2) Make sure the irda modules have been totally removed.
3) Edit /etc/syslog.conf, adding the following lines:
*/* -/var/log/all
4) Do killall -1 syslogd .

5) Print, or do whatever causes problems with irlpt .

6) Check all the files in /var/log/ .