I have a 300GB drive that works totally fine in any windows machine but always seems to cause DMA errors in the UnRaid which lead to a total lock up.  Well just tested 3.0 beta 1 and the condition still exists.  In the syslog you see the error DMA timer expire and then it hoses up with the yellow drive light of the drive it did not like on steady, same condition as always.

 

I know Tom had said the 2.4 kernel was less picky about DMA errors and that may account for what seems to be less complaints about them but it looks like they CAN still happen.

Based on my admittedly limited knowledge, I believe DMA problems can arise from the connectors/cabling/controllers rather than the hard disk itself. I suppose what I'm trying to say is that the fact that a hard disk works under Windows on a DIFFERENT box but has DMA errors on the unRaid box does not necessarily indicate that the problems are with the unRaid software.

Based on my admittedly limited knowledge, I believe DMA problems can arise from the connectors/cabling/controllers rather than the hard disk itself. I suppose what I'm trying to say is that the fact that a hard disk works under Windows on a DIFFERENT box but has DMA errors on the unRaid box does not necessarily indicate that the problems are with the unRaid software.

 

 

Most of the time this is true.  However I do have a Seagate drive which works fine as long as it's not the "Slave" drive of a Promise Ultra100/133 controller.  I tried all combinations of moving this drive to different ports, used different cables, had different Master drives (and no Master drive), etc., etc.  Bottom line was that it simply would not work reliably as a Slave device on a Promise controller.  (Actually didn't try another type of controller, e.g., SIIG.)

 

The problem with this drive is a subtle electrical defect which could probably only be caught with a logic analyzer and a lot of time - two things I don't have 

Based on my admittedly limited knowledge, I believe DMA problems can arise from the connectors/cabling/controllers rather than the hard disk itself. I suppose what I'm trying to say is that the fact that a hard disk works under Windows on a DIFFERENT box but has DMA errors on the unRaid box does not necessarily indicate that the problems are with the unRaid software.

 

I have put this drive in several different slots (not 100% sure of the slave/master thing) but it has caused the DMA timer expire error each and every time I attempt to run a parity with this drive installed.  I keep it around for testing reasons, but I have installed it in Windows machines several times with zero errors.  Also if it were a slot (cable etc.) issue any drive put there would have issues and that is not the case at all.  Tom will remember I had the lock-up problem from way back and it finally got isolated to two drives that the UnRaid did not like and both caused the DMA error, one was still under warranty and one was not so guess which one I still have for testing.

Just FWIW, a friend of mine has been messing with FreeNAS a good bit. The other day he too was bitching about DMA errors and has several drives that he cannot use in his system. From what he was telling me he's not the only one having this issue so I'm thinking it's a Linux thing that it's so sensitive to DMA timing

...

I have put this drive in several different slots (not 100% sure of the slave/master thing) but it has caused the DMA timer expire error each and every time I attempt to run a parity with this drive installed.  I keep it around for testing reasons, but I have installed it in Windows machines several times with zero errors.  Also if it were a slot (cable etc.) issue any drive put there would have issues and that is not the case at all.  Tom will remember I had the lock-up problem from way back and it finally got isolated to two drives that the UnRaid did not like and both caused the DMA error, one was still under warranty and one was not so guess which one I still have for testing.

 

The source of DMA errors is electrical: either glitches on power or signals, marginal power, crosstalk, etc, and it could be the "right" combination of motherboard/controller/drive, which exposes this.  The addition of a mobile rack will also just exacerbate any problems.

 

Linux tends to report everything, and in general, will not drop into PIO mode when it encounters errors.  Windows, I believe, will drop into PIO mode and not tell you it did so - you just see a slower disk.

 

I would propose that if you have a flaky unRAID disk you could do this: hook up a CD drive on say the parity cable and install windows on the flaky disk; and that windows system would exhibit disk problems also.  NOTE: I"m not suggesting anyone actually try this, but knowing rharvey, this will keep him busy for a while 

 

I would propose that if you have a flaky unRAID disk you could do this: hook up a CD drive on say the parity cable and install windows on the flaky disk; and that windows system would exhibit disk problems also.  NOTE: I"m not suggesting anyone actually try this, but knowing rharvey, this will keep him busy for a while 

Why not, it's the best test surely?  If you put the drive in another system, you are not testing like-for-like.  If the drive works in other systems but not in your unRaid system, and you install Windows on the drive whilst it's in your unRaid system, you'll know for sure if it doesn't like the combination of components at an electrical level or, if it works, that Linux/or it's drivers don't like it, or it's a surface problem, not an electrical one.  If it *does* work (absolutely no errors in Windows), then something like Spinrite might just be able to sort it out....

 

HTH,

 

Matt

  NOTE: I"m not suggesting anyone actually try this, but knowing rharvey, this will keep him busy for a while 

 

Tom now that was not nice.......!  :'(