--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

kernel: integer divide fault trap, code=3D0
Stopped in pid 4445.1 (mkdir) at netbsd:__qdivrem+0x3b: divl %ecx,%eax
db> bt
__qdivrem(109e0000,0,0,0,0) at netbsd:__qdivrem+0x3b
__divdi3(ef620000,ffffffff,0,0,0) at netbsd:__divdi3+0x29
ffs_dirpref(cca46218,c1875c00,c0336926,cc7ef540) at netbsd:ffs_dirpref+0x170
ffs_valloc(...
VOP_VALLOC(...
ufs_mkdir(...
VOP_MKDIR(...
sys_mkdir(...
syscall_plain()
--- syscall (number 136) ---
0x480e3b8f:
db>=20

I'm not an expert programmer, so could someone tell me if the
arguments given to qdivrem would cause the code in sys/lib/libkern/qdivrem.c
to do naughty math. The area around line 91 looks suspicious.

Secondly is ffs_dirpref getting what I assume to be a zero from my
file system or elsewhere?

This box runs 2.0.2/i386. This happens with both a
Pentium 3 optimized GENERIC+IPSec kernel, and the official GENERIC.
The bt is from GENERIC. I've been able to reproduce this a few times
already. I've had this problem when running "mkdir daily" in a directory
on a file system for large files. I've haven't tried mkdir(8)ing in another
directory.

here is the problematic slice's entry in the disklabel
 e: 398297025        63     4.2BSD  65536 65536 61282  # (Cyl.      0*- 395=
135)

	Jonathan Kollasch

--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDiQiOOjx1ye3hmokRAs1dAJ4yq+GcOF1+H4kGamasQ+jAak+74wCgp1Mp
pv7GU6VMSo1Idihrfkn575M=
=ei0I
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--