User Tools

Site Tools


Nouveau Bother

After my fourth abrupt crash on my newly-installed Debian system, I'd had enough. CPU, disk and graphics card temperatures were all fine and Memtest didn't record any problems with my 96GB RAM, so the PC is physically as fine as I can check it to be. So: it clearly must be the operating system!

I therefore swiftly wiped Debian Testing and installed Fedora 29 (KDE Spin). Looks a lot better than most Fedoras I remember, everything application-wise installed fine too, with minimal fuss. Then the neighbour popped round for a short chat and once she'd gone, I returned to whatever I'd been up to when she first arrived… and discovered my PC had completely locked up again! Maybe it wasn't the operating system after all!

Again, physical health checks were fine, so in desperation, I did what I should have done the first time… and read the contents of /var/log/messages. Therein, I found this:

Mar 25 16:49:10 britten kscreenlocker_greet[25948]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
Mar 25 16:54:12 britten kernel: nouveau 0000:02:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
Mar 25 16:54:12 britten kernel: nouveau 0000:02:00.0: fifo: runlist 0: scheduled for recovery
Mar 25 16:54:12 britten kernel: nouveau 0000:02:00.0: fifo: channel 2: killed
Mar 25 16:54:12 britten kernel: nouveau 0000:02:00.0: fifo: engine 7: scheduled for recovery
Mar 25 16:54:12 britten kernel: nouveau 0000:02:00.0: fifo: engine 0: scheduled for recovery
Mar 25 16:54:12 britten kernel: nouveau 0000:02:00.0: Xorg[1307]: channel 2 killed!
Mar 25 16:54:43 britten kernel: perf: interrupt took too long (3929 > 3925), lowering kernel.perf_event_max_sample_rate to 50000
Mar 25 16:55:01 britten cupsd[1256]: REQUEST localhost - - "POST / HTTP/1.1" 200 182 Renew-Subscription successful-ok
Mar 25 17:25:58 britten kernel: Linux version 5.0.3-200.fc29.x86_64 ([email protected]) (gcc version 8.3.1 20190223 (Red Hat 8.3.1-2) (GCC)) #1 SMP Tue Mar 19 15:07:58 UTC 2019
Mar 25 17:25:58 britten kernel: Command line: BOOT_IMAGE=/vmlinuz-5.0.3-200.fc29.x86_64 root=UUID=5b2c6cd0-adfb-427b-af31-864ce0dd2d0c ro resume=UUID=1b31f287-5672-4a4f-8e28-a7a9ec39f3a6 rhgb quiet LANG=en_GB.UTF-8
Mar 25 17:25:58 britten kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Mar 25 17:25:58 britten kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Mar 25 17:25:58 britten kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'

You can see from the time jump that the lock-up happened around 4:55pm and I had to wield the power switch at 5:25pm. The interesting lines are what proceed the 4:55pm dramas: they are all, in various ways, reporting that the Nouveau graphic driver is doing something peculiar, including 'killing off' channel 2 (whatever that means).

This would explain why, although my machine appears to lock up, it will quite happily continue playing music in the background if any were playing beforehand: the error messages suggest that the PC itself has not locked up at all, but that everything graphical (which, thanks to Xorg, also means keyboard-related) is dead beyond repair.

So: my suspicions were raised that all was not well with Nouveau and its attempts to interact with my Quadro K4000 graphics card. A swift bit of Googling later, and my suspicions seemed confirmed. Others had reported sporadic 'nouveau channel X killed' messages in the past, too: this report seemed to describe my situation exactly, for example.

I therefore followed this invaluable guide to installing the “proper” NVIDIA drives (and taking Nouveau off the system entirely). So far, so good (though the intermittent nature of the lock-ups means I can't yet guarantee that the problem has genuinely been fixed).

I can't say I've ever had Nouveau problems on this PC before… but, come to think of it, I used to install Nvidia's proprietary drivers routinely because I was using a dual-monitor setup that Nouveau had difficulty configuring properly. These days, I'm single-monitor, and thus didn't think the proprietary drivers were needed… but it seems that sometimes, they are, no matter how many monitors you're using!

It seems I owe Debian Testing an apology, therefore! It wasn't really the distro at fault, just the Nouveau drivers (which every distro uses anyway, so all of them would presumably have faced the same issue, sooner or later).

By way of a happy side-effect, I had also noticed that when I ran my Stellarium astronomy program, it's version of the daylight sky had a weird pink glow about it, like this one (reported by another user a couple of years ago, presumably not for the same reasons):

After the change to proprietary Nvidia graphics drivers, everything looks normal once again:

So, there are a few 'morals-of-the-story' here. First, check your logs before you go doing drastic things like changing operating systems! Second, if one of your applications is showing signs of 'graphical distress', something probably isn't all good with your graphics subsystem. Third, don't blame an entire distro for a single driver's mishap! Fourth, Nouveau is good, but it's not perfect, so don't imagine it can never produce strange results (though this is the first time in many years it has for me and my multitudinous and varied computers).

And there's just one 'outstanding issue' here, too: do I revert back to Debian Testing (which I was enjoying before I unfairly lost my temper with it!)? Or do I stick with Fedora 29 because it's now installed and seems to be working fine??

I suspect I'll stick with Fedora for a while, just because I've done too many installations of late! But watch this space…

2019/03/25 19:07 · dizwell

Clementine Scrobbling Fixed

I have stumbled upon a fix for Clementine's inability to scrobble to which I reported earlier. It turns out to be a problem with Firefox, not Clementine: I mentioned last time that the error reported seemed to indicate that was replying to Clementine's authorisation request in plain http when secure https was expected. This was close! In fact, explicitly do use http for this authorisation process and it's Firefox's built-in attempts to upgrade the connection to https that's causing the problem.

So the fix is to temporarily stop Firefox attempting to upgrade to https all the time. This is done in the about:config page; search for security.csp, as shown here:

The first option shown (security.csp.enable) is the one which, if enabled, causes this 'escalate to https' behaviour (since the “csp” in its name stands for Content Security Policy). So double-click it to flip to 'false' and then try your Clementine↔ authorisation process again:

As you can see, Clementine is now registered and happy with its connection to That done, you should double-click the “security.csp.enable” item in about:config once more to flip it back to being enabled: using secure http rather than its insecure cousin is something you probably want to do more often than not.

2019/03/24 09:49 · dizwell

Debian Blues...

So, Day 1 with a fresh Debian Testing install. It has completely locked up my PC three times thus far: at this point, I'm thinking there might be something wrong with my PC! No logs to help me out, of course: just sudden and unpredictable system freezes requiring the use of the power switch to resolve.

Also, this is a bit of a show-stopper:

Clementine has long been my music player of choice and it has always been able to 'scrobble' details of the music I play to the website. Only now, it can't! The error message you see there implies that is sending a partially plain http response when a secure https message is expected, which would make it's fault (I guess). On the other hand, I did find a report which suggested that Debian itself might have removed things that break this particular feature.

In any case, happy though I am with the ease of setup of this particular Debian installation, no scrobbling is a deal breaker… and I've prepared a Fedora KDE live USB to test things out on instead. If it scrobbles, it's replacing Debian. :-)

Updated to add: the live USB of Fedora doesn't include Clementine, but it's easily installable… and once it's running, it can't scrobble either. It's clearly a problem with this version of Clementine, rather than a Debian or Fedora issue, therefore. Debian can thus stay (at least until the next unexpected system lock-up)! Meanwhile, I need to find an alternative, scrobbling music player for KDE… (I shan't hold my breath).

Further updated to add: The problem isn't Clementine, but Firefox's built-in security mitigations. A description of how to fix Clementine's inability to be authorised with is to be found here.

2019/03/24 09:30 · dizwell

Desktop Woes (Part #94)

Slightly over two months ago, I installed OpenSuse Leap 15 as my main desktop operating system. I managed to tweak it to be the way I liked and it has been a mostly happy experience since.

But not entirely.

Some bugs appeared from time-to-time, for example. Mostly transient and of so little real consequence that I didn't make a note of them and can't, therefore, now describe what they were particularly.

But then a week ago, something much more problematic started happening and hasn't really stopped: anything to do with Dolphin (the file manager) would go e x t r e m e l y … …. s  l   o    w     l      y. To the point where the desktop would effectively hang for tens of seconds on end, with mouse-clicks doing nothing until suddenly doing everything at once. Copying a 1GB file to my file server became a 'start it and come back after dinner' affair.

I couldn't explain it, and still can't. All my PC's hard disks are solid state; the link to the file server is gigabit ethernet. Nothing is running out of space; all SSDs have been trimmed. There's neither rhyme nor reason to it, other than the fact that I have continued to apply updates to the OS as they've been produced (perhaps thereby introducing instability: constant updates are something I really need to get out of the habbit of doing!

I've put up with it for a week because I hoped it would resolve itself, but after a week, I thought it was time to bite the bullet and replace OpenSuse Leap 15 with something less problem-prone. The great distro hunt of 2019 therefore began!

In searching around for a suitable replacement for OpenSuse 15 (which, it turns out, has a bit of reputation for being a tad buggy), I made some brief notes from assorted test installs I performed onto a spare (and somewhat sacrificial!) laptop. I reproduce them now, verbatim:

  • Kubuntu wireless network keeps asking for password, no matter how many times I supply it
  • Debian 9.8 Stable -incredibly old software (eg, LibreOffice back at version 5.x etc)
  • Debian testing - No live environment, but easy install. Can't use wireless network during install (no firmware and cannot install it by presenting a second USB with relevant file). This wouldn't be an issue on a desktop without wireless networking, of course.
  • Zorin - looks incredibly childish. Would not be happy long-term with this look-and-feel.
  • Mint - no KDE version at all these days, and I'm not touching MATE, and dislike Cinnamon. Non-starter.
  • Fedora - not keen. Too bleeding edge. Want something less prone to breakage.
  • KDE Neon - Same as Kubuntu in that it constantly re-asks for wifi password, even though I've supplied it a zillion times. Also missing most software out-of-the-box. Nothing to distinguish it otherwise.
  • Gecko. Got the STATIC plasma version. Boots live (unlike 'real' OpenSuse), but is extremely slow to do so. So laggy when it finally finishes booting that it's practically unusable. Tried again using USB3 instead of USB2, but speed is still poor. Software reasonably modern (LibreOffice, for example, though 'real' OpenSuse is up to KDE continually prompting for wifi password even so, just like with Kubuntu and Neon.

One of the common themes there is KDE forever asking for a wifi password. That seems to be a widely known problem, too! Unfortunately, I couldn't really find a fix that applied to me in a live session, other than to 'save the password for all, unencrypted', which seems a bit of a blunderbus approach to things.

Anyway, long story short: none of these distros seemed perfect, but the least bad one, I think, is probably Debian Testing. Debian Stable is way too out-of-date, software-wise, for my tastes, but Testing is pretty much as up-to-date as you could ask for. Every piece of application software I require seems to be readily available in the standard repositories, too. It's KDE implementation is pretty vanilla and thus nicely customisable. Of course, it's essentially a Beta version of what will eventually be Debian 10 …and running beta-quality software is not exactly my cup of tea. But, reading around the place a bit, it seems that Debian Testing might be a good deal more stable than many other distros' stable releases!

This weekend, therefore, I shall be backing up my main PC with a bit of rsync magic and a spare USB drive and then wiping the lot and starting afresh with a brand new Debian Testing install. We'll see if this can make it to the middle of Summer, at least!

2019/03/23 13:18 · dizwell


We have just returned from a short break in Leipzig, formerly the home of Johann Sebastian Bach. It was something of a music pilgrimmage for me, though we found time to do less music 'sights', such as the immense (and immensely impressive) Völkerschlachtdenkmal, a memorial to the dead of the Battle of Leipzig in 1813. I hadn't even realised there was a Battle of Leipzig then, but it turns out to have been the largest battle ever fought by mankind up to that point and sealed the fate of Napoleon, who abdicated shortly thereafter.

Anyway: I have to say I was a bit disappointed in the Bach side of things. There is certainly the Tomaskirche (pictured), where Bach was Director of Music for the last 27 years of his life. We went to a service there, which was moving enough. The church has two organs, JSB's grave, a memorial window to him and an excellent continuing choral tradition. Except the organs are relatively modern and definitely wouldn't have been played by Bach; the church interior was renovated extensively throughout the 20th Century, so that it looks nothing like what Bach would have known; and we're not even quite sure if the contents of the Bach grave are actually of Bach and not some random other gentleman. Bach was actually buried at St. John's, which was destroyed by bombing in WW2, so what were thought to be his remains were moved to the Tomaskirche in 1950 -but the identification of the St. John's grave as Bach's relied on 'folk memories' of him having been buried in a certain location.

Meanwhile, Bach also ran the Nicolaikirche, which was just a hundred yards or so from our hotel. It had its interior completely re-done during the late 18th Century in fantastic neo-classical style -meaning that it too bears no relation to anything Bach would have seen, no matter how splendid it looks today.

So we drove to Eisenach, Bach's birthplace. There, the Bachhaus is the place where Bach grew up until he was about 10. It is full of furniture from the mid-18th Century -except none of it was actually owned by the Bachs. The house, though, is as he would have known it -except for the minor detail revealed by one display photograph, of the morning after an American bombing raid in 1944 -namely, that the building was extensively damaged and thus what you see today is, mostly, a fairly modern repair job.

Back to Leipzig: the Bach Museum opposite the Tomaskirche is well worth an extended visit. I think we spent the best part of three hours in there, which is a bit of a record for us and museums of any sort! At one point, their guided audio tour invites you to look out of a window to a place where the Thomas School that Bach worked in (and composed in) would have been. Why isn't it there now? Because the Mayor of Leipzig decided to demolish it.

Yup. Just like that, in 1902, the place where Bach composed some of the most glorious works of music the world possesses was demolished. They managed to save a door (which they transplanted to the Eisenach Bachhaus museum).

So, sadly, I came to the conclusion that Bach isn't really in Leipzig anymore (unlike, say, Britten in Aldeburgh: go to that part of the Suffolk coast and Britten's presence is still real, tangible and immediate). There are some places he would have wandered, some buildings he would have known -but they mostly don't bear any resemblance to what he would have seen. Some of the most important places he lived and worked in don't exist. Even his grave might not be his.

I came to the conclusion that the only substantial, real monument to Bach these days is his music -and after learning about the Battle of Leipzig (some 60 years after his death), with thousands of Napoleon's troops camping in the town in a cold October, with their tendency to burn anything made of wood or paper to keep warm, I'm rather more surprised than I was that so much of Bach's music has survived the predations of time!

It was a flying visit, of course (three days), so no time to visit Weimar, Arnstadt, Mühlhausen, Köthen or the many other places in that corner of Germany that Bach would have known and visited or lived in. Perhaps the presence of Bach is better felt in those other places? Future visits may tell me!

I nevertheless enjoyed Leipzig a lot. It just wasn't the 'Bach lives Here' memorial I'd hoped to discover there -which probably says more about the level of my expectations than anything else.

2019/02/24 11:27 · dizwell

<< Newer entries | Older entries >>

wiki/blog.txt · Last modified: 2018/12/12 14:06 by dizwell