On Wednesday, 13 June 2007 00:24, Siddha, Suresh B wrote: > On Wed, Jun 13, 2007 at 12:16:08AM +0200, Rafael J. Wysocki wrote: > > On Tuesday, 12 June 2007 23:56, Siddha, Suresh B wrote: > > > 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. > > > > OK > > > > In that case, do I understand correctly that we are going to implement the > > Eric's algorithm above for the CPU hotunplugging on x86 once you've figured > > out what's the E75xx issue? > > That is the idea. Thanks.
OK, thanks. Eric, would you agree to follow this plan without making the entire CPU hotplug (on x86) depend on BROKEN? Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
