error executing adb command on HPUX11i 64 bit

[Pilar Serna]

Hi,
When I try to execute the command on HPUX11i 64bit platform in order to print the names and values of external variables as follow:

# adb -k -w /stand/vmunix /dev/kmem > /tmp/file
$e
$q

The following error message appear:
" data address not found "

Could you please help me.
Many Thanks

[Dagmar Boelen]

you should use adb64 instead of adb.

[Massimo Bianchi]

Hi,
check this link for your error, looks like a typo !



http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xba5a28c64656d71190080090279cd0f9,00.html


Massimo

[Dagmar Boelen]

Hi,

Check this link.

http://www.tek-tips.com/gfaqs.cfm/pid/51/fid/1184

You provides lots of examples using adb64 (not adb!!!!) on 64-bit platform.

regards,

D.

[Pete Randall]

First off, from "man adb":

"adb calls adb64 to process 64 bit files."

so that's not a problem.

Secondly, I cut and pasted the command as shown and it works fine, so where is this typo?


Pete

[Massimo Bianchi]

Hi Pete,
the command worked also for me.

Searching for a smilir error in the forum lead to this consenquence: in that thread was a typo, maybe a second try will work also for him/her

Massimo

[Pilar Serna]

Thanks to everyone for your help.

I've tried to run the command several times using adb ( or adb64 ) on HPUX11i 64 bit platform in different servers and still give me the same message everytime I type " $e" but it's working fine on HPUX11.00 64bit platform.

Do you know if I need to setup or export any path/libraries in order to get all the external variables?

Cheers,
Pilar

[James Murtagh]

Hi Pilar,

Its good to see you on the forums!

What this is saying is a global variable is not in memory. What I did to check which one was the following, rather ugly loop:

# for i in $(nm /stand/vmunix|egrep "\..*data\||bss"|awk -F"|" '{print $8}'|egrep -v '\$|.data|.rodata|.sdata')
do
echo $i/D|adb -k /stand/vmunix /dev/kmem >>/tmp/adb.out 2>&1
done

Checking the output showed the variable topIcs gave the error. This was found in the following libraries:

libinit-pdk.a[locore.o]
libinit-pdk.a[boot_machdep.o]
libkgdb-pdk.a[kgdb_system_console.o]

No idea what it is, possibly related to the Interrupt Control Stack. In any case I did a quick check and it appears your adb command still outputs the rest of the symbols.

You can check this is the same on your server, just beware this loop is a CPU killer, although I'm pretty sure this is a test box you are on.

Regards,

James.

[Pilar Serna]

Hello James,
It is very nice to hear from you.
I try to test if we are suffering from wakeup issue on HP-UX 11i 64bit with KAIO up and running. There is a kernel variable called "_ncolls" which maintains a count of the number of times selwakeup() is called with the collision (global) flag set, this can be easily pulled from the kernel using the adb:

echo "_ncolls/D" | adb -k /stand/vmunix /dev/kmem

When I run this command on HPUX 11i the follow message appear:
"symbol not found"

I don't know if this kernel variable "_ncolls" is available for HPUX11i. For that reason I ran the "$e" variable in order to get all external variables and it's when the error "data address not found" appear. It's true I can get many external variables even with the output error but not the required one.
Could you please let me know if "_ncolls" variable is available for HPUX11i or have been replaced for another one and if you know any way to fix the output error when $e is executed under adb command?

Many thanks in advance,
Pila

[James Murtagh]

Hi Pila,

Oh I see, I did wonder why you were doing that! :-)

I can't find that symbol on my 11i boxes, so I guess its been replaced, unfortunately I don't have access to an 11.00 box at the moment. I'll need to do a bit more digging though. Can you run the following command for me on an 11.00 server from /usr/conf/lib :

# nm -A *|grep -i ncolls

I don't think the message you are seeing using the adb command is stopping it, so I think you are getting all the symbols. I ran a check and the adb and nm outputs seemed to match up even though I got the warning too.

Regards,

James.

[Pilar Serna]

James,

The output of running "nm -A *|grep ncolls" under /usr/conf/lib directory is:

[52] | 4 | 4|OBJT |GLOB |0| ANSI CO | libhp-ux.a[sys_gen.o]:_ncolls

I hope this can help you.
Cheers,
Pilar

[James Murtagh · Accepted solution]

Hi Pilar,

Sorry for the delay in getting back to you.

The code for select was completely re-written for 11i to try and stop the "thundering herd" syndrome I think you experienced on 11.00, where all threads waiting on a select are suddenly awakened even if they are not waiting on the resource freed. It also tries to minimise spinlock contention.

The _ncolls counter is not implemented in 11i, or can I see a similar one. I don't whether this is due to the above re-write being so successfull. The select collisions are now held in a per processor structure, per_processor_selects. However, I cannot at this time pull this imformation in a sensible format out of the kernel, even using q4. Its seems from this view it is implemented as a base address to an array which is difficult to read. I also cannot find a way to check this through a system call or tools like glance. I've checked some recent bsd/linux code and while something similar to _ncolls was implemented before I don't see it now.

If you want to check all the functions, symbols relating to select, you can few the object symbol table:

# cd /usr/conf/lib
# ar -x libfs.a select.o
# nm select.o

This is a patch on 11i for select and poll hangs, PHKL_25233, I would check this out. If you think the problem is in this area I would raise a call with HP to get an authorative answer to the missing kernel counter, otherwise maybe describe the performance problems you are facing - it may be another issue?

Cheers,

James.

[Pilar Serna]

James,
Many thanks for your answer, it's good enough for me.
I was suffered performance issues on UX11.00 with KAIO active on few servers.For that reason, I just wanted to check that it's no happen with HP-UX11i with KAIO in. At the moment everything is look ok and no action need to be taken.

Cheers,
Pilar