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.
Bluecore is back, but this wasn’t necessarily good news for me. The current situation is a bit complicated, but it can be summed up like this: my father (who supposedly gave me rather than lent Reicore) wants a laptop again, and so do I. He doesn’t need graphics or CPU power, but I do. Right now, Reicore barely fits the bill even if it works better than Bluecore in practice thanks to the extra 100 Hz of clock frequency and not suffering from Bluecore’s mysteriously subnormal I/O performance.
The most optimal solution for us is that we buy a new laptop for me and I return Reicore to its original owner. The only problem with this is that I have even more special needs: I have to run Linux.
And I have a goal: I want to own a piece of NVIDIA hardware.
While I could easily buy the components to build a new desktop machine with the same money, this would not be a good investment now that I’m primarily a laptop user. My poor desktop machine, Blackcore is suspected of having an unstable PSU and may have more internal components damaged than it’s healthy for an expensive graphics card — until now Blackcore has been running with its utterly shitty (even on Windows) VIA Unichrome Pro IGP.
For the purpose of saving electric power while on batteries (or not, global warming and all that crap) computer hardware engineers have come up with hybrid configurations in which there’s a low-power IGP serving as front-end for a beefier discrete GPU that activates whenever it’s deemed to be required for heavy tasks. NVIDIA calls this “Optimus.”
NVIDIA Optimus is not officially supported in Linux, and won’t be, at least for a while.
Unsupported solutions with NVIDIA sound very risky to me (temporary /usr bomb aside) after witnessing the possibilities of supported ones with AMD/ATI. Besides, it seems that to get Optimus to work with Bumblebee it’s necessary to use a wrapper for pretty much every application one wants to use. That isn’t bad per se, however I’m not sure I’ll be able to boast about running Linux and Windows/Wine games like that.
NVIDIA’s official statement on the matter makes me think of their leaders as vile and smug sadists who look down on poor mobile Linux users who pay for their shit. I personally don’t feel so keen on purchasing hardware made by people like that, but it’s a well known fact that NVIDIA basically owns the consumer graphics market nowadays, truly rivaled only by AMD.
Yet, I’m not sure I want to buy laptops with AMD ATI GPUs again after all that I went through with Bluecore’s Radeon HD 3200 on Linux.
After playing around with Debian “wheezy” and getting fed up with X.org 1.10.x, I decided to go back to Debian stable — but not without trying downgrading to X.org server 1.9.2 from Debian Experimental 2010-11-31 first!
It turns out that yes, most of the slowness and pre-paint garbage were caused by the X.org server alone. Sadly, the intermittent shadow glitches are seemingly inherent to KDE SC 4.6 and not to the graphics server.
Annoyed and without the required willpower to file bugs and wait for things to be magically fixed in a few months, I burned a Grml live CD from an ISO I downloaded for no particular reason at all about a week ago (!) and embarked on a journey to wipe out my root file system and restore Squeeze from the pre-ugprade backup in my external hard disk.
It was a successful mision, barring the ensuing breakage caused by the inconsistent versions of GRUB found in /boot and the disk’s MBR.
Whoops.
One chroot and grub-install and update-grub later, Reicore was running Debian GNU/Linux 6.0.1 again, at last. In total, I spent around an hour on the restoration procedure. Cheap.
While it’s true that in previous occasions I have switched to Debian testing awaiting the worst to happen to my computer and at the end it’s all been for the better minus the unavoidable annoyance of having to rebuild some of the software I run without the blessings of a package manager, this time the switch from Debian GNU/Linux 6.0 “squeeze” to “wheezy” (current Testing) surpassed my expectations.
I knew that something would go wrong but I expected it to be a temporary issue of the kind “oops, packager screwed up this build, uploading a fix to Sid shortly”. However, for all I know it’s a more complicated issue that just hit me in the face, and it’s called X.org server 1.10.
Stable uses X.org server 1.7.7, which is well tested and stable and worked well with my hideous mix of newer libraries from upstream (Mesa and libdrm from git master, xf86-video-intel 2.15.0) and in fact provided top-notch performance despite its age.
Some time around the end of 2010 while I was still using Bluecore, I switched to X.org 1.9.x from Experimental, of all things, and didn’t cause any problems with my ATI R6xx-based configuration. I was an idiot and switched to Debian testing now based on my previous experience with X.org 1.9.x instead of considering that the second version number is not attached to bug fixes but features. (A Wesnoth developer is supposed to know better, I know. I’m an idiot and I deserve this.)
Now the jump from Debian Stable to Testing was particularly rough because it’s left me swamped with a lot of bugs that are difficult to describe and leave me in the uneasy position where I’m unable to discern exactly what I should report and to whom.
Following the switch, I restarted X without rebooting and logged into KDE SC 4.4, noticing some annoying issues:
Kwin’s compositing became glitchy, with menu shadows being partially or completely missing at random.
Huge black rectangles or random garbage lines started appearing in place of popup menus or combo box popups for an instant; while the menus/popups are correctly drawn at the end (bar their shadows) the effect is pretty nauseating.
Cairo/Gtk2 applications’ performance went down the sink with compositing enabled.
Frogatto and other GL clients no longer run at near max framerate when compositing is enabled. (Uncannily, this also affects Wesnoth, a pure-software SDL client which I previously had to run under a compositing WM to make it playable at all on Bluecore!)
That was with X.org server 1.10.1. In rage, I grabbed version 1.10.2 from Sid, and KDE SC 4.6. Neither solved it.
I’d like to blame the X.org server itself since using Mesa, libdrm and xf86-video-intel from Debian did not help either. Neither did switching from Linux 2.6.38.8 to 2.6.39.1. All signs point to an issue that’s completely out of my control as a user. To make sure this was the case, I asked Ivanovic in the Wesnoth devs IRC channel about it. For the record, he uses Gentoo and the open-source Radeon stack on an ATI R6xx family GPU, while here I use the Intel stack on a GM45 IGP.
Me: are you using X.org server 1.10.x and KDE SC 4.6 there? do you see some garbage beneath the areas where a window will be drawn when compositing is enabled and very awful gtk2 drawing performance?
Me: (garbage that goes away once the window and its shadow are actually drawn)
Ivanovic: no idea about gtk2 drawing performance
Ivanovic: but yeah to the rest
The drawing glitches are only slightly more bearable when using QtCurve in place of Oxygen and Oxygen-gtk. Using Fluxbox helps with the Cairo/Gtk2 performance loss (which impacts GIMP hard) but not with the menu pre-paint garbage glitch, which seems to not be tied to any window manager, Gtk2 engine or client in particular.
So yeah, I got KDE SC 4.6 as I wanted. Is it an improvement over 4.4? Perhaps — whatever Kwin optimizations have been done in the mean time are pretty much irrelevant right now. Plasma is very dependent upon a graphics server that does shit right, and this is not one of those right now. The new (4.5?) notifications are nice, though.
Of course I really regret the idea of switching to Testing at this point, but I somehow can’t bring myself to nuke it and restore Stable from the pre-upgrade backup snapshot that I still have in my external hard disk. Perhaps I am masochist after all, or I have hopes that this will be solved in the next version of whatever component regressed so hard. Just… don’t try this at home!
Sooner than expected, I was notified that Bluecore had been repaired and was awaiting to be retrieved in the support center. Thanks to my never-ending laziness, however, the retrieval did not take place until yesterday.
The verdict was that the screen had to be replaced.
A big problem with this is that I still see the same gray stains beneath the screen’s outer layer that were there back in February the last time I used Bluecore, around the top left corner of the panel, which brings up the question, what did they mean by “screen”?
Whoever did the repairs or testing managed to boot and properly shutdown Linux several times, so my logs indicate that the first successful boot (resuming from hibernation) took place around 15:30 UTC-04:00 (+DST) on April 28th. I’m glad that they figured out how to turn it off from the KDE display manager instead of resorting to wild button pushing.
Since the repairs were effected under an “extended warranty” plan from the store at which Bluecore was purchased, the only mission of the tech support people was to make Bluecore boot again, so everything else (fan, keyboard, etc.) is still in the same crappy conditions, except for the touchpad buttons — oddly enough, the right button is no longer hyper-sensitive to touch and works correctly.
I’d love to know exactly how a screen replacement fixed the laptop or whether it is really possible and valid to replace all display components bar the outer transparent material layers with the aforementioned stains.
Bluecore is now officially dead, and only a miracle could bring it back to a usable state. During the next week I’ll be taking it to technical support, so the current condition will hopefully be temporary.
Some days ago, I came up with a joke in ##shadowm regarding a hypothetical “Reicore” laptop, which would have some awesome NVIDIA GPU and a quad-core processor. This is most likely not going to happen, yet I have reused the computer name on my new, temporary laptop, which used to belong to my father and was, in fact, bought exclusively for his use during 2010.
1. Describing Reicore
Reicore is a fairly decent HP Pavilion dv4-1624la with 4 GiB of RAM (like Bluecore after an upgrade), 500 GB hard disk (as opposed to 250 GB) and an Intel Pentium T4300 dual core processor, which supports the AMD64/Intel64 instruction set — in fact, it came with Windows 7 Home Premium x64 preinstalled. Since its CPU is optimized for mobile usage, it doesn’t have some newer-generation assets like the Intel VT-x technology, which is essential for full-fledged hardware virtualization with KVM or VirtualBox. This is a major loss for me, since I doubt I’ll be able to achieve the same performance with Windows XP SP3 on a VM on Bluecore here.
(My Windows XP SP3 VM had been used for production purposes twice, during the development of Wesnoth RCX 0.1.x.)
This laptop has an integrated graphics controller from Intel’s Mobile 4 line-up as well, which is nonetheless decent enough for running software like Frogatto along with a composited window manager, in this case Kwin from KDE SC 4.4.
The LED-based display panel leaves much to desire though, as I can clearly see the LED grid beneath the screen when it’s active, no matter what colors are being visualized.
2. Choosing and preparing a Linux distribution for installing
The operating system I chose to install was Debian GNU/Linux 6.0 a.k.a. Squeeze, using a DVD snapshot of the Testing distribution from December 2010, which I later upgraded to current Stable. I had downloaded that snapshot of the amd64 builds along with a 32-bit x86 one I used on Blackcore for the sake of having a backup Linux system. The amd64 DVD image had seen no use until the night after Bluecore’s death, during which I rescued it from my awesome external 2 TB hard disk, as part of the last backup tree made from Bluecore’s Linux installation.
This decision makes Reicore the fourth machine on which I have installed Debian. Funnily enough, in all four cases I have not had a Stable snapshot handy, and have had to use Testing instead.
The actual preparation of the physical disc for installing Debian involved a lengthy and complicated operation involving Blackcore, Greycore, the backup hard disk (“multi”) and a 16 GiB USB pendrive (“UTIL_Q”).
Greycore has been running Debian Lenny (oldstable) since the last time I used it around the first week of January 2009, and thus has no Ext4 support.
The Squeeze DVD image was stored both on Bluecore (inaccessible) and the backup HDD, the latter consisting of a single Ext4 partition.
Blackcore runs Windows XP SP2 and Debian Squeeze, so it does have Ext4 support. The DVD drive, however, turned out to be defective and cannot burn DVDs.
Greycore, despite being in a miserable state, still has a functional Linux system and a DVD drive.
After juggling a 4.4 GiB ISO 9660 image around between the external hard disk, the USB pendrive and Greycore, I was ready to install a Linux OS on Reicore, deliberately wiping out Windows 7 in the process for a change.
3. Installing Debian
Installing Debian on Reicore turned out to be a quite satisfying experience compared to those I had on Bluecore (testing Lenny 2008-11) and Blackcore (testing Squeeze 2010-12). Unlike the initially Lenny-based laptop’s case, there were no hardware compatibility issues against the installer kernel; and unlike the desktop machine’s case, there is full availability of highly functional, free drivers for Reicore’s hardware in the first DVD of the distribution, without the need of installing optional firmware packages.
After finishing Debian’s installation I was greeted by a shiny Intel graphics driver with KMS and 3D graphics support, and a clean KDE SC 4.4 desktop. From this state I upgraded to the current Stable distribution.
4. Restoring from backups
Due to my painfully lazy nature, I didn’t make daily backup snapshots of Bluecore while it was still working. In my defense, I could say that transferring nearly 220 GiB of data through USB 2.0 is a royal pain in the ass!
shadowm@reicore:~$ stat /media/multi/bu/daily.0/ | fgrep Modify
Modify: 2011-01-19 18:51:34.000000000 -0300
The real losses since then aren’t very important, since all my projects are hosted in distributed repositories using Mercurial or Git, as I foresaw the possibility of theft or damage to the laptop. The only tree with local modifications that I didn’t push upstream in time is “rei2-rei2”, corresponding to a series of Rei 2 IRC bot scripts used by the official Rei2 instance administrating the ##shadowm IRC channel on freenode.
Other losses include configuration changes, local IMAP caches, unimportant downloads and various VM state changes, including a Windows Vista VM I set up around one week ago.
The configuration changes aren’t that important either, since although I have a full snapshot with all my configuration from Bluecore at that time, I decided to start fresh on purpose. This has unveiled some performance issues I initially attributed to Debian Squeeze’s architecture — they might have been in fact caused by the carry-over of configuration from the days of Lenny as a testing distribution on Bluecore. A rough estimate indicates that Bluecore would take around 2 minutes to boot into the KDE login screen, while Reicore takes around 30 seconds.
Last night, after shutting down bluecore and leaving it alone for hours, the BIOS boot stage failed and I had to turn it off and try again. Today that’s not the case, and bluecore won’t boot.
I do not understand why is this, or what could be the cause, since in both opportunities the laptop went through a successful hibernation cycle from Linux. There doesn’t seem to be any relation to the AC adapter or battery status, since I tried turning it on with different power source combinations. The GPU and display screen don’t come up, and the keyboard doesn’t work — the only visible indication of (in)activity is the two blinking Caps Lock and Num Lock LEDs, which I saw before when Linux wouldn’t resume from suspend-to-RAM properly back in the 2.6.26 days, two years ago.
This means that my files, configuration and software are currently inaccessible and unusable, save for a ~2 weeks old complete system backup on my 2 TiB external hard disk, which I could use with the machine I’m using right now, blackcore. There are various problems with this desktop computer, however, that make it barely usable with Linux. In particular, GL applications crash X.org thanks to VIA’s nearly nonexistent IGP support, and there’s nearly no means of 2D acceleration.
The current plan is to take bluecore to the technical support people. Hopefully they’ll prove their worth in money this time.
Due to general laziness, it took me a long while to research how to make my EPSON Stylus TX105 multifunctional inkjet printer work natively on Linux. I got one of the steps done, arguably only because it was relatively easy to do on a Debian system without messing things up too much — I got the printer piece working on May 2009 with Debian GNU/Linux 5 “Lenny.” Ever since then, I’ve stuck with Windows Vista for scanning and Linux for printing.
This is not the case anymore, now that I’ve learned better. This is one of the many ridiculous things one may need to do when stuck with old hardware that doesn’t work on Linux out-of-the-box. In comparison, I recently installed a Brother HL-2140 laser printer by just plugging the USB cable and waiting for KDE to tell me that the device was configured and ready. Amazing.
So, without further ado, here’s my personal recipe for making the TX105 work natively on Debian GNU/Linux 6 “Squeeze.”
I have just rebooted from a 2.6.35 kernel to 2.6.34.2 in order to have the ability to hibernate bluecore with Tux-on-Ice again. However, the laptop acted up after the warm reboot as a consequence of running Linux in KMS operation mode, apparently. The greatest sign of doom: the Giant Blinking Cursor of Doom.
It’s normal for these HP laptops to display the text-mode blinking cursor for a bit after the BIOS splash screen, right before transferring execution to the first available boot medium. The cursor’s size is similar to Linux’s or MS-DOS under a default configuration with any generic VGA-compatible video adapter. In this transition state, the bold-white cursor blinks a few times at the top-left corner of the empty black screen, before changing its color to the normal text terminal white when GNU GRUB takes over.
However, whenever the AMD ATI Catalyst drivers lock up the laptop and I perform a warm reboot using one of the Magic SysRq sequences, the laptop doesn’t get past the system initialization code and after the BIOS splash screen disappears, instead of the usual bright blinking cursor, an abnormally large and wide white blinking cursor appears as the computer gets stuck forever.
I had not seen this occur after running with the open-source KMS drivers before, but I guess it might indicate I own a faulty GPU or motherboard.
Today, while having breakfast at a subway station, I stumbled upon a weird case of the laptop’s battery going crazy again.
As you know, Bluecore’s battery basically dropped dead after an unfortunate accident with charging cycles, but now the outlook has slightly improved after its capacity increased as a consequence of booting the laptop on battery power this morning.
$ acpitool -B
Battery #1 : present
Remaining capacity : 1504 mAh, 66.20%
Design capacity : 9000 mAh
Last full capacity : 2272 mAh, 25.24% of design capacity
Capacity loss : 74.76%
Present rate : unknown
Charging state : charging
Battery type : rechargeable
Model number : 25 mAh
Serial number : Primary
(The last two information fields and the design capacity are bogus as usual.)
The BIOS didn’t warn me about charge capacity this time either, nor after plugging the AC adapter in at the university’s central library, so there’s something clearly odd about this. I didn’t wait for the battery to discharge at the subway and left it at 66% before proceeding to charge it again now, so let’s see how this goes in the future. I might be able to squeeze some life out of this deteriorated power source before sending off Bluecore for maintenance and repair.
