|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Denis Zaitsev 2:5010/70 09 Aug 2003 18:50:44
To : Denis Revin
Subject : Re: What does it mean?
--------------------------------------------------------------------------------
Вот ещё, вдогонку, из того же треда:
X-UIDL: c7f6bbea422407dd8b9c3c6705a0a9ff.1043208557.844
Reply-To: root@chaos.analogic.com
cc: LKML <linux-kernel@vger.kernel.org>
In-Reply-To: <3E2D4D15.4080001@tin.it>
Message-ID: <Pine.LNX.3.95.1030121084206.20505A-100000@chaos.analogic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
X-UID: 844
Date: Tue, 21 Jan 2003 08:54:33 -0500 (EST)
Subject: Re: Spurious 8259A interrupt: IRQ7 ????
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: AnonimoVeneziano <voloterreno@tin.it>
Status: RO
Content-Length: 3618
Lines: 88
On Tue, 21 Jan 2003, AnonimoVeneziano wrote:
> David D. Hagood wrote:
>
> > AnonimoVeneziano wrote:
> >
> >> What does it mean this message?
> >>
> >> Of what problem is the signal?
> >
> >
> > It is most likely a hardware problem.
> >
> > When a device signals an interrupt, it asserts its interrupt pin. When
> > the CPU asks the interrupt controller what device generated the
> > interrupt, the interrupt controller tells the CPU.
> >
> > But if the interrupt line "goes away" before the CPU fetches the
> > vector, then the interrupt controller doesn't "know" what IRQ caused
> > the interrupt. So the interrupt controller sends an IRQ #7 to the CPU,
> > along with setting a bit in the interrupt controller's status register
> > that says in effect "this isn't really an IRQ 7, but I have no idea
> > what it was. Sorry."
> >
> > If you have ISA cards in your system, remove them from the system and
> > re-insert them (with the power off, of course) - they may have
> > developed some oxidization on the card edge connector. You can also
> > try scrubbing the card edge with some plain paper (a US dollar bill
> > works even better, but you might not have access to dead presidents in
> > Italy.)
> >
> > Ditto with PCI cards - remove them, polish the connector, then
> > re-insert them.
> >
> >
> >
> Thank you very much all of you for the answers.So, this should be an
> harmless message, I've tried to attach something to the parallel port ,
> or disable it in the bios, but doesn't work, the only way to remove this
> problem is to load the parport_pc module, this message with the module
> loaded doesn't appear. I've tried with other bioses , and the problem
> appears on all of them. If I compile in the kernel UP-IO-ACPI the
> problem disappears, but I have a lot of other problems, because my
> system is quite young and the support for IO-APIC is not added yet for
> me.If I use only UP-APIC this problem appears, and if don't use apic
> this disappears.
>
> I'll try to remove some HW and retry. Someone had this problem without
> APIC enabled?
>
> Thank you
>
> Bye
>
> Marcello
If it bothers you, just comment out the message in the kernel.
A "catch-all" for interrupt glitches is the IRQ7. It can be
caused by real problems (unlikely if the rest of the machine
works), or the occasional glitch where some hardware didn't
assert its IRQ line long enough for it to be recognized. This
is a hardware glitch and they happen. They started to happen
more often once level interrupts, necessary for PCI interrupt
sharing, started to become common. Level interrupts, as opposed
to edge interrupts are not latched. If a glitch occurs on a
edge interrupt, the event is latched. If enabled, the interrupt
is handled just like a "real" one and nobody is the wiser. With
level interrupts, the CPU can become "confused" with a glitch
if, by the time the CPU starts to handle the interrupt, it no-
longer exists. The result is that the CPU executes the IRQ7
handler, the "catch-all", which is also used for the printer.
Bottom line, it's normal. It's being handled. You probably should
just comment out the message in "production" software so it doesn't
bother anybody.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
-
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/
X-UIDL: ccb6fed525e50e654e6caf4800c59fad.1043463430.691
Message-ID: <3E308120.1090704@WirelessNetworksInc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: linux-kernel@vger.kernel.org
References: <3E2C8EFF.6020707@tin.it> <20030121235339.GB4794@yzero>
<20030123221428.GA31588@gandalf.sch.bme.hu>
In-Reply-To: <20030123221428.GA31588@gandalf.sch.bme.hu>
Content-Type: text/plain; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jan 2003 23:53:32.0500 (UTC)
FILETIME=[A2B3B140:01C2C33A]
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
X-UID: 691
Date: Thu, 23 Jan 2003 16:56:16 -0700
Subject: Re: Spurious 8259A interrupt: IRQ7 ????
From: Herman Oosthuysen <Herman@WirelessNetworksInc.com>
To: Zsolt Babak <zod@sch.bme.hu>
Status: RO
Content-Length: 901
Lines: 25
A glitch on any interrupt line, will cause IRQ7 to trigger on the 8259A.
It is a documented 'feature' and is not really useful, but software
has to handle it gracefully.
Zsolt Babak wrote:
>>i get it on my thinkpad 560e when using a linksys ne2k pcmcia card. i only
>>get the message once, and it's triggered after a few seconds of high
>>throughput (fast, fd).
>>
>
> Same here with an Acer TravelMate laptop, with an smc pcmcia network card. The
> message occures only once at high network load. But the system is quite
> stable, so I didn't bother to track this down...
>
> Oh, and the laptop is based on Ali, not on VIA chips.
>
> Zsolt.
-
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/
--- Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
* Origin: South Ural Network (2:5010/70)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
