bdf command hanging

[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.