Problem with cdsdoc & firefox

Discussion in 'Cadence' started by spectrallypure, Dec 11, 2007.

  1. Hello all! I really hope someone can help me to figure this one out.

    For some reason my cdsdoc-Firefox couple doesn't work correctly
    anymore. It worked fine until a couple of months ago; honestly I don't
    know what could have happened, I haven't touched the Cadence
    installation though I recall to have updated Firefox at least once
    time since then. Here is an example of the erroneous behavior:

    1. Open a terminal and launch 'cdsdoc' after setting the following
    environment (only relevant entries shown):
    LD_LIBRARY_PATH=/programs/cadence/IC_5.1.41/tools/lib:/usr/lib
    IC=/programs/cadence/IC_5.1.41
    IC_DIR=/programs/cadence/IC_5.1.41
    CDSDIR=/programs/cadence/IC_5.1.41
    CDS=/programs/cadence/IC_5.1.41
    PATH=/programs/cadence/MMSIM/tools/bin:/programs/cadence/IC_5.1.41/
    tools/plot/bin:/programs/cadence/IC_5.1.41/tools/dfII/bin:/programs/
    cadence/IC_5.1.41/tools/bin:/bin:/usr/bin:/etc:/usr/share:.:/home/
    cdsmgr

    2. Cdsdoc lauchs without erros. In the 'Active Library' field, select
    any product family, say "IC5.1.41"
    3. In the 'Docs by Product' tree, select any product, say "Analog
    Design Environment"
    4. In the opened product subtree, select any documentation, say "OCEAN
    Reference"
    5. In the opened documentation subtree, select any entry, say "Table
    of Contents" and click the 'Open' button

    6. Firefox starts and a browser tab is opened with the following
    address:
    file:///programs/cadence/IC_5.1.41/share/verity/forms/start.htm
    ....while the contents area displays the message "Starting ..."

    7. After about 4-5 seconds, another browser tab is opened with the
    following address (note that letsbegreat2 is my workstations' name):
    http://letsbegreat2:9000//programs/cadence/IC_5.1.41/doc/oceanref/oceanrefTOC.html
    The "OCEAN Reference, Product Version 5.1.41" Table of Contents
    appears in the contents area of the browser. The structure of the
    hypertext seems OK, but the navigation icons on top and bottom of the
    page fail to load.

    8. HERE COMES THE PROBLEM: Whenever one clicks to any link referring
    to a different page, the browser fails to load the contents, showing
    the infamous Firefox message:

    (start)
    Unable to connect
    Firefox can't establish a connection to the server at
    letsbegreat2:9000.
    * The site could be temporarily unavailable or too busy. Try
    again in a few
    moments.
    * If you are unable to load any pages, check your computer's
    network
    connection.
    * If your computer or network is protected by a firewall or
    proxy, make sure
    that Firefox is permitted to access the Web.
    (end)

    What's more perplexing: even just trying to refresh the page that
    loaded initially (the TOC in my example) triggers this same error!!!

    I discovered that by manually editing the address bar the contents can
    be forced to load. For instance, if the following link failed to load
    when it was clicked:
    http://letsbegreat2:9000//programs/cadence/IC_5.1.41/doc/oceanref/chap1.html#1019902

    and if I edit the address bar to the following:
    file://letsbegreat2//programs/cadence/IC_5.1.41/doc/oceanref/chap1.html

    then the page loads correctly (this however is not really a viable
    solution, since it is very frustrating having to edit manually the
    addresses every time!).

    Last but not least, I would like to add that if (in cdsdoc) instead of
    clicking the 'Open' button I click 'Search', then the browser
    irremediably fails to load the search page (http://letsbegreat2:9000/
    search.htm). This time, no matter how I try to manually tweak the
    address, I cannot make it to load at all. A real pity, since it's for
    sure one of the most useful features of cdsdoc!!! :S

    What could be going wrong here? I'm using Firefox v.2.0.0.9 on CentOS
    3.

    Thanks so much in advance for any ideas.

    Regards,

    Jorge Luis.
     
    spectrallypure, Dec 11, 2007
    #1
  2. spectrallypure

    Nicolas Guest

    this is a common problem, with mozilla as well, found in
    cdsdoc2.1 .... should be fixed in cdsdoc2.2 apparently ...

    Solution:

    $ps aux | grep cds

    I don't recall the exact name of the cds* process, but it may be
    cdsNameServer or another one .... anyways ... they usually linger
    around even if you shutdown all cadence apps. Kill the processes,
    close cdsdoc. Then in this order
    1) open browser (firefox)
    2) open cdsdoc
    links should work now ...

    Let me know if this doesn't work out for you and I'll get the exact
    name of the processes to kill

    Another alternative .... reboot!

    Nicolas
     
    Nicolas, Dec 11, 2007
    #2
  3. spectrallypure

    andrewb Guest

    I've seen this before. The web server has an annoying tendency to
    crash on Linux - which is almost certainly the problem here.

    Unfortunately I don't recall if there's a solution to it - it's one of
    those problems I always hit when out of the office and forget to do
    something about when I return. Since cdsdoc is being replaced by
    cdnshelp in all new releases, there aren't really any fixes to it now.

    You may be better off getting cdnshelp from a newer release stream
    (e.g. MMSIM62 or IC611) and pointing it to the documentation in your
    IC5141 installation.

    Regards,

    Andrew.
     
    andrewb, Dec 11, 2007
    #3
  4. Thanks so much for your help, guys. The solution proposed by Nicolas
    worked nicely and now I am able to use precious cdsdoc like a normal
    human being again! :9

    In the case that someone else experiences this problem, the
    process(es) needed to be killed is(are) the one(s) named
    "cdsNameServer". So in order to solve this issue, just open a terminal
    and:

    1. type "ps -e | grep cdsNameServer" and take note of the PID number
    for this(these) process(es)
    2. type "kill [PID_of_cdsNameServer_process]", for each of the
    cdsNameServer PID obtained in step 2.

    Thanks once again for your help!

    Regards,

    Jorge Luis.
     
    spectrallypure, Dec 12, 2007
    #4
  5. spectrallypure

    S. Badel Guest

    1. type "ps -e | grep cdsNameServer" and take note of the PID number
    I guess 'killall cdsNameServer' would accomplish the same thing :)


    Regards,

    Stéphgane
     
    S. Badel, Dec 12, 2007
    #5
  6. spectrallypure

    prime_number Guest

    Dosn't, especially as root ;) under SunOS:

    # man killall

    NAME
    killall - kill all active processes

    SYNOPSIS
    /usr/sbin/killall [signal]

    DESCRIPTION
    killall is used by shutdown(1M) to kill all active processes
    not directly related to the shutdown procedure.

    killall terminates all processes with open files so that the
    mounted file systems will be unbusied and can be unmounted.

    killall sends signal (see kill(1)) to the active processes.
    If no signal is specified, a default of 15 is used.

    The killall command can be run only by the super-user.
     
    prime_number, Dec 12, 2007
    #6
  7. spectrallypure

    andrewb Guest

    I'm surprised about this - because in my case it is related to the
    http server crashing. You need to be careful about killing
    cdsNameServer when you have DFII running because it will prevent some
    of the DFII tools from talking to each other (e.g. library manager and
    DFII, or Hierarchy Editor and DFII).

    I used cdnshelp from a recent MMSIM62 ISR, and ran "cdnshelp -library
    <IC5141_instDir>/doc" (you need write access to the IC5141 directory).

    I then ran it again as myself and opened the IC5141 documenation
    library and then ran the "refresh index" menu - this writes an updated
    index.

    Then I can use cdnshelp to access IC5141 documentation - this is much
    cleaner than cdsdoc and doesn't depend on a web browser or lots of
    server processes.

    Regards,

    Andrew.
     
    andrewb, Dec 12, 2007
    #7
  8. Thanks to everybody for your observations. That latter trick about
    using cdnshelp for accessing the documentation of tools others than
    the ones providing this utility sound nice. Unluckily I don't have any
    tool including cdnshelp yet. Maybe in the next Europractice Cadence
    release for 2008.

    Regards,

    Jorge.
     
    spectrallypure, Dec 13, 2007
    #8
  9. spectrallypure

    andrewb Guest

    I think in the Sept 2007 EuroPractice release (I don't know how they
    number them) it also has MMSIM62 (I think, if my memory serves me
    correctly from discussions we had with EuroPractice).

    So does this mean that Peru is in Europe now?

    Regards,

    Andrew.
     
    andrewb, Dec 13, 2007
    #9
  10. Well, at least the latest version released to us includes only MMSIM
    6.0.2.290
    No, no that I have noticed; but were if not for EP allowing us as
    members, we would still be trying to layout chips with pencil & paper -
    no kidding! :S

    Regards,

    Jorge Luis.
     
    spectrallypure, Dec 14, 2007
    #10
  11. spectrallypure

    S. Badel Guest

    I think in the Sept 2007 EuroPractice release (I don't know how they
    As far as I know, there is no release in the course of the year. At least, we always have upgrades
    when we receive new license files in january every year.

    Maybe uoon request one can get it... don't know...


    This said, I'm able to use cdnshelp from MMSIM61 release without a MMSIM61 license (does cdnshelp
    even check out a license?).

    And it's.. great! Fantastic improvement over cdsdoc IMHO. Thanks for pointing this out.

    Most foundries do not accept paperrolls anymore... Sad ! :)



    Cheers,

    Stéphane
     
    S. Badel, Dec 14, 2007
    #11
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.