11.23/IPF: any patch for hung nfsds: stack trace included

[Tanuj Vohra]

I have an rx1620 running 11.23/IPF on bundle
B.11.23.0603.040a

It is experiencing daily nfsd hangs with this stack trace :

#0 0xe00000000065cdd0:0 in swtch_to_thread+0x2d0 ()
#1 0xe000000000659850:0 in _swtch+0x30 ()
#2 0xe00000000065fbe0:0 in real_sleep+0x5f0 ()
#3 0xe000000000665070:0 in sleep_one+0x30 ()
#4 0xe0000000006374b0:0 in ksleep_one+0x2d0 ()
#5 0xe00000000148c4c0:0 in hp_cv_wait+0xa0 ()
#6 0xe000000001488d50:0 in mir_close+0x290 ()
#7 0xe0000000014880e0:0 in rmm_close+0x60 ()
#8 0xe000000000877160:0 in close_wrapper+0x80 ()
#9 0xe000000000730b40:0 in csq_protect+0x2d0 ()
#10 0xe000000000552020:0 in osr_pop_subr+0x4d0 ()
#11 0xe00000000054f780:0 in osr_close_subr+0x740 ()
#12 0xe00000000053e9e0:0 in hpstreams_close_int+0x700 ()
#13 0xe000000000510680:0 in hpstreams_close+0x50 ()
#14 0xe00000000077a400:0 in call_open_close+0x580 ()
#15 0xe000000000779c40:0 in closed+0x160 ()
#16 0xe00000000077d860:0 in spec_close+0xe0 ()
#17 0xe00000000063a150:0 in vn_close+0x90 ()
#18 0xe00000000063a2a0:0 in vno_close+0x80 ()
#19 0xe0000000007105a0:0 in closef+0x150 ()
#20 0xe000000000710f10:0 in close+0xf0 ()
#21 0xe000000000670590:0 in syscall+0x920 ()

Does anyone know if there is a patch to this
problem ?

This is the lan card:
lan 0 0/1/2/0 iether CLAIMED INTERFACE HP PCI-X 1000Base-T Dual-port Built-in

These are the disks it serves:

ext_bus 4 0/2/1/0 lpfc CLAIMED INTERFACE PCI SerialBus (10dff900)
ext_bus 6 0/2/1/0.0.1.0 lpfd CLAIMED INTERFACE Pseudo HBA
target 7 0/2/1/0.0.1.0.0 tgt CLAIMED DEVICE
disk 3 0/2/1/0.0.1.0.0.0 sdisk CLAIMED DEVICE IBM 1722-600
/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0
disk 4 0/2/1/0.0.1.0.0.1 sdisk CLAIMED DEVICE IBM 1722-600
/dev/dsk/c6t0d1 /dev/rdsk/c6t0d1
ext_bus 7 0/2/1/0.0.1.7 lpfd CLAIMED INTERFACE Pseudo HBA

[Dave Olker]

Hi Tanuj,

There was a problem very close to this reported on 11.11. The bug listed as JAGad37405 (fixed in PHNE_24035) shows:
_______________________________________


LEVEL FUNC ARG0 ARG1 ARG2 ARG3
lev 0) _swtch+0x2b4 0x5c55c n/a n/a n/a
lev 1) _sleep_one+0x6a4 0x51cd4e0 0x1029a n/a n/a
lev 2) ksleep_one+0x2b4 0x502 0x90b10a80x215e540 0
lev 3) hp_cv_wait+0x5c 0x90b10a8 0x90b108c 0x2152c8 0x2152f4
lev 4) mir_close+0xe4 n/a n/a n/a n/a
lev 5) rmm_close+0x1c n/a n/a n/a n/a
lev 6) close_wrapper+0x38 0x7fff1120 0xfffffff0 n/a n/a
lev 7) csq_protect+0x108 0x85fae40 0x85faf04 0x55686c0x7fff1120
lev 8) osr_pop_subr+0x208 0x723a444 0x85faf04 0 n/a
lev 9) osr_close_subr+0x2cc 0x7fff0e84 n/a n/a n/a
lev 10) hpstreams_close_int+0x2a4 n/a 0x10003 n/a n/a
lev 11) hpstreams_close+0x24 0xa000002 0x10003 0x2000 n/a
lev 12) call_open_close+0x1ac 0x2 0x2000 0xa000002 0x10003
lev 13) closed+0xd4 n/a n/a 0x10003 n/a
lev 14) spec_close+0x54 0x339c104 0x10003 n/a n/a
lev 15) vn_close+0x40 0x339c104 n/a n/a n/a
lev 16) vno_close+0x20 0x163e338 n/a n/a n/a
lev 17) closef+0x64 n/a n/a n/a n/a
lev 18) close+0x84 0x7fff0258 n/a n/a n/a
lev 19) syscall+0x1bc n/a n/a n/a n/a
lev 20) $syscallrtn+0x0


Unfortuately this fix is already included in 11.23, so what you're hitting looks to be very closely related to the defect we've already fixed.

My suggestion would be to collect a TOC dump the next time the problem occurs, contact HP Support and get the support folks to look at the dump. They'll likely have to open a defect with the NFS lab and get someone to work on it.

Regards,

Dave