Messages in this thread | | | Date | Wed, 23 Sep 2009 12:48:04 +0400 | Subject | Re: perf sched record hangs machine | From | Cyrill Gorcunov <> |
| |
On 9/23/09, Cyrill Gorcunov <gorcunov@gmail.com> wrote: > On 9/23/09, Ingo Molnar <mingo@elte.hu> wrote: >> >> * Ingo Molnar <mingo@elte.hu> wrote: >> >>> >>> * Peter Zijlstra <peterz@infradead.org> wrote: >>> >>> > .size default_send_IPI_self, .-default_send_IPI_self >>> > >>> > Which seems to suggest that cmove is in __prepare_ICR, but I'm not >>> > sure how that can cause a page-fault, as that function is rather >>> > pointer-less. >>> > >>> > Did it maybe delay evaluating apic->dest_logical that late, it appear >>> > to be the first usage of that argument? >>> > >>> > Ingo, any ideas? >>> >>> Yeah, the problem is: >>> >>> [ 0.042445] Local APIC not detected. Using dummy APIC emulation. >>> >>> we shouldnt be trying to program the lapic in that case - all ops >>> should be a NOP, including send-ipi-self. Cyrill? >> >> Cyrill, the right fix would be to define a: >> >> struct apic apic_none; >> >> with dummy functions injected. Set struct apic *apic to _that_, instead >> of apic_default. >> >> This means that if we manage to detect a local APIC, we will set it to >> apic_default (or some other driver) - but the bootup default will be 'no >> APIC'. >> > > May it wait till evening (i'll back from office and take a look)? > >> This is a lot cleaner and a lot less error-prone than the direct >> frobbing of the function pointers. >> >> Ingo >> >
Btw, meanwhile Chris may try to pass lapic boot-option in attempt to reenable apic via msr registers. Also (iirc) i feel we may be hiding errors if complete noop apic would be used since i belive we need to check out under which condition a particular operation is called and when apic is disabled it's mean we're switched to UP mode and inter-cpu interrupts are under suspicion too. Will take a look during ~6 hours ;)
| |