Skip site navigation (1)Skip section navigation (2)
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>