we had a problem where a machine would panic with
	page fault in kernel mode during normal usage of a
	filesystem.  fsck detected no problem but a closer
	look at a kernel crashdump showed that a cg->cg_irotor
	was hugely negative; this led to crashes in skpc like this:

#5  0xc02872bf in trap (frame={tf_fs = 24, tf_es = -1072037872, tf_ds = 16, 
      tf_edi = -724213760, tf_esi = -1002668032, tf_ebp = -413647876, 
      tf_isp = -413647896, tf_ebx = 115468226, tf_edx = -724210968, 
      tf_ecx = 255, tf_eax = -839679194, tf_trapno = 12, tf_err = 0, 
      tf_eip = -1071319959, tf_cs = 8, tf_eflags = 66195, tf_esp = -413647832, 
      tf_ss = -1071520840}) at /usr/src/sys/i386/i386/trap.c:467
#6  0xc024f469 in skpc (mask0=255, size=115468226, 
    cp0=0xcdf38326 <Address 0xcdf38326 out of bounds>)
    at /usr/src/sys/libkern/skpc.c:50
#7  0xc021e3b8 in ffs_nodealloccg (ip=0xc43d5600, cg=88, ipref=157696, 
    mode=33188) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1252
#8  0xc021d587 in ffs_hashalloc (ip=0xc43d5600, cg=88, pref=157696, 
    size=33188, allocator=0xc021e278 <ffs_nodealloccg>)
    at /usr/src/sys/ufs/ffs/ffs_alloc.c:768
#9  0xc021d27a in ffs_valloc (pvp=0xe75c7b00, mode=33188, cred=0xc1ddf900, 
    vpp=0xe7583ca0) at /usr/src/sys/ufs/ffs/ffs_alloc.c:596
#10 0xc02301f7 in ufs_makeinode (mode=33188, dvp=0xe75c7b00, vpp=0xe7583edc, 
    cnp=0xe7583ef0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2097
#11 0xc022dbac in ufs_create (ap=0xe7583dfc)
    at /usr/src/sys/ufs/ufs/ufs_vnops.c:194
#12 0xc02304b9 in ufs_vnoperate (ap=0xe7583dfc)
    at /usr/src/sys/ufs/ufs/ufs_vnops.c:2382
#13 0xc01b830c in vn_open (ndp=0xe7583ec8, fmode=1538, cmode=420)
    at vnode_if.h:106
#14 0xc01b44f8 in open (p=0xe33c5f60, uap=0xe7583f80)
    at /usr/src/sys/kern/vfs_syscalls.c:1010

because ffs_nodealloccg depends on start = cgp->cg_irotor / NBBY;
to be a valid index into the "inosused" array.

fsck has a check of cg->cg_irotor but only for "too large"
values, not for negative values.  I've also added a printf
to actually report the change made by fsck since this should
only happen when the filesystem has been damaged.

Fix: The following two patches are for current and for RELENG_4;
	they are very similar, and follow the current code-style
	in fsck.  Please apply.
How-To-Repeat: 	overwrite cylinder group data with random junk. "fix"
	with fsck -y. try to use filesystem normally.  observe
	the panic - if you're lucky.  If you're not lucky
	the kernel will probably read some random memory and
	write data to random places on the disk, or something...