cvs commit: src/sys/kern vfs_subr.c

[Alfred Perlstein]

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 -