Hello All, Not sure what list this is most appropriate to…guess I’ll start with -pci. The short, short version: Strange DMA(?) bug only occurs with a specific card x laptop combination, is maybe fixed by passing “acpi=off noapic” to the kernel, but this also slows the system down to an unusable crawl. This is under kernels 3.11.0 (Mint 16 stock) and 3.13.2 (custom compiled, have tried fiddling with/disabling various clock settings, acpi/power-saving stuff, etc. to no avail). Will attach cpuinfo, lspci -v, and lshw output. Long version: My research group has hit a dead end with getting two pieces of hardware to work together, and I’m asking around here because it seems like this might be, if not a Linux bug, then perhaps a hardware bug/oddity that Linux could work around if I had the right settings or…something. We’re trying to use a PCI analog-to-digital sampler (a Measurement Computing PCI-DAS4020/12) with a comedi Linux driver, plugged into a Magma Corp. PCI->PCIe enclosure, connected to the expresscard slot in a Lenovo T530 laptop. The 4020 card, enclosure, cabling, and expresscard have all been tested by plugging into a desktop pc with an expresscard->pcie adapter, and it works just as well as when the 4020 is plugged directly into a PCI slot on the same pc. The expresscard slot on the laptop has been tested by Lenovo support and by us (with a usb 3.0 -> expresscard adapter), and it is capable of well over the 80 MBps acquisition rate that we require. We’ve also tested a usb 2.0 PCI card in the Magma enclosure, and seemed to get reasonable rates through that as well. After weeks of fiddling around, it seems that perhaps there's something going wrong when the driver copies from the onboard buffer to the comedi driver buffer. The card can just barely work with 1 channel at 10 MSps (20 MBps, as each ’sample’ is 2 bytes). Any attempt to go to 1 channel at 20 MSps (or 2x10 MSps) fails, and the symptom I've found is that the comedi buffer takes longer to fill than it should, and there are gaps in the data that does come across (i.e. waveforms are broken). For example, a 20 MBps should take approximately 210 ms to acquire 4MB, and it properly averages to that, but a 40 MBps mode should then take 105 ms, and instead comedi_get_buffer_contents() takes over 160 ms to reach 4MB. To reiterate: these numbers all make perfect sense when this is done on a PC, the issue only occurs on these laptops. I was close to giving up, after getting baffled shrugs from the Comedi mailing list, Magma, and Lenovo (Measurement Computing hears ‘Linux’ and nopes out the door); however, while trying out limiting the RAM to 2 GB to test for 64-bit addressing issues, I also decided to play around with some random kernel command line parameters, and I found something that seems to make 40 MBps modes kinda work: the combination "acpi=off noapic". At a guess, the issue seems to be the ACPI (noapic by itself does nothing), but disabling ACPI alone yields an error (perhaps because the card is getting assigned interrupt 18?) Unfortunately this creates the issue that this 'fix' seems to slow the system down quite a bit: we can't even try to test top-speed 80 MBps modes because the code can't keep up and the comedi buffer overflows. From watching the comedi buffer status, it seems like the system is just barely keeping up with 40 MBps. Under previous suggestions from Magma, we've disabled all of the CPU/PCIe power saving stuff in the laptop’s BIOS, but I don't know if the Linux ACPI system can overrule that, or if it's something else. I've tried the obvious combinations I could find of acpi=ht,strict,noirq and pci=noacpi, but only the complete acpi=off parameter shows the improvement in dma->buffer timing. I’ll take any suggestions on things to try (or different MLs to ask), and will try to provide any additional info that could help. Thanks, Micah P. Dombrowski Dartmouth College Physics and Astronomy Dept.
Attachment:
cpuinfo.out
Description: Binary data
Attachment:
lshw.out
Description: Binary data
Attachment:
lspci-v.out
Description: Binary data
