Re: comedi_config causes system reboot, opteron problem?

Quoting Andreas Leuner <"Ryan Hooper" <ryan.hooper_at_emory.edu>:

> After compiling a vanilla kernel with MTRR disabled, I went with CVS,
> too, since I had to rebuild the kernel, anyhow. The system still
> crashed/rebooted when I ran comedi_config /dev/comedi0 ni_pcimio,
> though, so it must not be a rtai dependency problem.
 From this I can't see that RTAI is not the problem. MTRR support is just a
general obstacle for RTAI to run fine in some circumstances. Did you test
a plain linux kernel - without adeos patch - plus non RTAI-dependent
comedi modules on your opteron? This should install fine next to your
linux-2.4.27-adeos if those kernels have a different extra version (which
they should have anyway: "-adeos" and "")

>
>> doesn't just 'modprobe ni_pcimio' work?
>
> That was a nice way to load those modules, works great.
If you plan to use the rtai_comedi module you will have to use the lxrt
scheduler. That means you will make sure that rtai_lxrt.o is listed as one
of its dependency - not rtai_up.o or rtai_smp.o. You get this if you
remove the link rtai_ksched.o from the module directory and re-run depmod
   rm RTAI_MODULESDIR/rtai_ksched.o && depmod -ae

>> There are a few things you could try:
>> - use comedi_test driver instead of ni_pcimio. This one doesn't need a
>> card
>
> Interestingly, that appears to work. I see this when I check dmesg:
>
> comedi1: comedi_test: 1000000 microvolt, 100000 microsecond waveform
> attached
This seems to indicate that RTAI is not guilty. There might still be
problems with PCI cards somehow caused only when rtai is enabled. I really
do not have the knowledge to say why - only that it is a possibility you
seem not to have eliminated yet. You could do that with a plain non-rtai
dependent comedi install.

Anyhow I think that it's more likely that comedi PCI problems on 64bit
architectures exist - not so many people seem to have used comedi with
opterons till now (try googling "opteron athlon64 comedi").

>
>> - test the card on another pc
This should mean "test the card on a 32bit linux pc with rtai-dependent
comedi" to decide if the opteron architecture is the problem
>>
>> - test the card with its accompanying software on a windows pc
>>
>
> I stuck the DAQ card in a windows machine with labview installed and ran
> some tests. The card seemed to work flawlessly; the system recognized it
> right away and handled digital and analog input and output just fine.
>
>>
>> That's quite a lot of modules. For realtime work you might disable those
>> of them (e.g. the sound related ones) you don't need. Also look in the
>> kernel configuration if you enabled mtrr support - if so, disable it.
>>
>
> I disabled sound and firewire in my BIOS and vanilla kernel config, but
> that didn't do the trick. Then I did a rmmod on everything that wouldn't
> crash the system before trying again, and still it crashed on
> comedi_config. Finally, I wiped my hard disk clean, installed Fedora
> Core 3, installed a vanilla 2.6.9 kernel, installed comedi/comedilib
> from CVS, and still comedi_config reboots the system. I tried the same
> for a kernel reconfigured for a uniprocessor.
That's quite a lot of work. I only suggested disabling those modules
because some might cause stability problems during realtime work - I had
experienced lots of oopses and hangs until I compiled a kernel configured
with minimality in mind. So this too is a general stability measure - I
suspect this won't help much with your problem since comedi_test worked
for you. All my oopses were card- independent.
>
> I'm curious, has anyone else managed to make comedi work on a computer
> with an Opteron, or any AMD64?
>
> I also wonder about my PCI bus, since I have 4X PCI-100MHz and 1X
> PCI-133MHz. At least the NI PCI-6052E is supposedly PCI 2.3 compliant (I
> tried moving the card to all the different PCI slots, no luck), but I
> wonder if comedi can handle those kind of busses. I still do get this in
> dmesg after I modprobe ni_pcimio, though:
>
> ......cut......
> comedi: version 0.7.70 - David Schleef <ds_at_schleef.org>
> Available NI device IDs: 0x18b0
That means the ni_pcimio driver -- which supports a lot of National
Instruments PCI cards with an "E" in their name -- correctly identified
your card as a PCI-6052E one.

I'll try to test a NI DAQCard 6024E PCMCIA card I am working with on a
Athlon64 laptop soon and provide the results of this then.

Bye,
  Andreas Leuner

Received on 2005-07-29Z08:04:30