altpll megawizard hangs under Linux

[Altera_Forum]

I've recently installed Quartus 10.0 on a system running Ubuntu Linux. Most functions are working fine, but I've noticed that the ALTPLL megawizard hangs if you attempt to move to the next page when entering data. 

 Has anyone else noticed this problem? I'm not sure if this is something specific to my Ubuntu setup or a general problem for anyone using Quartus under Linux.  I've tried running the megawizard both from the SOPC builder interface and also from the megawizard plugin manager with the same results.

[Altera_Forum]

--- Quote Start ---  I've recently installed Quartus 10.0 on a system running Ubuntu Linux.  --- Quote End ---   Sorry. Ubunty 10.04? 64bit or 32 bit?

[Altera_Forum]

32-bit. Tried it under 10.04 and also 9.04 with the same results on both systems.

[Altera_Forum]

no problems on Fedora 12 32-bit with QII 10.0 Web Edition Linux, it must be Ubuntu specific

[Altera_Forum]

Figured out the problem after a little experimenting. This megawizard doesn't like the desktop visual effects (compiz) that I was using. If I turn them off then it runs normally.

[Altera_Forum]

You are awesome! I would just have chalked it up to bad software on altera's part. I turned off the fancy graphics options like you siad a nd voila, megawizard works like a charm. I am running ubuntu 10.04/amd64 with quartus 10.0

[Altera_Forum]

agreed, nice sleuthing

[Altera_Forum]

--- Quote Start ---  You are awesome! I would just have chalked it up to bad software on altera's part. I turned off the fancy graphics options like you siad a nd voila, megawizard works like a charm. I am running ubuntu 10.04/amd64 with quartus 10.0  --- Quote End ---    I also ran into this exact symptom, but running Quartus II 14.1 under Xubuntu 14.04 which means that Compiz is not a suspect in my situation. Now here's where it gets interesting. I had edited the parameters of an existing ALTPLL megafunction before without any sort of hangs or other problems on the very same machine just a day or two earlier and had not changed anything meaningful about my software environment. This had me very puzzled, so I tried the usual suspects (clean project, google search, even attaching to the offending process with strace (it was in a tight wait loop writing {0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00} successfully to fd 3 (an event interface of some sort)) but nothing stuck out at me aside from this thread.  On a hunch figuring that this would be a library API or environment issue I remembered that the day I had successfully edited the PLL I had happened to start quartus from the command line by going to ~/altera/14.1/quartus and typing ./bin/quartus for no other reason that I happened to be at a shell poking around after having done the normal "mv linux64/libcurl.so.4 linux64/libcurl.so.4.backup" drill to make 14.1 work on Debian derived Linux flavors without dying of a SIGSEGV in libcurl.so.4 every five or so minutes.  I get the sense this isn't so much bad software as just the ever present difficulty of managing the complexity inherent to a large software package standing on the shoulders of many external libraries and system functions which we then want to run on many different base configurations. As a nearly lifelong computer programmer (and a latecomer to electronics / digital logic) I appreciate how difficult this problem is, and how quickly the complexity grows as you add in variables.  The takeaway is that if you are not fairly comfortable troubleshooting application behavior in a Linux/UNIX environment it would definitely be a time saver (and worth some piece of mind) to stick to the distributions that are officially supported (or at least direct derivatives like CentOS) so as to tread only on a more well worn path. If you are a dyed in the wool Linux nerd and feel strongly about your distro, be prepared to need to do a bit of troubleshooting / black box debugging.

[Altera_Forum]

It might be smart to keep a virtual box with CentOS or any other supported release just to verify if the problem is dependent upon the distribution or not.

[Altera_Forum]

--- Quote Start ---  It might be smart to keep a virtual box with CentOS or any other supported release just to verify if the problem is dependent upon the distribution or not.  --- Quote End ---    Not a bad idea at all. My box only has 4G of RAM total (and it is maxed out in terms of what the motherboard will support) so it'd be hard to spin up a VM capable of running Quartus. That being said, a chroot with a Centos install in it might do the trick so long as the breakage wasn't tied to kernel or kernel module related factors.  The fact that it worked if launched from the command line in one particular working directory, but failed if launched from the desktop icon at first made me think I was losing my marbles until I figured out that it was repeatably tied to that factor.

[Altera_Forum]

Yes, a chroot environment or dual boot is probably a better option than a VM if you're low on physical memory. BTW, the suggested memory requirements for the more recent families are more than 4GB RAM. Cyclone V is listed from 6-8GB, Arria 10 is 28-48GB.

[Altera_Forum]

--- Quote Start ---  Yes, a chroot environment or dual boot is probably a better option than a VM if you're low on physical memory. BTW, the suggested memory requirements for the more recent families are more than 4GB RAM. Cyclone V is listed from 6-8GB, Arria 10 is 28-48GB.  --- Quote End ---    Yeah, for sure. I'm actually building a project with the Max 10 series of self-configuring parts that are meant to be CPLD replacements so I am squeaking by without replacing my box (the motherboard is maxed out at 4GB).