Often on IRC I refer to my computers by their unique hostnames, which I also use to differentiate their Linux kernel configuration sets, optimized for every individual machine.
Many get confused with this because the names aren’t very descriptive of these machines, so here’s some technical background and history for every one of my technological pets.
Two days ago, my HP laptop’s battery was working perfectly fine. Then I had to unplug the AC adapter and do stuff with the laptop elsewhere, so the battery was completely discharged afterwards. Then, I charged it again, but when going to bed I unplugged the adapter again when the battery was around 50% charged.
Fast-forward to the next afternoon, when I’m going with my family to celebrate stuff, and I turn on the laptop while in the car. Linux resumes from hibernation fine, and I see my KDE desktop again, with the battery meter at 50%. I check the Wesnoth.org forums for spambots as usual, fire up my IRC client…
And then the battery meter drops to 0%, KDE warns about suspending to disk in 5 seconds, and the laptop’s front panel battery status LED starts flashing.
I assumed that the laptop had just gone bonkers like it’s done before and ignored the warnings of imminent failure. Just as I was mentioning the ongoing problem on IRC, the laptop shut down completely, as it ran out of power.
It seems that this battery has finally collapsed, since the maximum charge dropped dramatically afterwards, and even the BIOS software warned me about it on the next boot. Here’s what acpitool has to say about the poor thing:
$ acpitool -BBattery #1 : presentRemaining capacity : 704 mAh, 100.0%Design capacity : 9000 mAhLast full capacity : 704 mAh, 7.822% of design capacityCapacity loss : 92.18%Present rate : 0Charging state : chargedBattery type : rechargeableModel number : 25 mAhSerial number : Primary
(Note: Linux has always reported 9,000 mAh as the battery’s design capacity since day zero. This information is incorrect, and the correct value should be 4,000 mAh. Also note the bogus model/serial information.)
Since this is a rather critical situation, I’m probably going to buy a new battery for the laptop soon — besides sending it away for maintenance, which is in my list as soon as I buy that external hard disk drive on which I’ll be able to fit a complete raw disk image of my laptop’s HDD.
My old patched ACPI DSDT didn't work well after adding 2 GB of RAM and caused a lot of “interesting” problems, so I built a kernel without a custom DSDT to be able to work safely without hitting a “bad page.”
Last night I fetched the system's DSDT again, patched and recompiled it, removing the rules that disallow non-Vista systems to get certain info from the thermal zone. So now I have a working 2.6.33.5 kernel that can access the ACPI thermal zone again.
shadowm@bluecore:~$ taintedness.plTainted: G AA (ACPI) - ACPI DSDT overridden.shadowm@bluecore:~$
With the usual side-effect of tainting the kernel.
Today I bought and installed another 2 GB of RAM from my HP Pavilion dv5-1132la laptop while on an errand to buy a new laptop for someone else — it ended up being a HP Pavilion dv4-something in case you are wondering.
This means that I can not only run Windows 2000, Windows XP, Windows 98, OpenSolaris 2009.06 and Debian Lenny on VirtualBox all at the same time now, but I'll also be able to compile Wesnoth faster now that I can take advantage of the dual-core AMD processor without running out of RAM and getting excess swapping to disk during the build!
It didn't work quite well at first, though. Problems occurred when I started enough processes to consume over 2 GB of RAM:
BUG: Bad page state in process VirtualBox pfn:6febepage:ffffea000187b990 flags:4000000000800000 count:0 mapcount:0 mapping:(null) index:0Pid: 4323, comm: VirtualBox Tainted: G A 2.6.33.4-bluecore263-preempt-suspend2 #1Call Trace:[<ffffffff81086a48>] ? bad_page+0x102/0x115[<ffffffff810882a2>] ? get_page_from_freelist+0x3b0/0x517[<ffffffff810884f6>] ? __alloc_pages_nodemask+0xed/0x588[<ffffffff810884f6>] ? __alloc_pages_nodemask+0xed/0x588[<ffffffff810a0b2a>] ? __vmalloc_area_node+0xea/0x10a[<ffffffffa021d514>] ? rtR0MemObjLinuxAllocPages+0xd8/0x1cc [vboxdrv][<ffffffffa021d630>] ? rtR0MemObjLinuxAllocPhysSub2+0x28/0xde [vboxdrv][<ffffffffa022a7dd>] ? g_abExecMemory+0x1ddd/0x180000 [vboxdrv][<ffffffffa022ad78>] ? g_abExecMemory+0x2378/0x180000 [vboxdrv][<ffffffffa022d2b0>] ? g_abExecMemory+0x48b0/0x180000 [vboxdrv][<ffffffff8102cc1c>] ? cpuacct_charge+0x54/0x76[<ffffffffa023b2f4>] ? g_abExecMemory+0x128f4/0x180000 [vboxdrv][<ffffffffa023d28f>] ? g_abExecMemory+0x1488f/0x180000 [vboxdrv][<ffffffffa023d7bb>] ? g_abExecMemory+0x14dbb/0x180000 [vboxdrv][<ffffffffa02316da>] ? g_abExecMemory+0x8cda/0x180000 [vboxdrv][<ffffffffa0218ded>] ? supdrvIOCtl+0x1241/0x20f8 [vboxdrv][<ffffffffa021ce22>] ? rtR0MemAlloc+0x90/0xb4 [vboxdrv][<ffffffffa02152a7>] ? VBoxDrvLinuxIOCtl+0x114/0x18e [vboxdrv][<ffffffff81028440>] ? pick_next_task_fair+0xac/0x112[<ffffffff810ba422>] ? vfs_ioctl+0x23/0x93[<ffffffff810ba92d>] ? do_vfs_ioctl+0x429/0x46d[<ffffffff810aeff3>] ? fget_light+0xc3/0xe8[<ffffffff810ba9ad>] ? sys_ioctl+0x3c/0x5c[<ffffffff81001f2b>] ? system_call_fastpath+0x16/0x1b
While at first I thought it was a problem with the new RAM module itself (either that or damage on the old module, which is occupying the formerly free slot) I quickly suspected of the Linux kernel configuration instead because of several ACPI-related errors in the boot log.
reserve_ram_pages_type failed 0x6febe000-0x6febf000, track 0x10, req 0x10ioremap reserve_memtype failed -16ACPI Error: Could not map memory at 000000006FEBEE70, size 7 (20091214/exregion-180)ACPI Exception: AE_NO_MEMORY, Returned by Handler for [SystemMemory] (20091214/evregion-475)ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.TOM_] (Node ffff88013f8605d0), AE_NO_MEMORYACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._CRS] (Node ffff88013f860430), AE_NO_MEMORYACPI Error (uteval-0250): Method execution failed [\_SB_.PCI0._CRS] (Node ffff88013f860430), AE_NO_MEMORY
After running some memory test utilities and getting no problem reports I recompiled another kernel (blessed be ccache, by the way!) without my patched DSDT which I needed for getting thermal zone readings with Linux. I might have mentioned before that this laptop has a special rule in the ACPI DSDT to not allow any operating system other than Windows Vista (even the particular version) to read the temperature status.
As I suspected, all the boot errors went away after rebooting to an unpatched/untainted kernel, and right now I'm using 3678 MB of 3707 MB (damned graphics controller) without hitting a “bad page.”
I'm not sure why the patched DSDT caused this little mess, but I'll check what happens if I repatch it now, using the current “original” DSDT.
The new AC adapter died last Sunday during normal operation while the laptop was running on it with the battery at 100%. I was just about to play a game when this happened.
Luckily, I got it replaced the next day and now I'm on bluecore again. I hope this is the last time this happens.
After almost two days of wandering around the streets of the city, my emissaries located a place to buy a new AC adapter for my much beloved HP Pavilion “ATI hellspawn” dv5-1132la, and I have thusly regained access to my development environment for Wesnoth and related projects.
48 hours of using a laptop with a broken display, short-lived (8 minutes) battery, unusable touchpad buttons, different keyboard layout and outdated user config can be very frustrating, but it was a good exercise nevertheless. It's better to have a broken spare laptop running Linux (Debian Lenny before Stable) than no spare laptop or no Linux laptop at all. 😉
My laptop's AC adapter has finally died after passing out in three opportunities. I've already sent my emissaries across the city to find a spare for this thing.
For now, I'm using my old, broken Acer laptop and I won't be available for most of the time until I can use my HP Pavilion dv5-1132la again.
When I got my current HP laptop on December 2008, it was pretty nice to compile Wesnoth from scratch with 3 or 4 parallel compiler instances in less than 15 minutes, even when making -O3 builds.
Nowadays, it can take an hour to make an -O3 build with 1 single compiler instance, and parallel compiling is out of the question. In comparison, Wesnoth 1.0 can be compiled in 3 minutes and a half with 1 single instance, and much less time with -j 4.
Exactly what is wrong with this? Let's take a look at the relevant system stats and compilation settings:
-pipe -mtune=native -march=native -O3 -Wl,--gc-sections,--relaxccache=True, fast=True)-O3 obviously involves extra CPU load at compile time because of the extra optimizations compared to, say, the default -O2. Nonetheless, I know well that it used not to take this long to build Wesnoth at the start of 2009. Wesnoth's code grew a lot over the course of the year due to the introduction of the new AI framework, the new lobby and more GUI2 development. Particularly, if I run scons with -j 2 or greater nowadays, I can run out of free RAM (making Linux page everything out to swap memory) during the compilation of the AI framework.
The most likely reason for this problem is the common use of C++ templates in that code. This feature is used a lot in GUI2 as well, but the code generated by template instantiation on every object file appears to be smaller.
While building stuff from scratch should be relatively uncommon for a developer like me who also has ccache installed and enabled, very minor changes in GUI2 or the AI from other developers currently trigger a near-total recompilation of Wesnoth. I have complained a lot about this in many opportunities, but it seems that I've hit a hard wall as a consequence of Wesnoth's evolution.
An -O3 executable of the main game target can be as large as 14 MiB. An -O0 debug build with symbols nears 400 MiB, and the directory with the resultant object files (including the executable) reaches 1.4 GiB of size.
Right now I'm considering adding more RAM for other reasons — namely, running Windows XP SP3 on VirtualBox can easily starve the host if certain apps like Iceweasel or Kate are running on the latter. I've yet to see if this will help me compile Wesnoth faster. It won't magically reduce the frequency of full rebuilds, though, and that's really discouraging me from hacking the mainline engine unless it's a one-shoot patch like the one involved in the fix for bug #15902.
The alternative is getting a quad-core machine or a distcc host. The first is least likely to happen. 😐
Finally, it's January! The New Year celebrations are mostly over and fading away, and people all around the world are going back to regular business and everything should be back to normal in a few days.
I used to be fond of the Christmas and New Year celebrations as a child as I could spend time with my family and eat delicious food. That is not the case anymore, because, even if I still live with my parents, there's no longer a sense of family here and we only want to throw sharp stuff at each other. There's not much enthusiasm by the end of the year anymore, and phrases such as “Merry Christmas” and “Happy New Year” (in Spanish, though) are truly unheard of in this house. Recent disagreements amongst us indicate that this is not going to be a good year for anyone. To add insult to injury, one of our cats died in a rather tragic and violent fashion on December 22th — it's a tradition here that one or more pets must always die in December. While we have many of them, the first ones to die are those whom we are most attached to.
To mark the actual start of 2010 (as far as the Gregorian calendar is involved, of course), there was a black-out on the area about 6 minutes 7 seconds past midnight, which left us with no Internet or tap water until around 1:50 AM. What a great way to start the first day of the year.
But there's still some hope at the moment. Some days before Xmas, my creativity returned from its long, chaotic journey and my Wesnoth add-on, After the Storm (sequel to Invasion from the Unknown has seen steady progress and two new releases were published in less than two weeks. Keep in mind that this add-on had not seen any public releases for almost a year.
After the last released version of AtS (0.2.1) including 5 of 12 planned scenarios in Episode I, there has been more progress in the Wesnoth-UMC-Dev repository. Just yesterday, I finished the two-part cutscene that is the sixth scenario of Episode I, one of the most important points of the plot's development, in which two forest elves finally make contact with the desert/Quenoth elves.
I won't be able to release AtS 0.2.2 or 0.3.0 until scenario 7 and the next cutscene (appropriately named “Resolutions”) are finished, since I'd be teasing the players otherwise. However, those who are really interested on it can always check AtS out from the repository's trunk into their <wesnoth preferences dir>/data/add-ons dir and play using the latest development version of Wesnoth:
svn co https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/After_the_Storm
It's really exciting to work with several plot elements from quartex's Under the Burning Suns in new, creative manners — kind of like Fanfic production taken to a new level using the power of the GNU General Public License (version 2 or later!). Nevertheless, I am fairly sure he deliberately left much details unresolved in the original campaign, and that he'd fry us (Espreon, AI0867 and me) alive if he found out what we are doing with his story.
One week before Xmas, the Wesnoth.org forums saw another upgrade on which Turuk and I worked hard and quickly to improve forum usability by not only upgrading the codebase to phpBB 3.0.6, but also tweaking the templates, adding modifications and a couple of new forum styles to take advantage of the new features implemented by the phpBB devs in this iteration of their software. The main points were highlighted in this forum post (originally a Global Announcement).
This year should also bring us a new stable series (1.8) of the Battle for Wesnoth game itself. There are currently some problems delaying the first Release Candidate and getting us flooded with generic beta releases, but the developers in charge of them will (hopefully!) find a solution so we can get 1.8 released and trunk “thawed” soon, to work on new features and allow new code contributors to join the project. As for me, I can't wait for the new stable series — development series players seem to be scarce and the new versions of IftU and AtS are receiving little feedback on the forums because of this! I suppose Multiplayer content authors are similarly eager to get more fresh meat to play their add-ons.
I also recently talked about how I can finally suspend my laptop to RAM using Linux, and run some basic OpenGL-based software without crashing or destroying anything. That's something I didn't expect to be able to do in the near future, so the Mesa, libdrm and X.org radeon driver developers have my thanks for improving the Linux experience of those unfortunate enough to own onboard ATI graphics controllers!
In summary, as usual, a new year brings good and bad news. I guess it's up to us to take what's good and fix what's wrong. So, anyway (although I guess it's pretty much unnecessary at this point): happy New Year and have fun!
So, last Friday I finally got around to upgrade from Debian Lenny (Stable) to Squeeze (Testing), but not without facing some problems.
network-manager got restarted too early while I still needed to download more packages to finish the upgrade, I got stuck for 20 minutes trying to convince cnetworkmanager to make the wifi adapter work again until I figured out I just needed to restart D-Bus, the Linux kernel package v2.6.30-2 in Squeeze has some patches that rendered the wifi adapter completely useless after restarting, had to quickly rebuild a custom kernel to solve that, and work with Squeeze's udevd and get rid of the annoying default console bell (BEEP! — in a library, thrice), and then had to build another kernel enabling PAT support because the new X.org needs it for some reason or radeonhd gets unusably slow — phew.
It was much better than I expected and the migration from KDE 3.5.9/10 to 4.3.1 was relatively seamless; Opera 10.0 and VirtualBox 3.0.10 for Debian lenny still work fine after the upgrade, and KDE 4 didn't try to eat my /home dir, nor did I try to prevent that after all.
After a few hours of using the new desktop environment I started to like it. IMHO, rumors of KDE 4's suckiness are being greatly exaggerated now that it's at 4.3.x.
Of course not everything is perfect, and I hit a very bad bug in Dolphin, KDE 4's lightweight file manager, which turns it into a time-bomb of sorts, crashing roughly after 1 minute of use. However, that bug doesn't affect good old Konqueror and that gave me an opportunity to go "whoaaah" and "ahhhh" and "ohhhh" at the various user interface changes in this version; for example, the previews of directories are much better than on the KDE 3.5 version of Konqui — now we have actual previews embedded on the directory icons, rather than little icon overlays. IMHO such feature belongs in the realm of eye candy, but there's still a fair possibility of revealing your pr0n stash if you navigate the parent directory with this enabled. 😉
KDE 4.3's performance here is far better than what I experienced with a amd64 openSUSE-based LiveCD image using KDE 4.2.x. I couldn't know if this is because it's Debian, or because it's KDE 4.3, or because my custom kernel config rocks. 😛 Regardless, the laptop's battery still lasts almost the same as before upgrading to Squeeze — roughly 45 minutes. Of course, although I did enable some eye-candy to give radeonhd's XRender acceleration a decent work-out, I made sure that the new power management applet will turn it off when running on batteries. This is all very handy and beautiful...
But Squeeze lacks an important component for me, uswsusp, which provided some reliable work-arounds to get my laptop working fine both before and after suspending to disk (S4 power state). It is currently excluded from Squeeze due to some rather astonishing bugs, which means I had to seek other solution for suspending my pretty Linux system to disk...
And the solution in my case is the TuxOnIce patch, which surprisingly manages to bring the screen, keyboard and touchpad back to life — a feat that the kernel's built-in S4 support won't perform here. With this patch applied on top of an otherwise vanilla Linux kernel I now have a completely usable Squeeze system that supports all the hardware and software features I need.