I have no idea what caused the trap.  It happens in stable code that
hasn't been changed in ages.  It could be due to a memory corruption bug
somewhere else in the kernel, either somewhere else in jfs or elsewhere.
Otherwise, it's something really subtle that I haven't seen before.

Ok, can vserver affect JFS's stability and in general what kernel[s] you can
recommend for use with JFS?

This fs contains  69955977 files and hardlinks. Can it change something?

It couldn't allocate enough memory.  It seems odd since you said that
you ran version 1.1.11 recently.  I don't know what would have changed
that would consume any more memory.  Maybe more inodes have been created
since the last attempt?

See above. Almost 70mln of files. And yes, since last 'fsck.jfs -f', more inodes and more files
were created during nightly backup.
 Is it possible to add some more swap space and
try again?

This machine have almost 5Gb of swap. Is this not enough for fixing 1.5Tb disk partition?

Have you tried mounting read-only after the reboot?  That's not the best
solution, but at least you may be able to recover the data.

This is actually a backup disk.