Your post displayed as blank because it was too large - the forum software does that to avoid causing performance problems. I've now removed the mostly irrelevant kernel initialization part from your dmesg output.

Based on the dmesg output, please disconnect all non-essential USB peripherals from your system (ie. everything but keyboard/mouse) and perform a cold reboot of the system.

Frequent resets of device usb 3-7 appear to be occurring around Kernel oopses, indicating a driver bug. Processes affected include plasma-desktop, upowerd, etc. which explains why you get a black screen.

Well, usb 3-7 is my Logitech iFeel mouse. And when I reboot and it changes ports, the timeouts stay with the mouse. I'm not seeing evidence that the crashes are caused by USB, but it's sensible to try and eliminate the timeouts.

I find that my mobo docs say: "Due to the design of the Intel® 8 series chipset, all USB devices connected to the USB 2.0 and USB 3.0 ports are controlled by the xHCI controller. Some legacy USB devices must update their firmware for better compatibility."

... and indeed the driver timing out is xhci_hcd, which is for usb3, even though my mouse and keyboard are plugged into the mobo's usb2 ports. Apparently it's using the usb3 driver for everything, and that driver has a bad reputation for waiting for timeout values to come from the client usb adapter rather than having them built-in. In some cases firmware has to be sent to the device, and I don't know of any for the iFeel device.

So my next step launched me on an unending nightmare which has only just begun. When I blacklisted xhci_hcd, I rebooted and entered the luks disk password... nothing. It didn't budge. It was locked up, and the light in the mouse was out. I tried everything I could think of, including removing the blacklist, to no avail. I am now on my 4th complete reinstall of Debian, trying to figure out at what point in configuration, this is caused by. Weeks, with my main server down. There comes a point where it is ridiculous, but Debian is the distro I've run for 15 years and it's the one I always fall back to when others fail. I should have been job hunting this week but I've been fscking with this server as I must have it to function.

Ben asked to remove the device, not blacklist the driver. No usb driver, no usb devices, no input.... in case you have not yet gained back access, see whether you can get and attach a PS/2 keyboard.

I was under the impression everyting worked after moving to SNA HW acceleration - was I wrong?
Then you ran an update and things were broken again? Did you check whether the update maybe simply reverted the acceleration mode?

Yes, you were under that impression because that's what I said. But the next boot disproved that theory. About every third boot I could run KDE.

Since then I've been immersed in a Hell of five reinstalls, each with varying symptoms and levels of despair. But I think I've just about got things sorted. The very worst problem, hung the system right as it asked for my luks disk password. That was caused by initramfs not knowing that it's supposed to include the sha256_generic and sha256-ssse3 modules. Finding that cost me a few years of my life. Thanks for not fixing yet another longstanding bug, Debian.

Once I got that sorted and about six other Debian problems solved, I found that there is no way I can blacklist the xhcd driver as that's exactly what the hardware is on the mobo. So I disconnected various USB devices until I found the one which actually stopped the crashes and timeouts. It's a Siig SD card reader. So far, disconnecting it has fixed everything. But it will take time to be sure as I've been fooled many times before.

So far the lesson would be that some motherboard require the USB3 driver, but some peripherals cannot cope with usb3 and crash kde but not xfce.

So I've found that one USB device is causing the timeouts (Realtek Semiconductor Corp. Mass Storage Device [Multicard Reader], ie a SIIG SDcard/CFcard multicard reader). This does not crash plasma nor interfere with KDE.

Another USB device is causing the crashes, and is what was killing KDE. (Silverstone/iMon case display touchscreen)

Apparently the USB3 driver is not backward-compatible with these for some reason. Neither has a firmware update I could apply.

I appreciate you guys sticking with me. Apparently KDE has some sorting out to do WRT the xhci_hcd driver, to make Plasma more tolerant.

I don't think anything (except maybe the input config module) deals with usb input devices directly but only with events generated by the X11 server (that esp. holds for plasma-desktop or kwin)

It's more likely that the hanging input device floods the X11 eventloop and causes a hung GPU, see https://bugs.kde.org/show_bug.cgi?id=299333#c61

xhci-hcd has a "quicks" option, but it's a bitfield and i found no documentation of it (or wheter it allows you to increase timeouts w/o recompiling the module)

If that were the case, XFCE shouldn't work, but it does.

I do not see where anything in xfce would link (or even use) OpenGL ...

That's correct. But the bug you cite has nothing to do with OpenGL. "It's more likely that the hanging input device floods the X11 eventloop and causes a hung GPU." I did see a hung GPU on more than one occasion, although it didn't stop XFCE.

BTW, is there any alternative to Klipper? It has the disruptive and annoying trait: I highlight text in one window and try to middle-click paste in another, but it does nothing. Check Klipper and my paste is there, but is number 2. #1 is completely blank. This happens all the time.

"implied" =)

#6 brw_update_renderbuffer_surface (brw=0x27a3d50, rb=0x27a00a0, unit=0) at brw_wm_surface_state.c:919
#7 0x00007f0794831a80 in brw_update_renderbuffer_surfaces (brw=0x27a3d50) at brw_wm_surface_state.c:1016
#8 0x00007f079481b628 in brw_upload_state (brw=0x27a3d50) at brw_state_upload.c:503
#9 0x00007f07948087bf in brw_try_draw_prims (max_index=<optimized out>, min_index=<optimized out>, ib=0x0, nr_prims=1, prim=0x7fff85bc0ec0, arrays=0x2818b18, ctx=0x27a3d50) at brw_draw.c:482
#10 brw_draw_prims (ctx=0x27a3d50, arrays=0x2818b18, prim=0x7fff85bc0ec0, nr_prims=1, ib=0x0, index_bounds_valid=<optimized out>, min_index=0, max_index=5, tfb_vertcount=0x0) at brw_draw.c:566
#11 0x00007f0794477544 in vbo_draw_arrays (ctx=0x27a3d50, mode=4, start=0, count=<optimized out>, numInstances=1) at vbo/vbo_exec_array.c:600
#12 0x00007f07ac12ced7 in KWin::GLVertexBufferPrivate::corePainting (this=0x2995b00, region=..., primitiveMode=4) at ../../../kwin/libkwineffects/kwinglutils.cpp:1189
#13 0x00007f07ac12cfd5 in KWin::GLVertexBuffer::render (this=0x2956cf0, region=..., primitiveMode=4) at ../../../kwin/libkwineffects/kwinglutils.cpp:1298
#14 0x00007f07affd578f in renderQuads (normalized=<optimized out>, tex=<optimized out>, quads=..., region=..., this=<optimized out>) at ../../kwin/scene_opengl.cpp:788
#15 KWin::SceneOpenGL::Window::renderQuads (this=<optimized out>, region=..., quads=..., tex=<optimized out>, normalized=<optimized out>) at ../../kwin/scene_opengl.cpp:768
#16 0x00007f07affdcb82 in KWin::SceneOpenGL::Window::performPaint (this=0x2e24610, mask=513, region=..., data=...) at ../../kwin/scene_opengl.cpp:592

Crash in the GL compositor.
A hung GPU can often be recovered, but is usually certain death for GL clients.

You could try appending "i915.i915_enable_rc6=0" to the kernel parameters - no guarantee that this (powersaving) is the cause.

BTW, is there any alternative to Klipper?

Not that i'm aware. What you describe seems a bug though. Could be related to the xhci_hcd issues.
Plain MMB pasting is supposed to work w/o an extra client like klipper (but only between open clients, ie. if you select sth. then close the window, you cannot paste it anymore)
Check whether that works. If yes: bug in klipper. If not: rather bug in mouse input.

In this case, there is very little KDE could do to solve the issue. It is completely unexpected behaviour that system services such as UPower, UDisks, etc. will misbehave in such a manner. Future changes to the Solid interface to make it asynchronous would be the only way to fix it at the KDE level (I think there may be such plans as part of KDE Frameworks 5, but i'm not sure).

The issue was caused because the XHCI driver problems caused those system services (UDisks, UPower) to become hung or crash, causing a kernel oops in the process. It is likely the card reader was a principal cause of this. As a result, KDE became hung awaiting their responses - in virtually all cases these services reply instantaneously, but this didn't occur in your case.