bdf command hanging

[-_]

Dear supports,

Here iam our hp-ux system unable to read file system so when i use bdf command no output & not responding.

When iam trying to view from sam-disks&filesystem-filesystem status is reading but no output under / filesystem.

here iam attaching out of some commands which is useful to trobleshoot.

let me know how to over come this issue.

Thanks & Regards,

satish reddy

[-_]

Its urgent to resolve this issue

[Naj]

Hello,

It would be issue with FS corrupted or FS full i guess but before that varify couples of things.

1. check mount point

#mount -l

2. could you please check any error in syslog.log

3. did you able to execute df command?

Thanks

BR

Naj

[-_]

Iam not able to execute commands df or bdf , I didn't find any error from syslog.log file.

i got output from mount -l

find the attachment for your requirements

[Naj]

Hello,

Based on syslog, your system has been  up too long and time time to upgrade firmware

Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ...
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks 
== 0xFE59CFE4,  flags == 0x0

I think that is one of causes this issue.

how about #mount -v ?

can you paste the output here

Thanks

BR

Naj

[V. Nyga]

Can you post:

ll /var/adm/syslog

date

V.

[-_]

Dear Naj,

out put for mount -v

# mount -v
/dev/vg00/lvol3 on / type vxfs log on Wed Aug 26 09:14:24 2009
/dev/vg00/lvol1 on /stand type hfs defaults on Wed Aug 26 09:14:26 2009
/dev/vg00/lvol8 on /var type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:34 2009
/dev/vg00/lvol7 on /usr type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:34 2009
/dev/vg00/lvol6 on /tmp type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:34 2009
/dev/vg00/lvol9 on /oracle type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:34 2009
/dev/vg03/lvol1 on /orabkp type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:34 2009
/dev/vg00/lvol5 on /opt type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:35 2009
/dev/vg01/lvol1 on /iwdmsdb_dr type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:35 2009
/dev/vg00/lvol10 on /infra_db type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:35 2009
/dev/vg00/lvol4 on /home type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:35 2009
/dev/vg02/lvol1 on /archive_log type vxfs delaylog,nodatainlog on Wed Aug 26 09:14:35 2009
#

[-_]

# ll /var/adm/syslog
total 4203232
-rw-r--r--   1 root       root         22927 Aug 26  2009 OLDsyslog.log
-r--r--r--   1 root       root       4523584 Jul  4 13:14 mail.log
-rw-r--r--   1 root       root       2147483647 Jan  8 16:32 syslog.log

# date
Mon Jul  4 20:15:52 IST 2011
#

[V. Nyga]

:-)

your logfile is much to big
Use for example SAM to 'trim' your logfiles!

Then check for the current messages in syslog.

[-_]

I didn't find any recent logs

# tail -20 /var/adm/syslog/syslog.log
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFDB,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFDA,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD9,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD8,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD7,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD6,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD5,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD4,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD3,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD2,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD1,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFD0,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFCF,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFCE,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFCD,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFCC,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFCB,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFCA,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFC9,  flags == 0x0
Jan  8 16:32:54 riwdmsdb vmunix: function == 0x92C520, arg == 0x42A31800, ticks
== 0xFE59CFC8,  flags == 0x0
Jan  8 16:32:54 riwdmsdb#

[V. Nyga]

Yeah - that logical:
Your syslog.log - file is 2147483647 Bytes, that's around 2 GB and that's the maximum file size without largefile-option in Filesystem.
So your system can't write more to the syslog.
You have to trim it or copy if needed and then zero it:
/dev/null > /var/adm/syslog/syslog.log
(or zero instead of null).
When syslog is zero again, then your system can give you syslog messages again!

V.

[V. Nyga]

You can see: your last sytem message is from January the 8th!
There can also be a file sytem completely full - maybe you check at once if you can delete something in /tmp.

[-_]

if i restart this server what would happen?

[-_]

how do i take backup of this syslog.log file before zeroing or null 

I hope it is file system is full so if it how can i resolve this problem?

[V. Nyga]

You hope it's full?
You have several logical volumes, so you can test /tmp (/dev/vg00/lvol6 on /tmp ) or /archive_log (/dev/vg02/lvol1 on /archive_log -> this would also be a different disk, that's even better)

>maybe you check at once if you can delete something in /tmp - this would be wrong by me - your problem would be in '/' (/dev/vg00/lvol3).

First try to copy your syslog.log (also it's already very, very old - you could zero it out at once). Then zero it out, then try bdf again and check your file system.

[V. Nyga]

>if i restart this server what would happen?

The system would write/rename the syslog to OLDsyslog.log.

[Stephan.]

As mentioned before ... get rid of the syslog

> /var/adm/syslog/syslog.log

Do not bother with copying or saving it - will you really ever try to open a 2 GB text file to search for some old messages?

If you reboot without deleting, it will copied to OLDsyslog.log which will need some time an will make the space situation more worse.

Your error message seems to be related to a bug in the U320 driver which shows up under some circumstances when the system has an uptime of more then 400 days (I guess you are running 11.23).

These Messages will end after updating the U320 driver or after a reboot (uptime < 400 days ..), the update itselfs requires a reboot anyway.

The Update can be found here: https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=scsiU320-00

hth,

Stephan

[Dennis Handly]

>how do I take backup of this syslog.log file before zeroing or null

You can use grep to remove those known errors:

grep -v "vmunix: function .* arg .* ticks .*  flags" /var/adm/syslog/syslog.log > syslog.filtered

Someone else also reported the same problem today:

http://h30499.www3.hp.com/t5/System-Administration/vmunix-function-arg-ticks-flag-in-syslog-log/m-p/4812357/message-uid/4812357#U4812357

[Laurent Menase]

you have a driver using a negative timeout hence the error message.

The best way to find out what is the problem is to log a call to HP support,

you can check what is the callback function with

echo 0x92c520?ia | adb -o /stand/vmunix

but this will give only indication on the potential root cause. - a streams_untimeout+0xf0 is only

showing that a a driver uses a streams_timeout() with a negative timeout.

The main known problem which gives that result is lmx:lmxpollport

https://sort.symantec.com/public/documents/sfha/5.1sp1/hp-ux/productguides/html/sfrac_notes/ch01s09s01.htm

1439223 The lmxpollport function times out with an incorrect timeout value on systems that have been running for more than 410 days. The issue was caused by the lbolt variable, which resets after 410 days.
 

[-_]

How can i resolve this resolve? cna u suggest me.

[V. Nyga]

1. Clean up your syslog.log
2. Check new messages in syslog.log
3. Either decide to reboot your server every 400 days or update your U320 driver
4. [edit] After update your server will [edit] reboot
5. Check new messages in syslog.log

[Hakki Aydin Ucar]

you have to get rid of syslog.log first by emptying content.

Besides, your syslog.log indicates January , it stopped! not collecting any log..

also did you try this ?  in case of an nfs issue ;

# bdf -l

[-_]

if i reboot the server is the problem  resolve automatically?

[V. Nyga]

... you're very critical ... :-)

About which problem are we talking now?
Whether 'bdf' will work then, I can't say.
But it is important that syslog is working.
As long as you have enough space at your file system you should reboot.
I think you've got enough informations from us .... you have to do something.

[Dennis Handly]

>How can I resolve this?

Update your HBA firmware and the reboot should solve it.

Or reboot until you have a better time to update the firmware.