Giving Debian Wheezy another whirl, and an unpleasant surprise from Reicore

The last time I tried to switch from Debian stable to testing I was hit by a disease known as X.org Server 1.10, and more specifically, fd.o bug #31017, which made my KDE experience less than worthwhile, to say the last. The solution I devised was not particularly productive either.

However, X.org Server 1.11.1 hit Testing a while ago, and it’s what I am using right now — I successfully switched to “wheezy” again, today, and this time it would seem a massive rollback won’t be required, since the aforementioned bug is finally fixed.

I don’t think I can claim the upgrade was smooth, though.

While the old apt-get update and apt-get dist-upgrade spell did work, in theory, I encountered a few issues in the process, both before and in middle of the upgrade.

  1. Debian-multimedia.org breaks upgrades, but I think I knew this beforehand from a mailing list post somewhere. The solution was to remove/install and downgrade several packages before proceeding. Luckily, I had a list of packages I pulled from this repository in the synaptic logs to spend as little time as possible cleaning up the dmo mess. Recent developments indicate that using dmo in the first place may have been unnecessary: firstly because some relevant packages can be found in the authentic squeeze-backports repository; secondly because YouTube may have broken Ogg/Theora file processing again.
  2. The upgrade failed in middle of the dist-upgrade run because of a conflict between manpages-dev and libaio-dev (Debian bug #642310). Too lazy to do any web browsing from a text terminal, I simply removed libaio-dev, waited for some packages to finish installing, and ran dist-upgrade again to resume.

Since #1 is mostly my fault, I imagine most people would only need to take care of #2, if at all. I’ll go out on a limb and say that third-party repositories in general are evil, though.

For some reason I am not willing to investigate further (as it may involve some of my own modifications of the graphics stack configuration), the switch to Debian wheezy caused a Gallium3D driver to be used by GL clients instead of the Mesa Classic DRI2 driver for Intel 965-compatible chipsets. I cannot fathom why this happened and why hardware acceleration still seemed to work in some fashion regardless of the ‘llvmpipe’ label, but it’s not like Gallium3D’s architecture is something I could even begin to understand.

OpenGL vendor string:                   VMware, Inc.
OpenGL renderer string:                 Gallium 0.4 on llvmpipe
OpenGL version string:                  2.1 Mesa 7.12-devel (git-440224a)

Above you can see a portion of KWin’s stderr I was examining while trying to figure out why GL compositing caused an instant segmentation fault. The renderer string triggered the alarm — it is normally “Mesa DRI Mobile Intel® GM45 Express Chipset” with my custom Mesa 7.11 builds.

Since Debian also uses Mesa 7.11, I’d guess this is all my fault — the version string above is utterly wrong, now that I read it again. Nonetheless, fixing this mess was trivial enough by use of the old fashioned method of making a new Mesa build of my own and installing again to undo wheezy’s changes. (If any potential Debian testing user is reading this, the general recommendation is to not be a lazy bum like me, and use checkinstall or something instead to keep track of experiments with upstream versions of libraries — right now it seems I’ve got Mesa 7.7, 7.11 and 7.12 mixed up.)

KWin works just fine with the correct driver enabled, and unlike the last time I tried wheezy, GL clients run with no noticeable performance regressions.

While trying to diagnose a logout issue that I later solved by setting KDE SC 4.6’s session management options to start a new session on logout (to discard the KDE 4.4 data), I found myself in need of an emergency reboot which shed some lights on my longstanding hard disk noise issues on reicore.

This happened in middle of the boot process:

[   77.423155] ata1.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x0
[   77.423159] ata1.00: irq_stat 0x40000008
[   77.423163] ata1.00: failed command: READ FPDMA QUEUED
[   77.423168] ata1.00: cmd 60/00:00:e8:e6:30/01:00:02:00:00/40 tag 0 ncq 131072 in
[   77.423169]          res 41/40:00:9b:e7:30/00:00:02:00:00/40 Emask 0x409 (media error) <F>
[   77.423172] ata1.00: status: { DRDY ERR }
[   77.423174] ata1.00: error: { UNC }
[   77.425378] ata1.00: configured for UDMA/100
[   77.425393] ata1: EH complete
[   80.370085] ata1.00: exception Emask 0x0 SAct 0xd SErr 0x0 action 0x0
[   80.370089] ata1.00: irq_stat 0x40000008
[   80.370093] ata1.00: failed command: READ FPDMA QUEUED
[   80.370099] ata1.00: cmd 60/00:18:e8:e6:30/01:00:02:00:00/40 tag 3 ncq 131072 in
[   80.370100]          res 41/40:00:9b:e7:30/00:00:02:00:00/40 Emask 0x409 (media error) <F>
[   80.370103] ata1.00: status: { DRDY ERR }
[   80.370105] ata1.00: error: { UNC }
[   80.372209] ata1.00: configured for UDMA/100
[   80.372221] ata1: EH complete
[   83.295268] ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0
[   83.295274] ata1.00: irq_stat 0x40000008
[   83.295279] ata1.00: failed command: READ FPDMA QUEUED
[   83.295289] ata1.00: cmd 60/00:00:e8:e6:30/01:00:02:00:00/40 tag 0 ncq 131072 in
[   83.295291]          res 41/40:00:9b:e7:30/00:00:02:00:00/40 Emask 0x409 (media error) <F>
[   83.295300] ata1.00: status: { DRDY ERR }
[   83.295302] ata1.00: error: { UNC }
[   83.297443] ata1.00: configured for UDMA/100
[   83.297454] ata1: EH complete
[   86.228784] ata1.00: exception Emask 0x0 SAct 0x7ff SErr 0x0 action 0x0
[   86.228788] ata1.00: irq_stat 0x40000008
[   86.228794] ata1.00: failed command: READ FPDMA QUEUED
[   86.228799] ata1.00: cmd 60/00:10:e8:e6:30/01:00:02:00:00/40 tag 2 ncq 131072 in
[   86.228800]          res 41/40:00:9b:e7:30/00:00:02:00:00/40 Emask 0x409 (media error) <F>
[   86.228803] ata1.00: status: { DRDY ERR }
[   86.228805] ata1.00: error: { UNC }
[   86.230895] ata1.00: configured for UDMA/100
[   86.230919] ata1: EH complete
[   89.202623] ata1.00: exception Emask 0x0 SAct 0x780 SErr 0x0 action 0x0
[   89.202627] ata1.00: irq_stat 0x40000008
[   89.202631] ata1.00: failed command: READ FPDMA QUEUED
[   89.202636] ata1.00: cmd 60/00:40:e8:e6:30/01:00:02:00:00/40 tag 8 ncq 131072 in
[   89.202637]          res 41/40:00:9b:e7:30/00:00:02:00:00/40 Emask 0x409 (media error) <F>
[   89.202640] ata1.00: status: { DRDY ERR }
[   89.202642] ata1.00: error: { UNC }
[   89.204773] ata1.00: configured for UDMA/100
[   89.204786] ata1: EH complete
[   92.154128] ata1.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x0
[   92.154132] ata1.00: irq_stat 0x40000008
[   92.154136] ata1.00: failed command: READ FPDMA QUEUED
[   92.154141] ata1.00: cmd 60/00:10:e8:e6:30/01:00:02:00:00/40 tag 2 ncq 131072 in
[   92.154142]          res 41/40:00:9b:e7:30/00:00:02:00:00/40 Emask 0x409 (media error) <F>
[   92.154145] ata1.00: status: { DRDY ERR }
[   92.154147] ata1.00: error: { UNC }
[   92.156288] ata1.00: configured for UDMA/100
[   92.156307] sd 0:0:0:0: [sda] Unhandled sense code
[   92.156309] sd 0:0:0:0: [sda]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   92.156313] sd 0:0:0:0: [sda]  Sense Key : Medium Error [current] [descriptor]
[   92.156317] Descriptor sense data with sense descriptors (in hex):
[   92.156319]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[   92.156326]         02 30 e7 9b
[   92.156329] sd 0:0:0:0: [sda]  Add. Sense: Unrecovered read error - auto reallocate failed
[   92.156334] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 02 30 e6 e8 00 01 00 00
[   92.156341] end_request: I/O error, dev sda, sector 36759451
[   92.156361] ata1: EH complete

One line is particularly ominous:

[   92.156329] sd 0:0:0:0: [sda]  Add. Sense: Unrecovered read error - auto reallocate failed

Checking with GSmartControl later I discovered that the Attributes tab title in reicore’s internal HDD info window helpfully turned red, and the Current Pending Sector Count attribute also turned red, and that this attribute changed its value to a non-zero one (1) for the first time.

According to GSmartControl, I should be worried.

Strangely enough, I am not very worried. Next month I’ll probably be able to purchase my next laptop and forget about this mess, and hopefully the hard disk issue isn’t serious enough yet — plus, I have backups, and bluecore still runs.

Now that I know KDE in wheezy is usable again (yay for X.org server 1.11) there’s probably only one issue remaining to be solved: the NVIDIA Optimus dilemma.

Hardware, Miscellaneous, Personal, Software