Zwane Mwaikambo <[EMAIL PROTECTED]> writes:
> On Sun, 11 Feb 2007, Eric W. Biederman wrote:
>
>> > 2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
>> > http://download.intel.com/design/chipsets/datashts/30262802.pdf
>>
>> Ouch. And this kind of thing isn't exactly uncommon.
>>
>>
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
> > 2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
> > http://download.intel.com/design/chipsets/datashts/30262802.pdf
>
> Ouch. And this kind of thing isn't exactly uncommon.
>
> However if we have the irqs also disabled in the i8259
Zwane Mwaikambo <[EMAIL PROTECTED]> writes:
>
> The 7500 issue isn't actually a race but a disease, if you mask a pending
> irq in its RTE, the PCI hub generates an INTx message corresponding to
> that irq. This apparently was done to support booting OSes without APIC
> support. So the
"Natalie Protasevich" <[EMAIL PROTECTED]> writes:
> On 2/11/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> The code currently in the kernel does:
>
> pending
> mask
> read io_apic
> ack
> reprogram vector and destination
> unmask
>
> So I guess it does retain
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
> What I am looking at doing is:
>
> mask
> read io_apic
> -- Past this point no more irqs are expected from the io_apic
> -- Now I work to drain any inflight/pending instances of the irq
> send ipi to all irq destinations cpus and wait for it to
Zwane Mwaikambo <[EMAIL PROTECTED]> writes:
> On Sat, 10 Feb 2007, Eric W. Biederman wrote:
>
>> There are not enough details in the justification to really understand
>> the issue so I'm asking to see if someone has some more details.
>>
>> The description makes the assertion that reprograming
Zwane Mwaikambo [EMAIL PROTECTED] writes:
On Sat, 10 Feb 2007, Eric W. Biederman wrote:
There are not enough details in the justification to really understand
the issue so I'm asking to see if someone has some more details.
The description makes the assertion that reprograming the ioapic
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
What I am looking at doing is:
mask
read io_apic
-- Past this point no more irqs are expected from the io_apic
-- Now I work to drain any inflight/pending instances of the irq
send ipi to all irq destinations cpus and wait for it to return
Natalie Protasevich [EMAIL PROTECTED] writes:
On 2/11/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
The code currently in the kernel does:
pending
mask
read io_apic
ack
reprogram vector and destination
unmask
So I guess it does retain the bug fix.
Zwane Mwaikambo [EMAIL PROTECTED] writes:
The 7500 issue isn't actually a race but a disease, if you mask a pending
irq in its RTE, the PCI hub generates an INTx message corresponding to
that irq. This apparently was done to support booting OSes without APIC
support. So the following would
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
http://download.intel.com/design/chipsets/datashts/30262802.pdf
Ouch. And this kind of thing isn't exactly uncommon.
However if we have the irqs also disabled in the i8259 we should
Zwane Mwaikambo [EMAIL PROTECTED] writes:
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
http://download.intel.com/design/chipsets/datashts/30262802.pdf
Ouch. And this kind of thing isn't exactly uncommon.
However if we have
On Sat, 10 Feb 2007, Eric W. Biederman wrote:
> There are not enough details in the justification to really understand
> the issue so I'm asking to see if someone has some more details.
>
> The description makes the assertion that reprograming the ioapic
> when an interrupt is pending is the
I have recently been investigating why we reprogram ioapic irqs in the
interrupt handler, because it significantly complicates the code, and
makes things more fragile. Eventually I found the commit with the
justification, see below.
There are not enough details in the justification to really
I have recently been investigating why we reprogram ioapic irqs in the
interrupt handler, because it significantly complicates the code, and
makes things more fragile. Eventually I found the commit with the
justification, see below.
There are not enough details in the justification to really
On Sat, 10 Feb 2007, Eric W. Biederman wrote:
There are not enough details in the justification to really understand
the issue so I'm asking to see if someone has some more details.
The description makes the assertion that reprograming the ioapic
when an interrupt is pending is the only
16 matches
Mail list logo
