svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

[Mark Millard]

On 2017-Feb-20, at 11:10 AM, Mateusz Guzik <mjguzik at gmail.com> wrote:

> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
>> [Note: I experiment with clang based powerpc64 builds,
>> reporting problems that I find. Justin is familiar
>> with this, as is Nathan.]
>> 
>> I tried to update the PowerMac G5 (a so-called "Quad Core")
>> that I have access to from head -r312761 to -r313864 and
>> ended up with random panics and hang ups in fairly short
>> order after booting.
>> 
>> Some approximate bisecting for the kernel lead to:
>> (sometimes getting part way into a buildkernel attempt
>> for a different version before a failure happens)
>> 
>> -r313266: works (just before use of atomic_fcmpset)
>> vs.
>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
>> 
>> (I did not try -r313268 through -r313270 as the use was
>> gradually added.)
>> 
>> So I'm currently running a -r313864 world with a -r313266
>> kernel.
>> 
>> No kernel that I tried that was from before -r313266 had the
>> problems.
>> 
>> Any kernel that I tried that was from after -r313271 had the
>> problems.
>> 
>> Of course I did not try them all in other direction. :)
>> 
> 
> I found that spin mutexes were not properly handling this, fixed in
> r313996.
> 
> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
> fcmpset to simulate failures. Everything works, while it would easily
> fail without the patch.
> 
> That said, I hope this concludes the 'missing check for not-reread value
> of failed fcmpset' saga.
> 
> -- 
> Mateusz Guzik <mjguzik gmail.com>

I tried to update from -r313864 to -r313999 in my amd64 context
(a VirtualBox machine under macOS) but it now crashes late in
the boot sequence (after it processes a dump if I make one but
before I can log in).

This update was via my usual explicit svnlite update; buildworld
buildkernel; etc. production style build of world and kernel,
including use of MALLOC_PRODUCTION.

The window shows:

_vm_map_lock+0xf
vm_map_wire+0x32
rtROMemObjNativeLockInMap+0x8c
rtROMemObjNativeLockUser+0x51
RTR0MemObjLockUserTag+0x231
vbglR0HGCMInternalPreprocessCall+0x65d
vbglR0HGCMInternalCall+0x17c
vgdrvIoCtl_HGCMCall+0x43f
VGDrvCommonIoCtl+0x261
vgdrvFreeBSDIOCtl+0x2cd
devfs_ioctl+0xae
VOP_IOCTL_APV+0x88
vn_ioctl+0x161
devfs_ioctl_f+0x1f
kern_ioctl+0x280
sys_ioctl+0x13f
amd64_syscall+0x397
Xfast_syscall+0xfb


===
Mark Millard
markmi at dsl-only.net