Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling

["Siddha, Suresh B" <suresh.b.siddha@intel.com>]

On Tue, Jun 12, 2007 at 10:52:09PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 12 June 2007 20:19, Eric W. Biederman wrote:
> > Because you are calling unfixably broken code.  That should be a decent
> > incentive to do something else won't it?
> 
> Can you please tell me _what_ else can be done?
> 
> > IOAPICs do not support what the code is doing here.  There is lots of
> > practical evidence including bad experiences and practical tests that
> > support this.
> 
> Well, AFAICS, Suresh has tried to debug one failing case recently without
> any consistent conclusions.  I don't know of any other test cases (links,
> please?).

Rafael, Darrick Wong's issue looks different and hence I was motivated to
look and fix if it was a SW issue. For now, I am not able to comprehend
what is happening on Darrick Wong's system. Need more help from Darrick
as he has the golden failing system.

Meanwhile I talked to our hardware folks about the irq migration in general.

One good news is that future versions of chipsets will have an Interrupt
Remapping feature(for more details please refer to
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf)
where in we can reliably migrate the irq to someother cpu in the process
context.

And for the existing platforms, chipset folks don't see a reason why the
Eric's algorithm(specified below) should fail.

Eric's algorithm for level triggered(edge triggered should be easier than
level triggered):
- Mask the irq in process context.
- Poll RIRR until an ack of for the irq was not pending.
- Migrate the irq.

Eric had a problem of stuck remote IRR on E75xx chipset with this algorithm
and my next step is to reproduce this issue on this platform and understand
the behavior.

thanks,
suresh