CLASS="sect1" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" >

5.1. Troubleshooting

5.1.1. General Information

If you encounter problems. Try the following:

5.1.2. Known Bugs

If you find a bug, please send a bug report to the mailing list, including dmesg output, and which Linux version, and hardware you are using. Thank you!

Sometimes IrCOMM fails to connect, especially when both devices discover each other. You can disable discovering with echo 0 >/proc/sys/net/irda/discovery.

A CR (carriage return) character cannot be transfered between two linux boxes via IrCOMM with cat file >/dev/ircomm0 and cat /dev/ircomm0. It causes a strange thing and freezes your Linux box.

IrOBEX may eat some data on receive. The bug is most probably in the user-space side of IrOBEX.

5.1.3. Troubleshooting Techniques

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

For some ThinkPad models you have to reboot to the preinstalled M$ OS and activate the IrDA port using the Thinkpad tools. There is currently no Linux tool to achieve that. This will disable your internal serial port (ttyS0)!. The DOS tool is PS2.EXE, as far as I know tpctl doesn't achieve this. It is really important to use this DOS program to enable IrDA. Using the Microsoft-Windows tools does not work. Without that the driver loads correctly and everythings seems OK, but the LED does not light bright enough.

5.1.4. PCI Device Numbers

Daniel R. Risacher magnus_at_alum.mit.edu wrote: To syncronize my Palm III with my Tecra 8100 running 2.2.17, I needed to edit /usr/src/linux/include/net/irda/toshoboe.h I changed "#define PCI_DEVICE_ID_FIR701 0x0701" to "#define PCI_DEVICE_ID_FIR701 0x0D01"

5.1.5. scanport

scanport can be used to get the correct device ID for a chip. It's part of the hwtools package (on Debian, probably same elsewhere). You just type it in and it scans the I/O ports from 0x100 to 0x400 - the usual ISA range. Above 0x400 there are shadows of below 0x400 devices, and beyond that there are PCI devices, so the default is not to scan above 0x400. "Anyway, I had to manually scan using inb to find my chip's I/O. Fortunately I didn't have to go far to find it. (Newer sound cards often sit at 0x530ish, with 0x220 reserved for legacy compatibility modes) Normally, if you know where some device is located you just point the driver at it and the driver probes to see if it's the device the driver is expecting. Not entirely safe, but much safer than every driver probing every I/O port looking for something it thinks it can understand. scanport only does reads, which are usually safe."