| |
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.
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 . 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:
4) Do killall -1 syslogd .
5) Print, or do whatever causes problems with irlpt .
6) Check all the files in /var/log/ .
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 (ps2.exe) to enable IR. Using the windows tools does not
work. Without that the driver loads correctly and everythings seems
OK, but the LED does not light bright enough. Daniel R. Risacher magnus@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 is 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." |
