This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri May 3 11:26:53 2024 Received: from lml.valinux.com (postfix@lml.valinux.com [198.186.203.19]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id UAA05166 for ; Tue, 29 Feb 2000 20:29:57 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by lml.valinux.com (Postfix) with ESMTP id 61E595979E; Tue, 29 Feb 2000 17:29:41 -0800 (PST) Received: by vger.rutgers.edu via listexpand id ; Tue, 29 Feb 2000 12:40:24 -0500 Received: by vger.rutgers.edu id ; Tue, 29 Feb 2000 12:14:42 -0500 Received: from smtp-outgoing.amazon.com ([209.191.164.153]:58642 "HELO smtp-outgoing.amazon.com") by vger.rutgers.edu with SMTP id ; Tue, 29 Feb 2000 12:05:19 -0500 Received: from mail-proxy-1.amazon.com (mail-proxy-1.amazon.com [10.16.42.201]) by smtp-outgoing.amazon.com (Postfix) with ESMTP id 66A6F791; Tue, 29 Feb 2000 13:16:22 -0800 (PST) Received: by mail-proxy-1.amazon.com id NAA29371; Tue, 29 Feb 2000 13:16:20 -0800 (PST) Message-Id: <38BC39FE.8F3F17FA@amazon.com> Date: Tue, 29 Feb 2000 13:28:30 -0800 From: Miles Lane Organization: Amazon.com X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.49 i686) X-Accept-Language: en Mime-Version: 1.0 To: Linus Torvalds Cc: Ingo Molnar , Linux Kernel List Subject: Re: 2.3.49-1 -- Compilation error in traps.c in function `do_nmi' References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig 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/