Kubuntu Wily 15.10 KDE upgrade from 5.4.3 to 5.5.3

So, Kubuntu 15.10 told me I had an update - a big update.  I'm pretty sure it's the KDE 5.5.2 that was put out last month.  Kubuntu is low on staff right now, so it takes longer for KDE releases to get repackaged.  Still, I'm thrilled that this is available.  Actually, the upgrade is to KDE 5.5.3 - amd64 4:5.5.3a-ubuntu1~ubuntu15.10~ppa5.  It looks like Qt is being upgraded to 5.5.1 - amd64 5.5.1+dfsg-1ubuntu1~wily1~test1.

Unfortunately, the upgrade didn't go smoothly.  It booted up into a TTY on the first reboot.  It looked like the nVidia driver didn't find any compatible displays so X wouldn't come up.  I switched to intel (prime-select) and rebooted, but now it's showing me a "low graphics mode" dialog with options for trying full graphical mode, reconfiguring, console, etc.  Dropped to a console.

MORALE OF THE STORY: SDDM was trying to start X before the nVidia driver was fully initialized, so X couldn't find any compatible displays.

SOLUTION: Use a systemd timer to delay the start of SDDM - I used 5s.  See the bottom of this post.

It's trying to load the failsafe X server and I'm still getting errors!

Rebooting back into nvidia mode to diagnose logs more thoroughly.

The Xorg log shows me this error:

(EE) modeset(G0): drmSetMaster failed: Invalid argument
...
(EE) addScreen/ScreenInit failed for gpu driver 0 -1

prime-offload.log shows:

Sorry we only support randr 1.4 or higher

The Xorg failsafe log shows me nothing terribly useful.

Google gave me this:

http://askubuntu.com/questions/613021/nvidia-xorg-crashes-on-15-04-drmsetmaster-failed-invalid-argument

I ran nvidia-xconfig.  Same error - no difference.

Doing an apt-get -s remove --purge nvidia-* shows me these files would be removed:

nvidia-352 [352.63-0ubuntu0.15.10.1
nvidia-opencl-icd-352
nvidia-prime [0.8.1]
nvidia-settings [352.21-0ubuntu1]

Do it.

On reinstall, it's trying to build the kernel modules for 4.4.0-rc2, which I haven't had installed in a while.  Where is it finding this??

Huh, there is an initramfs file in my /boot with that version.  Oops.  Deleted it via update-initramfs -d -k 4.4.0-rc2+.  Seemed to do something.

Let's reinstall the nvidia drivers.  Gonna purge first and reinstall.  Super safe...

Seemed to go smoothly, no errors.  ::sigh::  Reboot.

Still no joy.  Same Xorg error.  Still the same, weird prime-offload error.

Manually running startx as root... display is black (no backlight).  Switched to TTY2 and did 'sudo pkill X' - at least tty1 is back.

Let's prime-select to 'intel' and reboot.

Wouldn't reboot gracefully - had to use power button.  Hung on the glowing Kubuntu logo.

OK, in intel mode I got the same "system is running in low graphics mode" dialog.  Let's select "try running with default graphical mode".

Whoa, kde 5.5.3 came right up!  Dang!  With a funky new background.  Yay!

Indeed, we're running on KDE 5.5.3 and Qt 5.5.1.  Woo-hoo!

Moral of the story: switch to intel mode after upgrade and then figure out why nvidia's broken (again).

My old xorg.conf was:

Section "ServerLayout"
    Identifier "layout"
    Screen 0 "nvidia"
    Inactive "intel"
EndSection

Section "Device"
    Identifier "intel"
    Driver "modesetting"
    BusID "PCI:0@0:2:0"
    Option "AccelMethod" "None"
EndSection

Section "Screen"
    Identifier "intel"
    Device "intel"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "PCI:1@0:0:0"
    Option "ConstrainCursor" "off"
EndSection

Section "Screen"
    Identifier "nvidia"
    Device "nvidia"
    Option "AllowEmptyInitialConfiguration" "on"
    Option "IgnoreDisplayDevices" "CRT"
EndSection

I'm going to prime-select to nvidia and reboot.

Still seeing the exact same errors.  Looking at journalctl -b is helpful.  Here are some relevant errors:

sddm Running /usr/bin/X -nolisten tcp -auth /var/run/sddm/{...} -background none -noreset -displayfd 17 vt7
sddm running display setup script "/usr/share/sddm/scripts/Xsetup"
sddm /usr/bin/xauth bad "remove" command line
sddm /usr/bin/xauth bad "add" command line
sddm Display server stopped.
sddm Running display stop script "/usr/share/sddm/scripts/Xstop"

It then tries again with additional problems:

sddm Running /usr/bin/X -nolisten tcp -auth /var/run/sddm/{...} -background none -noreset -displayfd 17 vt7
sddm running display setup script "/usr/share/sddm/scripts/Xsetup"
sddm /usr/bin/xauth bad "remove" command line
sddm /usr/bin/xauth bad "add" command line
sddm Display server stopped.
sddm Running display stop script "/usr/share/sddm/scripts/Xstop"
sddm QProcess Destroyed while process ("/usr/lib/x86-64-linux-gnu/sddm/sddm-helper") is still running
sddm-helper Received a wrong opcode instead of AUTHENTICATED: 0
sddm.service: Main process exited, code=dumped, status=11/SEGV
sddm.service: Failed to schedule restart job: Transaction is destructive.
sddm.service: Failed with result 'resources'.
Started X.org diagnosis failsafe.

WTF?

I did get it running by manually running 'systemctl restart sddm' from the TTY.  Hey, that's something!

Here's an interesting exchange about a problem similar to this:

https://bbs.archlinux.org/viewtopic.php?id=189145

As always, it's between arch users - apparently the geniuses of the Linux world.

He suggests delaying sddm by creating a systemd timer that runs after a set period.  Huh.  Here's what he used:

cat /etc/systemd/system/sddm.timer 
[Unit]
Description=Start sddm service fixed time after boot

[Timer]
OnStartupSec=20
Unit=sddm.service

[Install]
WantedBy=multi-user.target

He then disabled sddm.service and enables the timer:

systemctl disable sddm.service
systemctl enable sddm.timer

I changed the "WantedBy" dependency to "graphical.target" instead of "multi-user" target and the delay to 5s.  On my system sddm was wanted by graphical.target and not multi-user.target.

Huh, it worked.  Damn!

KDE 5.5.3 on Kubuntu Wily 15.10

I recently updated my Kubuntu Wily Verix 547 (nVidia Optimus) laptop from KDE 5.4.3 to 5.5.3 via backports and it's performing well so far!  The system feels very smooth now, the notification area is consistent and predictable, suspend/resume feels like it's a solved problem, and the system as a whole feels more stable.  Note that the Kubuntu packagers also upped Qt to 5.5.1, which is probably also a piece of the ever-improving KDE puzzle.

Thanks for all the hard work!

There are a few problems, still, mainly related to Optimus.  My system won't currently start X using the discrete (970M) video card.  X says it can't find an output and fails.  With prime-select in 'intel mode, the system boots to a "running in low graphics mode" dialog but will load successfully when selecting the normal graphical boot.  The Verix is an Intel 4810QM which has a perfectly serviceable IGPU for non-gaming work, so this is acceptable for now.  But, I'll be fighting with nVidia soon enough, I'm sure.

KDE Plasma 5 Notifications - missing characters??

Sometimes I'll see this very strange behavior when notifications pop up.  Some characters are simply not displayed.  Here's an example:

It should say:

System Notification Helper
A system restart is needed to complete the update process

Is that bizarre or what?  Here are the mising letters:

e
s e e s e e e e e s s

So, it looks like 'e' is missing a lot.  I never noticed that it was only ees and esses.  But, not all ees and esses - just some of them.

I've noticed them in other notification types as well, not just system restarts.

Plasma 5 resume image corruption issues

I frequently have plasma (5.4.3 in Kubuntu 15.10 Wily) issues on resume from suspend (wake from sleep).  Often times plasma crashes but usually automatically restarts. This post is about a different issue - image corruption.  Note that I have a 970M-based nVidia Optimus laptop running PRIME in nvidia mode.  I don't run off the integrated GPU (intel) enough to notice the problem.

Sometimes a portion of the screen is corrupted.  On my system this takes the form of a "snow" image, mostly white with lots of light-colored dots, reminding me of the snow image analog TVs would display when no signal was present.

Once, the "snow" was present in a Konsole window.  The decorations and border were fine, but the actual console content was this snow image.

Other times, the desktop background was this snow image.

Interestingly, the functionality of the desktop remains unchanged.  I can switch between desktops, move windows, etc.  And compositing is still enabled, with my fancy desktop-cube switcher and wobbly windows.  But, the background remained snowy.

The only way I found to fix it, short of logging out and back on, was by disabling compositing ("disable desktop effects" - shift-alt-F12).  The background image was correctly displayed.  I then re-enabled compositing and all was good.

Confusing, but there you have it.  At least I didn't have to end my session and restart X!

Plasma in Kubuntu Wily (15.10) crashes on resume

Every time I suspend my laptop (Verix 547 with nVidia 970M in optimus), Plasma crashes.  Well, not every time, but quite frequently.  Here's the error I see:

Application: Plasma (plasmashell), signal: Segmentation fault

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

[Current thread is 1 (Thread 0x7fefbcd2f800 (LWP 2622))]

Thread 12 (Thread 0x7fefa688e700 (LWP 2624)):

#0 0x00007fefb74df8dd in poll () at ../sysdeps/unix/syscall-template.S:81

#1 0x00007fefbb526bd2 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1

#2 0x00007fefbb52874f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1

#3 0x00007fefa9450a39 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so

#4 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5 0x00007fefb6cc16aa in start_thread (arg=0x7fefa688e700) at pthread_create.c:333

#6 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 11 (Thread 0x7fef9ffff700 (LWP 2668)):

#0 0x00007fefb7e08664 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#1 0x00007fefb428b77d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#2 0x00007fefb428c11b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#3 0x00007fefb428c2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#4 0x00007fefb7e0929b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5 0x00007fefb7daf75a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#6 0x00007fefb7bcd3d4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#7 0x00007fefba3f5f85 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5

#8 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#9 0x00007fefb6cc16aa in start_thread (arg=0x7fef9ffff700) at pthread_create.c:333

#10 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 10 (Thread 0x7fef9555c700 (LWP 2679)):

#0 0x00007fefb428b728 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#1 0x00007fefb428c11b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#2 0x00007fefb428c2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#3 0x00007fefb7e0929b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#4 0x00007fefb7daf75a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5 0x00007fefb7bcd3d4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#6 0x00007fefba3f5f85 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5

#7 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#8 0x00007fefb6cc16aa in start_thread (arg=0x7fef9555c700) at pthread_create.c:333

#9 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 9 (Thread 0x7fef8ec5a700 (LWP 2691)):

#0 0x00007fefb7e0722e in QTimerInfoList::repairTimersIfNeeded() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#1 0x00007fefb7e072a3 in QTimerInfoList::timerWait(timespec&) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#2 0x00007fefb7e0867e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#3 0x00007fefb428b77d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#4 0x00007fefb428c11b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#5 0x00007fefb428c2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#6 0x00007fefb7e0929b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#7 0x00007fefb7daf75a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#8 0x00007fefb7bcd3d4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#9 0x00007fefba3f5f85 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5

#10 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#11 0x00007fefb6cc16aa in start_thread (arg=0x7fef8ec5a700) at pthread_create.c:333

#12 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 8 (Thread 0x7fef8d359700 (LWP 2708)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

#1 0x00007fefbc781114 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5

#2 0x00007fefbc781159 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5

#3 0x00007fefb6cc16aa in start_thread (arg=0x7fef8d359700) at pthread_create.c:333

#4 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 7 (Thread 0x7fef867fa700 (LWP 2714)):

#0 0x00007fefb74df8dd in poll () at ../sysdeps/unix/syscall-template.S:81

#1 0x00007fefb428c1ec in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#2 0x00007fefb428c2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#3 0x00007fefb7e0929b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#4 0x00007fefb7daf75a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5 0x00007fefb7bcd3d4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#6 0x00007fefbad71ef6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#7 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#8 0x00007fefb6cc16aa in start_thread (arg=0x7fef867fa700) at pthread_create.c:333

#9 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 6 (Thread 0x7fef8580f700 (LWP 2715)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

#1 0x00007fefb7bd355b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#2 0x00007fefbade4b3e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#3 0x00007fefbade53c3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#4 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5 0x00007fefb6cc16aa in start_thread (arg=0x7fef8580f700) at pthread_create.c:333

#6 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 5 (Thread 0x7feeeae00700 (LWP 2857)):

#0 0x00007fefb7e08633 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#1 0x00007fefb428b77d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#2 0x00007fefb428c11b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#3 0x00007fefb428c2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#4 0x00007fefb7e0929b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5 0x00007fefb7daf75a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#6 0x00007fefb7bcd3d4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#7 0x00007feeed0978f7 in KCupsConnection::run() () from /usr/lib/x86_64-linux-gnu/libkcupslib.so

#8 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#9 0x00007fefb6cc16aa in start_thread (arg=0x7feeeae00700) at pthread_create.c:333

#10 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 4 (Thread 0x7feee9ec1700 (LWP 2867)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

#1 0x00007fefb7bd355b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#2 0x00007fefbade4b3e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#3 0x00007fefbade53c3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#4 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5 0x00007fefb6cc16aa in start_thread (arg=0x7feee9ec1700) at pthread_create.c:333

#6 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 3 (Thread 0x7feee120a700 (LWP 2927)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

#1 0x00007fefb7bd355b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#2 0x00007fefbade4b3e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#3 0x00007fefbade53c3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#4 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5 0x00007fefb6cc16aa in start_thread (arg=0x7feee120a700) at pthread_create.c:333

#6 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7feee0a09700 (LWP 3020)):

[KCrash Handler]

#6 __strstr_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:40

#7 0x00007fefbadc280a in QSGRenderContext::initialize(QOpenGLContext*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#8 0x00007fefbade5619 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#9 0x00007fefb7bd22be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#10 0x00007fefb6cc16aa in start_thread (arg=0x7feee0a09700) at pthread_create.c:333

#11 0x00007fefb74eaeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7fefbcd2f800 (LWP 2622)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

#1 0x00007fefb7bd355b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#2 0x00007fefbade183b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#3 0x00007fefbade432f in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#4 0x00007fefbade493b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#5 0x00007fefb80dc7c5 in QWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5

#6 0x00007fefbae14fd3 in QQuickWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5

#7 0x00007fefbc8b1efb in PlasmaQuick::Dialog::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libKF5PlasmaQuick.so.5

#8 0x00007fefb888fb8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5

#9 0x00007fefb8895230 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5

#10 0x00007fefb7db1f1b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#11 0x00007fefb80d5336 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5

#12 0x00007fefb80d607d in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5

#13 0x00007fefb80bb5b8 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5

#14 0x00007fefa947d250 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so

#15 0x00007fefb428bff7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#16 0x00007fefb428c250 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#17 0x00007fefb428c2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#18 0x00007fefb7e0927f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#19 0x00007fefb7daf75a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#20 0x00007fefb7db72cc in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#21 0x00000000004322c3 in main (argc=2, argv=<optimized out>) at ../../shell/main.cpp:176

Yeah, a lot of crap.  I think all that matters is the actual location of the error:

Application: Plasma (plasmashell), signal: Segmentation fault

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

I'm not the only one dealing with this - try googling and you'll find more.  Fortunately, Plasmashell automatically restarts and the session isn't restarted, so it's not a huge loss.

Because I'm running on Kubuntu 15.10 and they've paired KDE5 with Qt 5.4, I've read that that this old Qt is part of the problem.  Supposedly the Kubuntu team is working on packaging Plasma 5.5 with Qt 5.5 (or 5.6?) - 5.5.1 is available for Xenial but not yet packaged for Wily.  We'll see what happens when the newer Plasma is in wily-backports.

Kubuntu 15.10 - SDDM crashes

Sometimes sddm-greeter will refuse to start.  The greeter simply presents a blank screen.  A syslog entry shows:

Jan  5 16:24:43 jason-verix kernel: [ 1666.636093] sddm-greeter[2074]: segfault  at 18 ip 00007f49c6e30e38 sp 00007ffdeda61c70 error 4 in libqxcb.so[7f49c6de7000+b5000]

This happened every time.  I tried restarting via systemd:

systemctl restart sddm

This produced the same error.  I tried restarting X with no luck, also pkill'ing X - still no luck.  So, I brought down SDDM:

sudo service sddm stop

and brought it back up

sudo service sddm start

And it came up.  I don't understand why.  Frustrating!

Note that it may be worthwhile delaying the start of sddm to give the video driver more time to initialize the displays.  Another set of problems I was having was resolved by this technique, which is described here:

http://jasontechstuff.blogspot.com/2016/01/kubuntu-wily-1510-kde-upgrade-from-543.html

Upgrading from Kubuntu 14.10 to 15.10 - can't access my work's WiFi

So, after the torturous upgrade from Kubuntu 14.10 to 15.10, I at least got to the point where I could start plasma (but only in intel mode, not nvidia).  But, when I got to work, I discovered I couldn't access my company's guest network (WPA2 personal authentication).  I could connect, but DNS failed.  I saw this error in the log:

blah blah NetworkManager /etc/resolvconf/update.d/libc: Warning resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf

I'm not sure how this broke during the upgrade, but simply reconfiguring the resolvconf did the trick:

sudo dpkg-reconfigure resolvconf

Another reboot and I'm back in action.  Whew!

Upgrading from Kubuntu 14.10 to 15.10 - can't log in

School has been intense and I haven't felt comfortable making the switch from Kubuntu 14.10 to 15.10 on my main laptop.  This involves transitioning from KDE4 to KDE5 with all of the attendant breakages that will inevitably occur.

But, since 14.10 support ended almost 6 months ago (Canonical only promises 9 months of package updates for non-LTS releases) and I'm going to end up on KDA/Plasma5 no matter what, I decided to take the plunge and do the in-place distribution upgrade.  I have a separate /home partition so I could have simply wiped / and reinstalled directly, which is the recommended process.  Eh, call me a masochist.

Note that this ALSO switched from upstart (a SysV-based init daemon) to systemd.  And a new session manager, SDDM, away from lightDM.  Lots of scary changes at once.

Note that you can't go from 14.10 to 15.10, you MUST go thru 15.04 (Vivid).  The upgrade to 15.04 went well, surprisingly, and I was able to boot back into the new system with no problems.  I didn't fiddle around in 15.04 - I just went straight into the next distribution upgrade to 15.10 (Wily - sorry, Vivid, I hardly knew ye).

Then the pain began.  It wouldn't boot for one thing - just came up in a black screen.  I ended up doing a recovery mode boot and could at least get the recovery menu to come up.  Whew.

Most of the problems for this laptop are related to the Optimus configuration.  So, I tried switching back to the intel driver (prime-select intel).  Still no joy.

I ended up uninstalling xorg-edgers and graphics-drivers PPAs and trying various incarnations of the Ubuntu-packaged nVIDIA drivers (nvidia-35[258]).  After much fiddling, I ended up being able to get a greeter, but only in intel mode.

However, I couldn't log in.  The greeter would go away and give me a black screen, and then 10s later the greeter would come back.  No change in the "failsafe" login.

I couldn't find any obvious issues in the logs, but I knew that updating KDE can be fragile and previous configurations can confuse newer components.  So, I tried creating  new user via useradd and seeing what would happen.

After a reboot, the greeter came up and I was able to log in via the new user.  HALLELUJAH!

At that point I went back to my original user account and began bisecting all of my configuration, specifically the entries in .local, .config, and .kde.  I would move a configuration directory into a backup area and reboot.  If plasma came up, then I'd try a different "configuration" of configuration directories until I found a config directory that broke the login.

After much directory moving and renaming, I ended up narrowing it down to kded5 in .local/share.  So, I simply removed that config and I was able to get back in.

WHEW.

I still can't re-enable the nvidia driver.  prime-select nvidia causes the same login problem, except that instead of looping back to the greeter, it just hangs.  Joy.  More testing to come.

ZaReason Verix 547 Touchpad Freezes

This is another in my series of love notes to ZaReason's Verix 547 Linux-compatible laptop.  This time I'm working on some odd "pauses" or "freezes" in the behavior of the touchpad.

Every now and then, seemingly at random, I'll be moving the pointer with the trackpad and suddenly the pointer simply stops.  Clicking, swiping, dragging... nothing.  I can continue to type, so the keyboard is still active, but otherwise the trackpad is simply unresponsive.  Interestingly, if I switch away to a virtual terminal and come back, miraculously the touchpad is active again!

At first I thought it was related to the trackpad itself, which is:

$ xinput --list | grep Touch
⎜   ↳ SynPS/2 Synaptics TouchPad id=11   [slave  pointer  (2)]

$ cat /proc/bus/input/devices
...
I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse0 event4
B: PROP=9
B: EV=b
B: KEY=6420 30000 0 0 0 0
B: ABS=260800011000003
...

So, a Synaptics part.  But I couldn't quite find anything that matched the exact behavior.  My weak Google-fu finally dropped me here:

https://devtalk.nvidia.com/default/topic/766166/elantech-touchpad-related-nvidia-driver-freeze/

It's not exactly the same environment - the author specifically calls out an ElanTech touchpad, but the behavior is smack on.  Naturally, this is an NVIDIA PRIME-/Optimus-related issue.  ::sigh::

Turns out this author helped identify a bug and it was fixed in an upstream Xorg release - but not the Xorg used in *ubuntu.  While my Xorg says it's 1.16.1 and the was applied to 1.16.0, apparently the patch didn't get accepted until a later release of 1.16.1 - comparing the release dates via 'X -version' showed me that.  Even xorg-edgers didn't have a later X release with the patched code.

A very kind soul packaged up a .deb with the patched xorg binaries and supplied them here:

http://askubuntu.com/questions/507744/touchpad-acting-weird-in-14-04-on-msi-cr70-2m/550603#550603

Long story short, I downloaded the .tar, extracted the .debs, and installed the ones that mattered.  (This user is obviously an X developer, as he had tons of debugging tools and virtualized X server tools installed.)  All I needed was xserver-common and xserver-xorg-core.

It worked!  The touchpad freeze is completely gone.  Thank you, friends!

Oh, and until I upgrade to Kubuntu 15.04, which comes with the fixed X, I put those two packages on hold in apt via:

echo "hold xserver-common" | dpkg --set-selections

This makes life easier when I'm doing upgrades and I might forget to uncheck the xorg packages.

OK, another laptop quirk knocked out!

Knocking out the little things with my ZaReason Verix 547

So, as I've detailed in prior posts, I'm running Kubuntu 14.10 on a new Verix 547 laptop from ZaReason, a vendor and integrator in Berkeley.  So far it's been going well, but there are niggles to deal with, of course.  Even ZaReason, which specifically configures and supports Linux on the machines they sell, has problems with some functionality on this laptop.  Just goes to show the power of OEMs that only test and guarantee operation on Windows - such a hassle!!

Here are some of the issues I've had out of the box with the Verix:

1. lightdm absolutely refuses to show the greeter (login) screen.  I can still log in and it starts up a Plasma session, meaning the keyboard is active and the greeter is detecting my keystrokes and parsing the password, but the greeter is blank.
2. There are intermittent pauses in the touchpad operation.  At random times the touchpad will simply cease accepting input.
3. Sometimes the desktop environment (Plasma/KWin) would become corrupted and unresponsive after a resume from suspend.
4. I can't get audio to output to the HDMI port.

Some of these I've already managed to get around.  Woo-hoo!  Thank you, Interwebz!!  Specifically:

1. After searching for days and trying many hacks, lightdm was still always showing a blank screen for a greeter.  The strangest thing was that I could still type my password, press enter, and then the splash would come up and the desktop environment (Plasma) launched fine.  This would happen whenver the greeter was shown, such as logging out and relogging in.  However, the screen locker was fine - resuming from suspend would show the password field.
   
   After a LOT of fiddling around and searching, I knew that the problem was related to X and not to the touchpad.  For example, I could tap the pad and move the cursor outside the password field, and suddenly typing and pressing <enter> wouldn't log me in.
   
   Also, I didn't see any errors in the X or lightdm log.  Nothing that screamed "Hey, I can't display myself!".  I found a post that describes dealing with black screen issues with NVIDIA Prime systems.  It referred specifically to 14.04, but it talked about the same problem - booting up into a black screen with keyboard active and switching to a VT.
   
   The post was mainly concerned with corrupt xorg.conf's that were being rewritting by 'gpu-manager', which I don't appear to have running on my system.  BUT, when I compared their "correct" xorg.conf to my own conf file, I noticed something interesting.  They included this option in the Intel device section:
   
   

   Section "Device"
       Identifier "intel"
       Driver "modesetting"
   EndSection

   
   The "modesetting" driver was something I hadn't seen before.  Here was my xorg.conf, autogenerated by nvidia-xconfig:
   
   

   Section "Device"
       Identifier "intel"
       Driver "intel"
       BusID "PCI:0@0:2:0"
       Option "AccelMethod" "SNA"
   EndSection
   

   
   Mine was a tad different - notice the "intel" driver, but that's really it.  Everything else is just extra specification.  So, I modified the driver to go from "intel" to "modesetting" and... VOILA!  I can see the lightdm greeter now!  It's not pretty - very barebones, but it works!  I assume I can hack on the theme (background, etc.) to make it nicer.

This post is a little longer than I expected, so I'll address the other issues in subsequent posts.

My new ZaReason Verix 547 and Kubuntu 14.10 - almost perfect!

So, as I recounted in a previous post, I returned the Gigabyte P55W rev4 laptop because I couldn't get it to run Kubuntu 14.10 reliably.  I replaced it with a ZaReason Verix 547 15.6" big, honkin' machine and I've been getting Linux up on it.  Little quirks along the way, but I can't complain so far.

I decided to try to save some dough and reuse 16GB of Corsair Vengeance DDR3L memory I had, as well as reuse a SanDisk Extreme 480GB SATA SSD and a Mushkin 120GB mSATA SSD, all from my late and lamented Dell Inspiron 15R Special Edition (2012).  ZaReason was amenable to this, and actually delivered a laptop to me without any memory or storage.

In retrospect, I should have just gone with their components.  For one thing, I blew up my memory during the install.  Well, it died sometime between when I ripped out of the obstreperous Gigabyte lappy and I installed it in the new Verix system.  The system booted fine and brought up the GRUB menu both on my SSD and from the live Kubuntu 14.10 stick.  But, trying to load an OS choked with kernel panics, and a subsequent mem test immediately barfed out tons of errors (red lines in MemTest86 are bad).

After a quick trip to Frys, and an eternal wait for them to actually find the memory in their little locked electronics wire bunker, I was back in business.  The Verix is easy to get out, with only 6 screws to undo and then easing the plastic tabs out to get access to the bottom of the laptop.  The two 2.5" SATA slots are there, as well as 2 of the memory slots.  But, I couldn't find the other two memory slots or the mSATA slot.

I think those are actually under the keyboard, but I couldn't figure out how to actually get it off.  I can see the tabs above the F-key row on the keyboard.  I have to insert some implement into the tabs to force the keyboard out of the tray... but I can't figure out how.  Oh, well.

The problem with adding the memory from the base of the computer is the memory slots are partially covered by the heatpipe from the 970M.  Ugh.  Here's a picture:

You can see the two empty SO-DIMM slots to the left of the big-ass heatsink.  This was more of a pain than I expected.  It took some time and patience, but I did finally get them installed:

It all came up fine.  The mem test went fine, the Kubuntu install was easy.  Woo-hoo!

 At this point it was running Nouveau and doing OK.  I did an update, an upgrade, then a dist-upgrade and rebooted.  Yeah, yeah, I probably didn't have to reboot... but there were some messages on the Interwebz indicating people had encountered problems installing nVidia binaries without doing HARD shutdowns in between.

Then came adding the xorg-edgers PPA and doing another update.  Another reboot, then going into a TTY (X didn't come up), running nvidia-xconfig to generate a default X.org config file... and here I am!  glxgears is rocking around 11K FPS (with anti-aliasing and font smoothing turned off...), and the display is nice.  Yeah, it's REALLY big, but the sound is also fine.  I can't complain.

Not all's perfect, though it is pretty durn good.

I've been having an odd "pause" problem where the display seems to freeze for a period of time.  Turns out it was related to my trackpad... but more on that later.

From Gigabyte to ZaReason!

About a month ago I needed a new laptop and bought a hot-of-the-presses Gigabyte P44W v4 from NewEgg.  In a previous post I described my experience with the Gigabyte.  My initial reports were positive, but unfortunately I quickly soured on the machine.  It suffered from a number of problems that were showstoppers for me:

1. I never got the nVidia proprietary drivers installed correctly.  The CPU (i7 4710MQ)'s integrated graphics and the discrete nVidia card never worked correctly.  The binary drivers would never correctly detect the discrete card.  Nouveau would work (unreliably), but X would always fall back to the iGPU.  What was the point of a 970M w/3GB?
   
2. Kubuntu 14.10 was never very happy.  I quickly backed away from Kubuntu 15.04, which is the first Kubuntu to feature systemd and Qt 5/Plasma 5, but even my workhorse 14.10 wasn't reliable.  I suffered from frequent lockups and long pauses.  It wouldn't always start up consistently, either.
   
3. Wireless range was quite poor.  I never had a problem with my Dell talking to my wireless router (D-Link Dir-645) through multiple walls and between floors, but the Gigabyte was barely able to hold the link open.  Throughput was poor, and I ended up having to actually go into the room with the router to do any downloading.

Because the laptop was so new, I didn't have any previous experience to mine (how did we live before StackOverfow and Google?), so I felt adrift.  I ended up pulling out my RAM, SATA and mSATA SSDs, replacing the OEM components, and returning it to NewEgg.  They quickly gave me an RMA and a full refund, including shipping.  STILL LOVE NEWEGG!!

I was looking for a laptop that had been vetted for Linux, and I ended up wading into the land of "Linux Certified" vendors, the most famous being System76.  After a lot of searching, I settled on ZaReason, a small system builder in Berkeley that has been around for 7+ years.  I liked ZaReason because it's computers were completely configurable (every component), their laptops all had removable batteries, and, of course every system came with Linux preinstalled and thus were guaranteed to work well with my favorite operating system.

I settled on a Verix 547, which has a 15.6" FHD screen (which is nice!), 2 2.5" SATA III ports, 4 SO-DIMM slots (up to 32GB), and a big 9-cell battery, amongst other goodies.

There are some trade-offs, however:

1. The systems are more expensive.  The components seem to be of high quality, but I paid about a 20% markup on the ZaReason as it was out of the box.
   
2. I really mean complete configurability.  In addition to choosing all the normal stuff (CPU, RAM, HDD/SDD size, etc.), I actually had them not supply any RAM or storage in my laptop.  Yes, it basically came in an unbootable state!  I had a very specific way I wanted to install Kubuntu and I didn't feel like describing it down to every detail for them.  They did test it on their own, but when the sent me the system with the components ripped out.
   
3. They really worked with me.  I sent a bunch of questions about how reliable they found the 970M to be with Linux, how they set it up, etc.  Tony @ ZaReason always got back to me quickly and with a positive, "Yeah, we can do that for you" response.  They even gave me a refund for the stock components I had them remove!  So, I saved about $100 by not including the stock 4GB of RAM or the 500GB HDD.
   
4. They provided an educational discount - as I'm enrolled in the OMSCS program at Georgia Tech, I could take advantage of it.  Every 5% helps!
   
5. The laptop uses a generic shell (case) rather than any customized, vendor-specific, space-optimized case.  So, it's BIG - like 2.1" thick!  It has a huge bezel, which makes room for a full-size keyboard w/number pad (bleah).  It's also about 6 pounds, so this is NOT a Macbook!  This might fit into the "luggable" category.
   
6. Shipping is slower than for a pre-configured system, so don't expect your rig to arrive just a few days after your order.

Overall, the ZaReason Verix 547 is working out well.  Maybe it'll be another post to describe installing Linux and getting the Optimus config working.

Brand spanking new Gigabyte P55W v4 laptop... Linux?!?

My workhorse Dell Inspiron 15R Special Edition that I got almost three years ago finally bit the dust.  It had Kubuntu 14.10 running from a SATA SSD and Windows 7 running off an mSATA SSD.  The laptop stopped detecting the power connection.  I tried multiple adapters (I had two, for both work and home), different wall sockets, etc., but nothing worked.  The power socket on the laptop had become very woodgie, with the male plug maintaining a very tenous connection and frequently falling out at the slightest jiggle.  I believe that an internal connection between the socket and the motherboard had become damaged.

After 3 years of faithful service, I wanted to go Dell again... but they've completely drunk the touchscreen, ultra-quad-wide-HD, Windows 8.1 Kool-aid that I couldn't find a laptop I liked.  I became hooked on the mSATA port, allowing me to showhorn two SSD disks plus the optical drive.  I ended up discovering a very new Gigabyte laptop, the P55W v4 (http://www.gigabyte.com/products/product-page.aspx?pid=5458#kf).  It only came out a few weeks ago but came with one of the first non-U (ulta lower power) mobile 5000-series CPUs (i7 5700HQ), up to 16GB, IPS FHD display, mSATA port, nVidia 970M... it looked really good.

Newegg had a great custom configuration (http://www.newegg.com/Product/Product.aspx?Item=N82E16834233094), the P55W-BNE, that perfectly met my needs.  Also, since the Dell was completely toast, I ripped out the extra memory, Samsung SATA SSD, and mSATA SSD and wanted to transfer it to the new lappy.  Turns out that the Newegg version was about as cheap as I could get for the features I wanted, since I reused the upgrades from the Dell (memory, SSDs).

But, would the Gigabyte run Linux?  There was a time running Linux on bleeding-edge hardware required persistence and determination.  The CPU was announced just a few weeks ago - this is HOT off the presses.  I pulled the OEM hard drive with Windows 8.1 (bleah) and the supplied 8G DDR3 1600 stick, replaced these with the parts from the Dell, and added the mSATA SSD (Gigabyte kindly provided a thermal pad for the mSATA SSD!).  The bottom of the Gigabyte is a single plastic part, so these replacements required me to completely remove the bottom (about 10 screws.  However, once the bottom was off, access to the SATA, mSATA, and memory slots was easy-peasy, which was in stark contrast to performing the same task on the Dell, which demanded that I remove four layers of case, keyboard, boards, and pray that I didn't snap off some plastic...

Naturally, I encountered problems:

1. The system wouldn't boot at first.  I had to turn off secure boot in the BIOS as well as switch to the SATA conroller to IDE mode (from AHCI) and switch the boot method from UEFI to legacy OS.
2. The bus order was different between the Gigabyte and the Dell, so my Linux drive (the Samsung with Kubuntu 14.10) switched from sda to sdb.  No huge biggie, since most of the Linux low-level disk access stuff (filesystems, grub, etc.) switched to using UUIDs, which aren't slot-specific.  I did have to modify /etc/fstab because I had hardcoded the Windows 7 NTFS drive's mountpoint (bad Jason!).
3. The WLAN card wouldn't initialize.  syslog was showing me that it detected the WiFi hardware (Intel 7265-N) but couldn't find any compatible firmware for it.  I build my own custom kernels, so I was at 4.0.4, but it apparently doesn't include the firmware for this adapter.  I ended up dowloading the firmware directly from kernel.org: https://wireless.wiki.kernel.org/_media/en/users/drivers/iwlwifi-7260-ucode-25.17.12.0.tgz.  I copied the iwlwifi-7265D-12.ucode file from that package into /lib/firmware, and we were off to the races.
4. The trackpad wouldn't work.  The system didn't even detect the touchpad at all.  It's attached to the i8042 input bus serial chip, and this is what I should have seen via cat /proc/bus/input/devices:
   
   I: Bus=0011 Vendor=0002 Product=000e Version=0000
   N: Name="ETPS/2 Elantech Touchpad"
   P: Phys=isa0060/serio1/input0
   S: Sysfs=/devices/platform/i8042/serio1/input/input8
   U: Uniq=
   H: Handlers=mouse0 event8
   B: PROP=1
   B: EV=b
   B: KEY=6420 30000 0 0 0 0
   B: ABS=260800011000003
   
   After googling around, I discovered a message that mentioned a patch for 3.13 to fix the problem, here: http://askubuntu.com/questions/529797/elantech-touchpad-not-detected-on-gigabyte-laptop.  The patch was to i8042.c.  I had a copy of the kernel source, so I looked into the file.  Turns out there was ALREADY a workaround for the problem in 4.0.4.  Yes!  The work around was controlled by an i8042 module parameter, 'kbdreset'.  A reboot and manually adding the 'i8042.kbdreset' parameter to the kernel boot line, my trackpad is now happy.
   
   To persist the change, I modified GRUB_CMDLINE_LINUX in /etc/defaults/grub with that option, and now it reliably comes up every time.
5. I can't start Windows from the mSATA SSD.  I haven't yet fixed this...

In the end, most of these would probably have been fixed if I had installed fresh, but the most relevant stuff I did:
 

1. I had to turn off secure boot in the BIOS as well as switch to the SATA conroller to IDE mode (from AHCI) and switch the boot method from UEFI to legacy OS.
2. I ended up dowloading the Intel 7265-N wireless firmware directly from kernel.org: https://wireless.wiki.kernel.org/_media/en/users/drivers/iwlwifi-7260-ucode-25.17.12.0.tgz.  I copied the iwlwifi-7265D-12.ucode file from that package into /lib/firmware.  This fixed the wireless issue.
3. I added i8042.kbdreset to GRUB_CMDLINE_LINUX in /etc/defaults/grub and regenerated the grub.cfg (update-grub) to fix the trackpad issue.

In the end, the Gigabyte P55W v4 seems to support Linux really well.  I'm happy!!

 I hope this may be useful for somebody down the line.