TTL triggers method 2

Hi all. I need to send TTL triggers from Ubuntu 14.04 LTS. Normally I use pp.m but our current solution uses Octave instead of Matlab and I can't get the mex file to compile. So I want to try the mysterious "method 2". But I cannot find the file LinuxParportServer.zip Could someone please send it or send a link to it?

Advice on compiling ppmex.c on Octave would also be helpful. Here's the list of errors I got.

mex -g -v ppmex.c
ppmex.c: In function ‘getBit’:
ppmex.c:75:13: error: ‘true’ undeclared (first use in this function)
return (true && (b & 1<<n)); /* need a bona fide bool */
^
ppmex.c:75:13: note: each undeclared identifier is reported only once for each function it appears in
ppmex.c: In function ‘printBits’:
ppmex.c:81:9: warning: incompatible implicit declaration of built-in function ‘printf’ [enabled by default]
printf("%c",getBit(b,i) ? '1' : '0');
^
ppmex.c: In function ‘ppd’:
ppmex.c:95:9: warning: incompatible implicit declaration of built-in function ‘printf’ [enabled by default]
printf("PPD ioctl %d: %d (%s)\n",action,result,strerror(errno));
^
ppmex.c: At top level:
ppmex.c:100:1: error: unknown type name ‘uint64_t’
void read(const uint64_T reg, void * const b, const int parportfd, const int reader, const int o) {
^
ppmex.c: In function ‘read’:
ppmex.c:53:19: error: expected ‘(’ before ‘false’
#define USE_PPDEV false /* just sketched in atm */
^
ppmex.c:101:8: note: in expansion of macro ‘USE_PPDEV’
if USE_PPDEV {
^
ppmex.c:53:19: error: ‘false’ undeclared (first use in this function)
#define USE_PPDEV false /* just sketched in atm */
^
ppmex.c:101:8: note: in expansion of macro ‘USE_PPDEV’
if USE_PPDEV {
^
ppmex.c: At top level:
ppmex.c:115:9: error: unknown type name ‘uint8_t’
const uint8_T * const data,
^
ppmex.c: In function ‘doPort’:
ppmex.c:119:25: error: ‘false’ undeclared (first use in this function)
static bool setup = false;
^
In file included from ppmex.c:30:0:
/usr/include/octave-3.8.1/octave/mex.h:112:18: error: unknown type name ‘uint64_t’
#define uint64_T uint64_t
^
ppmex.c:121:5: note: in expansion of macro ‘uint64_T’
uint64_T reg;
^
ppmex.c:53:19: error: expected ‘(’ before ‘false’
#define USE_PPDEV false /* just sketched in atm */
^
ppmex.c:125:8: note: in expansion of macro ‘USE_PPDEV’
if USE_PPDEV {
^
In file included from ppmex.c:30:0:
ppmex.c: In function ‘mexFunction’:
/usr/include/octave-3.8.1/octave/mex.h:112:18: error: unknown type name ‘uint64_t’
#define uint64_T uint64_t
^
ppmex.c:265:5: note: in expansion of macro ‘uint64_T’
uint64_T *addresses;
^
/usr/include/octave-3.8.1/octave/mex.h:160:17: error: unknown type name ‘uint8_t’
#define uint8_T uint8_t
^
ppmex.c:266:5: note: in expansion of macro ‘uint8_T’
uint8_T *data;
^
/usr/include/octave-3.8.1/octave/mex.h:112:18: error: unknown type name ‘uint64_t’
#define uint64_T uint64_t
^
ppmex.c:269:5: note: in expansion of macro ‘uint64_T’
uint64_T address, port;
^
/usr/include/octave-3.8.1/octave/mex.h:160:17: error: unknown type name ‘uint8_t’
#define uint8_T uint8_t
^
ppmex.c:270:5: note: in expansion of macro ‘uint8_T’
uint8_T bitNum, regOffset, value = 0;
^
ppmex.c:305:23: error: ‘false’ undeclared (first use in this function)
writing = false;
^
ppmex.c:308:23: error: ‘true’ undeclared (first use in this function)
writing = true;
^
ppmex.c:51:15: error: expected ‘(’ before ‘true’
#define DEBUG true
^
ppmex.c:315:8: note: in expansion of macro ‘DEBUG’
if DEBUG printf("%d lhs\n",nlhs);
^
ppmex.c:51:15: error: expected ‘(’ before ‘true’
#define DEBUG true
^
ppmex.c:335:8: note: in expansion of macro ‘DEBUG’
if DEBUG printf("\n\ndata:\n");
^
ppmex.c:51:15: error: expected ‘(’ before ‘true’
#define DEBUG true
^
ppmex.c:344:12: note: in expansion of macro ‘DEBUG’
if DEBUG {
^
ppmex.c:51:15: error: expected ‘(’ before ‘true’
#define DEBUG true
^
ppmex.c:359:8: note: in expansion of macro ‘DEBUG’
if DEBUG {
^
g++: error: ppmex.o: No such file or directory
gcc -c -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/octave-3.8.1/octave/.. -I/usr/include/octave-3.8.1/octave -g -O2 -fstack-protector--param=ssp-buffer-size=4 -Wformat -Werror=format-security -pthread -fopenmp -g -I. ppmex.c -o ppmex.o
g++ -shared -Wl,-Bsymbolic -o ppmex.mex ppmex.o -L/usr/lib/x86_64-linux-gnu/octave/3.8.1 -L/usr/lib/x86_64-linux-gnu -loctinterp -loctave -Wl,-Bsymbolic-functions -Wl,-z,relro

with kind regards,

Jonathan

--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...
This one...

https://github.com/widmann/ppdev-mex

... can only send TTL triggers over parallel port, but is reported to work very well under Octave. Had a query and success feedback for this just about a month ago.

Hope it helps,
-mario
Mario was faster. Yes, ppdev-mex should compile under Octave (tested with Octave 4 on Ubuntu 16.04) and there is an Octave 64bit mex binary.

Best,
Andreas

> Am 01.10.2016 um 19:36 schrieb mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com>:
>
>
>
> This one...
>
> https://github.com/widmann/ppdev-mex
>
> ... can only send TTL triggers over parallel port, but is reported to work very well under Octave. Had a query and success feedback for this just about a month ago.
>
> Hope it helps,
> -mario
>
>
Hi all, just got around to testing this. It almost worked. I am using Octave 3.8.1 on Ubuntu 14.04 LTS.

1) I compiled the ppdev_mex.c by typing "mex ppdev_mex.c", producing ppdev_mex.mex
2) opened octave as superuser from the terminal
2) I ran the following simple script under various configurations described below:


addpath('/home/vpixx/Desktop/Experiments/ppdev-mex-master');

pportaddress = 1
disp('setaddress');
%ppdev_mex('Open');
ppdev_mex('Open', pportaddress);
disp('opened port');
more off
for i = 1:3

%pportaddress = i-1;
%ppdev_mex('Open', pportaddress);

bitarray = ppdev_mex('Write', pportaddress, 100);
bitarray
WaitSecs(0.001);
ppdev_mex('Write', pportaddress, 0);
disp('sent a stim ttl');

WaitSecs(.5);


end
ppdev_mex('Close', pportaddress);


Configuration 1: instead of the compiled mexfile, I used the included ppdevmex.mexa64. Under this the script runs, but bitarray is empty and no eventcodes show up in EEGlab.

Configuration 2: Use the mexfile I compiled myself. The script freezes at the ppdev_mex('Open', pportaddress);

If I run the script as a normal user, I can get it to tell me "permission denied" for opening the parallel port:
/dev/parport0 Permission denied
error: ppdev_mex: couldn't access port


If I give it the wrong address (2) I get

/dev/parport1 No such file or directory
error: ppdev_mex: couldn't access port


So it seems to be working basically right, but it is failing somewhere inside of opening the port.

I'll probably switch to matlab now and see if I can get it to work that way, but I just wanted to give you feedback for this particular Octave/Ubuntu combination. Any advice would of course be welcome but thanks for this updated code in any case. I'll see if it works in matlab.

with kind regards,

Jonathan




On Sat, Oct 1, 2016 at 3:56 PM, Andreas Widmann widmann@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Mario was faster. Yes, ppdev-mex should compile under Octave (tested with Octave 4 on Ubuntu 16.04) and there is an Octave 64bit mex binary.

Best,
Andreas

> Am 01.10.2016 um 19:36 schrieb mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> :
>
>
>
> This one...
>
> https://github.com/widmann/ppd ev-mex
>
> ... can only send TTL triggers over parallel port, but is reported to work very well under Octave. Had a query and success feedback for this just about a month ago.
>
> Hope it helps,
> -mario
>
>




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...
Hi,

several points/issues:

(1) mexa64 is a MATLAB binary. Please try/use the octave binary in the Octave3LinuxFiles64 subdir:
https://github.com/widmann/ppdev-mex/blob/master/Octave3LinuxFiles64/ppdev_mex.mex?raw=true

(2) Please confirm that you followed the instructions given in the ppdev_mex.m help text (Note section).
https://github.com/widmann/ppdev-mex/blob/master/ppdev_mex.m
In particular please reconfirm that the lp module is NOT loaded as it will block the port. You may post the output of the lsmod command (from terminal). You will also find instructions there how to get rid of the need of superuser privileges.

(3) Please check/post the specifications of your EEG system. Not all EEG systems work with 1ms triggers. Some need trigger durations >= sampling rate.

(4) In case all that really doesn’t help I would suggest to first manually confirm with a multimeter that port status (pin 2-9 against GND 18-25, IIRC) doesn’t change by:
ppdev_mex('Write', pportaddress, 255)
ppdev_mex('Write', pportaddress, 0)
respectively.

And I do not remember having ever checked the bitarray output after making the changes for Octave compatibility (as we never use it). I have to confirm in the lab on Monday that the expected value/output is indeed returned.

Hope this helps,
Andreas

> Am 07.10.2016 um 20:44 schrieb Jonathan Folstein jonathan.r.folstein@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com>:
>
>
>
> Hi all, just got around to testing this. It almost worked. I am using Octave 3.8.1 on Ubuntu 14.04 LTS.
>
> 1) I compiled the ppdev_mex.c by typing "mex ppdev_mex.c", producing ppdev_mex.mex
> 2) opened octave as superuser from the terminal
> 2) I ran the following simple script under various configurations described below:
>
>
> addpath('/home/vpixx/Desktop/Experiments/ppdev-mex-master');
>
> pportaddress = 1
> disp('setaddress');
> %ppdev_mex('Open');
> ppdev_mex('Open', pportaddress);
> disp('opened port');
> more off
> for i = 1:3
>
> %pportaddress = i-1;
> %ppdev_mex('Open', pportaddress);
>
> bitarray = ppdev_mex('Write', pportaddress, 100);
> bitarray
> WaitSecs(0.001);
> ppdev_mex('Write', pportaddress, 0);
> disp('sent a stim ttl');
>
> WaitSecs(.5);
>
>
> end
> ppdev_mex('Close', pportaddress);
>
>
> Configuration 1: instead of the compiled mexfile, I used the included ppdevmex.mexa64. Under this the script runs, but bitarray is empty and no eventcodes show up in EEGlab.
>
> Configuration 2: Use the mexfile I compiled myself. The script freezes at the ppdev_mex('Open', pportaddress);
>
> If I run the script as a normal user, I can get it to tell me "permission denied" for opening the parallel port:
> /dev/parport0 Permission denied
> error: ppdev_mex: couldn't access port
>
>
> If I give it the wrong address (2) I get
>
> /dev/parport1 No such file or directory
> error: ppdev_mex: couldn't access port
>
>
> So it seems to be working basically right, but it is failing somewhere inside of opening the port.
>
> I'll probably switch to matlab now and see if I can get it to work that way, but I just wanted to give you feedback for this particular Octave/Ubuntu combination. Any advice would of course be welcome but thanks for this updated code in any case. I'll see if it works in matlab.
>
> with kind regards,
>
> Jonathan
>
>
>
>
> On Sat, Oct 1, 2016 at 3:56 PM, Andreas Widmann widmann@...[PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
> Mario was faster. Yes, ppdev-mex should compile under Octave (tested with Octave 4 on Ubuntu 16.04) and there is an Octave 64bit mex binary.
>
> Best,
> Andreas
>
> > Am 01.10.2016 um 19:36 schrieb mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com>:
> >
> >
> >
> > This one...
> >
> > https://github.com/widmann/ppdev-mex
> >
> > ... can only send TTL triggers over parallel port, but is reported to work very well under Octave. Had a query and success feedback for this just about a month ago.
> >
> > Hope it helps,
> > -mario
> >
> >
>
>
>
>
>
> --
> Jonathan Folstein
> Assistant Professor
> Department of Psychology
> Florida State University
> 1107 W. Call St.
> Tallahassee, FL 32306-4301
> office: 850-645-0654
> fax: 850-644-7739
> folstein@...
>
>
>
If you use the latest PTB beta from us (not yet in NeuroDebian), and run PsychLinuxConfiguration again, also the "user setup" section, and reboot the machine once, it should automatically add you to the 'lp' group for root-less access to the parallel port and make sure the interfering 'lp' parallel port line-printer driver is no longer loaded.

Hopefully parallel port access with Andreas mex file should then work, but i couldn't test it with an actual parallel port - don't have one in my reach atm.

If this automatic setup does/doesn't work, please let me know.
-mario
Well, first thank you both so much for your quick and helpful replies. I started messing with things before Mario's reply. I had indeed neglected to add the user name to the group and comment out the lp line in the group file.

The relevant line in /etc/group now reads:

"lp:x:7:vpixx,root" (the root part was only added after a later PTB reinstallation)


lsmod produces:

vpixx@TestPC:~/Desktop/Experiments/AliensNM$ lsmod
Module Size Used by
snd_hda_codec_hdmi 46368 1
hp_wmi 14062 0
sparse_keymap 13948 1 hp_wmi
rfcomm 69160 0
bnep 19624 2
bluetooth 395387 10 bnep,rfcomm
snd_hda_codec_realtek 65904 1
x86_pkg_temp_thermal 14205 0
intel_powerclamp 14705 0
coretemp 13435 0
snd_hda_intel 56562 5
snd_hda_codec 193017 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
kvm 459872 0
snd_hwdep 13602 1 snd_hda_codec
snd_pcm 102040 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
nvidia 10744943 39
crct10dif_pclmul 14250 0
snd_page_alloc 18710 2 snd_pcm,snd_hda_intel
crc32_pclmul 13113 0
snd_seq_midi 13324 0
snd_seq_midi_event 14899 1 snd_seq_midi
snd_rawmidi 30682 1 snd_seq_midi
aesni_intel 55624 0
aes_x86_64 17131 1 aesni_intel
snd_seq 61567 2 snd_seq_midi_event,snd_seq_midi
joydev 17332 0
lrw 13286 1 aesni_intel
gf128mul 14951 1 lrw
glue_helper 13990 1 aesni_intel
ablk_helper 13597 1 aesni_intel
cryptd 20359 2 aesni_intel,ablk_helper
snd_seq_device 14497 3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer 29500 2 snd_pcm,snd_seq
serio_raw 13413 0
snd 69367 21 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
lpc_ich 21080 0
mei_me 18627 0
mei 82276 1 mei_me
soundcore 12680 1 snd
drm 303102 2 nvidia
parport_pc 32701 1
wmi 19177 1 hp_wmi
ppdev 17671 0
tpm_infineon 17372 0
shpchp 37032 0
mac_hid 13205 0
lp 17759 0
parport 42299 3 lp,ppdev,parport_pc
hid_generic 12548 0
usbhid 48514 0
hid 106148 2 hid_generic,usbhid
e1000e 254433 0
ahci 34091 1
psmouse 106643 0
ptp 18933 1 e1000e
libahci 32716 1 ahci
pps_core 19333 1 ptp



The modules file now looks like:


# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

#lp
rtc

Unfortunately, the script still froze at the pport open command when I used the native compiled mex file. Oddly, if I opened octave as su, this happened:

>> testppmex
PPD ioctl 28811: -1 (No such device or address)
pportaddress = 1
setaddress
error: ppdev_mex: couldn't claim pport
error: called from
testppmex at line 6 column 1

Trying it with the octave mex file Andreas suggested, it crashed wanting a library associated with Octave 4. I then updated to Octave 4 and reinstalled PTB with DownloadPsychtoolbox. The setup did in fact add vpixx and root to the group. PTB seems to work fine. Unfortunately, the provided octave mex file and a newly compiled one caused the same behavior. Freezing at the Open command with no su and the error above calling octave as su.

I know the parallel port card is working somehow because others have used it successfully from a Windows XP partition on the same computer.

Thanks again for your help. Any further thoughts would be great.


On Sat, Oct 8, 2016 at 10:21 AM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

If you use the latest PTB beta from us (not yet in NeuroDebian), and run PsychLinuxConfiguration again, also the "user setup" section, and reboot the machine once, it should automatically add you to the 'lp' group for root-less access to the parallel port and make sure the interfering 'lp' parallel port line-printer driver is no longer loaded.

Hopefully parallel port access with Andreas mex file should then work, but i couldn't test it with an actual parallel port - don't have one in my reach atm.

If this automatic setup does/doesn't work, please let me know.
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...
Did you reboot after running the PTB setup again?

If no, please do so.

If yes, execute this ...
sudo update-initramfs -u -k all
... then reboot.

Report which of those had an effect. "lsmod | grep lp" should not show a line with the "lp"module after such a reboot. "id" should show your vpixx user being a member of the "lp" group which allows non-root access to parallel ports.

Currently the 'lp' module for driving good ol' parallel port line printers is still loaded, which will claim exclusive access to the port. PTB's setup should prevent that _after_ a reboot. But maybe i need to add a call to update-initramfs to the setup routine. Don't know if that is needed or not. Depends if parallel port setup is already done during early boot (while still running from within the initial ram disc aka initramfs), or only later after initial bootup. Without an actual parallel port i can't test that myself.

-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Well, first thank you both so much for your quick and helpful replies.  I started messing with things before Mario's reply.  I had indeed neglected to add the user name to the group and comment out the lp line in the group file.

The relevant line in /etc/group now reads:

"lp:x:7:vpixx,root" (the root part was only added after a later PTB reinstallation)


lsmod produces:

vpixx@TestPC:~/Desktop/Experiments/AliensNM$ lsmod
Module                  Size  Used by
snd_hda_codec_hdmi     46368  1
hp_wmi                 14062  0
sparse_keymap          13948  1 hp_wmi
rfcomm                 69160  0
bnep                   19624  2
bluetooth             395387  10 bnep,rfcomm
snd_hda_codec_realtek    65904  1
x86_pkg_temp_thermal    14205  0
intel_powerclamp       14705  0
coretemp               13435  0
snd_hda_intel          56562  5
snd_hda_codec         193017  3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
kvm                   459872  0
snd_hwdep              13602  1 snd_hda_codec
snd_pcm               102040  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
nvidia              10744943  39
crct10dif_pclmul       14250  0
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
crc32_pclmul           13113  0
snd_seq_midi           13324  0
snd_seq_midi_event     14899  1 snd_seq_midi
snd_rawmidi            30682  1 snd_seq_midi
aesni_intel            55624  0
aes_x86_64             17131  1 aesni_intel
snd_seq                61567  2 snd_seq_midi_event,snd_seq_midi
joydev                 17332  0
lrw                    13286  1 aesni_intel
gf128mul               14951  1 lrw
glue_helper            13990  1 aesni_intel
ablk_helper            13597  1 aesni_intel
cryptd                 20359  2 aesni_intel,ablk_helper
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              29500  2 snd_pcm,snd_seq
serio_raw              13413  0
snd                    69367  21 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
lpc_ich                21080  0
mei_me                 18627  0
mei                    82276  1 mei_me
soundcore              12680  1 snd
drm                   303102  2 nvidia
parport_pc             32701  1
wmi                    19177  1 hp_wmi
ppdev                  17671  0
tpm_infineon           17372  0
shpchp                 37032  0
mac_hid                13205  0
lp                     17759  0
parport                42299  3 lp,ppdev,parport_pc
hid_generic            12548  0
usbhid                 48514  0
hid                   106148  2 hid_generic,usbhid
e1000e                254433  0
ahci                   34091  1
psmouse               106643  0
ptp                    18933  1 e1000e
libahci                32716  1 ahci
pps_core               19333  1 ptp



The modules file now looks like:


# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

#lp
rtc

Unfortunately, the script still froze at the pport open command when I used the native compiled mex file.  Oddly, if I opened octave as su, this happened:

>> testppmex
PPD ioctl 28811: -1 (No such device or address)
pportaddress =  1
setaddress
error: ppdev_mex: couldn't claim pport
error: called from
    testppmex at line 6 column 1

Trying it with the octave mex file Andreas suggested, it crashed wanting a library associated with Octave 4.  I then updated to Octave 4 and reinstalled PTB with DownloadPsychtoolbox.  The setup did in fact add vpixx and root to the group. PTB seems to work fine. Unfortunately, the provided octave mex file and a newly compiled one caused the same behavior. Freezing at the Open command with no su and the error above calling octave as su.

I know the parallel port card is working somehow because others have used it successfully from a Windows XP partition on the same computer.

Thanks again for your help. Any further thoughts would be great.


On Sat, Oct 8, 2016 at 10:21 AM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

If you use the latest PTB beta from us (not yet in NeuroDebian), and run PsychLinuxConfiguration again, also the "user setup" section, and reboot the machine once, it should automatically add you to the 'lp' group for root-less access to the parallel port and make sure the interfering 'lp' parallel port line-printer driver is no longer loaded.

Hopefully parallel port access with Andreas mex file should then work, but i couldn't test it with an actual parallel port - don't have one in my reach atm.

If this automatic setup does/doesn't work, please let me know.
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...
> PPD ioctl 28811: -1 (No such device or address)
This is actually good news as it shows that the mex file itself compiled properly and works as expected but the lp module is still loaded. In addition to Mario’s suggestions another potential candidate is cups.

In summary, please, check:
* /etc/modules: lp commented?
* /etc/modules-load.d/cups-filters.conf: lp commented?
* Does /etc/default/cups possibly exist? If yes, change "LOAD_LP_MODULE=yes" to "LOAD_LP_MODULE=no“ (actually should not exist as moved to cups-filters in 14.04 but who knows)
* /etc/modprobe.d/blacklist-psychtoolbox.conf: exists and lp NOT commented?
* sudo update-initramfs -u -k all
* reboot
* lsmod | grep lp
* lp module still loaded?

Further, open issues are (a) the need for super-user privileges and (b) octave version compatibility. I would like to postpone sorting out (a).

(b) I confirmed that the octave4 binary does not work under octave3 and vice versa. Mario, could you please give me a hint how to compile binaries running with both, octave 3 and 4 (as the PTB binaries do). Error message is missing liboctaveinterp.so.2 vs 3.

Best,
Andreas

PS: I confirmed that the output of ppdev_mex is consistent with documentation also with Octave (3 and 4).

> Am 09.10.2016 um 22:39 schrieb mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com>:
>
>
>
> Did you reboot after running the PTB setup again?
>
> If no, please do so.
>
> If yes, execute this ...
> sudo update-initramfs -u -k all
> ... then reboot.
>
> Report which of those had an effect. "lsmod | grep lp" should not show a line with the "lp"module after such a reboot. "id" should show your vpixx user being a member of the "lp" group which allows non-root access to parallel ports.
>
> Currently the 'lp' module for driving good ol' parallel port line printers is still loaded, which will claim exclusive access to the port. PTB's setup should prevent that _after_ a reboot. But maybe i need to add a call to update-initramfs to the setup routine. Don't know if that is needed or not. Depends if parallel port setup is already done during early boot (while still running from within the initial ram disc aka initramfs), or only later after initial bootup. Without a n actual parallel port i can't test that myself.
>
> -mario
>
> XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :
>
> Well, first thank you both so much for your quick and helpful replies. I started messing with things before Mario's reply. I had indeed neglected to add the user name to the group and comment out the lp line in the group file.
>
> The relevant line in /etc/group now reads:
>
> "lp:x:7:vpixx,root" (the root part was only added after a later PTB reinstallation)
>
>
> lsmod produces:
>
> vpixx@TestPC:~/Desktop/Experiments/AliensNM$ lsmod
> Module Size Used by
> snd_hda_codec_hdmi 46368 1
> hp_wmi & nbsp; 14062 0
> sparse_keymap 13948 1 hp_wmi
> rfcomm 69160 0
> bnep 19624 2
> bluetooth 395387 10 bnep,rfcomm
> snd_hda_codec_realtek 65904 1
> x86_pkg_temp_thermal 14205 0
> intel_powerclamp 14705 0
> coretemp 13435 0
> snd_hda_intel 56562 5
> snd_hda_codec 193017 3 snd_hda_codec_realtek,snd_hda_codec_hd mi,snd_hda_intel
> kvm 459872 0
> snd_hwdep 13602 1 snd_hda_codec
> snd_pcm 102040 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
> nvidia 10744943 39
> crct10dif_pclmul 14250 0
> snd_page_alloc 18710 2 snd_pcm,snd_hda_intel
> crc32_pclmul 13113 0
> snd_seq_midi 13324 0
> snd_seq_midi_event 14899 1 snd_seq_midi
> snd_rawmidi 30682 1 snd_seq_midi
> aesni_intel 55624 0
> aes_x86_64 17131 1 aesni_intel
> snd_seq 61567 2 snd_seq_midi_event,snd_seq_midi
> joydev 17332 0
> lrw 13286 1 aesni_intel
> gf128mul 14951 1 lrw
> glue_helper 13990 1 aesni_intel
> ablk_helper 13 597 1 aesni_intel
> cryptd 20359 2 aesni_intel,ablk_helper
> snd_seq_device 14497 3 snd_seq,snd_rawmidi,snd_seq_midi
> snd_timer 29500 2 snd_pcm,snd_seq
> serio_raw 13413 0
> snd 69367 21 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
> lpc_ich 21080 0
> mei_me ; 18627 0
> mei 82276 1 mei_me
> soundcore 12680 1 snd
> drm 303102 2 nvidia
> parport_pc 32701 1
> wmi 19177 1 hp_wmi
> ppdev 17671 0
> tpm_infineon 17372 0
> shpchp 37032 0
> mac_hid 13205 0
> lp 17759 0
> parport 42299 3 lp,ppdev,parport_pc
> hid_generic 12548 0
> usbhid 48514 0
> hid 106148 2 hid_generic,usbhid
> e1000e 254433 0
> ahci 34091& nbsp; 1
> psmouse 106643 0
> ptp 18933 1 e1000e
> libahci 32716 1 ahci
> pps_core 19333 1 ptp
>
>
>
> The modules file now looks like:
>
>
> # This file contains the names of kernel modules that should be loaded
> # at boot time, one per line. Lines beginning with "#" are ignored.
> # Parameters can be specified after the module name.
>
> #lp
> rtc
>
> Unfortunately, the script still froze at the pport open command when I used the native compiled mex file. Oddly, if I opened octave as su, this happened:
> >> testppmex
> PPD ioctl 28811: -1 (No such device or address)
> pportaddress = 1
> setaddress
> error: ppdev_mex: couldn't claim pport
> error: called from
> testppmex at line 6 column 1
>
> Trying it with the octave mex file Andreas suggested, it crashed wanting a library associated with Octave 4. I then updated to Octave 4 and reinstalled PTB with DownloadPsychtoolbox. The setup did in fact add vpixx and root to the group. PTB seems to work fine. Unfortunately, the provided octave mex file and a newly compiled one caused the same behavior. Freezing at the Open command with no su and the error above calling octave as su.
>
> I know the parallel port card is working somehow because others have used it successfully from a Windows XP partition on the same computer.
>
> Thanks again for your help. Any further thoughts would be great.
>
>
> On Sat, Oct 8, 2016 at 10:21 AM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
>
> If you use the latest PTB beta from us (not yet in NeuroDebian), and run PsychLinuxConfiguration again, also the "user setup" section, and reboot the machine once, it should automatically add you to the 'lp' group for root-less access to the parallel port and make sure the interfering 'lp' parallel port line-printer driver is no longer loaded.
>
> Hopefully parallel port access with Andreas mex file should then work, but i couldn't test it with an actual parallel port - don't have one in my reach atm.
>
> If this automatic setup does/doesn't work, please let me know.
> -mario
>
>
>
>
> --
> Jonathan Folstein
> Assistant Professor
> Department of Psychology
> Florida State University
> 1107 W. Call St.
> Tallahassee, FL 32306-4301
> office: 850-645-0654
> fax: 850-644-7739
> folstein@...
>
>
>

To foreshadow, this story has a happy ending. Read on.



Mere reboot: no effect

sudo update-initramfs -u -k all, then reboot: no effect


/etc/modules-load.d/cups-filters.conf DID exist and lp WAS uncommented. Changed it to:


# Parallel printer driver modules loading for cups

# LOAD_LP_MODULE was 'yes' in /etc/default/cups

#lp

ppdev

parport_pc


/etc/default/cups: does exist but everything was commented, so I didn't change it:


# Cups configure options


# LOAD_LP_MODULE: enable/disable to load "lp" parallel printer driver module

# LOAD_LP_MODULE has migrated to /etc/modules-load.d/cups-filters.conf

# LOAD_LP_MODULE=yes


/etc/modprobe.d/blacklist-psychtoolbox.conf looks like (I didn't change it):


# Blacklist the lp modules for parallel port line printers.

# It would prevent exclusive use of ppdev for low-level

# parallel port access by Psychtoolbox.

blacklist lp



To evaluate the need for update-initramfs, I did the following:


1: UNCOMMENTED lp in cups-filters.conf

2: UNCOMMENTED lp in /etc/modules

3: REMOVED vpixx,root from lp group in /etc/group

4: ran sudo update-initramfs -u -k all

5: RECOMMENTED lp in cups-filters.conf

6: RECOMMENTED lp in /etc/modules

7: ADDED vpixx,root to lp group in /etc/group

8: rebooted

9: lsmod | grep did not produce an lp line:

vpixx@TestPC:~$ lsmod | grep lp

glue_helper 13990 1 aesni_intel
ablk_helper 13597 1 aesni_intel
cryptd 20359 2 aesni_intel,ablk_helper
lpc_ich 21080 0


10: called testppmex from octave as normal user: STILL DID NOT WORK, freezes at ppdev_mex('Open', pportaddress);

11: restarted octave as superuser: STILL DID NOT WORK, freezes at ppdev_mex('Open', pportaddress);

12: ran sudo update-initramfs -u -k all

13: rebooted

14: called testppmex from octave as super user: STILL DID NOT WORK, freezes at ppdev_mex('Open', pportaddress);

15: commented out the rest of /etc/modules-load.d/cups-filters.conf:

# Parallel printer driver modules loading for cups

# LOAD_LP_MODULE was 'yes' in /etc/default/cups

#lp
#ppdev
#parport_pc

16: rebooted

17: called testppmex from octave as super user: STILL DID NOT WORK, freezes at ppdev_mex('Open', pportaddress);

18: ran sudo update-initramfs -u -k all

19: rebooted

20: called testppmex from octave as super user, omg the joy IT WORKS:


>> testppmex

pportaddress = 1

setaddress

opened port

bitarray =

0

0

1

0

0

1

1

0

sent a stim ttl

bitarray =

0

0

1

0

0

1

1

0

sent a stim ttl

bitarray =

0

0

1

0

0

1

1

0

sent a stim ttl



...note that output of bitarray is correct: I told it to 'Write' 100 in the script


21: called testppmex from octave as normal user (from the octave gui), STILL WORKS

22: connected amplifiers and started BrainVision Recorder (EEG recording app receiving event codes), called testtrigger.m

23: IT WORKS. The codes are detected by Recorder.


In conclusion:


comment out all lines in /etc/modules-load.d/cups-filters.conf

comment out lp in /etc/modules

add yourself to the lp group in /etc/group if PTB hasn't done it already

at this time the update-initramfs step appears necessary

when “bitarray = ppdev_mex('Write', pportaddress, 100)” is called, bitarray produces the correct output.

Superuser does not appear necessary when everything is working right.

Boom drop the mic (note to self, learn linux).


But seriously, thanks for the help.


Cheers,


Jonathan

Thanks for the info! Hopefully this won't be needed in the future anymore:

I've changed ptb for the next beta to execute update-initramfs as required. I've also updated the blacklist-psychtoolbox.conf file to blacklist the lp module harder, so hopefully it won't be neccessary to modify any of the files you described anymore. At least on my Ubuntu 14.04.5-LTS machine this reliably disabled lp after a run of PsychLinuxConfiguration + Reboot.

The file now looks like this, with the new redirection of lp to /bin/false:

# Blacklist the lp modules for parallel port line printers.
# It would prevent exclusive use of ppdev for low-level
# parallel port access by Psychtoolbox.
blacklist lp
install lp /bin/false

Btw., apart from the fact that PsychLinuxConfiguration does this for you automatically, if you had to do it manually, you wouldn't edid the /etc/groups file by hand. Look at PsychLinuxConfiguration.m for how this is done properly - and safely via the:

sudo usermod -a -G lp myusername

command to add user myusername to group 'lp'.

best,
-mario
Um, I'm actually really depressed right now because Ubuntu installed some updates and now ppdev_mex stopped working. It freezes during the Open command.

All of the settings above are completely unchanged and I added install lp /bin/false to the blacklist file as you suggested.

lsmod produces:

Module Size Used by
snd_hda_codec_hdmi 46368 1
rfcomm 69160 0
bnep 19624 2
bluetooth 395387 10 bnep,rfcomm
snd_hda_codec_realtek 65904 1
mei_me 18627 0
mei 82276 1 mei_me
snd_hda_intel 56562 5
ppdev 17671 6
snd_hda_codec 193017 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
hp_wmi 14062 0
nvidia 10561198 39
x86_pkg_temp_thermal 14205 0
intel_powerclamp 14705 0
sparse_keymap 13948 1 hp_wmi
snd_hwdep 13602 1 snd_hda_codec
coretemp 13435 0
snd_pcm 102040 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
kvm 459872 0
snd_page_alloc 18710 2 snd_pcm,snd_hda_intel
snd_seq_midi 13324 0
joydev 17332 0
snd_seq_midi_event 14899 1 snd_seq_midi
crct10dif_pclmul 14250 0
crc32_pclmul 13113 0
aesni_intel 55624 0
aes_x86_64 17131 1 aesni_intel
lrw 13286 1 aesni_intel
snd_rawmidi 30682 1 snd_seq_midi
gf128mul 14951 1 lrw
glue_helper 13990 1 aesni_intel
ablk_helper 13597 1 aesni_intel
cryptd 20359 2 aesni_intel,ablk_helper
drm 303102 2 nvidia
serio_raw 13413 0
snd_seq 61567 2 snd_seq_midi_event,snd_seq_midi
snd_seq_device 14497 3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer 29500 2 snd_pcm,snd_seq
parport_pc 32701 2
snd 69367 21 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
parport 42299 2 ppdev,parport_pc
shpchp 37032 0
soundcore 12680 1 snd
lpc_ich 21080 0
wmi 19177 1 hp_wmi
tpm_infineon 17372 0
mac_hid 13205 0
hid_generic 12548 0
usbhid 48514 0
hid 106148 2 hid_generic,usbhid
e1000e 254433 0
ahci 34091 1
psmouse 106643 0
ptp 18933 1 e1000e
libahci 32716 1 ahci
pps_core 19333 1 ptp


see anything suspicious?


On Tue, Oct 11, 2016 at 5:49 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Thanks for the info! Hopefully this won't be needed in the future anymore:

I've changed ptb for the next beta to execute update-initramfs as required. I've also updated the blacklist-psychtoolbox.conf file to blacklist the lp module harder, so hopefully it won't be neccessary to modify any of the files you described anymore. At least on my Ubuntu 14.04.5-LTS machine this reliably disabled lp after a run of PsychLinuxConfiguration + Reboot.

The file now looks like this, with the new redirection of lp to /bin/false:

# Blacklist the lp modules for parallel port line printers.
# It would prevent exclusive use of ppdev for low-level
# parallel port access by Psychtoolbox.
blacklist lp
install lp /bin/false

Btw., apart from the fact that PsychLinuxConfiguration does this for you automatically, if you had to do it manually, you wouldn't edid the /etc/groups file by hand. Look at PsychLinuxConfiguration.m for how this is done properly - and safely via the:

sudo usermod -a -G lp myusername

command to add user myusername to group 'lp'.

best,
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...
XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Um, I'm actually really depressed right now because Ubuntu installed some updates and now ppdev_mex stopped working. It freezes during the Open command.

-> Most surprising. Cheap alcohol helps a lot to cope with computer problems.

All of the settings above are completely unchanged and I added install lp /bin/false to the blacklist file as you suggested.

-> Ran PsychLinuxConfiguration + Reboot again? I wonder if your manual editing of the groups file could have caused some problems?

-> That said, i don't see anything suspicious in the output below. The 'lp' module doesn't seem to be loaded, so it can't block the parport, i can't see anything else blocking it either. I looked at the driver source code and afaics the reason for blocking (in the PPCLAIM ioctl()) is if some other higher level driver would claim access to the port, but afaik 'lp' is the only one doing this on a typical standard setup.

This is a regular builtin PC parallel port, right? Is there anything related to the parallel port in the output of the 'dmesg' command after the failure?

"strace octave --no-gui" might also help to see in which function call it actually blocks. I can't test anything here further without access to an actual computer with parallel port, but this used to work just fine when i still had such machines, so this is surprising.

-mario

lsmod produces:

Module                  Size  Used by
snd_hda_codec_hdmi     46368  1
rfcomm                 69160  0
bnep                   19624  2
bluetooth             395387  10 bnep,rfcomm
snd_hda_codec_realtek    65904  1
mei_me                 18627  0
mei                    82276  1 mei_me
snd_hda_intel          56562  5
ppdev                  17671  6
snd_hda_codec         193017  3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
hp_wmi                 14062  0
nvidia              10561198  39
x86_pkg_temp_thermal    14205  0
intel_powerclamp       14705  0
sparse_keymap          13948  1 hp_wmi
snd_hwdep              13602  1 snd_hda_codec
coretemp               13435  0
snd_pcm               102040  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
kvm                   459872  0
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
snd_seq_midi           13324  0
joydev                 17332  0
snd_seq_midi_event     14899  1 snd_seq_midi
crct10dif_pclmul       14250  0
crc32_pclmul           13113  0
aesni_intel            55624  0
aes_x86_64             17131  1 aesni_intel
lrw                    13286  1 aesni_intel
snd_rawmidi            30682  1 snd_seq_midi
gf128mul               14951  1 lrw
glue_helper            13990  1 aesni_intel
ablk_helper            13597  1 aesni_intel
cryptd                 20359  2 aesni_intel,ablk_helper
drm                   303102  2 nvidia
serio_raw              13413  0
snd_seq                61567  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              29500  2 snd_pcm,snd_seq
parport_pc             32701  2
snd                    69367  21 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
parport                42299  2 ppdev,parport_pc
shpchp                 37032  0
soundcore              12680  1 snd
lpc_ich                21080  0
wmi                    19177  1 hp_wmi
tpm_infineon           17372  0
mac_hid                13205  0
hid_generic            12548  0
usbhid                 48514  0
hid                   106148  2 hid_generic,usbhid
e1000e                254433  0
ahci                   34091  1
psmouse               106643  0
ptp                    18933  1 e1000e
libahci                32716  1 ahci
pps_core               19333  1 ptp


see anything suspicious?


On Tue, Oct 11, 2016 at 5:49 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Thanks for the info! Hopefully this won't be needed in the future anymore:

I've changed ptb for the next beta to execute update-initramfs as required. I've also updated the blacklist-psychtoolbox.conf file to blacklist the lp module harder, so hopefully it won't be neccessary to modify any of the files you described anymore. At least on my Ubuntu 14.04.5-LTS machine this reliably disabled lp after a run of PsychLinuxConfiguration + Reboot.

The file now looks like this, with the new redirection of lp to /bin/false:

# Blacklist the lp modules for parallel port line printers.
# It would prevent exclusive use of ppdev for low-level
# parallel port access by Psychtoolbox.
blacklist lp
install lp /bin/false

Btw., apart from the fact that PsychLinuxConfiguration does this for you automatically, if you had to do it manually, you wouldn't edid the /etc/groups file by hand. Look at PsychLinuxConfiguration.m for how this is done properly - and safely via the:

sudo usermod -a -G lp myusername

command to add user myusername to group 'lp'.

best,
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...
Hm, the output of "lsof /dev/parport0" could also give some hint if some other running application got a hold of the parport.

-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Um, I'm actually really depressed right now because Ubuntu installed some updates and now ppdev_mex stopped working. It freezes during the Open command.

-> Most surprising. Cheap alcohol helps a lot to cope with computer problems.

All of the settings above are completely unchanged and I added install lp /bin/false to the blacklist file as you suggested.

-> Ran PsychLinuxConfiguration + Reboot again? I wonder if your manual editing of the groups file could have caused some problems?

-> That said, i don't see anything suspicious in the output below. The 'lp' module doesn't seem to be loaded, so it can't block the parport, i can't see anything else blocking it either. I looked at the driver source code and afaics the reason for blocking (in the PPCLAIM ioctl()) is if some other higher level driver would claim access to the port, but afaik 'lp' is the only one doing this on a typical standard setup.

This is a regular builtin PC parallel port, right? Is there anything related to the parallel port in the output of the 'dmesg' command after the failure?

"strace octave --no-gui" might also help to see in which function call it actually blocks. I can't test anything here further without access to an actual computer with parallel port, but this used to work just fine when i still had such machines, so this is surprising.

-mario

lsmod produces:

Module                  Size  Used by
snd_hda_codec_hdmi     46368  1
rfcomm                 69160  0
bnep                   19624  2
bluetooth             395387  10 bnep,rfcomm
snd_hda_codec_realtek    65904  1
mei_me                 18627  0
mei                    82276  1 mei_me
snd_hda_intel          56562  5
ppdev                  17671  6
snd_hda_codec         193017  3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
hp_wmi                 14062  0
nvidia              10561198  39
x86_pkg_temp_thermal    14205  0
intel_powerclamp       14705  0
sparse_keymap          13948  1 hp_wmi
snd_hwdep              13602  1 snd_hda_codec
coretemp               13435  0
snd_pcm               102040  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
kvm                   459872  0
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
snd_seq_midi           13324  0
joydev                 17332  0
snd_seq_midi_event     14899  1 snd_seq_midi
crct10dif_pclmul       14250  0
crc32_pclmul           13113  0
aesni_intel            55624  0
aes_x86_64             17131  1 aesni_intel
lrw                    13286  1 aesni_intel
snd_rawmidi            30682  1 snd_seq_midi
gf128mul               14951  1 lrw
glue_helper            13990  1 aesni_intel
ablk_helper            13597  1 aesni_intel
cryptd                 20359  2 aesni_intel,ablk_helper
drm                   303102  2 nvidia
serio_raw              13413  0
snd_seq                61567  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              29500  2 snd_pcm,snd_seq
parport_pc             32701  2
snd                    69367  21 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
parport                42299  2 ppdev,parport_pc
shpchp                 37032  0
soundcore              12680  1 snd
lpc_ich                21080  0
wmi                    19177  1 hp_wmi
tpm_infineon           17372  0
mac_hid                13205  0
hid_generic            12548  0
usbhid                 48514  0
hid                   106148  2 hid_generic,usbhid
e1000e                254433  0
ahci                   34091  1
psmouse               106643  0
ptp                    18933  1 e1000e
libahci                32716  1 ahci
pps_core               19333  1 ptp


see anything suspicious?


On Tue, Oct 11, 2016 at 5:49 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Thanks for the info! Hopefully this won't be needed in the future anymore:

I've changed ptb for the next beta to execute update-initramfs as required. I've also updated the blacklist-psychtoolbox.conf file to blacklist the lp module harder, so hopefully it won't be neccessary to modify any of the files you described anymore. At least on my Ubuntu 14.04.5-LTS machine this reliably disabled lp after a run of PsychLinuxConfiguration + Reboot.

The file now looks like this, with the new redirection of lp to /bin/false:

# Blacklist the lp modules for parallel port line printers.
# It would prevent exclusive use of ppdev for low-level
# parallel port access by Psychtoolbox.
blacklist lp
install lp /bin/false

Btw., apart from the fact that PsychLinuxConfiguration does this for you automatically, if you had to do it manually, you wouldn't edid the /etc/groups file by hand. Look at PsychLinuxConfiguration.m for how this is done properly - and safely via the:

sudo usermod -a -G lp myusername

command to add user myusername to group 'lp'.

best,
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...


On Wed, Oct 12, 2016 at 8:48 AM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Hm, the output of "lsof /dev/parport0" could also give some hint if some other running application got a hold of the parport.

This gives a blank.

Here's some output from dmesg after the failure. To be clear, it freezes and I have to press ^C

[ 240.220918] INFO: task python:459 blocked for more than 120 seconds.
[ 240.220929] Tainted: P OX 3.13.0-96-lowlatency #143-Ubuntu
[ 240.220932] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 240.220936] python D ffff88022dd93300 0 459 1 0x00000000
[ 240.220945] ffff8800bda33e10 0000000000000086 ffff880221688000 0000000000013300
[ 240.220954] ffff8800bda33fd8 0000000000013300 ffff880221688000 ffffffffa028d040
[ 240.220960] ffffffffa028d044 ffff880221688000 00000000ffffffff ffffffffa028d048
[ 240.220968] Call Trace:
[ 240.220992] [<ffffffff81732761>] schedule_preempt_disabled+0x31/0x80
[ 240.221000] [<ffffffff81734395>] __mutex_lock_slowpath+0x165/0x200
[ 240.221009] [<ffffffff81734447>] mutex_lock+0x17/0x27
[ 240.221018] [<ffffffffa028acc3>] pp_ioctl+0x23/0x50 [ppdev]
[ 240.221027] [<ffffffff811d7a40>] do_vfs_ioctl+0x2e0/0x4c0
[ 240.221037] [<ffffffff811d46c2>] ? final_putname+0x22/0x50
[ 240.221044] [<ffffffff811d7ca1>] SyS_ioctl+0x81/0xa0
[ 240.221051] [<ffffffff8173da1d>] system_call_fastpath+0x1a/0x1f
[ 265.656105] octave-gui (2372): Using mlock ulimits for SHM_HUGETLB is deprecated
[ 360.117575] INFO: task python:459 blocked for more than 120 seconds.
[ 360.117586] Tainted: P OX 3.13.0-96-lowlatency #143-Ubuntu
[ 360.117589] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 360.117593] python D ffff88022dd93300 0 459 1 0x00000000
[ 360.117602] ffff8800bda33e10 0000000000000086 ffff880221688000 0000000000013300
[ 360.117611] ffff8800bda33fd8 0000000000013300 ffff880221688000 ffffffffa028d040
[ 360.117617] ffffffffa028d044 ffff880221688000 00000000ffffffff ffffffffa028d048
[ 360.117625] Call Trace:
[ 360.117650] [<ffffffff81732761>] schedule_preempt_disabled+0x31/0x80
[ 360.117659] [<ffffffff81734395>] __mutex_lock_slowpath+0x165/0x200
[ 360.117668] [<ffffffff81734447>] mutex_lock+0x17/0x27
[ 360.117676] [<ffffffffa028acc3>] pp_ioctl+0x23/0x50 [ppdev]
[ 360.117685] [<ffffffff811d7a40>] do_vfs_ioctl+0x2e0/0x4c0
[ 360.117696] [<ffffffff811d46c2>] ? final_putname+0x22/0x50
[ 360.117702] [<ffffffff811d7ca1>] SyS_ioctl+0x81/0xa0
[ 360.117709] [<ffffffff8173da1d>] system_call_fastpath+0x1a/0x1f



-mario


XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Um, I'm actually really depressed right now because Ubuntu installed some updates and now ppdev_mex stopped working. It freezes during the Open command.

-> Most surprising. Cheap alcohol helps a lot to cope with computer problems.

All of the settings above are completely unchanged and I added install lp /bin/false to the blacklist file as you suggested.

-> Ran PsychLinuxConfiguration + Reboot again? I wonder if your manual editing of the groups file could have caused some problems?

-> That said, i don't see anything suspicious in the output below. The 'lp' module doesn't seem to be loaded, so it can't block the parport, i can't see anything else blocking it either. I looked at the driver source code and afaics the reason for blocking (in the PPCLAIM ioctl()) is if some other higher level driver would claim access to the port, but afaik 'lp' is the only one doing this on a typical standard setup.

This is a regular builtin PC parallel port, right? Is there anything related to the parallel port in the output of the 'dmesg' command after the failure?

"strace octave --no-gui" might also help to see in which function call it actually blocks. I can't test anything here further without access to an actual computer with parallel port, but this used to work just fine when i still had such machines, so this is surprising.

-mario

lsmod produces:

Module Size Used by
snd_hda_codec_hdmi 46368 1
rfcomm 69160 0
bnep 19624 2
bluetooth 395387 10 bnep,rfcomm
snd_hda_codec_realtek 65904 1
mei_me 18627 0
mei 82276 1 mei_me
snd_hda_intel 56562 5
ppdev 17671 6
snd_hda_codec 193017 3 snd_hda_codec_realtek,snd_hda_ codec_hdmi,snd_hda_intel
hp_wmi 14062 0
nvidia 10561198 39
x86_pkg_temp_thermal 14205 0
intel_powerclamp 14705 0
sparse_keymap 13948 1 hp_wmi
snd_hwdep 13602 1 snd_hda_codec
coretemp 13435 0
snd_pcm 102040 3 snd_hda_codec_hdmi,snd_hda_ codec,snd_hda_intel
kvm 459872 0
snd_page_alloc 18710 2 snd_pcm,snd_hda_intel
snd_seq_midi 13324 0
joydev 17332 0
snd_seq_midi_event 14899 1 snd_seq_midi
crct10dif_pclmul 14250 0
crc32_pclmul 13113 0
aesni_intel 55624 0
aes_x86_64 17131 1 aesni_intel
lrw 13286 1 aesni_intel
snd_rawmidi 30682 1 snd_seq_midi
gf128mul 14951 1 lrw
glue_helper 13990 1 aesni_intel
ablk_helper 13597 1 aesni_intel
cryptd 20359 2 aesni_intel,ablk_helper
drm 303102 2 nvidia
serio_raw 13413 0
snd_seq 61567 2 snd_seq_midi_event,snd_seq_ midi
snd_seq_device 14497 3 snd_seq,snd_rawmidi,snd_seq_ midi
snd_timer 29500 2 snd_pcm,snd_seq
parport_pc 32701 2
snd 69367 21 snd_hda_codec_realtek,snd_ hwdep,snd_timer,snd_hda_codec_ hdmi,snd_pcm,snd_seq,snd_ rawmidi,snd_hda_codec,snd_hda_ intel,snd_seq_device,snd_seq_ midi
parport 42299 2 ppdev,parport_pc
shpchp 37032 0
soundcore 12680 1 snd
lpc_ich 21080 0
wmi 19177 1 hp_wmi
tpm_infineon 17372 0
mac_hid 13205 0
hid_generic 12548 0
usbhid 48514 0
hid 106148 2 hid_generic,usbhid
e1000e 254433 0
ahci 34091 1
psmouse 106643 0
ptp 18933 1 e1000e
libahci 32716 1 ahci
pps_core 19333 1 ptp


see anything suspicious?


On Tue, Oct 11, 2016 at 5:49 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Thanks for the info! Hopefully this won't be needed in the future anymore:

I've changed ptb for the next beta to execute update-initramfs as required. I've also updated the blacklist-psychtoolbox.conf file to blacklist the lp module harder, so hopefully it won't be neccessary to modify any of the files you described anymore. At least on my Ubuntu 14.04.5-LTS machine this reliably disabled lp after a run of PsychLinuxConfiguration + Reboot.

The file now looks like this, with the new redirection of lp to /bin/false:

# Blacklist the lp modules for parallel port line printers.
# It would prevent exclusive use of ppdev for low-level
# parallel port access by Psychtoolbox.
blacklist lp
install lp /bin/false

Btw., apart from the fact that PsychLinuxConfiguration does this for you automatically, if you had to do it manually, you wouldn't edid the /etc/groups file by hand. Look at PsychLinuxConfiguration.m for how this is done properly - and safely via the:

sudo usermod -a -G lp myusername

command to add user myusername to group 'lp'.

best,
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...
Doesn't make much sense to me, because in your debug output, the ppdev and parport_pc module were already loaded. ppdev is needed because that's what the mex file uses, and parport_pc is needed to drive the actual parallel port hardware. Maybe something else "fixed" it during the reboot, as a side effect of your change. But let's see how it goes.

All i know is from the driver source code that there was a potential bug related to this that could cause a deadlock if the timing - or the order in which driver modules got loaded - was just right (or just wrong) and that got fixed mid 2015. So that bug is present in your 3.13 kernel but not in more modern kernels post mid 2015.

The kernel i recommended is the kernel used in Ubuntu 14.04.5-LTS and in Ubuntu 16.04-LTS. Essentially the hw support of 14.04.5-LTS is identical to the one in 16.04-LTS.

-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Ok, I fixed it by again editing /etc/modules-load.d/cups-filters.conf

Prior to the updates, the script wouldn't work until the file looked like this:

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
#ppdev
#parport_pc



..or this (didn't matter):

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
ppdev
#parport_pc



Now it won't work until it looks like this:

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
ppdev
parport_pc


...and then of course calling initramfs and rebooting.

argh, there you have it.


On Wed, Oct 12, 2016 at 9:41 AM, Jonathan Folstein <jonathan.r.folstein@...> wrote:


On Wed, Oct 12, 2016 at 8:48 AM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Hm, the output of "lsof /dev/parport0" could also give some hint if some other running application got a hold of the parport.

This gives a blank.

Here's some output from dmesg after the failure.  To be clear, it freezes and I have to press ^C

[  240.220918] INFO: task python:459 blocked for more than 120 seconds.
[  240.220929]       Tainted: P           OX 3.13.0-96-lowlatency #143-Ubuntu
[  240.220932] "echo 0 > /proc/sys/kernel/hung_task_ timeout_secs" disables this message.
[  240.220936] python          D ffff88022dd93300     0   459      1 0x00000000
[  240.220945]  ffff8800bda33e10 0000000000000086 ffff880221688000 0000000000013300
[  240.220954]  ffff8800bda33fd8 0000000000013300 ffff880221688000 ffffffffa028d040
[  240.220960]  ffffffffa028d044 ffff880221688000 00000000ffffffff ffffffffa028d048
[  240.220968] Call Trace:
[  240.220992]  [<ffffffff81732761>] schedule_preempt_disabled+ 0x31/0x80
[  240.221000]  [<ffffffff81734395>] __mutex_lock_slowpath+0x165/ 0x200
[  240.221009]  [<ffffffff81734447>] mutex_lock+0x17/0x27
[  240.221018]  [<ffffffffa028acc3>] pp_ioctl+0x23/0x50 [ppdev]
[  240.221027]  [<ffffffff811d7a40>] do_vfs_ioctl+0x2e0/0x4c0
[  240.221037]  [<ffffffff811d46c2>] ? final_putname+0x22/0x50
[  240.221044]  [<ffffffff811d7ca1>] SyS_ioctl+0x81/0xa0
[  240.221051]  [<ffffffff8173da1d>] system_call_fastpath+0x1a/0x1f
[  265.656105] octave-gui (2372): Using mlock ulimits for SHM_HUGETLB is deprecated
[  360.117575] INFO: task python:459 blocked for more than 120 seconds.
[  360.117586]       Tainted: P           OX 3.13.0-96-lowlatency #143-Ubuntu
[  360.117589] "echo 0 > /proc/sys/kernel/hung_task_ timeout_secs" disables this message.
[  360.117593] python          D ffff88022dd93300     0   459      1 0x00000000
[  360.117602]  ffff8800bda33e10 0000000000000086 ffff880221688000 0000000000013300
[  360.117611]  ffff8800bda33fd8 0000000000013300 ffff880221688000 ffffffffa028d040
[  360.117617]  ffffffffa028d044 ffff880221688000 00000000ffffffff ffffffffa028d048
[  360.117625] Call Trace:
[  360.117650]  [<ffffffff81732761>] schedule_preempt_disabled+ 0x31/0x80
[  360.117659]  [<ffffffff81734395>] __mutex_lock_slowpath+0x165/ 0x200
[  360.117668]  [<ffffffff81734447>] mutex_lock+0x17/0x27
[  360.117676]  [<ffffffffa028acc3>] pp_ioctl+0x23/0x50 [ppdev]
[  360.117685]  [<ffffffff811d7a40>] do_vfs_ioctl+0x2e0/0x4c0
[  360.117696]  [<ffffffff811d46c2>] ? final_putname+0x22/0x50
[  360.117702]  [<ffffffff811d7ca1>] SyS_ioctl+0x81/0xa0
[  360.117709]  [<ffffffff8173da1d>] system_call_fastpath+0x1a/0x1f


 


-mario


XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Um, I'm actually really depressed right now because Ubuntu installed some updates and now ppdev_mex stopped working. It freezes during the Open command.

-> Most surprising. Cheap alcohol helps a lot to cope with computer problems.

All of the settings above are completely unchanged and I added install lp /bin/false to the blacklist file as you suggested.

-> Ran PsychLinuxConfiguration + Reboot again? I wonder if your manual editing of the groups file could have caused some problems?

-> That said, i don't see anything suspicious in the output below. The 'lp' module doesn't seem to be loaded, so it can't block the parport, i can't see anything else blocking it either. I looked at the driver source code and afaics the reason for blocking (in the PPCLAIM ioctl()) is if some other higher level driver would claim access to the port, but afaik 'lp' is the only one doing this on a typical standard setup.

This is a regular builtin PC parallel port, right? Is there anything related to the parallel port in the output of the 'dmesg' command after the failure?

"strace octave --no-gui" might also help to see in which function call it actually blocks. I can't test anything here further without access to an actual computer with parallel port, but this used to work just fine when i still had such machines, so this is surprising.

-mario

lsmod produces:

Module                  Size  Used by
snd_hda_codec_hdmi     46368  1
rfcomm                 69160  0
bnep                   19624  2
bluetooth             395387  10 bnep,rfcomm
snd_hda_codec_realtek    65904  1
mei_me                 18627  0
mei                    82276  1 mei_me
snd_hda_intel          56562  5
ppdev                  17671  6
snd_hda_codec         193017  3 snd_hda_codec_realtek,snd_hda_ codec_hdmi,snd_hda_intel
hp_wmi                 14062  0
nvidia              10561198  39
x86_pkg_temp_thermal    14205  0
intel_powerclamp       14705  0
sparse_keymap          13948  1 hp_wmi
snd_hwdep              13602  1 snd_hda_codec
coretemp               13435  0
snd_pcm               102040  3 snd_hda_codec_hdmi,snd_hda_cod ec,snd_hda_intel
kvm                   459872  0
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
snd_seq_midi           13324  0
joydev                 17332  0
snd_seq_midi_event     14899  1 snd_seq_midi
crct10dif_pclmul       14250  0
crc32_pclmul           13113  0
aesni_intel            55624  0
aes_x86_64             17131  1 aesni_intel
lrw                    13286  1 aesni_intel
snd_rawmidi            30682  1 snd_seq_midi
gf128mul               14951  1 lrw
glue_helper            13990  1 aesni_intel
ablk_helper            13597  1 aesni_intel
cryptd                 20359  2 aesni_intel,ablk_helper
drm                   303102  2 nvidia
serio_raw              13413  0
snd_seq                61567  2 snd_seq_midi_event,snd_seq_mid i
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_mi di
snd_timer              29500  2 snd_pcm,snd_seq
parport_pc             32701  2
snd                    69367  21 snd_hda_codec_realtek,snd_hwde p,snd_timer,snd_hda_codec_hdmi ,snd_pcm,snd_seq,snd_rawmidi, snd_hda_codec,snd_hda_intel, snd_seq_device,snd_seq_midi
parport                42299  2 ppdev,parport_pc
shpchp                 37032  0
soundcore              12680  1 snd
lpc_ich                21080  0
wmi                    19177  1 hp_wmi
tpm_infineon           17372  0
mac_hid                13205  0
hid_generic            12548  0
usbhid                 48514  0
hid                   106148  2 hid_generic,usbhid
e1000e                254433  0
ahci                   34091  1
psmouse               106643  0
ptp                    18933  1 e1000e
libahci                32716  1 ahci
pps_core               19333  1 ptp


see anything suspicious?


On Tue, Oct 11, 2016 at 5:49 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Thanks for the info! Hopefully this won't be needed in the future anymore:

I've changed ptb for the next beta to execute update-initramfs as required. I've also updated the blacklist-psychtoolbox.conf file to blacklist the lp module harder, so hopefully it won't be neccessary to modify any of the files you described anymore. At least on my Ubuntu 14.04.5-LTS machine this reliably disabled lp after a run of PsychLinuxConfiguration + Reboot.

The file now looks like this, with the new redirection of lp to /bin/false:

# Blacklist the lp modules for parallel port line printers.
# It would prevent exclusive use of ppdev for low-level
# parallel port access by Psychtoolbox.
blacklist lp
install lp /bin/false

Btw., apart from the fact that PsychLinuxConfiguration does this for you automatically, if you had to do it manually, you wouldn't edid the /etc/groups file by hand. Look at PsychLinuxConfiguration.m for how this is done properly - and safely via the:

sudo usermod -a -G lp myusername

command to add user myusername to group 'lp'.

best,
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...



--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...
Ok, updated the kernel as you suggested and ppdev_mex stopped working again. Who knows if the update had anything to do with it or if something random changed in the background. Anyway, I updated to 16.04 and happily it seems to work. I'll keep you posted.

On Wed, Oct 12, 2016 at 3:16 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Doesn't make much sense to me, because in your debug output, the ppdev and parport_pc module were already loaded. ppdev is needed because that's what the mex file uses, and parport_pc is needed to drive the actual parallel port hardware. Maybe something else "fixed" it during the reboot, as a side effect of your change. But let's see how it goes.


All i know is from the driver source code that there was a potential bug related to this that could cause a deadlock if the timing - or the order in which driver modules got loaded - was just right (or just wrong) and that got fixed mid 2015. So that bug is present in your 3.13 kernel but not in more modern kernels post mid 2015.

The kernel i recommended is the kernel used in Ubuntu 14.04.5-LTS and in Ubuntu 16.04-LTS. Essentially the hw support of 14.04.5-LTS is identical to the one in 16.04-LTS.

-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Ok, I fixed it by again editing /etc/modules-load.d/cups- filters.conf

Prior to the updates, the script wouldn't work until the file looked like this:

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
#ppdev
#parport_pc



..or this (didn't matter):

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
ppdev
#parport_pc



Now it won't work until it looks like this:

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
ppdev
parport_pc


...and then of course calling initramfs and rebooting.

argh, there you have it.


On Wed, Oct 12, 2016 at 9:41 AM, Jonathan Folstein <jonathan.r.folstein@...> wrote:


On Wed, Oct 12, 2016 at 8:48 AM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Hm, the output of "lsof /dev/parport0" could also give some hint if some other running application got a hold of the parport.

This gives a blank.

Here's some output from dmesg after the failure. To be clear, it freezes and I have to press ^C

[ 240.220918] INFO: task python:459 blocked for more than 120 seconds.
[ 240.220929] Tainted: P OX 3.13.0-96-lowlatency #143-Ubuntu
[ 240.220932] "echo 0 > /proc/sys/kernel/hung_task_ timeout_secs" disables this message.
[ 240.220936] python D ffff88022dd93300 0 459 1 0x00000000
[ 240.220945] ffff8800bda33e10 0000000000000086 ffff880221688000 0000000000013300
[ 240.220954] ffff8800bda33fd8 0000000000013300 ffff880221688000 ffffffffa028d040
[ 240.220960] ffffffffa028d044 ffff880221688000 00000000ffffffff ffffffffa028d048
[ 240.220968] Call Trace:
[ 240.220992] [<ffffffff81732761>] schedule_preempt_disabled+ 0x31/0x80
[ 240.221000] [<ffffffff81734395>] __mutex_lock_slowpath+0x165/ 0x200
[ 240.221009] [<ffffffff81734447>] mutex_lock+0x17/0x27
[ 240.221018] [<ffffffffa028acc3>] pp_ioctl+0x23/0x50 [ppdev]
[ 240.221027] [<ffffffff811d7a40>] do_vfs_ioctl+0x2e0/0x4c0
[ 240.221037] [<ffffffff811d46c2>] ? final_putname+0x22/0x50
[ 240.221044] [<ffffffff811d7ca1>] SyS_ioctl+0x81/0xa0
[ 240.221051] [<ffffffff8173da1d>] system_call_fastpath+0x1a/0x1f
[ 265.656105] octave-gui (2372): Using mlock ulimits for SHM_HUGETLB is deprecated
[ 360.117575] INFO: task python:459 blocked for more than 120 seconds.
[ 360.117586] Tainted: P OX 3.13.0-96-lowlatency #143-Ubuntu
[ 360.117589] "echo 0 > /proc/sys/kernel/hung_task_ timeout_secs" disables this message.

[ 360.117593] python D ffff88022dd93300 0 459 1 0x00000000
[ 360.117602] ffff8800bda33e10 0000000000000086 ffff880221688000 0000000000013300
[ 360.117611] ffff8800bda33fd8 0000000000013300 ffff880221688000 ffffffffa028d040
[ 360.117617] ffffffffa028d044 ffff880221688000 00000000ffffffff ffffffffa028d048
[ 360.117625] Call Trace:
[ 360.117650] [<ffffffff81732761>] schedule_preempt_disabled+ 0x31/0x80
[ 360.117659] [<ffffffff81734395>] __mutex_lock_slowpath+0x165/ 0x200
[ 360.117668] [<ffffffff81734447>] mutex_lock+0x17/0x27
[ 360.117676] [<ffffffffa028acc3>] pp_ioctl+0x23/0x50 [ppdev]
[ 360.117685] [<ffffffff811d7a40>] do_vfs_ioctl+0x2e0/0x4c0
[ 360.117696] [<ffffffff811d46c2>] ? final_putname+0x22/0x50
[ 360.117702] [<ffffffff811d7ca1>] SyS_ioctl+0x81/0xa0
[ 360.117709] [<ffffffff8173da1d>] system_call_fastpath+0x1a/0x1f



-mario


XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Um, I'm actually really depressed right now because Ubuntu installed some updates and now ppdev_mex stopped working. It freezes during the Open command.

-> Most surprising. Cheap alcohol helps a lot to cope with computer problems.

All of the settings above are completely unchanged and I added install lp /bin/false to the blacklist file as you suggested.

-> Ran PsychLinuxConfiguration + Reboot again? I wonder if your manual editing of the groups file could have caused some problems?

-> That said, i don't see anything suspicious in the output below. The 'lp' module doesn't seem to be loaded, so it can't block the parport, i can't see anything else blocking it either. I looked at the driver source code and afaics the reason for blocking (in the PPCLAIM ioctl()) is if some other higher level driver would claim access to the port, but afaik 'lp' is the only one doing this on a typical standard setup.

This is a regular builtin PC parallel port, right? Is there anything related to the parallel port in the output of the 'dmesg' command after the failure?

"strace octave --no-gui" might also help to see in which function call it actually blocks. I can't test anything here further without access to an actual computer with parallel port, but this used to work just fine when i still had such machines, so this is surprising.

-mario

lsmod produces:

Module Size Used by
snd_hda_codec_hdmi 46368 1
rfcomm 69160 0
bnep 19624 2
bluetooth 395387 10 bnep,rfcomm
snd_hda_codec_realtek 65904 1
mei_me 18627 0
mei 82276 1 mei_me
snd_hda_intel 56562 5
ppdev 17671 6
snd_hda_codec 193017 3 snd_hda_codec_realtek,snd_hda_ codec_hdmi,snd_hda_intel
hp_wmi 14062 0
nvidia 10561198 39
x86_pkg_temp_thermal 14205 0
intel_powerclamp 14705 0
sparse_keymap 13948 1 hp_wmi
snd_hwdep 13602 1 snd_hda_codec
coretemp 13435 0
snd_pcm 102040 3 snd_hda_codec_hdmi,snd_hda_cod ec,snd_hda_intel
kvm 459872 0
snd_page_alloc 18710 2 snd_pcm,snd_hda_intel
snd_seq_midi 13324 0
joydev 17332 0
snd_seq_midi_event 14899 1 snd_seq_midi
crct10dif_pclmul 14250 0
crc32_pclmul 13113 0
aesni_intel 55624 0
aes_x86_64 17131 1 aesni_intel
lrw 13286 1 aesni_intel
snd_rawmidi 30682 1 snd_seq_midi
gf128mul 14951 1 lrw
glue_helper 13990 1 aesni_intel
ablk_helper 13597 1 aesni_intel
cryptd 20359 2 aesni_intel,ablk_helper
drm 303102 2 nvidia
serio_raw 13413 0
snd_seq 61567 2 snd_seq_midi_event,snd_seq_mid i
snd_seq_device 14497 3 snd_seq,snd_rawmidi,snd_seq_mi di
snd_timer 29500 2 snd_pcm,snd_seq
parport_pc 32701 2
snd 69367 21 snd_hda_codec_realtek,snd_hwde p,snd_timer,snd_hda_codec_hdmi ,snd_pcm,snd_seq,snd_rawmidi, snd_hda_codec,snd_hda_intel, snd_seq_device,snd_seq_midi
parport 42299 2 ppdev,parport_pc
shpchp 37032 0
soundcore 12680 1 snd
lpc_ich 21080 0
wmi 19177 1 hp_wmi
tpm_infineon 17372 0
mac_hid 13205 0
hid_generic 12548 0
usbhid 48514 0
hid 106148 2 hid_generic,usbhid
e1000e 254433 0
ahci 34091 1
psmouse 106643 0
ptp 18933 1 e1000e
libahci 32716 1 ahci
pps_core 19333 1 ptp


see anything suspicious?


On Tue, Oct 11, 2016 at 5:49 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Thanks for the info! Hopefully this won't be needed in the future anymore:

I've changed ptb for the next beta to execute update-initramfs as required. I've also updated the blacklist-psychtoolbox.conf file to blacklist the lp module harder, so hopefully it won't be neccessary to modify any of the files you described anymore. At least on my Ubuntu 14.04.5-LTS machine this reliably disabled lp after a run of PsychLinuxConfiguration + Reboot.

The file now looks like this, with the new redirection of lp to /bin/false:

# Blacklist the lp modules for parallel port line printers.
# It would prevent exclusive use of ppdev for low-level
# parallel port access by Psychtoolbox.
blacklist lp
install lp /bin/false

Btw., apart from the fact that PsychLinuxConfiguration does this for you automatically, if you had to do it manually, you wouldn't edid the /etc/groups file by hand. Look at PsychLinuxConfiguration.m for how this is done properly - and safely via the:

sudo usermod -a -G lp myusername

command to add user myusername to group 'lp'.

best,
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...



--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...
Good. Andreas Widmann who wrote ppdev_mex is also on 16.04.1 and doesn't seem to have these kind of problems, so maybe it helps.

In general i spent a huge ton of time testing - and also improving some bits of the kernel and graphics stack of - 16.04 LTS before its release on the set of hardware we have here (though not parallel ports as i don't have any), and from that i can not think of any downsides to upgrading from 14.04 to 16.04, only various improvements.

Currently i'm testing PTB on both 14.04 and 16.04, but i intend to switch my laptop to 16.04 soon, and then i will only test and tweak for 16.04 LTS. Ubuntu 14.04.5 LTS has the same kernel and graphics stack as 16.04 though, so if one has to stick to 14.04, upgrading to 14.04.5 is the right thing to do.

-mario

In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Ok, updated the kernel as you suggested and ppdev_mex stopped working again.  Who knows if the update had anything to do with it or if something random changed in the background.  Anyway, I updated to 16.04 and happily it seems to work. I'll keep you posted.

On Wed, Oct 12, 2016 at 3:16 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Doesn't make much sense to me, because in your debug output, the ppdev and parport_pc module were already loaded. ppdev is needed because that's what the mex file uses, and parport_pc is needed to drive the actual parallel port hardware. Maybe something else "fixed" it during the reboot, as a side effect of your change. But let's see how it goes.


All i know is from the driver source code that there was a potential bug related to this that could cause a deadlock if the timing - or the order in which driver modules got loaded - was just right (or just wrong) and that got fixed mid 2015. So that bug is present in your 3.13 kernel but not in more modern kernels post mid 2015.

The kernel i recommended is the kernel used in Ubuntu 14.04.5-LTS and in Ubuntu 16.04-LTS. Essentially the hw support of 14.04.5-LTS is identical to the one in 16.04-LTS.

-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Ok, I fixed it by again editing /etc/modules-load.d/cups- filters.conf

Prior to the updates, the script wouldn't work until the file looked like this:

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
#ppdev
#parport_pc



..or this (didn't matter):

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
ppdev
#parport_pc



Now it won't work until it looks like this:

# Parallel printer driver modules loading for cups
# LOAD_LP_MODULE was 'yes' in /etc/default/cups
#lp
ppdev
parport_pc


...and then of course calling initramfs and rebooting.

argh, there you have it.


On Wed, Oct 12, 2016 at 9:41 AM, Jonathan Folstein <jonathan.r.folstein@...> wrote:


On Wed, Oct 12, 2016 at 8:48 AM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Hm, the output of "lsof /dev/parport0" could also give some hint if some other running application got a hold of the parport.

This gives a blank.

Here's some output from dmesg after the failure.  To be clear, it freezes and I have to press ^C

[  240.220918] INFO: task python:459 blocked for more than 120 seconds.
[  240.220929]       Tainted: P           OX 3.13.0-96-lowlatency #143-Ubuntu
[  240.220932] "echo 0 > /proc/sys/kernel/hung_task_ timeout_secs" disables this message.
[  240.220936] python          D ffff88022dd93300     0   459      1 0x00000000
[  240.220945]  ffff8800bda33e10 0000000000000086 ffff880221688000 0000000000013300
[  240.220954]  ffff8800bda33fd8 0000000000013300 ffff880221688000 ffffffffa028d040
[  240.220960]  ffffffffa028d044 ffff880221688000 00000000ffffffff ffffffffa028d048
[  240.220968] Call Trace:
[  240.220992]  [<ffffffff81732761>] schedule_preempt_disabled+ 0x31/0x80
[  240.221000]  [<ffffffff81734395>] __mutex_lock_slowpath+0x165/ 0x200
[  240.221009]  [<ffffffff81734447>] mutex_lock+0x17/0x27
[  240.221018]  [<ffffffffa028acc3>] pp_ioctl+0x23/0x50 [ppdev]
[  240.221027]  [<ffffffff811d7a40>] do_vfs_ioctl+0x2e0/0x4c0
[  240.221037]  [<ffffffff811d46c2>] ? final_putname+0x22/0x50
[  240.221044]  [<ffffffff811d7ca1>] SyS_ioctl+0x81/0xa0
[  240.221051]  [<ffffffff8173da1d>] system_call_fastpath+0x1a/0x1f
[  265.656105] octave-gui (2372): Using mlock ulimits for SHM_HUGETLB is deprecated
[  360.117575] INFO: task python:459 blocked for more than 120 seconds.
[  360.117586]       Tainted: P           OX 3.13.0-96-lowlatency #143-Ubuntu
[  360.117589] "echo 0 > /proc/sys/kernel/hung_task_ timeout_secs" disables this message.

[  360.117593] python          D ffff88022dd93300     0   459      1 0x00000000
[  360.117602]  ffff8800bda33e10 0000000000000086 ffff880221688000 0000000000013300
[  360.117611]  ffff8800bda33fd8 0000000000013300 ffff880221688000 ffffffffa028d040
[  360.117617]  ffffffffa028d044 ffff880221688000 00000000ffffffff ffffffffa028d048
[  360.117625] Call Trace:
[  360.117650]  [<ffffffff81732761>] schedule_preempt_disabled+ 0x31/0x80
[  360.117659]  [<ffffffff81734395>] __mutex_lock_slowpath+0x165/ 0x200
[  360.117668]  [<ffffffff81734447>] mutex_lock+0x17/0x27
[  360.117676]  [<ffffffffa028acc3>] pp_ioctl+0x23/0x50 [ppdev]
[  360.117685]  [<ffffffff811d7a40>] do_vfs_ioctl+0x2e0/0x4c0
[  360.117696]  [<ffffffff811d46c2>] ? final_putname+0x22/0x50
[  360.117702]  [<ffffffff811d7ca1>] SyS_ioctl+0x81/0xa0
[  360.117709]  [<ffffffff8173da1d>] system_call_fastpath+0x1a/0x1f


 


-mario


XX---In PSYCHTOOLBOX@yahoogroups.com, <jonathan.r.folstein@...> wrote :

Um, I'm actually really depressed right now because Ubuntu installed some updates and now ppdev_mex stopped working. It freezes during the Open command.

-> Most surprising. Cheap alcohol helps a lot to cope with computer problems.

All of the settings above are completely unchanged and I added install lp /bin/false to the blacklist file as you suggested.

-> Ran PsychLinuxConfiguration + Reboot again? I wonder if your manual editing of the groups file could have caused some problems?

-> That said, i don't see anything suspicious in the output below. The 'lp' module doesn't seem to be loaded, so it can't block the parport, i can't see anything else blocking it either. I looked at the driver source code and afaics the reason for blocking (in the PPCLAIM ioctl()) is if some other higher level driver would claim access to the port, but afaik 'lp' is the only one doing this on a typical standard setup.

This is a regular builtin PC parallel port, right? Is there anything related to the parallel port in the output of the 'dmesg' command after the failure?

"strace octave --no-gui" might also help to see in which function call it actually blocks. I can't test anything here further without access to an actual computer with parallel port, but this used to work just fine when i still had such machines, so this is surprising.

-mario

lsmod produces:

Module                  Size  Used by
snd_hda_codec_hdmi     46368  1
rfcomm                 69160  0
bnep                   19624  2
bluetooth             395387  10 bnep,rfcomm
snd_hda_codec_realtek    65904  1
mei_me                 18627  0
mei                    82276  1 mei_me
snd_hda_intel          56562  5
ppdev                  17671  6
snd_hda_codec         193017  3 snd_hda_codec_realtek,snd_hda_ codec_hdmi,snd_hda_intel
hp_wmi                 14062  0
nvidia              10561198  39
x86_pkg_temp_thermal    14205  0
intel_powerclamp       14705  0
sparse_keymap          13948  1 hp_wmi
snd_hwdep              13602  1 snd_hda_codec
coretemp               13435  0
snd_pcm               102040  3 snd_hda_codec_hdmi,snd_hda_cod ec,snd_hda_intel
kvm                   459872  0
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
snd_seq_midi           13324  0
joydev                 17332  0
snd_seq_midi_event     14899  1 snd_seq_midi
crct10dif_pclmul       14250  0
crc32_pclmul           13113  0
aesni_intel            55624  0
aes_x86_64             17131  1 aesni_intel
lrw                    13286  1 aesni_intel
snd_rawmidi            30682  1 snd_seq_midi
gf128mul               14951  1 lrw
glue_helper            13990  1 aesni_intel
ablk_helper            13597  1 aesni_intel
cryptd                 20359  2 aesni_intel,ablk_helper
drm                   303102  2 nvidia
serio_raw              13413  0
snd_seq                61567  2 snd_seq_midi_event,snd_seq_mid i
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_mi di
snd_timer              29500  2 snd_pcm,snd_seq
parport_pc             32701  2
snd                    69367  21 snd_hda_codec_realtek,snd_hwde p,snd_timer,snd_hda_codec_hdmi ,snd_pcm,snd_seq,snd_rawmidi, snd_hda_codec,snd_hda_intel, snd_seq_device,snd_seq_midi
parport                42299  2 ppdev,parport_pc
shpchp                 37032  0
soundcore              12680  1 snd
lpc_ich                21080  0
wmi                    19177  1 hp_wmi
tpm_infineon           17372  0
mac_hid                13205  0
hid_generic            12548  0
usbhid                 48514  0
hid                   106148  2 hid_generic,usbhid
e1000e                254433  0
ahci                   34091  1
psmouse               106643  0
ptp                    18933  1 e1000e
libahci                32716  1 ahci
pps_core               19333  1 ptp


see anything suspicious?


On Tue, Oct 11, 2016 at 5:49 PM, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Thanks for the info! Hopefully this won't be needed in the future anymore:

I've changed ptb for the next beta to execute update-initramfs as required. I've also updated the blacklist-psychtoolbox.conf file to blacklist the lp module harder, so hopefully it won't be neccessary to modify any of the files you described anymore. At least on my Ubuntu 14.04.5-LTS machine this reliably disabled lp after a run of PsychLinuxConfiguration + Reboot.

The file now looks like this, with the new redirection of lp to /bin/false:

# Blacklist the lp modules for parallel port line printers.
# It would prevent exclusive use of ppdev for low-level
# parallel port access by Psychtoolbox.
blacklist lp
install lp /bin/false

Btw., apart from the fact that PsychLinuxConfiguration does this for you automatically, if you had to do it manually, you wouldn't edid the /etc/groups file by hand. Look at PsychLinuxConfiguration.m for how this is done properly - and safely via the:

sudo usermod -a -G lp myusername

command to add user myusername to group 'lp'.

best,
-mario




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...



--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
folstein@...




--
Jonathan Folstein
Assistant Professor
Department of Psychology
Florida State University
1107 W. Call St.
Tallahassee, FL 32306-4301
office: 850-645-0654
fax: 850-644-7739
folstein@...