amplc_pci230: spurious interrupt

Hello there,

Um, newbie question, please be kind.

I'm using comedi-0.7.67 and comedilib-0.7.21, with a "stock" redhat kernel
(2.4.20-24.9).

I've managed to compile and install comedi and comedilibs ok. I have an
Amplicon PCI230 board (A/D, DIO, D/A etc) and have managed to
comedi_config the device (after insmod-ing comedi and amplc_pci230). In
the comedilib/demo directory, running ./info gives sensible information
about the card:

--------------------------------------------------------------------------
sds[beanbag]/demo: ./info
overall info:
  version code: 0x010000
  driver name: amplc_pci230
  board name: Amplicon PCI230
  number of subdevices: 4
subdevice 0:
  type: 1 (analog input)
  number of channels: 16
  max data value: 4095
  ranges:
    all chans: [-10,10] [-5,5] [-2.5,2.5] [-1.25,1.25] [0,10] [0,5]
[0,2.5]
  command:
    start: now
    scan_begin: follow
    convert: timer|ext
    scan_end: count
    stop: none|count
  command fast 1chan:
    start: now 0
    scan_begin: follow 0
    convert: timer 3200
    scan_end: count 1
    stop: count 2
subdevice 1:
  type: 2 (analog output)
  number of channels: 2
  max data value: 4095
  ranges:
    all chans: [0,10] [-10,10]
  command:
    start: int
    scan_begin: timer
    convert: now
    scan_end: count
    stop: none|count
  command fast 1chan:
    start: int 0
    scan_begin: timer 3200
    convert: now 0
    scan_end: count 1
    stop: count 2
subdevice 2:
  type: 0 (unused)
subdevice 3:
  type: 7 (timer)
  number of channels: 1
  max data value: 65535
  ranges:
    all chans: [0,5]
  command:
    not supported
sds[beanbag]/demo:
--------------------------------------------------------------------------

My problem is the message log. As soon as I comedi_config the device, the
kernel log gets swamped. Here's the log immediately after I run
comedi_config /dev/comedi0 amplc_pci230:

--------------------------------------------------------------------------
Dec 17 10:20:01 beanbag modprobe: modprobe: Can't locate module
char-major-98-0
Dec 17 10:20:01 beanbag kernel: comedi0: amplc_pci230
Dec 17 10:20:01 beanbag kernel: PCI: Found IRQ 11 for device 02:01.0
Dec 17 10:20:01 beanbag kernel: comedi0: amplc_pci230: I/O region 1 0xd880
I/O region 2 0xd800
Dec 17 10:20:01 beanbag kernel: comedi0: amplc_pci230: registered irq 11
Dec 17 10:20:01 beanbag kernel: 8255 support not configured -- disabling
subdevice
Dec 17 10:20:01 beanbag kernel: attached
Dec 17 10:20:01 beanbag kernel: comedi0: amplc_pci230::pci230_interrupt
spurious interruptcomedi0: amplc_pci230::pci230_interrupt spurious
interruptcomedi0: amplc_pc
i230::pci230_interrupt spurious interruptcomedi0:
amplc_pci230::pci230_interrupt spurious interruptcomedi0:
amplc_pci230::pci230_interrupt spurious interruptcomedi0:
 amplc_pci230::pci230_interrupt spurious interruptcomedi0:
amplc_pci230::pci230_interrupt spurious interruptcomedi0:
amplc_pci230::pci230_interrupt spurious interrup
tcomedi0: amplc_pci230::pci230_interrupt spurious interruptcomedi0:
amplc_pci230::pci230_interrupt spurious interruptcomedi0:
amplc_pci230::pci230_interrupt spurious
 interruptcomedi0: amplc_pci230::pci230_interrupt spurious
interruptcomedi0: amplc_pci230::pci230_interrupt spurious
interruptcomedi0: amplc_pci230::pci230_interrupt
 spurious interruptcomedi0: amplc_pci230::pci230_interrupt spurious
interruptcomedi0: amplc_pci230::pci230_interrupt spurious
interruptcomedi0: amplc_pci230::pci230_
interrupt spurious interruptcomedi0:
--------------------------------------------------------------------------

It doesn't take long for the /var/log/messages file to reach a _very_
silly size indeed. :o(

I could of course remove the printk in amplc_pci230.c, but I'm generally
of the opinion that error messages are there for a reason.

I haven't actually started using the card yet, I wanted to get this
problem out of the way first. Are there any sensible board settings I
should be applying? Is it just a case of grounding one of the pins? Has
anyone else encountered this? I've tried it on a couple of machines with
different architectures and different kernels, and I get the same result.

Any help, or requests for further information to help solve this, would be
gladly appreciated.

Many thanks,

   Steve Sharples.

Received on 2003-12-17Z10:29:52