> On Tue, 2002-07-16 at 22:10, Filip Van Raemdonck wrote:
> > Hi,
> > I upgraded from 2.4.19-pre7 to -rc1 and this resulted in my aha152x card not
> > working anymore. (The error was "trying software interrupt, lost")
> > Below is a patch which makes it work again. Note that this is just reverting
> > a minimal part of the last applied patch to aha152x.c; so this may only be
> > fixing the symptom and not the problem.
> > Can somebody confirm if this is correct or not, and give some more insight
> > into this behaviour?
> I've seen reports but not figured out what is going on yet. Are you
AFAICT, the patch which went into 2.4.19-pre10 (looks like a 2.5 backport)
removed the release/re-acquire of the io_request_lock with interrupts off
around a mdelay(1000) while the scsi_host->detect method probes for
interrupts. The identical code (i.e. with the unlock/lock removed) works
Apparently the io_request_lock policy was changed in 2.5 and
aha152x_detect() is called without io_request_lock taken - in contrast to
2.4. However, the aha152x_detect strategy depends on some status change
driven by interrupt completion which doesn't happen when the lock is still
acquired by the caller - hence the interrupt appears to be lost.
Well, I'm definetely not the one to judge what's really correct here, but
my impression is, if the detect() is called with io_request_lock held and
interrupts off it wouldn't be allowed to release it down there. OTOH it
was there before and the driver used to work this way - in contrast to the
2.4.19-pre10 and later 2.4 which isn't working at all.
> using an AHA152x or the PCMCIA version ?
I can confirm Filip's patch putting back in place the old unlock/lock
makes things working again. Tested with an AVA1505AE (ISA, configured to
non-pnp fixed irq/io) on UP box running SMP kernel.
Therefore if you ask me, my vote would be to put this back in for
2.4.19-final until we have a better solution.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/