Just to be clear, there are a host of apparently related
problems showing up on my laptop running 2.3.49-1 right now:
Scenario#1
When I boot up my laptop with both my 3c575bt and PCMCIA modem
inserted and PCMCIA/Cardbus has been built into the kernel,
from my boot messages I can see that yenta, pci_socket and
ds functionality are getting activated in the kernel. But
I only hear one set of "beeps" instead of two. As far as I
can tell from the messages logfile, the 3c575bt card doesn't
get detected. Then, when I get to a GDM login prompt, I find
that my mouse and keyboard are locked up and I am forced to
power cycle my machine.
Scenario#2
(This is the scenario where I am seeing the spurious interrupts)
If I boot with just the PCMCIA modem inserted, everything works.
If I then insert the 3c575bt card, it gets recognized too. I seem
to be getting the spurious interrupt after starting a PPP connection.
Last night when XFree86 crashed on me, this was the configuration I
was running. Although there were additional errors in the messages
logfile after X crashed (the spurious interrupt and AT keyboard not
present) I was able to restart XFree86 and use the machine.
My keyboard still worked in spite of the keyboard error. I was
unable to find any debugging info either in dmesg or my X logfile
to give any indication of why X had crashed.
Scenario#3
Lastly, when I build PCMCIA/Cardbus as a module; pci_socket, yenta
and ds do not load during the boot process. I have to load them
interactively. Once they are loaded, if I run "cardctl eject",
remove my two PCMCIA cards and then reinsert them, the 3c575bt
card gets recognized, but the modem card does not.
When I insert the modem adapter, I get these errors in my messages
logfile:
cs: warning: no high memory space available!
cs: unable to map card memory
Thanks for all your help,
Miles
Linus Torvalds wrote:
>
> On Tue, 29 Feb 2000, Miles Lane wrote:
> >
> > spurious 8259A interrupt: IRQ7
> > keyboard: Timeout - AT keyboard not present?
>
> The spurious 8259A interrupt is probably just because there is a driver
> that had some timing whereby it made its own interrupt go away without it
> having ever been acknowledged by the CPU - so the 8259A had had time to
> raise it, but by the time the CPU got along to servicing it it wasn't
> there any more and the i8259 gives us the spurious 7 instead.
>
> A spurious irq7 is not necessarily a sign of anything really bad
> happening..
>
> The keyboard thing makes me more worried. My current suspicion would be
> that somehow a edge-triggered interrupt is just lost due to some magic
> timing issues, and it stays lost forever because we don't touch the
> keyboard controller unless it asks us to look at it.
>
> So putting the two theories would be that it's the _keyboard_ interrupt
> that the driver just made go away, and because it wasn't handled the
> machine is now dead forever as far as the keyboard is concerned.
>
> When we read the keyboard status or data ports enough to make the
> controller think we handled the interrupt, but not enough to realize that
> there isn't anything more to read, then..
>
> The simple solution to this may be just a timeout - having a timer that
> checks the keyboard every few seconds and does a "handle_kbd_event()"
> whether an interrupt came in or not.
>
> Linus
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:23 EST