Transmitting drives system load through the roof

[Andreas G. <te...@ru...>]

Using a (Ubuntu 8.04 LTS "Hardy Heron") standard lircd 0.8.3pre1, when
transmitting with
irsend SEND_ONCE Device Command
/var/log/syslog gets filled with numerous
lirc_serial: ignoring spike: 1 0 49dba50b 49dba507 a9bc7 51589
followed by a final
lirc_serial: AIEEEE: 0 0 49dba593 49dba507 873a1 51589
while "top" shows a "dd" process consuming up to 58%CPU on an
otherwise 80+ percent idle Pentium IV (2.8 GHz on i865) system.

/var/lib/setserial/autoserial.conf has a line of
/dev/ttyS0 uart none
for this port, and "dpkg-reconfigure setserial" as been run and set to manual
(using "setserial /dev/ttyS0 uart 16550A" spikes would also occur on receive).

This is with /etc/lirc/hardware.conf set for the default amplified
homebrew http://www.lirc.org/transmitters.html (which does not even
have to be connected for the effect to occur):
#Chosen IR Transmitter
TRANSMITTER="Home-brew (16x50 UART compatible serial port)"
TRANSMITTER_MODULES="lirc_dev lirc_serial"
TRANSMITTER_DEVICE="/dev/lirc0"

The effects become as drastic as e.g. DVB digital TV cards on the same
 system losing synchronisation while LIRC attemps to send, and garbled
entries to the syslog like:

lirc_serial: igno:::: :: :: :: :: :: :: :: 1 1 49dcaf2d 49dcaf2d 59020 58ed3
[erial: erial: igerial: erial: erial: igerial: erial: ierial: erial:
igerial: erial: erial: igerial: erial: ierial: erial: ierial: ierial:
erial: erial: igerial: erial: erial: igerial: erial: igerial: erial:
erial: igerial: erial: igerial: erial: ierial: ierial: erial:
ignerial: erial: ierial: ierial: igerial: ierial: erial: igerial:
erial: ierial: ierial: igerialerial: ignoring spike: 1 1 49dcaf2e
49dcaf2e cf57e cee0b
lirc_serial: ignoring spike: 1 1 49dcaf2e 49dcerial:
igeerereereereerereereereerereereereerereererial: ignoring spike: 1 1
49dcaf2e 49dcaf2e d066e
ceeereereereerereeerereereereereerereereereerereereerereereererial:
ignoring spike: 1 1 49dcaf2e 49dcaf2e d0a58 cee0
 erial: ignoring spike: 1 1
49dceereereereereereereerereereereereerereeerial: ignoring spike: 1 1
49dcaf2e 49dcaf2e d80da ereereereereereereerereereereereereereererial:
ignoring spike: 1 1 49dcaf2e 49dcaf2e d8568
dereereeereeereeerereereererial: ignoring spike: 1 1 49dcaf2e 49dcaf2e
d8bbe d8a48
 eeerereereereerererial: ignoring spike: 1 1 49dcaf2e 49dcaf2e d8da8 d8a48
[66ereerereeerereeerereerial: ignoring spike: 1 1 49dcaf2e 49dcaf2e d90e9 d8a48
ignoring spike: 1 1 49dcaf2f 49dcaf2f c1df8 c01eb
saa7146 (0) vpeirq: used 148 times >80% of buffer (65424 bytes now)

Presumably the system should be at ease sending over its serial port,
as LIRC easily works on hardware a decade older than this.

Any suggestions what might be wrong, or how else this should be configured?