актуального нет. там zoomer лежит рядом с драйверами это типо оно должно быть. но если в файле данных встречаются осмысленные слова то там однозначно все мусор...

Ну тогда что-то с буферами данных... Либо в библиотеке liblcomp либо в самом test.cpp. Я уже перепробовал все варианты, и обнулять tmp1 перед присвоением *p и сам *p обнулять перед передачей в либу и с размером буфера экспериментировал. Единственное, чего я не делал - это не лез в библиотеку. По идее, надо проверить всю цепочку передачи данных, начиная с драйвера, на предмет "узких мест". Но в драйвер мне лезть оооооочень не хотелось бы. Я там все равно ничего не пойму

а на другой машине попробовать?

Имеете в виду, поменять именно машину, а систему оставить ту же?(Astra Linux x64). Или попробовать сменить и операционку на другую х64 (например Ubuntu или Fedora)?

и то и другое...

ОК. Сейчас попробую поставить сначала на то же железо другую операционку, потом поменяю и машину.

Напишите, пожалуйста, на какой операционной системе Вы тестировали драйвера версии 1.4 (32 или 64 бит Slackware 13)?

на обеих. и 32 и 64.

Успех! Установил на ту же систему Debian 6.0.6 x64. Установил драйвер, записал сигнал через test и проверил потом файл test.dat через LGraph. Получил оригинальный сигнал (синус), правда с каким-то непонятным шумом в верхней части (выше оси X). Но тут я подозреваю некорректную работу приложения LGraph под wine в линуксе. Замечу, что вывод команды "lsmod | grep ldev" в Debian возвращает только 2 модуля: ldevice, ldevpcibm;
тогда, как в Astra Linux та же команда возвращала все 4 модуля (ldevice, ldevpci, ldevpcibm, ldevusb).
Кстати, в Debian несколько раз так же наблюдал в файле test.dat осмысленные слова, но потом каким-то чудом они исчезли и пока больше не появлялись...
Сейчас продолжу тестирование в Astra Linux и попытаюсь определить, в чем же собственно проблема...

памяти сколько в компе? у меня 1 гиг всего.

У меня 4 и процессор Core Quad

Напишите, пожалуйста полную версию ядра в Slackware, на которой проводили тестирование.

2.6.29.6 2.6.37.6 3.2.29

Спасибо, сравню со своими!

Poul, подскажите, пожалуйста, можно ли принудительно задать IRQ плате через SlotParam? Или каким-либо другим образом... Проводим тестирование на новой системе, а у нее в биосе нет настройки IRQ... (система совсем новая на i7 процессоре). Дело в том, что при загрузке плата вешается на IRQ-17, а тестовая программа показывает, что IRQ на плате 10. В итоге с платы не поступают данные...

не обращайте внимание на это. плате вообще не особо и нужно прерывание.

Ну тогда не совсем понятно, почему плата не работает. В dmesg дебагер выдает такие строки:
not my working adc ovf!

и shared word 0 0

ни ошибок, ни глюков, все работает, но при этом данные с платы не поступают... В чем может быть проблема? Повторюсь, что в биосе новой материнской платы вообще нет настроек IRQ...

Да и операционка та же "Astra Linux x86_64"

но на какой-то системе она заработала?

Да, драйвер прекрасно себя чувствовал на Windows XP и Debian 6 x64. На новой системе сейчас буду ставить Debian, надеюсь заработает... Вообще с bus mastering какие-то непонятные проблемы. Недавно, например, после переустановки Debian на нашем стенде (там, где установлена Astra Linux), драйвер тоже перестал корректно работать, хотя до этого все было нормально. Где-то в драйвере идет неправильное обращение к области памяти, либо неправильно мапится буфер, но проявляется это при определенных условиях. Изначально я полагал, что это из-за возможных конфликтов IRQ в системе, но на новой системе конфликтов нет и быть не может (ACPI в биосе по умолчанию включено и выключить его нельзя). При этом, в Windows все работает, несмотря на конфликты. К сожалению, Windows нам не нужен, а учитывая сроки, нам просто необходимо завести Вашу плату в Astra Linux на нашем стенде. В связи с этим, не могли бы вы проверить всю цепочку обращения к bus master в драйверах и библиотеке. Если плата не зависит от IRQ, то это единственное место, где может скрываться ошибка...

нет такой доки.

Прогнал memtest+ никаких ошибок не нашел. Память чистая. Вероятнее всего дело в 64-х битной системе Astra Linux, точнее в работе драйвера платы в ней...

Отправил еще одну версию.

Poul! ЗАРАБОТАЛО! Как я понял, дело было в мапе буфера в цикле. Изменили GFP_KERNEL на GFP_DMA32 Всего одна строчка, а какой эффект Завтра устрою хард тест, но думаю, теперь все будет отлично! Спасибо Вам огромное! Надеюсь,  Вы выложите финальную версию этого драйвера?

Да выложу.