I would rather get the taskfile complete first before attempting anything
that is depended upon the use of it. Thus no one can see the point.
Second there is an onion layer bug in the driver that can only be solved
with correctly addressing the full taskfile services. I can never fix
this problem because I can not flush the register and there may be stuff
left over that does not get cleared. So shit is pumped back into the
drive that has nothing to do with the scope of the current request.
Basically, RANDOM FS Corruption that is not tracable and not reproducable
but will happen. I can not stop it without at least the basic design
change of at least 35K of patch or more. Also any attempt to kludge the
current kernel will break it worse than it is broken now.
The rules changed to state that all unused registers must be zero and may
not be defaulted to an unknown state.
Second the table IO which is a supercharger for the driver and nothing to
do with an chipset wil return about a 16x to 20x throughput based on
current IO access and schedules (or what ever the new buzz word is).
Since none of this will happen it goes out the door broken, period.
Because it is not fixable in its current form. No ifs ands or buts.
I have tried but it breaks more and after about three layers deep in
fixing, I gave up because the patch code was larger than what I have been
trying to submit. So ugly I deleted because I was embarassed to even
admit that I thought to attempt this nasty-hack-abot.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:34 EST