> > Comparing code from 2.0.33 and 2.2.4 I see that sti()
> > became restore_flags() and hence the interrupts are _never_ enabled inside
> > NCR5380_main() 8-|
>
> Thats not the case.
Sorry, it's the case. I'm looking at the sources in 2.2.5.
^^^^^^^^^^^^^
run_main() does cli()
NCR5820_main() does cli(),
then in several places
{unsigned long flags;
...save_flags(flags);cli();...;restore_flags(flags);...}
> > It means that despite all tricks with USLEEP the system is paralized while
> > accessing scsi. Even the date does not advance :)
>
> The delay loops do
>
> spin_unlock_irq(&io_request_lock)
>
> blah
>
> spin_lock_irq(&io_request_lock)
>
> which means interrupts are running during the delays. It still cripples the
I meant that since we enter NCR5380_main() we do not allow any interrupts
before we return. And (date; dd something-with-scsi; date) clearly shows
that even system clock does not advance as it should... (compared with an
external clock - "date" counted 4 seconds during a transfer that took 75
seconds in reality).
And it does not conform to the comments in the code :-)
> machine because its a polled 8 bit device that demands continual CPU
> attention.
>
> Alan
After inserting sti() back at two places in NCR5380.c the performance is
still the same (as supposed) but at least the system clock goes as
necessary...
Regards,
-- Ivan Popov <pin@math.chalmers.se> Systemman, Driftavdelningen, Matematiska institutionen, Chalmers TH
- 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/