Hmm.. I managed to install only when my laptop was tilted at a 30-degree angle tho, so not quite sure if it's not a hardware error heh (although I haven't tried tiliting it down again yet, just compiled 2.6.10 so we'll see if it's the same thing heh)

kiwibird: you're hard drive is probably on the way out.

when you get dma timeout errors, try a slower dma speed. like udma4. hdparm -X68 /dev/hda

Well, strangely, now after kernel 2.6.10 it's working fine, and has been for days...

The last kernel that worked for me was a debian 2.6.6. Anything beyond that caused that error. It still works with 2.6.6 by the way.

I've tried ubuntu and mandriva, and sure enough, they have the error as well. I can't turn dma on and that causes buffered access to be 25 times slower (than with kernel 2.6.6)

All the searches I have done have yielded no acknowledgement that any problem has cropped up in newer kernels on the ide front.

I got my harddrive changed again, dunno if the kernel errors caused the hardware to fail (is that even possible?) or if it was just faulty like the first one, but Ubuntu is working perfectly for me now anyway, knock on wood...

"I got my harddrive changed again, dunno if the kernel errors caused the hardware to fail (is that even possible?)"

I don't think that software errors cause hardware to fail. What does happen fairly often is that the software works correctly for good hardware but the error correction routines are buggy. So your problems could be caused by bad hardware and then some versions of the kernel handle the hardware errors smoothly and other versions of the kernel handle the hardware errors poorly.

"or if it was just faulty like the first one"

Sometimes hardware errors are design flaws in the hardware. Every piece of hardware of that model has the error built into it. The manufacturer then finds it cheaper to program around the error in the software driver. I ran into this type of problem on Promise IDE chips about 3 years ago. One indication that this is your problem would be if the kernel has a driver written specifically for your model of hardware. You could be in the position that the generic driver will not work but the specific driver has code to work around the design flaw.

---------------------------
Steve Stites

Well I'm back to report that I don't like kernel 2.6.10 as much as I did originally.

I've found that I can still produce dma_expiry errors if I have devices on both the primary and secondary channel in master/slave fashion, and try and copy large data between them.

It didn't seem to matter if I had 3 EIDE "cards" in the machine or just the mainboard EIDE, or any mixture. I even tried several variations of mainboard / external card in different PCI slots, resetting BIOS configuration data, etc., and came up with the same results.

To work around this, I ended up putting only 1 device per bus on the 2 motherboard busses, and then 2 add-in cards with 1 device per bus on each of those to get me to a total of 6 hard drives in the box; two 80 GB's and 4 200 GB's.

I can still periodically get the system to kick off dma_expiry errors if I copy large amounts of data between the disks, which sucks because the problem isn't gone but it's tons better than it was!

To work around that, I just do the copies in smaller stages. I personally wouldn't trust it in a RAID array so I've been doing manual mirroring of my data with rsync. Which coincidentally is how I trigger the error. I if I copy, or rsync, or dd a whole disk to another disk, the dma_expiry will kick off. If I just rsync or cp a collection of folders at a time (via scripting) the copies work fine. I try to keep my copy stages below 380 MB chunks because that's the loose mark I noticed where problems start (for me).

Found what it is, at least for me :

Read this :
http://www.mail-archive.com/linux-id.../msg00704.html

so a patch has been submitted :
http://lwn.net/Articles/127199/

Still trying to figure in which kernel the fix has been put. 2.6.6's dma works without a glitch but the hoary's version of udev demands a kernel > 2.6.8

"I've found that I can still produce dma_expiry errors if I have devices on both the primary and secondary channel in master/slave fashion, and try and copy large data between them."

"It didn't seem to matter if I had 3 EIDE "cards" in the machine or just the mainboard EIDE, or any mixture. I even tried several variations of mainboard / external card in different PCI slots, resetting BIOS configuration data, etc., and came up with the same results."

"To work around this, I ended up putting only 1 device per bus on the 2 motherboard busses, and then 2 add-in cards with 1 device per bus on each of those to get me to a total of 6 hard drives in the box; two 80 GB's and 4 200 GB's."

"I can still periodically get the system to kick off dma_expiry errors if I copy large amounts of data between the disks, which sucks because the problem isn't gone but it's tons better than it was!"

I think that your problem is that your IDE controller has a hardware bug in it. I had similar problems with a Maxtor secondary IDE card using a Promise IDE chip. The problem turned out to be that the chip would run a single hard drive fine but could not do I/O in parallel without errors. Maxtor solved this problem by writing a Windows driver that single threaded disk I/O. Maxtor and Promise then refused to tell the Linux developers what the problem was so the Linux IDE drivers had to be reversed engineered by trial and error. For about 2 years Promise IDE chipsets would not do parallel I/O in Linux. Eventually the Linux developers created work arounds for Promise chipsets. I think that you have some sort of similar problem. Your problem is not exactly the same because I could do I/O between master and slave. I could not do I/O between IDE2 and IDE3. Here are some threads where I discuss my problems with IDE controllers.

http://www.linuxquestions.org/questi...hreadid=265997

http://www.linuxquestions.org/questi...hreadid=258461

http://www.linuxquestions.org/questi...hreadid=190309

-----------------------------
Steve Stites

I would tend to agree - if I didn't have another system that uses the Highpoint chipset and exibits the same symptoms...

I recently put three Promise Ultra-133tx PCI EIDE controllers in my gentoo system, thinking that I could build a NAS system, and have been plauged by the dreded dma_expiry errors that would either lockup the system, crash the EVMS raid5 array, and now the linked drive storage as well.

Since these are recent purchases, does the hardware limitations still apply?

Is there any workarounds specific to hdparm settings or idebus= kernel parameters that may alleviate this problem? Currently running kernel 2.6.11-r11

Well, I've configured the start up scripts such that the drives connected to the extra 3 Promise controllers are running udma3 rather than the udma5 or 6 that the drives are capable of. I figure that this slower DMA speed would allow the controller to keep up with the timing, in case there is DMA contention on the PCI bus. Let you know if it works, and someone posts a reply.

I do not recommend using Promise controllers in Linux because they use black art to make them perform better. This goes true for Silicon Image, Intel SATA, and now ALI. I recommend using Highpoint controllers because they work the way they are suppose to work. I am using Highpoint controllers in both of my systems. I am getting performance and reliability. One controller (HPT370) is on a VIA KX133 chipset which has a history of data corruption problems. The Highpoint controller has no problems on this chipset. The second Highpoint controller (HPT372) is on a Intel 850 chipset. All my Highpoint controllers are on-board which is not any different than buying the PCI card version. Unfortunately, Highpoint controllers cost from 30 US dollars to 90 US dollars which can be costly to most people.

I do not recommend using RAID-5 because it hurts the computer's performance when there is only one processor. I suggest making multiple RAID-1 arrays and add them to the EVMS pool. Reduntancy is included and as well as stripping.

Use Hitachi or Western Digital hard drives instead of Seagate and Maxtor. Hitachi and Western Digital hard drives consumes the least CPU resources and they work better in file server.

TIP:
When using IDE or SATA hard drives, use the manufacture's hard drive utility to turn off automatic sector reassign and cache. By doing this, the RAID can be consistent every time you boot up the computer. The hard drive can not have bad blocks or else the RAID will fail.

Set multi-mode in the kernel. Also turning on or off 80 wire detection might give better results.

Changing the UDMA setting for the drives didn't work either.

Instead, I took the third Promise Controller card out of the system, and made use of the secondary IDE controller from the motherboard.

Since I removed the third controller, I've not had any errors, DMA or otherwise. Seems like you can only put two Promise IDE controllers in a single system. Guess I'll have to start looking as some sort of distributed file system to scale the storage that I'd like to get to.

Yea, well, spoke too soon. Down to two controllers, but I'm starting to think that a flaky drive is the source of the problems. Disconnecting the raid5 drives, and see what happens. Still got the LVM drives (3).