Man, what a craptacular holiday I had. Lots of stuff to blog about tho.

Broken car.
Say ain’t so! Yeah, it’s broken – making a CLACK CLACK CLACK from the engine. Regardless of the gear it’s in, rolling or not, or whether the clutch is in or out. Waited THREE hours on the freeway onramp where I stopped for a tow truck to haul me and the car to the dealer. It’s there now… my research on srtforums.com says it may be loose flywheel bolts. That’d be a lot better than a thrown rod or something. Hope to hear from the dealer today.

X Windows woes The problems continue – sort of. I’ve completely disabled all acceleration and haven’t seen any signs of the mousedeath OR the BadLength issues. I plan on running it like this for a while, and if the problem doesn’t occur, I think I’ll recompile the Mach64 kernel module with the OMG crusoe optimizations. We’ll see….

Hackergotchi Ken took about the only picture I could find of myself and made me a floating hacker head. We’ll see how it looks.

Hotswapping an IDE Optical drive on the FujiP Blogging this for the benefit of other FujiP owners. It’s possible to hotswap the optical drive for the extended battery - you just gotta have the right mojo. What I did was dig up an script called “idectl” on the web that uses some hdparm mojo to turn on and off the ide channels. It works well, assuming you are running a udev-enabled kernel to do this. I modfiied the script to tail the kernel log so you can see when the devices are added or removed from the /dev tree. Note that you have to wait a bit before re-inserting a previously ejected drive if you want it to have the same node in the tree (ie, /dev/hdc) - if I do it too quickly it gets /dev/hdd) – dunno why. Script posted in the Extended Entry field below.

Of course, just when I post a “Yay, X problems are fixed.” blog post X decides to shit the bed with the same symptoms.

But it did make it thru a couple of days of strenous testing, maybe it’s “good enough”. We’ll see.

As stated in my previous bitchy, whiny rant, I was having spontaneous X crashing problems while using DRI on the ATI Mach64 chipset. I believe I’ve found a magic bullet – the XF86Config-4 config variable “Option” “BackingStore” “true”. I haven’t suffered a crash yet.

Deft hands and a pure heart triumph again.

Shit. Some time ago, I picked up a Fujitsu P2110 computer used. Now, this is a nice little system… 384MB RAM, 867Mhz Crusoe, great form factor. I upgraded it with a 60GB disk, DVD+-RW burner, and a Intel 2200GB wireless “G” card. I also picked up the extended bay battery (10 hrs of total battery life), and two more AC adapters. I should have been set, right?

WRONG. Like a fucking MORON, I decided to run Linux on this box. Again. Everytime I run Linux on a laptop it winds up being a tremendous time sink. The major bane of my existence is the fact that the X server, for some reason on this system, shits the bed at random. This wouldn’t be so bad if it’d fucking give me SOME KIND OF DIAG info in the logs or anything, but nooo…. it just dies.

It always dies on mouse movement, too, which is really bizarre. Call up an app, say, mplayer, and watch movies – the box is fine. I watched all 12 Battlestar Galactica (KILLER SHOW, BTW) on a coast-to-coast flight and never had a crash. But god forbid if you fire up Firefox, or Thunderbird, and actually use the mouse a bit. BOOM. X will crash, sooner or later, and you’ll be SOL. Oh, and after X shits the bed, you can’t simply restart X or reboot. No, that’d be too fucking easy. You have to POWER THE SYSTEM DOWN. That’s cause the Crusoe chip (thank you Linus) has a CMS instruction cache that’s only cleared on power down. Yay.

Now, before I get flamed, I wanna say I’ve seriously tried every fucking reasonable thing I can think of to fix or workaround this problem. Turns out there’s a bug in the CMS code of the Crusoe, that can be worked around by recompiling certain apps (read: the entire fucking X server) with different GCC optimization flags. So I tried that. No good. Oh, wait, here’s a bug for an ATI Mobility Radeon using the new fancy X pointers - the workaround was to use the standard X “core” pointer. Changed that, no effect. Turned off HWcursor, enabled SWcursor, no good.

Some people have told me to dump GNOME in favor of another WM. I’m not willing to go that far, simply because Ubuntu and GNOME 2.8 were two of the key factors that made me buy this machine in the first place.

I’m pissed off, in case you can’t tell. I’m mad at myself, for wasting the time and money to dick around with Linux on the laptop when I’ve got a perfectly good Powerbook that work’s provided. I’m also mad cause I really DO like this box - the weight and form factor are unbelievable, not to mention the amazing battery life with the bay battery slotted. I’m mad at Transmeta, for not catching this bug. I’m mad at Fujitsu, for never releasing a BIOS/CMS update to this platform.

Most of all, I’m disgusted at the fact that I CAN’T figure this out. There’s literally no info to go on… the logs have nothing in them when the problem occurs. The problem is entirely sporadic… I’ve gone as long as four days before hitting it. Of course, there are times when it’ll blow up twice in five minutes. It’s not ubuntu’s fault, cause Knoppix shows the same behavior.

Bottom line is; it may be time to cut my losses, sell this thing, and give up and buy a fucking iBook or something. Any windows users out there interested in a FujiP?

Sport Compact Car got their hands on the “Extreme” SRT-4 – a SRT-4 that Mopar has trimmed ~400 pounds from and bumped the horsepower to 370, with 383 ft-lbs of torque. OMG.