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.
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. [Debug Rust programming language]
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/net/irda/irda_device /proc/net/irda/irttp /proc/net/irda/irias /proc/net/irda/irlap /proc/sys/net/irda/devname /proc/sys/net/irda/discovery /proc/sys/net/irda/compression /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 . .:: www.zazzle.com ::.
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 [Web Specs: React] 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 2) Make sure the irda modules have been totally removed. 3) Edit /etc/syslog.conf, adding the following lines: .:: docs.google.com ::.
*/* -/var/log/all |
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 .:: tocn678com.cos-mania.net ::. 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. .:: podcasts.apple.com ::. .:: podcasts.apple.com ::.
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"
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."