[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: LOCKDEBUG kernel option crashes if vcpu > 1
>>>>> "Manuel" == Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
Manuel> On Fri, Nov 21, 2014 at 08:59:57PM +0530, Cherry G. Mathew wrote:
>> >>>>> "Emmanuel" == Emmanuel Dreyfus <manu%netbsd.org@localhost> writes:
Emmanuel> On Tue, Nov 18, 2014 at 10:30:28PM +0530, Cherry G. Mathew wrote:
>> >> Does the following patch work for you ?
Emmanuel> It does.
>> Cool - I'll check it in unless anyone has reasonable objections.
Manuel> Hello, it looks like your patch cause Xen (at last i386/PAE)
Manuel> to panic at boot:
Manuel> reverting this commit:
Manuel> fixes the problem for me.
Manuel> At first glance, I'd say this is because the non-boot CPUs
Manuel> are not properly xen_kpm_sync()'ed in this case. Waiting for
Manuel> mp_online is probably way too late to call xen_kpm_sync().
Hmmm, looks like you're right. I did test it on PAE before committing
though, so that seems a bit odd.
Manuel> Sorry, but I didn't clearly understand what the problem is
Manuel> with the initial code. It looks like it's using a cpu_info
Manuel> before it's fully initialised (especially the lock), right ?
Manuel> If so, what's the problem with initialising the lock before
Manuel> it's made available to CPU_INFO_FOREACH() ?
Yes, it's a per-cpu lock, which is being used before init.
Manuel> The attached patch reverts your change, and moves
Manuel> pmap-related initialisations to cpu_attach_common() where
Manuel> ci_pmap and ci_tlbstate are already set.
Looks good to me - will you commit ?
Main Index |
Thread Index |