Summary: SunOS 4.1.1 panic in ufs_putpage hole (with Sybase)

From: Claude Scarpelli (
Date: Thu Nov 07 1991 - 11:00:52 CST

I received only one reply to my query :

----- Begin Included Message -----

Dear Sun Managers,

My SparcStation 2 under 4.1.1 crash (with ufs_putpage hole) when I
create new database devices with sybase. Here is my configuration:

Sparc2 with 16 Mb, 200 Mb disk + MicroPolis 1.6 Gb (1528-15)
OS: 4.1.1 with the following patches:
        100343-02 Disk > 1Gb
        100159-01 Sybase hangs (tcplocal)
        100376-01 Integer division security patch
        100188-01 redirection of /dev/console
        100075-06 rpc.lockd patch

+ some other security patch, not involve with the kernel.

The panic arrives when I create new database devices with Sybase,
on the Micropolis disk. Here is the traceback.

[ traceback deleted ]

----- End Included Message -----

Thank to Manavendra K. Thakur (
for his very interesting posting (see at the end). But,
even with this powerfull informations, I was unable to
correct my problem in a good way...

I also asked my local sun software support : He said the
responsible of the problem is the MicroPolis 1.6 Gb. His
solution : wait for 4.1.2 !!! and don't use unsupported devices.

in fact, moving from 1.6Gb disk to 1.2 Gb solved the problem.
I've done another test: I split my 1.6Gb disk in two partitions
(0ne of about 500Mb, and the other the rest). Even when sybase
creates files in the first partition, the system panics : May be
it's a disk problem ; I've asked my local supplier, without
success for now.

Claude Scarpelli Internet :
Human Polymorphism Study Center or :

----- Begin Included Message -----

Hi there,

The purpose of the ufs_putpage() routine is to write dirty pages to
the disk. Much of the I/O clustering features added in SunOS 4.1.1 is
also handled by this routine.

The panic you report above indicates that ufs_putpage() found itself
trying to write a dirty page to disk when there was no physical disk
block already allocated for that page.

More specifically, this panic occurs when
1) the vnode being written to is NOT part of a virtual swap device
2) there is no block number allocated for the dirty page in question.

If you look at your /var/adm/messages file, you'll see a message right
before the panic that lists the contents of the following variables:

ip = inode pointer (see VTOI macro in /usr/include/ufs/inode.h)
lbn = logical block number (see lblkno macro in /usr/include/ufs/fs.h)
boff = block offset (see blkoff macro in /usr/include/ufs/fs.h)
off = offset into file being written - 2nd argument passed to ufs_putpage()
io_off = offset into vnode for this dirty page

Here are some more details:

ufs_putpage() calls bmap_read() to map the logical block numbers in a
file to physical block numbers on the device.

If bmap_read() finds that no physical blocks have been allocated to
this page, it returns UFS_HOLE (defined in /usr/include/ufs/inode.h).
Then ufs_putpage() checks whether the page in question is part of a
virtual swap device. If it isn't, then ufs_putpage calls panic().

Since you have the inode pointer and a complete core dump, you can use
the crash(8) utility to find out the specific major/minor device
numbers and the inode number of the file that ufs_putpage was working
on. (The ip variable is declared in ufs_putpage() as a pointer to an
inode structure. See /usr/include/ufs/inode.h for a definition of the
inode structure.)

This way, at least, you can verify whether it was a Sybase related
file that ufs_putpage() was working on when the panic occurred. If it
turns out that the inode in question was a Sybase related file, I
would recommend that you report this panic to Sybase and describe it
as a bug in their software.

Good luck, and if you get any more specific information, please be
sure to summarize.

Manavendra K. Thakur Internet:
Systems Programmer, High Energy Division BITNET: thakur@cfa.BITNET
Harvard-Smithsonian Center for DECNET: CFA::thakur
Astrophysics UUCP: ...!uunet!mit-eddie!thakur

----- End Included Message -----

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:17 CDT