Re: [PARPORT] parport irq handler v7 test w/ 3 pp devices


Andrea Arcangeli (andrea@e-mind.com)
Thu, 24 Sep 1998 12:44:46 +0200 (CEST)


On Mon, 21 Sep 1998, David Campbell wrote:

>The ZIP drive has a minimum of a single timer tick before a request
>is issued (due to SCSI pedantics - if I didn't wait a timer tick, a race
>condition would occur resulting in the kernel about 200+ calls deep
>and panic due to "out of stack space").

That' s not a race condition. Is due how scsi code works. Every time you
run scsi_done() inside the main ppa engine the scsi code will recall again
the ppa engine:

ppaengine -> scsi_done -> new scsi command ready -> ppa engine -> scsi_done

If this would be done in the same stack without wait a bit between the two
ppa engine this logic will overflow the kstack for sure (I experienced
this many time in the past trying to make the ppa lighter and faster (and
probably David remeber about that ;-)). To workaround this scsi code
behavior, ppa do heavily use of bh handlers to put a delay between
consequential ppa engine and to avoid nesting calls in the same kstack.
The problem of bh handlers is that it' s not trivial force a schedule()
when we found that the next scsi_phase is not ready yet (and a polled
driver would like to do many schedule() to be very lighter).

This bad behavior of the scsi code can' t be noticed with anything other
ppa since all other driver are irq driven and so they never run
scsi_done() from the same context that sent the scsi command to the scsi
controller.

Andrea[s] Arcangeli

-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --



This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:21 EST