On Tue, 4 Sep 2001, Tester wrote:
> >
> > What they are doing, however, is to generate a SCI, ie "System Control
> > Interrupt". Which, I bet you five bucks, is routed to the same interrupt
> > that your CardBus controller is on.
>
> Seems like you may have lost five bucks... When ACPI is enabled the sci is
> on IRQ 9, while the CardBus controller is on a IRQ 11 along with
> the Sound card, the ethernet card, the modem and the usb controller. The
> SCI seems to go to irq 9... and be alone there... The bug does not happen
> when acpi is enabled tho... So I can't confirm...
No, I think I'll keep my 5 bucks, cheap bastard that I am.
The thing is, enabling ACPI will also force the _correct_ routing of the
SCI interrupt (assuming ACPI works - it doesn't on all machines), and thus
it doesn't show up as some random other irq. Which is why you don't get a
lockup.
> > However, the interrupt handler we have is _not_ aware of system
> > control interrupts. So it won't be able to handle them, and the
> > interrupts will go on forever - locking up the machine.
>
> Where would that loop occur?
There won't be any explicit loop - what will happen is that irq12 will
stay active, so we will keep on having irq12 interrupts that the CardBus
interrupt handler doesn't know what to do with - and immediately when the
irq handler returns and acks the interrupt we'll just take the irq again.
Over and over.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:42 EST