Archive for April, 2005

The Customer is Always Wrong (apparently)

Judgement Day
I purchased an external 2.5″ drive from a company online, which is basically a Yahoo! store behind it. The drive enclosure I received wasn’t exactly what I had ordered. I wanted the IEEE1394a (Firewire 400) model, and received the IEEE1394b (Firewire 800) model. Since I don’t have fw800 ports, I’d have to use the usb2 connection. The problem there, is that Linux doesn’t support the Oxford 922 chipset on this drive. I mentioned this in a previous entry.

I went out and purchased a bilingual cable to make the drive work, and it did, though it was not bus-powered, as the original product spec sheet indicated. It doesn’t work with USB bus power or with Firewire bus power. After about a week, the power supply on the external enclosure just stopped working outright. It takes a lot of weird twisting and turning of the power cable and the drive enclosure itself to find the exact position that lets it power up. I should just be able to plug it in and not worry about it.

I received an email this morning from Yahoo! asking me to rate the vendor that sold me this drive. . I rated them with an “F”. Their customer service is non-existant, their entire website has zero contact information, there is no customer service number, there is no information on their privacy or returns policy, and many other shady things.

5 minutes after I submitted the review, I get a phone call from someone representing the company. He basically asserted that I was “an IDIOT“, and that I couldn’t read, and many other interesting and colorful profane phrases. Instead of finding out why I rated him with an “F”, he just proceeded to try to insult my intelligence with slander and libel. I calmly tried to explain that the device wasn’t what I thought I was getting (bus-powered, IEEE1394a), and that the PSU had died on the unit.

After several more insults and swears from this individual, I asked if he knew what slander was, and he said he did, and basically suggested I “go ahead and sue” or something to that effect. Then he tells me he is recording the whole conversation (also illegal, since he did not notify me of this at the beginning of the call, which is required by law. He wasn’t recording anyway, another series of lies).

Then he breaks down and tells me to send the drive enclosure back to him for a full refund, because “…he doesn’t want to do business with people like me.” I’m not sure if he was being discriminatory there or just ignorant, but these things didn’t bolster his side of the case.

We terminate the call and then I see in my email, a copy of a message he apparently sent to several others, calling me a “fucking idiot“, and then states “As posted on our checkout page prior to any purchase we do not do business with IDIOTS” (obviously their checkout page says no such thing, another lie on his part). I’ve made a local copy of their entire website, just in case they try to get smart and change what it says.

Here is a copy of the relevant parts of that email (maybe it wasn’t supposed to go to me?)

Date  Wed Apr 6 09:18:56 PDT 2005

Mark Reason  Other (every pages has our policy, and
our checkout page is very clear what a fucking idiot!)

It seems that you must not know how to READ, please
try to read your invoice and send item back for refund.

As posted on our checkout page prior to any purchase
we do not do business with IDIOTS


I’m sure if I was to send him the enclosure back (I will be anyway, certified mail, through the USPS, not Fedex or UPS, since it is defective) that he would just keep it, and my money, and not refund anything. The Better Business Bureau in Clearwater, FL has already been notified, as has my local BBB in CT.

I don’t tolerate or appreciate lies, deceit, insults, slander and libel being wrongfully directed at me. This person has absolutely no idea who he is dealing with.

In any case, if you are online looking for peripherals, avoid this company as much as you can. They’re shady, and they clearly don’t care about their customers.

More toys…


My shiny new Thinkpad T42p came with an UltraBay Slim DVD-RW drive, which is nice and fast. Unfortunately, it also came with a 60gb primary IDE drive, which isn’t enough to hold my source, documents, projects and all of my VMware images for development and testing. On my Thinkpad T23, I had always used the UltraBay slot to hold a second IDE drive for these images.

This puts me in a quandry, because I’d like to use the DVD-RW, but also use my VMware images..

I decided to look into getting an external 2.5″ usb2.0/Firewire enclosure to hold a spare 60/80gb drive for the VMware images. I went with one based on the Oxford chipset, because I’d read that they were the fastest external chipset out there for these kind of enclosures.


I received the enclosure yesterday, and there were a few problems with it right off the top:

  • The Firewire interface was 1394b, not 1394a (Firewire 800 vs. Firewire 400). I only have Firewire 400 peripherals, so this connection is useless to me, and the Firewire 800 pcmcia cards out there don’t have a usb2.0 combo interface, so I’d be swapping out pcmcia cards for each device. Not fun.
  • The enclosure doesn’t run without external power when using the usb2.0 connection. One of the selling points of this enclosure was that I could use it without having to carry around a separate power “brick” with me when I travel. With usb2.0 being the only possible connection interface, this was important. Unfortunately, it requires a wall plug to power up the drive when using usb2.0. Ugh.
  • It doesn’t work with Linux. Double-ugh. I thought it would “Just Work™”, but apparently not. I found this informative post from someone who had done some pretty extensive testing, and found that the Oxford 922 chipset is buggy, and doesn’t work with Linux. I wish I found this before I bought the enclosure!

The errors I’m getting look like this:

Apr 11 17:04:15 angst kernel: usb 5-2.6: khubd timed out on ep0in
Apr 11 17:04:15 angst kernel: usb 5-2.6: device descriptor read/8, error -110
Apr 11 17:04:15 angst kernel: usb 5-2.6: new high speed USB device using ehci_hcd and address 10
Apr 11 17:04:20 angst kernel: usb 5-2.6: khubd timed out on ep0in
Apr 11 17:04:20 angst kernel: usb 5-2.6: device descriptor read/8, error -110
Apr 11 17:04:25 angst kernel: usb 5-2.6: khubd timed out on ep0in

These are fatal, and the drive isn’t recognized. I use a LOT of external usb and firewire peripherals, so this was unusual for me. I tried about 7 different kernels and different suggestions from the community about ACPI and noapic at boot, but those didn’t seem to help.

So now I’ve got an enclosure that seems flaky with Linux, and doesn’t have the interfaces that work with the rest of my peripherals.

But.. I found a possible solution, a bilingual cable! Basically this cable takes Firewire 800 (1394b) and transforms it to Firewire 400 (1394a).

Firewire Bilingual Cable

It was fairly cheap, so I ordered it. Hopefully this will let me use the drive on bus-power only, and in a way that Linux will recognize. Otherwise, I’m going to have to eBay the device. The company I purchased it from had a policy (that only showed up after my order was confirmed) that allows repair or replacement of the same device, but no exchanges. Ugh.

Upgrading that backup drive!

Tags: , ,

A couple of years ago, I purchased a Western Digital external combo drive to back up my laptops and a couple of the critical servers here. It was also partitioned for holding the digital images we take with our Minolta DiMAGE 7Hi. It was only a mere 120gb of capacity, but it lasted for quite a long time… but it was time to upgrade it.

The enclosure has two interfaces: usb2.0 and Firewire 400 (1394a). It works great, and has served me well for the couple of years I’ve had it. No complaints at all with it.

I recently went out and bought two Maxtor MaxLine Plus II 250gb drives; one for the main server, and one to replace the 120gb drive in the WD enclosure.

The upgrade of the external enclosure’s drive went pretty smoothly (full details of the disassembly), and recognizing the new drive went smoothly. I proceeded to back up 3 of the servers here to the drive, including making a duplicate copy of what was on the 120gb WD onto this new 250gb drive. I made sure to verify the backups to be sure things were intact. I’ve had a LOT of bad luck with storage and computer peripherals in general, so I was taking no chances.

The other drive went into the main server here, and that wasn’t so easy. I did an rsync of the existing running data to the Maxtor while installed in the primary slave location. So far, so good. I wanted to chroot to that drive’s mountpoint and just re-run lilo to create a working mbr on the slave, but that didn’t work so well.

Ok, second plan: switch the drives, boot the server to KNOPPIX and chroot from there, and run lilo. Nope, of course not. My KNOPPIX disks, which I use almost weekly were all no longer recognized in the CDROM drive in the server. In fact NO cdrom was recognized in that drive. Arg!

So I had to put the original drive back in as slave, switch the bios to allow me to boot to that second drive, and then re-ran lilo from there, which put the right mbr on the master. Whew. A few hiccups with some startup scripts, and I was back in business. The drive is pushing about 1gb/sec. over cache, and 49mb/sec. over disk reads. Not bad at all.

Once I wiped the servers after doing the backup, I stupidly decided to try to defrag the ext partition. It was ext3, so e2defrag barfed on it. I used tune2fs to take off the has_journal and dir_index bits from the drive metadata, and tried again.

This time it got as far as calculating the inode indices, then crashed. Ut oh. I ran e2fsck on the drive, and it segfaulted about 70% into the process. Double-ut-oh! I ran it several times, all segfaulting in the same place. Running it under gdb produced the following barf:

     0xb7fcf45b in ext2fs_unmark_generic_bitmap () from /lib/

Rut-roh! So I decided to yank all of the data off of the backup drive onto other systems with enough free space to hold it, and reformatted it to XFS instead. After restoring the data across, all seems well.


Bad Behavior has blocked 104 access attempts in the last 7 days.