"Matthew Dillon" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
