Known Problems
This section documents some issues to be aware of when using the FarSync
Drivers. Where possible, workarounds to problems are also documented.
- Frame ordering on multi processor architectures
When
the FarSync driver has been installed in WAN mode, or has been installed in
OEM mode but the OEM application is using the Raw API, then there is a
possibility that any frames passed up to the networking layer could be
re-ordered.
This is because the function that the FarSync driver calls to
queue the received frame will place the frame on a queue that is associated
with the CPU that the driver is running in. This queue is serviced at
intervals (along with a similar queue for all the other CPU's) by the
networking layer, and the queues are processed in CPU number order.
In
this way it is possible for one frame to be placed on a queue for CPU1 and
the next frame to be placed on the queue for CPU0. Hence, the next
time the networking software is scheduled, it will pick up the second frame
before the first.
The problem can be resolved for the case when
FarSync PCI cards are used by setting the affinity of the interrupt
assigned to the FarSync card to the first CPU.
e.g. echo "1" > /proc/irq/<irq no>/smp_affinity
This will ensure that
all received frames are handled by CPU0 and therefore avoids the "frames out
of order problem". Please see the /etc/init.d/farsync init script
for the placeholder on where to set the processor affinity to the required interrupt
number for the card.
However, this approach cannot be taken for the FarSync Flex, as there
are no interrupts assigned for this device. However, for the WAN mode
driver, the higher layer protocols will resolve
this issue if it occurs. And for the OEM mode driver, we recommend using the Char
interface for your applications in order to avoid this problem.
We
have modified the farmon utility to correct the frame ordering.
The problem
could still potentially affect the LapB API when used with the FarSync Flex.
- Transmit Timeouts
When using the FarSync WAN driver with large packets (e.g an MTU of 1500
byte) with slow line rates (e.g. 9600 bps or less) it is possible that
sometimes Transmit Timeouts messages may appear in the Kernel log files. If
they occur infrequently then it may be that no action is required, and the
networking layer will recover from the timeout. However, if this is a
frequent problem then there are several options that can be tried:
a) set the MTU size to a much smaller value
b) reduce
the depth of the driver transmit queue 12 frames to 2.
c) increase the timeout value from 2 seconds to something larger
If this
problem is affecting you then please contact
support@farsite.com for further
information.
- Interrupts disabled on USB controllers
It has been noted that in some 2.6.25 and 2.6.26 Kernels
disconnecting the Flex USB device causes the following message in the Kernel
log
HC died; cleaning up USB disconnect, address 4 irq 23: nobody
cared (try booting with the "irqpoll" option)
and when the device is reconnected they are not detected. This appears to be
a bug in the 2.6.25 and 2.6.26 Kernels and has been reported as fixed in
2.6.27. The workaround is to restart the usb sub-system with the following
commands:
rmmod fsflex
rmmod ehci_hcd
rmmod uhci_hcd
rmmod usbhid
modprobe ehci_hcd
modprobe uhci_hcd
insmod /etc/farsite/modules/fsflex.ko
- Unwanted Interactions with UDEV
The farsync and flex drivers now create devices from within the Kernel
modules. It has been noted that in the case of Mandirva the device names can
end up being changed to unpredictable values and the networking software
cannot them find the devices to use. It may be that the syncX and hdlcX
devices need to be added to a blacklist of devices that are ignored by the
distro's udev rules. In the case of Mandriva this is done by editing the
file /etc/sysconfig/udev_net and making adding the sync and hdlc devices to
the BLACKLIST_PERSISTENT variable, as shown below.
BLACKLIST_PERSISTENT="bnep*|tap*|tun*|usb*|sync*|hdlc*|*.*"
You may also need to remove any automatically generated rules in the /etc/udev/rules.d/
directory. Again, in the case of Mandriva the following rules were deleted
from the file 61-net_config.rules
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*",
SYSFS{address}== "58:30:30:30:30:30:30:31", NAME="hdlc0",
ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*",
SYSFS{address}== "58:30:30:30:30:30:30:31", NAME="hdlc1",
ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*",
SYSFS{address}== "58:30:30:30:30:30:30:31", NAME="hdlc2",
ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*",
SYSFS{address}== "58:30:30:30:30:30:30:31", NAME="hdlc3",
ENV{MDV_CONFIGURED}="yes"
- Memory leak
There is a small memory leak when the FarSync drivers are continuously
loaded/unloaded. This should not be a problem in normal operation.
- Fixing Device Names
It is only possible to fix a
Flex device name to a specific serial number with Kernel version greater
than 2.6.12