[clue-tech] Bad IDE hardware + compactflash, what to do?

[David L. Anselmi]

Sorry that I don't have any specific answers for your problem.  But...

Jim Ockers wrote:
[...]
> Unfortunately our motherboard has the DMA pin disconnected on the
> compactflash socket, so DMA is not an option.  The boards are 
> expensive and we have 2,000 of them.  The board has Via 82c596b 
> IDE chipset.

What changed?  Surely you didn't deploy 2,000 boards that don't work in 
your application.  Why is this a problem now and not when you were 
prototyping?

[...]
> 3. Hack the kernel's IDE device driver.  This seems like it would
> be a bit of work.  If the hdparm -u1 doesn't have any effect maybe
> this is a hardware bug not a software bug.  Anyone know how to do
> this or what we could look for?  Any easy tweaks we could make?
> 
> 4. Look at realtime linux (rtlinux) or different IRQ scheduler
> algorithms.  I don't know anything about this, does anyone on the
> list?  Is it likely we could work around this problem with a real-
> time kernel?

Can you determine why the interrupt takes so long to reset?  My 
understanding is that when an interrupt happens an ISR gets run.  As 
soon as it's "safe" the interrupt is reset (don't know whether unmasking 
can happen before it's "safe").  So it seems like there's a bit of code 
that takes too long to get done.  If slow CF means it isn't safe to 
reset for 80ms then you seem to be out of luck.

Perhaps this depends on the size of the data transfer and splitting it 
up somehow would help?

Maybe the board vendor or the kernel maintainers could help you identify 
a fix, if you can figure out the cause of the latency.

Dave
_______________________________________________
CLUE-tech mailing list
CLUE-tech at cluedenver.org
http://cluedenver.org/mailman/listinfo/clue-tech