Date: Fri, 4 Feb 2000 18:21:37 -0800 From: "Scott Hess" <scott@avantgo.com> To: "Matthew Dillon" <dillon@apollo.backplane.com> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: Re: aio_read crashing certain kernels. Message-ID: <185c01bf6f7f$bb381dd0$1e80000a@avantgo.com> References: <01b301bf6824$46e928a0$1e80000a@avantgo.com> <200001262330.PAA16635@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Matthew Dillon" <dillon@apollo.backplane.com> wrote: > If you can reproduce the bug easily, can you post the program that > causes it plus instructions on how to reproduce the bug? If one of us > can reproduce it we may be able to squeeze more info out of the crash. Sorry I took so long to follow-up on this. The issue is definitely, definitely, definitely related to SMP. On a 3.3-RELEASE kernel compiled without SMP support, my various aio_read() based programs work fine, I've probably pushed terabytes through them by now. On a kernel with SMP support, it locks the entire system up. It might not happen on the first call to aio_read(), or the second, but it always happens relatively quickly. I speculate that if the data is already cached, then sometimes it works by virtue of being able to service the request from the same CPU, so the rfork VM-sharing bug isn't an issue. I saw the same symptoms, working on a uniprocessor kernel, not on an SMP kernel, on kernels based on 3.4-RELEASE. Unfortunately, I haven't had time to build kernels verified to be from the same sources for 3.4-RELEASE. I'm leaning towards not bothering, because I'm not sure what it would prove at this point. I should have some time next week to wrap this up into a solid test which will always invoke the crash. Thanks, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?185c01bf6f7f$bb381dd0$1e80000a>