Re: IDE + SMP Lockup (no OOPS) in 2.2.12, 2.2.10

Jes Sorensen (Jes.Sorensen@cern.ch)
30 Sep 1999 11:29:56 +0200


>>>>> "Rogier" == Rogier Wolff <R.E.Wolff@BitWizard.nl> writes:

Rogier> Jes Sorensen wrote:
>> Most of the interrupt sharing problems I have seen have been due to
>> driver writers forgetting to check whether an interrupt actually
>> came from the device before they start processing it.

Rogier> To get some extra speed out of a drive, some manufacturers
Rogier> give the interrupt a few microseconds earlier than when the
Rogier> data is fully available. With faster and faster hardware, it
Rogier> becomes possible to empty the buffer before it is fully
Rogier> available.... Data corruption. Now by sharing the interrupt,
Rogier> the OTHER drive may be interrupting, and the processor gets
Rogier> that few microsecond lead....

Well it is supposedly the job of the driver to check that with the
hardware that data is actually available before taking it for
granted. This may for various reasons be problematic if the cheap
designers did stupid things etc.

Rogier> When I was on the same room with the hardware guy, we had the
Rogier> rule: "if it's untested it won't work". Well if Abit tested
Rogier> that board with NT, its drive subsystem probably didn't get a
Rogier> workout comparable with what it's getting from Linux. So:
Rogier> "It's untested and may not work".

Rogier> I'm not saying that that's what is going on, but a hardware
Rogier> problem like that could sure be possible.

Sure this is a good rule of thumb, however shared interrupts should
not cause any problems on PCI. If they are the first one to turn to is
really the device driver author ;-)

Rogier> Tell me. Is the Linux serial driver reliable? I'm seeing
Rogier> datacorruption. That's for sure. Ok. There is a neato, new PCI
Rogier> serial chip involved. The chip looks reliable to me. The
Rogier> driver looks reliable to me. Where is the data getting
Rogier> corrupted? Anyway: Something to do for today...

Well serial is a medium that is almost guaranteed to lose data once in
a while ;-)

Jes

-
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/