On 2017-Mar-3, at 6:17 AM, Rodney W. Grimes <freebsd-rwg at pdx.rh.CN85.dnsmgr.net> wrote: >> On 2017-Mar-2, at 7:19 AM, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote: >> >> On Thu, Mar 02, 2017 at 01:10:21PM +0100, Mateusz Guzik wrote: >>> On Wed, Mar 01, 2017 at 09:45:07AM -0800, Mark Millard wrote: >>>> >>>>> Summary of the transition interval: >>>>> >>>>> So for powerpc64 (and powerpc?) It is a good >>>>> idea to avoid anything that is after -r313254 >>>>> and before -r314474 in head. (Would this be >>>>> appropriate for a UPDATING notice given its >>>>> span?) >>>>> >>>>> There may be other architectures that might have >>>>> a similar status(?): the last fixes involved were >>>>> not in Machine Dependent code. (Some architectures >>>>> are apparently insensitive to the errors, such as >>>>> amd64). >>>>> >>>> >>>> When following current you are expected to be on the newest revision, >>>> so I don't think mentioning interim broken releases makes much sense. >>>> >>> >>> Documenting the range may aid those bisecting src/ to find a bug. >>> How is one to know that anything in the range that Mark points >>> out should be skipped on powerpc64? >>> >>> -- >>> Steve >> >> I have tested with a TARGET_ARCH=powerpc -r314473 build and >> its kernel version has locking problems like >> TARGET_ARCH=powerpc64 does for that version. >> >> [Note: This was run on a PowerMac G5 so-called "Quad Core" >> so most of the memory was ignored.] >> >> Both TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc need -r314474 >> or later as of the new locking. >> >> I've not explicitly tested other architectures. As I remember >> armv6/v7 are classified as having some from of a weak memory >> model compared to the likes of amd64. If so armv6/v7 might be >> candidates for having problems. There might be other candidates. > > I also had locking issues on amd64 around this build time that > sent me down a week long rabbit hole chasing what I thought was > a bug in the new AMD/IOMMU code. IMHO if we can at least > flag prior snapshot builds as "Broken for reason X" it might > save someone some time and time is a one way depleting resource > usually worth saving if possible. > > If needed I can dig out the specifc build. Oh, nvm, let me > just do that, it was r309302. This revision I beleive is > a november snapshot. It has kernel panics due to spinlock > timeout and sparatic deadlock that is undetected. > > > -- > Rod Grimes rgrimes at freebsd.org Sounds like that amd64 -r309302 problem might be another good example. Locking tends to be central and heavily used. When it breaks many other things tend to also end up broken. This is the sort of context I was thinking about if it goes on very long. I'm not sure that the -r309302 problem would reproduce at -r313259 so -r309302 might be a separate issue. I've no clue what -rdddddd range had the amd64 -r309302 problem. Details that I'm aware of are something like: -r309302 is dated 2016-Nov-30. (your reported amd64 locking problem's -rdddddd) -r312973 is dated 2017-Jan-30. (example add of an atomic_fcmpset implementation) (getting ready for machine independent usage) -r313259 is dated 2017-Feb-5. (last before "machine independent use of atomic_fcmpset"?) (powerpc64 and powerpc working here) -r313260 is dated 2017-Feb-5. (first machine-independent usage of atomic_fcmpset?) . . . (various machine-independent atomic_fcmpset usage check-ins) . . . -r313271 is dated 2017-Feb-5. (observed powerpc64 failures for this version) (powerpc would fail too) . . . (various machine-independent atomic_fcmpset usage check-ins) . . . . . . (powerpc64 [and powerpc] continuing to fail) . . . -r314474 is dated 2017-Mar-1. (powerpc64 and powerpc started working) === Mark Millard markmi at dsl-only.netReceived on Fri Mar 03 2017 - 21:32:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC