RE: Spurious 8259A? [SOLVED]
> (jag hittar dessutom inget i maskinen anslutet till IRQ7) 7 är väl den första printerporten?
Re: Spurious 8259A? [SOLVED]
tis 2003-02-25 klockan 17.01 skrev Karl Hammar: > > men däremot hittar jag > > meddelanden i loggen: Kernel spurious 8259A interupt; IRQ7 på två > > ställen. Någon som vet vad det gäller? Kan det ha något samband med > > någon fläkt vars lager är på upphällningen? Något med temperaturen? Kan > > jag friskriva disken? > Från: > "Intel386TM EX Embedded Microprocessor User' s Manual" > Intel Corporation > 1996 > Order Number 272485-002 > (går förmodligen att ladda ner från nätet) > > 9.4.3 Spurious Interrupts > For both edge and level-triggered interrupts, a high level must be > maintained on the IR line until after the falling edge of the first > INTA# pulse (see Figure 9-18). A spurious interrupt request is generated > if this stipulation is not met. A spurious interrupt on any IR line > generates the same vector number as an IR7 request. The spurious > interrupt, however, does not set the in-service bit for IR7. Therefore, > an IR7 interrupt service routine must check the in-service register to > determine whether the interrupt source was a valid IR7 (the in-service > bit is set) or a spurious interrupt (the in-service bit is cleared). > > (IR = interrupt request) > Dvs. en sk. "surious interrupt" inträffar bara för irq7, men manualen > säger ingenting varför de inträffar. Tack alla för tipsen, jag är nöjd med detta! Min tolkning är att våra vänner kernel-experter inte bedömt det vara mödan värt att analysera detta meddelande närmare, och eftersom jag litar på storebror så sitter jag nöjd, dvs jag oroar mig inte och låtsas som om det regnar. (jag hittar dessutom inget i maskinen anslutet till IRQ7) /Anders W > > > > Från kärnan: > > $ sed -ne '272,286p' /usr/src/kernel-source-2.4.20/arch/i386/kernel/i8259.c > /* > * Lightweight spurious IRQ detection. We do not want > * to overdo spurious IRQ handling - it's usually a sign > * of hardware problems, so we only do the checks we can > * do without slowing down good hardware unnecesserily. > * > * Note that IRQ7 and IRQ15 (the two spurious IRQs > * usually resulting from the 8259A-1|2 PICs) occur > * even if the IRQ is masked in the 8259A. Thus we > * can check spurious 8259A IRQs without doing the > * quite slow i8259A_irq_real() call for every IRQ. > * This does not cover 100% of spurious interrupts, > * but should be enough to warn the user that there > * is something bad going on ... > */ > > > > Från loggar: > > # zgrep -C -i spurious /var/log/all.log.?.gz > /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: ext3: No journal on > filesystem on ide0(3,2) > /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: Adding Swap: 96384k > swap-space (priority -1) > /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: spurious 8259A interrupt: > IRQ7. > /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: Real Time Clock Driver > v1.10e > /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: Linux Tulip driver version > 0.9.15-pre12 (Aug 9, 2002) > /var/log/all.log.3.gz:Feb 21 08:42:38 pyrit ippl: ICMP message type > destination unreachable - bad port from 127.0.0.1 > /var/log/all.log.3.gz:Feb 21 08:42:42 opal ippl: ICMP message type > destination unreachable - bad port from 127.0.0.1 > /var/log/all.log.3.gz:Feb 21 08:42:52 swat kernel: spurious 8259A interrupt: > IRQ7. > /var/log/all.log.3.gz:Feb 21 08:43:04 opal ippl: port 13327 connection > attempt from 192.168.93.38 > /var/log/all.log.3.gz:Feb 21 08:43:38 pyrit ippl: ICMP message type > destination unreachable - bad port from 127.0.0.1 > /var/log/all.log.3.gz:-- > /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: Adding Swap: 96384k > swap-space (priority -1) > /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: Real Time Clock Driver > v1.10e > /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: spurious 8259A interrupt: > IRQ7. > /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: Linux Tulip driver version > 0.9.15-pre12 (Aug 9, 2002) > /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: PCI: Found IRQ 9 for > device 00:0b.0 > /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: > /dev/ide/host0/bus0/target0/lun0: [PTBL] [1869/255/63] p1 p2 p3 p4 < p5 p6 p7 > p8 > > /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: ext3: No journal on > filesystem on ide0(3,2) > /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: spurious 8259A interrupt: > IRQ7. > /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: Adding Swap: 96384k > swap-space (priority -1) > /var/log/all.log.4.gz:F
Re: Spurious 8259A?
> Listan, > > Jag har en burk där jag misstänker något håller på att rasa, bland annat > låter den annorlunda (disk, fläkt, cpu-fläkt?) än vad jag tror den gjort > tidigare. > > En fsck på disken i samband med boot går igenom, men däremot hittar jag > meddelanden i loggen: Kernel spurious 8259A interupt; IRQ7 på två > ställen. Någon som vet vad det gäller? Kan det ha något samband med > någon fläkt vars lager är på upphällningen? Något med temperaturen? Kan > jag friskriva disken? > > /Anders W ... Från: "Intel386TM EX Embedded Microprocessor User' s Manual" Intel Corporation 1996 Order Number 272485-002 (går förmodligen att ladda ner från nätet) 9.4.3 Spurious Interrupts For both edge and level-triggered interrupts, a high level must be maintained on the IR line until after the falling edge of the first INTA# pulse (see Figure 9-18). A spurious interrupt request is generated if this stipulation is not met. A spurious interrupt on any IR line generates the same vector number as an IR7 request. The spurious interrupt, however, does not set the in-service bit for IR7. Therefore, an IR7 interrupt service routine must check the in-service register to determine whether the interrupt source was a valid IR7 (the in-service bit is set) or a spurious interrupt (the in-service bit is cleared). (IR = interrupt request) Dvs. en sk. "surious interrupt" inträffar bara för irq7, men manualen säger ingenting varför de inträffar. Från kärnan: $ sed -ne '272,286p' /usr/src/kernel-source-2.4.20/arch/i386/kernel/i8259.c /* * Lightweight spurious IRQ detection. We do not want * to overdo spurious IRQ handling - it's usually a sign * of hardware problems, so we only do the checks we can * do without slowing down good hardware unnecesserily. * * Note that IRQ7 and IRQ15 (the two spurious IRQs * usually resulting from the 8259A-1|2 PICs) occur * even if the IRQ is masked in the 8259A. Thus we * can check spurious 8259A IRQs without doing the * quite slow i8259A_irq_real() call for every IRQ. * This does not cover 100% of spurious interrupts, * but should be enough to warn the user that there * is something bad going on ... */ Från loggar: # zgrep -C -i spurious /var/log/all.log.?.gz /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: ext3: No journal on filesystem on ide0(3,2) /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: Adding Swap: 96384k swap-space (priority -1) /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: spurious 8259A interrupt: IRQ7. /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: Real Time Clock Driver v1.10e /var/log/all.log.2.gz:Feb 22 10:10:18 swat kernel: Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002) /var/log/all.log.3.gz:Feb 21 08:42:38 pyrit ippl: ICMP message type destination unreachable - bad port from 127.0.0.1 /var/log/all.log.3.gz:Feb 21 08:42:42 opal ippl: ICMP message type destination unreachable - bad port from 127.0.0.1 /var/log/all.log.3.gz:Feb 21 08:42:52 swat kernel: spurious 8259A interrupt: IRQ7. /var/log/all.log.3.gz:Feb 21 08:43:04 opal ippl: port 13327 connection attempt from 192.168.93.38 /var/log/all.log.3.gz:Feb 21 08:43:38 pyrit ippl: ICMP message type destination unreachable - bad port from 127.0.0.1 /var/log/all.log.3.gz:-- /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: Adding Swap: 96384k swap-space (priority -1) /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: Real Time Clock Driver v1.10e /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: spurious 8259A interrupt: IRQ7. /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002) /var/log/all.log.3.gz:Feb 21 16:18:48 swat kernel: PCI: Found IRQ 9 for device 00:0b.0 /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: /dev/ide/host0/bus0/target0/lun0: [PTBL] [1869/255/63] p1 p2 p3 p4 < p5 p6 p7 p8 > /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: ext3: No journal on filesystem on ide0(3,2) /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: spurious 8259A interrupt: IRQ7. /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: Adding Swap: 96384k swap-space (priority -1) /var/log/all.log.4.gz:Feb 20 07:39:24 swat kernel: Real Time Clock Driver v1.10e /var/log/all.log.5.gz:Feb 19 08:53:01 swat kernel: /dev/ide/host0/bus0/target0/lun0: [PTBL] [1869/255/63] p1 p2 p3 p4 < p5 p6 p7 p8 > /var/log/all.log.5.gz:Feb 19 08:53:01 swat kernel: ext3: No journal on filesystem on ide0(3,2) /var/log/all.log.5.gz:Feb 19 08:53:01 swat kernel: spurious 8259A interrupt: IRQ7. /var/log/all.log.5.gz:Feb 19 08:53:01 swat kernel: Adding Swap: 96384k swap-space (priority -1) /var/log/all.log.5.gz:Feb 19 08:53:01 swat kernel: Real Time Clock Driver v1.10e /var/log/all.log.5.gz:-- /
Re: Spurious 8259A?
On Tue, Feb 25, 2003 at 15:29 CET, Fredrik Persson <[EMAIL PROTECTED]> wrote: > Så jag tror inte att det är där ditt problem ligger. Vad meddelandet > gäller har jag dock ingen aning om. Vart leder IRQ 7? Vad ger 'cat > /proc/interrupts' ? Vet inte riktigt hur jag ska förklara det, men följande kom jag fram till efter några korta efterforskningar i kärnans källkod: Meddelande kommer från /usr/src/linux/arch/i386/kernel/i8259.c och kort kommer meddelandet ifrån initieringen av avbrottshanteraren. Iaf om man har satt CONFIG_X86_LOCAL_APIC=Y ... Blev det lite klarare? Om inte: läs kommentarerna i källkoden, de förklarar ganska bra. mvh -- +---+ | Johan Björklund <[EMAIL PROTECTED]> http://whero.net/ | | PGP = 813B 014F C0FA B56C FA70 31DC 1C11 3A20 B02B C881 | +---+ | HEAD CRASH!! FILES LOST!! | Details at 11. + -- - --- -- -
Re: Spurious 8259A?
Anders Wallenquist <[EMAIL PROTECTED]> writes: > En fsck på disken i samband med boot går igenom, men däremot hittar jag > meddelanden i loggen: Kernel spurious 8259A interupt; IRQ7 på två > ställen. Denne besked plejer at betyde at kernen har modtaget et interrupt som der ikke er noget hardware der vil kendes ved. Det er altid IRQ7, det er vidst PIC'en der sætter den til det. -- Peter Makholm | I laugh in the face of danger. Then I hide until [EMAIL PROTECTED] | it goes away http://hacking.dk | -- Xander
Re: Spurious 8259A?
> Listan, Speak, and the lista shall heed thy call... (oops, spelat för mycket RPG nu igen). > Jag har en burk där jag misstänker något håller på att rasa, bland annat > låter den annorlunda (disk, fläkt, cpu-fläkt?) än vad jag tror den gjort > tidigare. Detta bör inte ha med nedanstående att göra. > En fsck på disken i samband med boot går igenom, men däremot hittar jag > meddelanden i loggen: Kernel spurious 8259A interupt; IRQ7 på två > ställen. Någon som vet vad det gäller? Kan det ha något samband med > någon fläkt vars lager är på upphällningen? Något med temperaturen? Kan > jag friskriva disken? Det där meddelandet har jag haft sedan urminnes tider på min huvudburk (hemma på skrivbordet). Jag har aldrig upplevt problem som jag kunnat koppla till det där, och jag har därför inte brytt mig om det. Däremot dyker det upp då och då på någon av de fyra andra debianburkarna i huset. Ingen av dem har problem med fläktlager eller diskar. Så jag tror inte att det är där ditt problem ligger. Vad meddelandet gäller har jag dock ingen aning om. Vart leder IRQ 7? Vad ger 'cat /proc/interrupts' ? /Fredrik Persson
Spurious 8259A?
Listan, Jag har en burk där jag misstänker något håller på att rasa, bland annat låter den annorlunda (disk, fläkt, cpu-fläkt?) än vad jag tror den gjort tidigare. En fsck på disken i samband med boot går igenom, men däremot hittar jag meddelanden i loggen: Kernel spurious 8259A interupt; IRQ7 på två ställen. Någon som vet vad det gäller? Kan det ha något samband med någon fläkt vars lager är på upphällningen? Något med temperaturen? Kan jag friskriva disken? /Anders W -- Anders Wallenquist <[EMAIL PROTECTED]> Kreawit
