bkil vs. programming

I had this post in draft for a long time now, however it is evergreen. Just consider the recent exploits  focused on RAM leakage. Although, do note that ECC by itself can't give 100% protection against row hammer, so it is only loosely related. An excellent empirical work has been published in 2009 regarding DRAM Errors in the Wild: A Large Scale Field Study . " About a third of machines and over 8% of DIMMs in our fleet saw at least one correctable error per year. " - analysis by  James Hamilton " Besides error rates much higher than expected - which is plenty bad - the study found that error rates were motherboard, not DIMM type or vendor, dependent. This means that some popular mobos have poor EMI hygiene. " - analysis by ZDnet Note that such an event plainly translates to faults on non-ECC machines. So despite the fact that human error is much more probable, it is not unlikely at all that you encounter bit errors in everyday life. Consider the foll...

A friend called for help when one of his computers failed a distribution upgrade. The upgrade was started from 12.04 LTS via the GUI. I'm not sure which version he had previously, but the standard update procedure stopped midway. The upgrade could not be resumed, so manual intervention was needed. I'm not sure whether the issue was caused by a bit error in memory, an out of space issue or by something else. Unfortunately, I don't have the error messages at hand. The solution boiled down to doing the following tedious steps: apt-get update apt-get dist-upgrade do-release-upgrade dpkg --configure -a apt-get -f install mcedit /var/lib/dpkg/status # delete section which is complained about mktexlsr # note down errors updmap-sys --synthwithtrees # note down errors mcedit /etc/texmf/... # remove invalid map file lines updmap-sys apt-get install ubuntu-desktop

It worked easily with the VESA driver, however the legacy mode tables don't have any of today's fancy aspect ratios. OpenChrome, the default driver, just gave a blank screen. Reviewing Xorg.log revealed an abort by signal 11, segmentation fault (segfault). Let me share the process of fixing it. I went on to generate a new xorg.conf for editing by Xorg -config xorg.conf.new . I then proceeded to add as much fail-safe options as possible from the driver documentation : Section "Device" Option "ModeSwitchMethod" "legacy" # or blank & segfault Option "SWCursor" "true" # unsure Option "EnableAGPDMA" "True" # unsure Option "NoAccel" # or starts to lag after some time Identifier "IGP" Driver "openchrome" BusID "PCI:1:0:0" EndSection Section "Module" # unsure Disable ...

I had to revert from compressed BTRFS to Ext4 on my tiny netbook partition, as it wasn't playing nice. That's a pity, as Ubuntu is highly compressible and compression didn't slow it down. The system occupied less than half of the space and reported such, however when I was starting to fill up the space, it complained of insufficient space. Probably because of metadata allocation. As I didn't want to reinstall the system, I went the more costly route: * I've rebuilt the partition in an image on ext4, * copied over the data * copied the initrd image from another computer of mine with the exact same system, both were updated at the same time - otherwise it couldn't read the new kind of partition * adjusted grub settings * reinstalled grub (was extra painful when I attempted to do that inside an image..).

I had a similar problem as described below on Ubuntu 12.04 and found that inserting saa7134-dvb into /etc/modules.conf did the trick for me too. It's interesting though that it has been working fine before. I did recall seeing this issue once or twice, but this time it did not seem to have been resolved by multiple cold booting by itself. http://linuxtv.org/pipermail/linux-dvb/2008-June/026775.html [ 43.162971] tda1004x: timeout waiting for DSP ready [ 43.202914] tda1004x: found firmware revision 0 -- invalid [ 43.202918] tda1004x: waiting for firmware upload... [ 48.675012] tda1004x: Error during firmware upload

The following didn't work by itself: How can I build 64 bit Qt on a 32 bit system ? The solution was to simple set the write-protect flag on the exe files under qt/bin (on moc, jom, etc.).

You can remove yourself by following this guide. * Invite your address with a +tag added or different capitalization or dots * Click on the confirmation link * Add owner rights to this account * Remove the plain account * You can never log in again afterwards

I only gave a quick shot at the beast, but it did work out pretty well. It didn't work out of the box, however. kernel: 2.6.31.5 (Puppy) hardware: IBM ThinkPad T42 error message: initrd boot error "pup-431.sfs not found" solution: remove 'pmedia=usbflash' from syslinux.cfg other remedies to try: kernel command line: add 'acpi=force' and 'pci=noacpi' BIOS: turn off Fast Boot