linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ross Dickson <ross@datscreative.com.au>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, george@mvista.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Catching NForce2 lockup with NMI watchdog
Date: Thu, 18 Dec 2003 04:14:17 +1000	[thread overview]
Message-ID: <200312180414.17925.ross@datscreative.com.au> (raw)

>On Tue, 16 Dec 2003, George Anzinger wrote: 
 


>> How confusing :( Could you give me some idea how this works? I have tried 
> > disable_irq(0) and, as best as I can tell, it does not do the trick. The 
> > confusion I have is understanding where in the chain of hardware each of these 
> > thing is taking place. 

Here is where to find Intel's MP arch spec Maceij mentions.
I had to find it recently wrt nforce2 issues

http://www.intel.com/design/pentium/datashts/24201606.pdf

Section 3.6.1 Apic Architecture is relevant
particularly
Section 3.6.2.2 Virtual Wire Mode

<snip>
great diagram!

<snip>
> If the above variant does not work, as a last resort, the path for the 
> 8254 timer interrupt is via the 8259 reconfigured back into its usual mode 
> and then LINT0 of the BSP reconfigured for an ExtINTA APIC interrupt. 
> Additionally, since at this point the glue logic has probably already 
> locked up due to the messing done above, a few artiffical sets of double 
> INTA cycles are sent to the system bus using the RTC chip and INTIN8 
> reconfigured temporarily to send ExtINTA APIC interrupts via the 
> inter-APIC bus. 
 
> I do hope a thorough read of the description will make the available 
> variants clear. The I/O APIC input numbers may differ but so far they are 
> almost always as noted above. 
 
>  Maciej 

All good.

I would like to add a footnote to highlight a potential gotcha as I understand it.

To clarify, the xt pic 8259A does not in itself have a transparent mode as would
a logic buffer or inverter. It always needs inta cycles to function. In PIC mode
it is wired to processor pins as per old 8086 and original cpu architecture
provides the inta cycles to it (bypasses apic, apic seems off).

In virtual wire mode with the 8259A output wired either to a local apic pin on cpu
or through the io-apic. In this mode it is the local apic which has to provide the 
inta cycles on the bus back to the 8259A for it to function correctly. 

The delivery mode has to be set to ExtInt for the register associated with the pin
that the 8259A output (int on Maceij diagram) is connected to. This is the only
way to force the apic to deliver the inta cycles to the 8259A and that is how it
appears transparent to the system. Spec says there can only be one source 
register (local apic) or redirection register (ioapic) of mode ExtInt per system
regardless of how many local apic and io-apic pins it (int on Maceij diagram)
is connected to. 

Gotcha: If none are set to ExtInt then the 8259A will hang for lack of IntA 
cycles.

Section 7.5.11 covers it
24319202.pdf available here

http://www.intel.com/design/pentiumii/manuals/243192.htm

Why only one Extint source in virtual wire mode?:

The 8259A in X86 architecture systems needs two inta cycles per interrupt event.
Do not confuse them with the EOI which is software, the inta is purely hardware.
It only works properly with one source causing inta cycles. Docs I have do not
say what happens with more than one source.

How 8259A works in a nutshell (it is more complex in cascade mode).

First the 8259A gets a request from H/ware and if unmasked etc generates its int 
(int on Maceij diagram) out.  8259A then sits there waiting for Inta from cpu 
(PIC mode) or local apic (Virtual wire mode). When the inta arrives the 8259A
latches its internal ISR bit and waits for second inta. When second inta arrives
it outputs a vector onto the data bus indicating which ISR bit was set. 

If the request from H/ware is still active when the first inta arrives then we get
the correct vector number.

If it is NOT still exerted then its tough luck and the vector we get 7 for the first
8259A or 15 for the second 8259A and it is too late to try and find out where
the real source was, hence the spurious irq7 messages and corresponding
irq 7 count increase.

It is pretty bad when the apic system that is handling the 8259A in virtual
wire mode cannot get the inta to the 8259A in time while the int request
hardware is still exerting but it happens.

I certainly agree with Marceij's comments that mixed mode of having 8254 PIT
routed via the 8259A was never meant to occur alongside ioapic handling of
the other interrupts. It is very problematic not to mention confusing. 

I do not know how smoothly the apic handles the 8259A if you would be turning
that source on and off frequently.

Regards
Ross Dickson




             reply	other threads:[~2003-12-17 17:50 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-17 18:14 Ross Dickson [this message]
2003-12-17 21:41 ` Catching NForce2 lockup with NMI watchdog George Anzinger
2003-12-17 21:48 ` George Anzinger
2003-12-18  1:30   ` Ross Dickson
2003-12-18 14:32     ` Maciej W. Rozycki
2003-12-19  4:17       ` Ross Dickson
2003-12-19 15:35         ` Maciej W. Rozycki
2003-12-18 14:04 ` Maciej W. Rozycki
2003-12-18 14:22   ` Craig Bradney
2003-12-19  5:38     ` Ross Dickson
2003-12-19 10:36       ` Craig Bradney
2003-12-19  4:06   ` Ross Dickson
2003-12-19 15:33     ` Maciej W. Rozycki
  -- strict thread matches above, loose matches on Subject: below --
2003-12-13  3:56 Ross Dickson
2003-12-15 13:16 ` Maciej W. Rozycki
2003-12-07 19:58 Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered Ian Kumlien
2003-12-08  2:07 ` Ross Dickson
2003-12-09 18:12   ` Catching NForce2 lockup with NMI watchdog Ian Kumlien
2003-12-09 22:04     ` Craig Bradney
2003-12-09 23:13       ` Ian Kumlien
2003-12-10  6:14       ` Bob
2003-12-10  7:51         ` Craig Bradney
2003-12-05 22:41 b
2003-12-05 20:56 Allen Martin
2003-12-05 19:11 Allen Martin
2003-12-05 20:18 ` cheuche+lkml
2003-12-05 20:34   ` Prakash K. Cheemplavam
2003-12-05 21:02     ` Mike Fedyk
2003-12-05 20:55   ` Jesse Allen
2003-12-06  3:20   ` Jesse Allen
2003-12-05 20:36 ` Jesse Allen
2003-12-05 22:55 ` Mike Fedyk
2003-12-05 23:11   ` Craig Bradney
2003-12-05  4:54 Jesse Allen
2003-12-05  7:40 ` Mikael Pettersson
2003-12-05  8:33   ` Josh McKinney
2003-12-05 12:14     ` Mikael Pettersson
2003-12-05 14:19       ` Craig Bradney
2003-12-05 17:05         ` Craig Bradney
2003-12-05 18:11         ` Josh McKinney
2003-12-05  8:58   ` Mike Fedyk
2003-12-05 12:06     ` Mikael Pettersson
2003-12-08  2:20     ` Bob
2003-12-09 14:21       ` Maciej W. Rozycki
2003-12-09 16:35         ` Bob
2003-12-10 13:41           ` Maciej W. Rozycki
2003-12-12 16:01             ` bill davidsen
2003-12-12 16:47               ` Maciej W. Rozycki
2003-12-12 16:57                 ` Richard B. Johnson
2003-12-12 17:21                   ` Maciej W. Rozycki
2003-12-13  5:16                 ` Bill Davidsen
2003-12-15 13:23                   ` Maciej W. Rozycki
2003-12-12 22:27               ` George Anzinger
2003-12-15 13:13                 ` Maciej W. Rozycki
2003-12-15 21:42                   ` George Anzinger
2003-12-16 13:37                     ` Maciej W. Rozycki
2003-12-16 13:57                       ` Richard B. Johnson
2003-12-16 15:47                         ` Maciej W. Rozycki
2003-12-16 16:44                           ` Richard B. Johnson
2003-12-16 16:50                             ` Maciej W. Rozycki
2003-12-16 17:26                       ` George Anzinger
2003-12-16 20:54                         ` Maciej W. Rozycki
2003-12-16 21:53                           ` George Anzinger
2003-12-17 14:03                             ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200312180414.17925.ross@datscreative.com.au \
    --to=ross@datscreative.com.au \
    --cc=george@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@ds2.pg.gda.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).