On 05/16/12 14:00, Jean-Yves Migeon wrote: > Le 16/05/12 10:45, Christoph Egger a écrit : >> On 05/13/12 13:24, Martin Husemann wrote: >> >>> On Sun, May 13, 2012 at 01:04:15PM +0200, Jean-Yves Migeon wrote: >>>> Are you sure that moving to low priority xcalls is the way to go? You >>>> can end up with CPUs not being updated because they are offline. >>> >>> Curiously, while I could reproduce the crash before this commit, I am >>> unable to reproduce it in any testing without the actual ucode update >>> happening - and I can not spot a bug in the xcall code that tries to >>> make >>> sure the number of cpus that did run the callback is == the expected >>> count >>> before returning. >>> >>> This clearly needs full analyzis. >> >> I am pleased to revert this change once this xcall(9) issue has been >> fixed. > > Sure, however I can't see where the xcall(9) code goes wrong. Care to > give more details, please? I cannot reproduce it on my side.
It is reproducable when the callback function makes an output with printf() or aprint_*(). > I am using xcall(9) to flush CPU-bound pool caches and having this sort > of bug can definitely cause serious cache incoherency that are hard to > track down afterwards. > > Is it specific to high priority xcalls? No. Christoph
