Hi all,

This is a bug that has baffled me for almost a year now, so today I decided to just attend to it exclusively. I have never understood why, exactly, the anecdotal and illogical fix for the sliver-of-the-brain issue seems to be to install an NVidia graphics card in the afflicted server.

I found this posting: https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2008-April/007558.htm...

Which seemed to indicate that it was not the card itself that made the difference, but rather some software component that made things work. There is an extension to X11, called GLX, which allows the remote side (the "client", in X11 speak) to bypass the processing of OpenGL commands and to send them to the server.

So, following the advice in the posting above, I downloaded the latest NVidia.run package and unpacked it by using the "-x" flag - then I copied all of the usr/lib/ and usr/lib32/ difrectories in the (freshly unpacked) NVIDIA-linux directory into /usr/lib and /usr/lib32, respectively. Then I ran "ldconfig -v" to update the ld cache.

And voila, I can run tksurfer over X11, VNC and NX now on a server that has no NVidia card, without any problems.

I still don't understand what exactly is being provided by NVidia's version of the libraries, but I suspect it has to do with "TLS" (in the context of OpenGL, not in the crypto sense). This appeared in the output of `ldd tksurfer.bin` on my systems with nvidia cards, and on my previously-broken system after I installed those files:

libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1

mjp

On Nov 18, 2008, at 9:35 PM, Bruce Fischl wrote:

Hi Sid,

this is a known problem. It actually used to work and we broke it. The current workaround is to use VNC.

cheers, Bruce

On Tue, 18 Nov 2008, Siddharth Srivastava wrote:

...

Hi ! I am a relatively new user of freesurfer, and currently i have 2 instances of the same -stable 64bit Linux versions installed, one on my local machine, and the other on a cluster, accessible over the network. I have been able to get freesurfer running without any problems on my local machine, but after i installed the same version on the remote machine, the tksurfer window did not display what i expectd to see, but only a small part of the data (%tksurfer bert lh inflated). This small patch responds to all commands from the GIU, but that is all that i see. I have trawled through the archives, both old and new, and there have been references to similar problems, without any definitive way to solve it. What exact aspect of the system configuration has to be examined/re-worked to solve it? Does anyone have any experience with this kind of problem? with regards, sid.

---

Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

hi Sid,

This should be done on the server side - where you are processing the data.

For example, I have a Dell PowerEdge 1950 that is running 64-bit Debian Gnu/Linux and has Freesurfer/fsfast installed. I log into it from my Mac, which is running os x. So I needed to add those libraries to the Dell machine to make things work.

My systems are 64 bit, so I think the instructions I gave should work for you, too.

mjp

On Nov 19, 2008, at 1:21 PM, Siddharth Srivastava wrote:

Hi mjp, Thanks for an account of a working solution to the problem. I just wanted to know if this intervention has to done on the client machine (from where i am viewing the results), or on the server side (on which i am processing the data)? Further, in case of a 64 bit machine, would the source and the destination directories change accordingly? best regards, sid.

Sid,

Firstly, make sure it didnt crash because of bad data. That is, if you can make the program that crashed crash again, check the input data. As for restarting, you can either use:

recon-all -s subjid -make all

which will make just the files that are missing or out-of-date relative to their dependencies. Or reference this chart:

https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllDevTable

and restart recon-all with just the flags used for the stages covering the parts that have not completed.

In your case:

recon-all -autorecon2-pial -autorecon3 -subjid subj

would be appropriate, as that starts with the finalsurfs stage.

Nick

On Fri, 2008-11-21 at 15:37 -0800, Siddharth Srivastava wrote:

Hi again, everyone, Apologies for another newbie question, but i was wondering what is the best thing to be done in case the program crashes in midflight, during the recon- all invocation. As of now, i have identified that the processing crashed sometime during mris_make_surfaces (stage 21?). Is there any way i can restart the process from this point? or, what is the most optimal strategy? regards, sid.

---

Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Sid,

Yes, you can run:

recon-all -s subjid -lgi

after your current recon-all run has completed. It will run just the local GI steps. you will need matlab installed to run the -lgi stage.

Nick

On Fri, 2008-11-21 at 16:47 -0800, Siddharth Srivastava wrote:

Hi Nick, Thanks. i restarted as you recommended. My initial command had a -lGI flag. Obviously, it will not be considered during this second run. I do not want to restart the process now, but i wanted to know if the GI can be calculated separately after all the stages of recon-all are done?

On a previous issue regarding the display (where only a part of the rendering was visible) we have managed (we think) to solve the problem, and get a proper display over the network, from a remote cluster. I will consolidate the steps that we followed and will send a mail around with this yet-another-solution.

thanks, sid.

On Fri, Nov 21, 2008 at 3:45 PM, Nick Schmansky nicks@nmr.mgh.harvard.edu wrote: Sid,

    Firstly, make sure it didnt crash because of bad data.  That
    is, if you
    can make the program that crashed crash again, check the input
    data.  As
    for restarting, you can either use:

    recon-all -s subjid -make all

    which will make just the files that are missing or out-of-date
    relative
    to their dependencies.  Or reference this chart:

    https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllDevTable

    and restart recon-all with just the flags used for the stages
    covering
    the parts that have not completed.

    In your case:

    recon-all -autorecon2-pial -autorecon3 -subjid subj

    would be appropriate, as that starts with the finalsurfs
    stage.

    Nick



    On Fri, 2008-11-21 at 15:37 -0800, Siddharth Srivastava wrote:
    > Hi again, everyone,
    >                               Apologies for another newbie
    question,
    > but i was wondering what is the best thing
    > to be done in case the program crashes in midflight, during
    the recon-
    > all invocation. As of now, i have
    > identified that the processing crashed sometime during
    > mris_make_surfaces (stage 21?). Is there any way
    > i can restart the process from this point? or, what is the
    most
    > optimal strategy?
    >                               regards,
    >                                sid.
    >

    > _______________________________________________
    > Freesurfer mailing list
    > Freesurfer@nmr.mgh.harvard.edu
    > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

---

Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer