I expect IET has moved forwards from here.. and certainly from what is currently in Debian stable. This is a fairly un-researched/experience based post.. and thats why it never made it to devel list. Not an issue we have experienced; just one that took a bit of time to find some context on (hence the repost).

As a matter of interest in one prod environment I access, we run software raid + luks_crypt + LVM2 under VMFS3 (for VMWARE) and OCFS2 (for Xen) on Debian just fine with channel bonding_afs to deliver 2Gbps to the SAN (max 1Gbps per physical initiator host still). Its been supporting our small production environment for some time. If the features are in Debian Stable, functioning, it seems to work great.

The only issue we have seen is when RAID resync I/O on monthly cron checks on large 2TB volumes (which takes more than 24hrs) creates a scenario where the IET queue sometimes appears to overflow sometimes in an instant _ and the kernel sorta borks. No filesystem corruption yet (that we know of) but worked around by applying a cap to the raid_ratelimit_max and raid_ratelimit_min settings that seems to prevent this from happening now. This was the original issue that had some initial iET output similar to the findings in the links above. If this is causing misinformation of confusion, I’ll just remove it.

For us its all about reducing costs and risk to a certain degree, and we have the Debian expertise in house. The Debian platform tends to require less testing and promotion of updates thanks to its strict rules on packages _ so as long as it does what you want it too, its great (albeit a bit outdated right now pending Squeeze). Its a different story for our clients.

The evergreening between distribution release has been great so far, though we have only used IET since Etch in this manner. Lenny update was flawless. We expect more of the same for Squeeze. Not to mention the myriad of other business services also running on Debian stable platforms, so extending that mantra to include IET was straighforward and fit nicely into existing MOPs, etc.

<3

IET when properly configured performs as well as the underlying storage does. Of course if you want to use it for anything other then a personal home network you really need to be running a later version then what comes with Debian.

-Ross

More in my blog: http://jacksgadgets.blogspot.com/

Try taking out the pci=pirqmask and replacing it with iommu=off

That’s been a bit more stable for me with stock Debian 2.6.18-3-amd64.

The pci=pirqmask leaves a more or less runnable system, but I still get the odd lockup in X (when an xterm is open). I’ve been unable to reproduce the lockup since using the iommu=off.

The headphone jack still doesn’t work, but it looks like everything else is going well.

Tech support suggested the latest F1A BIOS. I didn’t see a difference with the F19.

One difference I had was that dexconf, for whatever reason, decided to point xorg.conf at the ATI fglrx driver. That was sort of odd – I’m using nv now, but had to manually change it.

Thank-you for posting this how-to!!!

I’ve had a D-link 614+ for about 2 years before it died.
So I hoped onto ebay and got the 614m (will get it in about 3 days)

Been very happy with dlink interface compared to netgear.

Did some googling only to find so many bad reviews.

Thank-god I found your site!

I have an old mac running os x.48 (hope a mac works on it, -it didn’t with netgear -(as far as changing settings))

Your site has brought me hope.
Again thanks for the website!

Sincerely Loni