Problem with cdsdoc & firefox

[spectrallypure]

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.

 

[Nicolas]

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

On Dec 11, 7:30 am, spectrallypure <jorgela...@gmail.com> wrote:

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/oce...
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/cha...

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.

 

[andrewb]

On Tue, 11 Dec 2007 04:30:45 -0800 (PST), spectrallypure
<jorgelagos@gmail.com> wrote:

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.

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.

 

[spectrallypure]

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.

 

[S. Badel]

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.

I guess 'killall cdsNameServer' would accomplish the same thing


Regards,

Stéphgane

 

[prime_number]

S. Badel wrote:

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.

I guess 'killall cdsNameServer' would accomplish the same thing

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.

 

[andrewb]

On Tue, 11 Dec 2007 19:02:12 -0800 (PST), spectrallypure
<jorgelagos@gmail.com> wrote:

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.

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.

 

[spectrallypure]

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.

 

[andrewb]

On Wed, 12 Dec 2007 16:31:39 -0800 (PST), spectrallypure
<jorgelagos@gmail.com> wrote:

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.

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.

 

[spectrallypure]

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).
Well, at least the latest version released to us includes only MMSIM

6.0.2.290

So does this mean that Peru is in Europe now?
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.

 

[S. Badel]

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).
Well, at least the latest version released to us includes only MMSIM
6.0.2.290

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.

So does this mean that Peru is in Europe now?
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

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



Cheers,

Stéphane