cvs commit: src/sys/kern vfs_subr.c
alfred at freebsd.org
Tue Mar 27 19:04:13 UTC 2007
I'm not sure if it helps, but I recall that PPC memory barriers
were pretty much useless except the strongest ones.
* Marcel Moolenaar <xcllnt at mac.com> [070327 09:38] wrote:
> On Mar 27, 2007, at 12:43 AM, Kris Kennaway wrote:
> >On Tue, Mar 27, 2007 at 05:29:41AM +0000, Marcel Moolenaar wrote:
> >>marcel 2007-03-27 05:29:41 UTC
> >> FreeBSD src repository
> >> Modified files:
> >> sys/kern vfs_subr.c
> >> Log:
> >> PowerPC is the only architecture with mpsafe_vfs=0. This is now
> >> broken. Rudimentary tests show that PowerPC can run with
> >> mpsafe_vfs=1. Make it so...
> >If this is the vget panic via soft updates then a fix is pending for
> >that. Nevertheless mpsafevfs=1 is a good thing :)
> Maybe. I don't have the backtrace handy. It had to do with S/U, so it
> probably is then. I didn't see it on my amd64 box, so I assumed it was
> specific to PowerPC. Setting mpsave_vfs=1 solved it for me (or
> should I say avoided it for me? :-) I figured it's better to hunt down
> bugs in the mpsafe_vfs=1 case then it is in the mpsafe_vfs=0 case.
> This is not to say that mpsafe_vfs=0 can be broken, but rather that
> I prefer to work on improving the mpsafe_vfs=1 case...
> Hmmm, maybe I don't have S/U on amd64 box (I don't bother to partition
> my development boxes, so I typically only have a / mount that has S/U.
> Everything is basically over NFS...)
> Marcel Moolenaar
> xcllnt at mac.com
- Alfred Perlstein, RED Incorporated Consulting.
- coder / sysadmin / FreeBSD Hacker / All that jazz -
More information about the cvs-src