kern/142728: Panic: Fatal trap 12 in g_io_request

Henry Wong hwong at
Tue Jan 19 20:02:36 UTC 2010

I have been able to narrow down this problem and have developed and
partially tested a circumvention.  The circumvention appears to be

I found that there was a race condition that allowed a file system to
possibly be mounted read-only more than once.  With a certain sequence
of mounting, mounting, retrieving, umounting and retrieving something
different I was able to reproduce the problem.

This problem can be considered as resolved as a duplicate of the problem
Steve Hartland reported in April of 2008 in the freebsd-stable list:

7.0 panic in geom/ufs
7.0-RELEASE panic any ideas?

except that it is still occurring in 8.0-RELEASE.

The bottom line is that although FreeBSD 8.0 RELEASE allows a ufs 
to be mounted read-only multiple times, doing so will easily cause the 
to panic trap with either a trap 12 or a trap 9 in g_io_request.

The instruction that is causing the trap is where it is constructing the
parametes for the g_trace.  The particular parameter is pp->name.  It
appears that the pp pointer is referring to a page that is not in the
address space.  I have no idea whether the *cp from which the pp was
retrieved is valid or not since each time this crashed for me, it either
took no dump or hung after partially dumping.


Henry Wong
Lead Software Engineer

Lumeta - / Securing the Network in the Face of Change
_hwong at lumeta.com_
732.357.3534 (office)
732.564.0731 (fax)
220 Davidson Avenue
Somerset , NJ 08873-4146

More information about the freebsd-bugs mailing list