Re: nvidia drivers mutex lock

SOME LINES BOTTOM POSTED, SEE...
--------------------------------------------
On Fri, 6/2/17, Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote:

 Subject: Re: nvidia drivers mutex lock
 To: freebsd-current_at_freebsd.org
 Cc: "Jeffrey Bouquet" <jeffreybouquet_at_yahoo.com>, "blubee blubeeme" <gurenchan_at_gmail.com>
 Date: Friday, June 2, 2017, 11:25 PM
 
 Hi.
 Version
 381.22 (5 days newer than 375.66) of the driver states...
 [1]
 
  Fixed hangs and
 crashes that could occur when an OpenGL context is
  created while the system is out of available
 memory.
 
 Can this be related
 with your hang?
 
 IMHO,
 possibly allocating new resource (using os.lock_mtx
 guard)
 without checking the lock first while
 previous request is waiting for
 another can
 cause the duplicated lock situation. And high memory
 pressure would easily cause the situation.
 
  [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us
 
 Hope it helps.
 
 
 On Thu, 1 Jun
 2017 22:35:46 +0000 (UTC)
 Jeffrey Bouquet
 <jeffreybouquet_at_yahoo.com>
 wrote:
 
 > I see the same
 message, upon load, ...
 >
 --------------------------------------------
 > On Thu, 6/1/17, blubee blubeeme <gurenchan_at_gmail.com>
 wrote:
 > 
 >  Subject:
 nvidia drivers mutex lock
 >  To: freebsd-ports_at_freebsd.org,
 freebsd-current_at_freebsd.org
 >  Date: Thursday, June 1, 2017, 11:35
 AM
 >  
 >  I'm
 running nvidia-drivers 375.66 with a GTX
 >  1070 on FreeBSD-Current
 >  
 >  This problem
 just started happening
 >  recently but,
 every so often my laptop
 >  screen will
 just blank out and then I
 >  have to
 power cycle to get the
 >  machine up and
 running again.
 >  
 >  It seems to be a problem with nvidia
 >  drivers acquiring duplicate lock. Any
 >  info on this?
 >  
 >  Jun〓 2 02:29:41 blubee kernel:
 >  acquiring duplicate lock of same
 type:
 >  "os.lock_mtx"
 >  Jun〓 2 02:29:41 blubee kernel: 1st
 >  os.lock_mtx _at_ nvidia_os.c:841
 >  Jun〓 2 02:29:41 blubee kernel: 2nd
 >  os.lock_mtx _at_ nvidia_os.c:841
 >  Jun〓 2 02:29:41 blubee kernel:
 >  stack backtrace:
 > 
 Jun〓 2 02:29:41 blubee kernel: #0
 > 
 0xffffffff80ab7770 at
 > 
 witness_debugger+0x70
 >  Jun〓 2
 02:29:41 blubee kernel: #1
 > 
 0xffffffff80ab7663 at
 > 
 witness_checkorder+0xe23
 >  Jun〓 2
 02:29:41 blubee kernel: #2
 > 
 0xffffffff80a35b93 at
 > 
 __mtx_lock_flags+0x93
 >  Jun〓 2
 02:29:41 blubee kernel: #3
 > 
 0xffffffff82f4397b at
 > 
 os_acquire_spinlock+0x1b
 >  Jun〓 2
 02:29:41 blubee kernel: #4
 > 
 0xffffffff82c48b15 at _nv012002rm+0x185
 >  Jun〓 2 02:29:41 blubee kernel:
 >  ACPI Warning:
 \_SB.PCI0.PEG0.PEGP._DSM:
 >  Argument #4
 type mismatch - Found
 >  [Buffer], ACPI
 requires [Package]
 > 
 (20170303/nsarguments-205)
 >  Jun〓 2
 02:29:42 blubee kernel:
 > 
 nvidia-modeset: Allocated GPU:0
 > 
 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) _at_
 >  PCI:0000:01:00.0
 > 
 
 >  Best,
 >  Owen
 > 
 _______________________________________________
 >  freebsd-ports_at_freebsd.org
 >  mailing list
 >  https://lists.freebsd.org/mailman/listinfo/freebsd-ports
 >  To unsubscribe, send any mail to
 "freebsd-ports-unsubscribe_at_freebsd.org"
 >  
 > 
 > 
 > ... then Xorg will
 run happily twelve hours or so.  The lockups here happen
 usually
 > when too large or too many of
 number of tabs/ large web pages with complex CSS etc
 > are opened at a time.  
 >     So no help, just a 'me
 too'.  
 >
 _______________________________________________
 > freebsd-current_at_freebsd.org
 mailing list
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current
 >
 To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
 > 
 > 
 
 
 -- 
 Tomoaki
 AOKI    <junchoon_at_dec.sakura.ne.jp>
 


........................
might be a workaround
Xorg/nvidia ran all night with this:
   nvidia-settings >>  X server display configuration >> Advanced >> Force Full Composition Pipeline
... for the laptop freezing.  Could not hurt to try.  " merge with Xorg.conf " from nvidia-settings...
......................
18 hours uptime so far, even past
the 3 am periodic scripts.   Have not rebooted out of the Xorg though so may require edit-out of
xorg.conf if that is the case, in other words differing from real-time apply and
xorg initially start applies.  
........