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

[David L. Anselmi]

Jim Ockers wrote:
[...]
>>Can you determine why the interrupt takes so long to reset?
[...]
> How would we determine this?  We can see the lengthy interrupts
> using the oscilloscope but I'm not sure how to tell which part of
> the code is taking too long to return.  I suspect it's something
> in the hardware.

Well, I don't really know.  A kernel hacker ought to be able to tell 
where in the code IDE interrupts are handled and you just look at that.

Even if the problem is hardware the trick is to make the software work 
around the slow parts of the hardware.

[...]
> However as a result of these findings, some of the senior hardware 
> people have said some Very Nasty Things about the Linux kernel and 
> I'd like to prove them wrong - but I'm not sure how. 

I think Linus et. al. don't care what they say ;-)

Seems that people work on this now and then.  So perhaps a newer kernel 
(though not 2.6) would help.  Here are some things I found:

A discussion of measuring latencies:
http://linuxdevices.com/articles/AT3479098230.html

Timepegs, for doing the kinds of measurements you might want:
http://www.ussg.iu.edu/hypermail/linux/kernel/0102.0/1028.html
http://www.zip.com.au/~akpm/linux/schedlat.html
http://www.zip.com.au/~akpm/linux/index.html#timepegs

Looks like you have to know a lot to use this stuff.

One thing that might help is if you could make the serial interrupts 
higher priority than the IDE.  So some real-time 
extensions/patches/whatever might help with that.  A guy named Kuhn has 
done a RT patch but I don't know whether it's in the kernel now or out 
of circulation.

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