[Eda-dev] Problems with qrouter getting stuck

Øyvind Harboe oyvind.harboe at zylin.com
Mon Oct 16 10:31:38 EDT 2017


On Mon, Oct 16, 2017 at 4:23 PM, Tim Edwards <tim at opencircuitdesign.com>
wrote:

> Hello Øyvind,
>
>> I need to run qrouter on a remote build server, when I try to
>> run qrouter 1.3, I get this error message below. Hmm.... is that going to
>> stop me... In my build script, I "unset DISPLAY", otherwise qflow will
>> fail
>> at the graywolf stage.
>>
>> *$ qrouter -noc*
>> *application-specific initialization failed: no display name and no
>> $DISPLAY environment variable*
>>
>
> Use "qrouter -nog -noc" to avoid all use of graphics;  that makes
> qrouter text-only.  The "-nog" option is the default used by qflow.


Hmmm... still some sort of configuration problem.


 ~$ qrouter -nog
couldn't load file "/usr/local/share/qrouter/qrouter.so":
/usr/local/share/qrouter/qrouter.so: undefined symbol: Tk_DestroyWindow


>
> I just compiled magic, qrouter, graywolf and installed yosys 0.7 and qflow
>> now and I've kicked off a new build job. I'll see what that does. I expect
>> the build, if successful, to take at least 24 hours. I guess it will die
>> in
>> qrouter though with the 'DISPLAY' error message above.
>>
>
> Possibly not, given the qflow default vs. running qrouter from the command
> line.  Also, I can run jobs of, say, 20K gates in less than an hour; 50K
> gates, maybe a couple of hours.  Run times are much, much lower than they
> used to be.
>
> I have no idea why Ubuntu is so enthusiastic about dash that they want to
>> make it the default. It's been like this for years now and I know lots of
>> people being suckerpunched by this.
>>
>
> I understand that bash is slow and running a lot of shell scripts at boot
> time means that the difference between dash and bash has a large effect
> on how long it takes to boot, which I can understand.  The real problem
> is that for years everyone has started using bashisms in shell scripts
> everywhere, and likewise everyone has been assuming that /bin/sh points
> to bash.  If that assumption is broken, then I guess I have to start
> explicitly putting /bin/bash in the shebang line.  But generally speaking
> I try *not* to use bashisms.  In this case, I tried running a perl
> script I found on sourceforge called "checkbashisms", but it doesn't find
> anything wrong with line 20.  So I'm not even sure what part of the
> syntax is not dash-compatible.


I see, that's good pratice!


>
>
> I've been using JIRA for the last couple of years in more than one
>> organization. I quite like it, I find it modern. I find it near impossible
>> to search for anything, but I guess I'm just spoiled rotten by Google. I
>> haven't used other bug-tracking tools in the last couple of years. I find
>> the JIRA Kanban + a few quick filters to be an effective way to manage and
>> prioritize hundreds of open bugs at a glance.
>>
>
> Initially I stayed away from JIRA because traditionally I stay away from
> anything new until it starts becoming widely accepted.  I will have to
> look into getting it up and running on the opencircuitdesign.com server.
>
>                                         ---Tim
>
>
> +--------------------------------+-------------------------------------+
> | R. Timothy Edwards (Tim)       | email: tim at opencircuitdesign.com    |
> | Open Circuit Design            | web:   http://opencircuitdesign.com |
> | 19412 Cissel Manor Drive       | phone: (301) 528-5030               |
> | Poolesville, MD 20837          | cell:  (408) 828-8212               |
> +--------------------------------+-------------------------------------+
>



-- 
Øyvind Harboe, General Manager, Zylin AS, +47 917 86 146
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.opencircuitdesign.com/pipermail/eda-dev/attachments/20171016/25c9dbd5/attachment-0001.html>


More information about the Eda-dev mailing list