Ben Heiskell's Blog

Follow Up on Linux Hardware Issues

2010-01-30T16:27:00.001-05:00

Fortunately, the hard drive problem seems to have been rooted in the cables. Unfortunately, after maneuvering them out of the case, I'm not 100% sure which one was causing the problem. To hopefully avoid a future problem, I moved the one I think has the issue to my internal backup drive. This is what I get for zip tying them for cosmetic appeal. Live and learn.

Life Changes and Future Plans

2010-01-26T20:18:00.002-05:00

Since this is suppose to be a technical blog, I'll keep personal details to a minimum. However, to provide some context of my absence, I believe and update is in order. I graduated from GT early December and spent the next month planning and executing a move to Norwalk CT. Last week I started a new job in with a company by the name of FactSet.

Moving on, my legacy of being endlessly haunted by Linux hardware errors continues. To be fair, I don't believe this new issue is actually Linux's fault however. One of my harddrives is performing a hard reset quite often. Unfortunately this is part of my boot partition's raid array.

I'm striping two old raptor drives using fake raid. (Yes, I know, bad idea.) Regular backups have ensured that all my data is safe. Never the less, I'm attempting to avoid having to reinstall the system. It's possible that since both smartmontools and badblocks have reported no errors, the problem is actually with a cable. Of course, it's also possible that it's a problem with the controller on this motherboard. I've already had problems with the nvidia controller on this board.

Since that will probably warrant a later blog post, I'll instead discuss a future project that I'm working out with a close friend of mine, Treijim. We're planning a custom application for a fictional role playing forum of his. Most of the ideas that are currently on the table are actually posted on his blog. I'm currently in the process of exploring ER diagrams and prototype mockups.

In parallel, I'm searching for a good web framework to develop on. Although I'd much rather learn a new language, I think due to wide spread server availability, we'll likely end up using PHP. I'm thinking about exploring CakePHP due to what seems like quality security features built directly into the framework.

In the meantime, a lot is still up in the air. More updates will be posted as plans are finalized. I plan to make this project as open as possible for my own sanity.

Asus P4C800 Rev 2

2009-11-18T14:49:00.002-05:00

This board has been my latest personal hell. Back in the year 2005, my Asus P4C800 Deluxe fried. After taking their time, Asus sent me a replacement board. I simply assumed that it was a Deluxe and reinstalled it. Unfortunately, it was actually a P4C800 Rev 2. There are three models of the P4C800: P4C800, P4C800 deluxe, and P4C800-e deluxe. From what I can tell online, the Rev 2 is actually the e deluxe, but it looks like a hacked together mix between the P4C800 and the e deluxe.

This is where I made a mistake. One night when trying to get suspend to work in Linux, I decided to flash this board. I flashed it without checking what bios version was already on there. Stupid. Worse, since I knew it wasn't the deluxe (because the updater rejected the bios), I assumed it was the e deluxe. As would be expected, after the flash, the system wont boot. Flash forward a few days, and I've managed to force a flash downgrading the system to a P4C800.

Now looking back, I honestly can't remember what the board was originally and which bios I first forced onto the board. Never flash bios when tired and in a rush. I still can't believe I did that. Anyways, the system suffered from random shutoffs. I assumed this was due to the flash. (Honestly I can't be sure one way or the other now.) Over time these flickers grew increasingly annoying. So, I tried another flash. That time I managed to brick the board.

Yesterday I received two replacement bios chips. (One is a backup for hot swapping.) The latest version of the P4C800-e deluxe bios works, but it wont reboot. The latest version of the P4C800 bios works and will reboot. Both suffer from the intermittent shutoffs, and both have bios errors referring to the IRQ routing table. At this stage, I'm pretty sure the problem either isn't a bios issue or at least isn't a bios issue that I can resolve.

I installed this board into a new case with new hardware and the shutoff problems ensued. This has brought me to the conclusion that the problem has to be with the board. Removing all hardware except the bare bones still results in the shutoff. Another irritation is the problem wont normally occur when the system is idle. Also odd is the problems happen most in XP, less in Ubuntu, and the least in Windows 7. I don't know what that means exactly, but it suggests that whatever is triggering the problem may be a deprecated technique that modern OS's don't use. Though it may be that the board is just getting old and needs to be tossed.

However, the two things that keep bring me back to suspecting the bios are: the coinciding timing of the first shut offs / bios flash and the fact that the board looks like a P4C800 with a Rev 2 sticker slapped on it instead of a P4C800-e deluxe board. There might be some bios out there that will stabilize this system that I have yet to find. I should probably contact Asus.

Although I'm sure this isn't the conclusion to this story, it should be noted that suspend still doesn't work. :(

Edit - 28/10/2010:
This is the conclusion, because the pieces are now sitting in a box. My brother upgraded and let me keep his old hardware, which is newer than the P4C800. I'm now looking for a good way to get rid of this old hardware.

GBA Development on a Mac

2009-10-30T12:19:00.001-04:00

In my media devices architecture class, we are developing on the GBA. Unfortunately, most of the students are developing on windows machines, which leaves me and a few others the odd men out. On macs, we're using devkitarm as our compiler with a provided makefile. Unfortunately, the Makefile had a few flags misconfigured.

The stock makefile worked perfectly until we started dealing with sound. The problem was two fold:

Setting the interrupt handler would cause the GBA to reset
Sound files larger than thirty seconds would overflow the ewram

There were two macros in the make file that were used for compiling and linking respectively:

MODEL = -mthumb -mthumb-interwork

SPECS = -specs=gba_mb.specs

The model affects how the assembly is compiled, and the specs defines the way the linker will link the c objects together. I figured out that mthumb wasn't needed by looking at the windows makefile. Removing it resolved the rebooting issue.

I knew that the overflow had to do with the linker, because that's where it failed. I was at the point where I was actually trying to modify the linker script to manually force the audio memory to go to the right region when I realized there was a second gba .specs file. Switching to that file resolved the issue.

The resulting makefile macros are as followed:

MODEL = -mthumb-interwork

SPECS = -specs=gba.specs

I am not a compiler expert. So, I can't tell you the full implications of changing these flags, but it did work for me. I'm still working on what I believe to be a compiler bug and plan to submit a bug report soon. If it turns out to be interesting, I'll make another post here.

Microsoft Natural Ergonomic Keyboard in Linux

2009-10-26T21:09:00.002-04:00

I decided I wanted to enable the zoom key on my "Microsoft Natural Ergonomic Keyboard 4000" under Linux. Ideally, this would be used for scrolling up and down a page instead of triggering Compiz's zoom feature.

Unfortunately, the kernel fix is triaged on ubuntu's bugtracker. This of course meant recompiling the kernel manually (or semi-manually since Ubuntu makes this task relatively easy). You'll notice, if you care to check, that there is a patch in the bugtracker to remap the zoom and spellcheck keys to something that xev (and therefore X11) can read.

If you don't know how to recompile your kernel, this fix probably isn't for you. However, should you choose to proceed anyways (or if you're just not familiar with recompiling your kernel under Ubuntu), you can find instructions for recompiling Ubuntu's kernel here.

Once you've downloaded and uncompressed the source, edit "/usr/src/linux-source-*/include/linux/input.h". Search for ZOOMIN, ZOOMOUT, and SPELLCHECK and change these constants to match the following:

#define KEY_ZOOMIN 246 /* AC Zoom In */
#define KEY_ZOOMOUT 247 /* AC Zoom Out */
...
#define KEY_SPELLCHECK 235 /* AL Spell Check */

Keep in mind that if some other input device already uses these key codes, then you'll have a conflict. Otherwise, once you've recompiled your kernel, you should be able to access these buttons in Gnome now.

Additional Information

What does this do and why do we do it? From my understanding, the reason this is a problem is X11 can't read key codes above a 255. Although this is a bug with X11, we can modify the kernel to remap these keys to a value lower. This enables X11 to read them and thus Gnome to use them.

I dislike patch files for problems that are not going to be fixed, because they often break on the next kernel release. This is why I chose to manually edit the file instead of offer a patch file

If you recompile your kernel, you'll likely have to recompile any other third party drivers you have installed. For instance, I had to recompile my Nvidia driver after rebooting. I also had to purge the nvidia-common package.

Mapping to Page Up / Down

Next, I wanted to map 246 and 247 to page up and page down respectively. To do this, I edited my ~/.Xmodmap file to include:

keycode 254 = Prior
keycode 255 = Next

You can activate this by running "xmodmap ~/.Xmodmap" or adding the command to startup applications. However, the next time you log in, I think you'll get an option to enable this automatically without having to add it to startup apps. (I haven't setup xmodmap in a while, because I already use it to swap caplocks and escape... yes, I'm a vim user.)

Good luck. Feel free to leave problems, suggestions, or any thoughts in the comments.

Edit:
I should note that I have since reverted to a stock kernel. For some reason the recompiled kernel would kill my mouse periodically.

Hello World

2009-10-21T11:54:00.000-04:00

I'm tired of running into technical problems, finding a solution, and not having a place to publish my solutions. So, in hopes of saving others a headache, I'm starting this blog to list technical solutions I find to various problems I encounter.

Mac OS X Snow Leopard Port Wine

2009-10-21T08:56:00.002-04:00

Currently, wine is not happy with my 64bit upgrade to Snow Leopard. Just for the record, I find no fault in either port or wine for this, because I was an early adopter. I upgraded port with a simple reinstall. (I know there are more elegant solutions than this, but I was being lazy.) After upgrading port, installing wine resulted in the following error:

Error: wine 1.0.1 is not compatible with Mac OS X 10.6 or later. Until wine 1.2 is released, please install wine-devel instead.

This is pretty straightforward. Obviously, the next step was "port install wine-devel". However, I was promptly stopped with another error in the following format:

Error: You cannot install wine-devel for the architecture(s) i386
Error: because /opt/local/lib/libjpeg.dylib only contains the architecture(s) x86_64.
Error: Try reinstalling the port that provides /opt/local/lib/libjpeg.dylib with the +universal variant.
Error: Target org.macports.extract returned: incompatible architectures in dependencies

I'm not too familiar with port or the complexities of 64bit architectures working with 32bit binaries, but I do understand the principle behind OS X's universal (fat) binaries. After googling around a bit I discovered that the way to compile in the universal format is with the following command:

sudo port upgrade --enforce-variants jpeg +universal

The part that hung me up was figuring out which package was associated with that file. After digging around in the man page I found the following solution:

port provides /opt/local/lib/libjpeg.dylib

That's it! Just keep installing the dependencies and retrying "sudo port install wine-devel". After about eight dependencies are recompiled, you'll be finished. Good luck.

P.S. If this is not the most elegant solution, since I'm sure it's not, feel free to leave a comment and I'll correct my entry.