Dear Sun Managers;
It appears I must apologize for my last query to this group. This question
was asked (and answered) recently, as a scan of the WAIS entries for
sun-spots/sun-managers should have (and later did) show me.
However, I will still summarize here, if for no other reason than to thank
the sun-mgrs who have helped me out. The problem was:
>A SparcStation 2 (SUN 4/75) which we use to serve
>a microcomputer laboratory (via (PC)NFS) has started to crash with:
>
>panic: ufs_putpage hole
>
>From digging through the savecore dump, we see that this is triggered
>by the update daemon, ...
[[ I neglected to include that the machine is running SunOS 4.1.1 ]]
>
> this partition is the whole disk (/dev/sd3c) of a
>Sun 1.3G disk (yes, we did apply the patch included with the disk).
The solution: UPGRADE to SunOS 4.1.2.
The reason for the problem:
When a page of data is being flushed to disk, there is no physical disk block
allocated for it. The system then panics.
(NOTE: There appear to be two causes for this. Many (most) people warned
that this is a common side effect of using "mkfile -n" to create swapfiles
for diskless clients.
The other cause appears to be more random, from a general flush-to-disk.)
I'd like to thank:
kla!brandari%sunra@Sun.COM (Paul Brandariz x6546)
matthew@cs.adelaide.edu.au (Matthew Donaldson)
who warned of the swapfile problem;
special thanks to:
cchtor!larry (Larry Chin) {larry@cch.com}
rcsmith@anagld.analytics.com (Ray Smith)
who sent me a copy of the earlier summary, (Larry also went out of his
way to answer another query of mine.)
and thanks and a feeling of empathy to:
claude@genethon.genethon.fr (Claude Scarpelli)
who was the person who posted the original problem, sent me a copy
of his summary, and the response that an upgrade to SunOS 4.1.2 has
solved the problem.
Enclosed is the answer which Claude received from Manavendra K. Thakur
(thakur@zerkalo.harvard.edu)
for those like myself who missed it the first time.
Thanks again to all who responded, and sorry for the duplication.
Ian.
Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan.
2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0
macphed@dvinci.USask.CA macphedran@sask.USask.CA
----- 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: thakur@zerkalo.harvard.edu
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:35 CDT