Well---I'm still picking up the pieces here. Not sure what happened, but that did not work for me & for some reason, I can't revert it back or boot the older 4.16-1. everything just hangs. I'm in my backup system, looking at the kernel logs. Last entry starts:
Jun 23 21:22:52 debian kernel: [ 0.000000] Linux version 4.16.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-23)) #1 SMP Debian 4.16.16-2 (2018-06-22) Jun 23 21:22:52 debian kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.16.0-2-amd64 root=UUID=c18c39f1-0e2c-4c89-a534-e3c8414bb273 ro cgroup_enable=memory swapaccount=1 elevator=noop nvidia-current.NVreg_EnablePCIeGen3=1 slab_common.usercopy_fallback=y Normal boot until GDM "should" come up, then I get: Jun 23 21:23:00 debian kernel: [ 28.992343] nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 242 Jun 23 21:23:00 debian kernel: [ 29.383969] resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] Jun 23 21:23:00 debian kernel: [ 29.384003] caller _nv001169rm+0xe3/0x1d0 [nvidia] mapping multiple BARs Jun 23 21:23:02 debian kernel: [ 30.747951] show_signal_msg: 14 callbacks suppressed Jun 23 21:23:02 debian kernel: [ 30.747953] gnome-shell[1370]: segfault at 20 ip 00007f2ee7714aed sp 00007fff4654cb00 error 4 in libmutter-2.so.0.0.0[7f2ee7617000+165000] Last line repeats about 50 times with slightly different addresses [7f2ee7617000+165000] is a typical example--the 165000 stays constant. There is also a note about updating runlevels during this period. I get the same result with my older 4.16-1 kernel now...no combination of workaround(s) seem to have any effect. Thoughts welcome.
