Hello.  I suspect raidframe is in the same boat as the other two users
because I've had issues with working on second raid sets in multiuser mode
similar to the ccd issues described in this thread.  I was able to deal
with them by not trying to manipulate two raid frame sets at the same time,
i.e. not trying to configure a second raid set while the first is
calculating its paritY, but I definitely think there's a similar problem
lurking in there.
-Brian
On Jun 26, 12:59pm, Quentin Garnier wrote:
} Subject: Re: ccd(4): kernel memory corruption?
} 
} --IiVenqGWf+H9Y6IX
} Content-Type: text/plain; charset=us-ascii
} Content-Disposition: inline
} Content-Transfer-Encoding: quoted-printable
} 
} On Tue, Jun 26, 2007 at 12:04:10PM +0200, Jukka Salmi wrote:
} [...]
} > Note the stange characters where I would have expected "/dev/wd1e".
} >=20
} > I added some debug printfs to ccdioctl() in sys/dev/ccd.c and noticed
} > that *(ccio->ccio_disks+1) is NULL even if ccio->ccio_ndisks is 2,
} > causing cpp[1] to contain garbage, but I'm not familiar with kernel
} > code to find the problem.
} 
} This is a nice bug.  What ccdioctl does wrong is passing cpp[i] to
} dk_lookup, because it's a userspace pointer and dk_lookup does ND_INIT()
} on it with UIO_SYSSPACE.  My tentative explanation is that the kernel
} sometimes sleeps when resolving the first name, and when it comes back,
} the userspace is different and UIO_SYSSPACE will not have the effect of
} having the relevant pages replaced with the correct ones.  And as those
} pointers come from argv[], they're unlikely to ever fault.  I might be
} completely wrong about how the second component is corrupted, but the
} UIO_SYSSPACE part is a bug nonetheless.
} 
} There are 3 users of dk_lookup:  ccd, cgd and raidframe.  cgd is in the
} same situation as ccd, I'm unsure about raidframe.
} 
} If you don't use the latter, can you try simply changing UIO_SYSSPACE
} into UIO_USERSPACE in dev/dksubr.c:dk_lookup()?
} 
} --=20
} Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
} "You could have made it, spitting out benchmarks
} Owe it to yourself not to fail"
} Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
} 
} --IiVenqGWf+H9Y6IX
} Content-Type: application/pgp-signature
} Content-Disposition: inline
} 
} -----BEGIN PGP SIGNATURE-----
} Version: GnuPG v1.4.6 (NetBSD)
} 
} iQEVAwUBRoDxl9goQloHrPnoAQI3wAf7B/KIJH82T8S5gnuL7KxCmxQtmV+GRVYF
} ZZw7qmlzE7PrnQtTYanRHQ3PzVKXQXOuLbkwY6eVhDfKFfw+VXLAxU1P1CnCic4J
} WyZbsT9z9qLeOigtTZFjrEQ/kkkjzDcgvTvMfEtE7buUw+Y9u1JSNbApUGfZ+dom
} Cyj7KHbqmaGRNsPs+qyFk5V3gAQILmB6C4K8fA9aRz+P02590oPA2w7LekWikzOv
} Vdaorvp3/2/ImfWgfemukppb9/M0JJCDRsKCdOJrM9w0zlrQA0avhAsHh4XbnmQ7
} pPO/bFBQmB5V4ynfm662F31x87fVzOhDccYwu99P/AhKa9PmkOBDHw==
} =AZM8
} -----END PGP SIGNATURE-----
} 
} --IiVenqGWf+H9Y6IX--
>-- End of excerpt from Quentin Garnier