> 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 rgri...@freebsd.org _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"