On Tue, 2006-10-10 at 08:44 +0800, Zou, Nanhai wrote:
> > -----Original Message-----
> > From: Khalid Aziz [mailto:[EMAIL PROTECTED]
> > Sent: 2006年10月10日 6:42
> > To: Zou, Nanhai
> > Cc: Horms; Fastboot mailing list
> > Subject: RE: [Fastboot] kexec_fake_sal_rendez broken?
> >
> > On Sun, 2006-10-08 at 10:13 +0800, Zou, Nanhai wrote:
> > > > -----Original Message-----
> > > > From: Khalid Aziz [mailto:[EMAIL PROTECTED]
> > > > Sent: 2006年10月2日 23:33
> > > > To: Horms
> > > > Cc: Zou, Nanhai; Fastboot mailing list
> > > > Subject: Re: [Fastboot] kexec_fake_sal_rendez broken?
> > > >
> > > > On Mon, 2006-10-02 at 17:29 +0900, Horms wrote:
> > > > > Hi Nanhai,
> > > > >
> > > > > I have been looking a little into kexec_fake_sal_rendez,
> > > > > as I think that kexec for xen will need to use it as I don't
> > > > > believe that any CPU hotplug infastructure is present there.
> > > > >
> > > > > Unfortunately, when compile linux without CPU hotplug support -
> > > > > thus forcing the kexec_fake_sal_rendez method of shutting down CPUs
> > > > > to be used - kexec no longer functions unless I set maxcpus=1 when
> > > > > kexecing into the second kernel.
> > > > >
> > > > > Is this a problem that you are aware of?
> > > > > Do you have any idea where I should poke around to fix it?
> > > > >
> > > >
> > > > That code has not caused problems on single cpu machine in the past. I
> > > > will take a look.
> > > >
> > >
> > >
> > > Hi Aziz,
> > > I think calling to the fake_rendz code need to be relocated to control
> > page.
> > > Otherwise there will be problem if kexec into a different kernel. New
> > > kernel
> > may overlap to the area of fake_rendz code linked in first kernel.
> > >
> > > Thanks
> > > Zou Nan hai
> >
> > Hi Nan hai,
> >
> > kexec_fake_sal_rendez is already on control page. Are you suggesting we
> > move kexec_stop_this_cpu() as well to control page? Theoretically since
> > we call smp_call_function() with wait=0, it is possible that monarch
> > might start copying new kernel over before other procesors have had a
> > chance to process IPI and execute kexec_stop_this_cpu(). In such a case,
> > there is a possibility kexec_stop_this_cpu() code might be overwritten
> > with something else before execution. The only right way I can think of
> > to solve this is to establish a handshake between monarch and slave
> > processors so monarch can ensure all slave processors have stopped
> > before it starts copying new kernel over. We could instead call
> > smp_call_function() with wait=1, but that somehow makes me nervous.
> >
> > --
> I mean in smp.c, you call kexec_fake_sal_rendez directly.
> So even kexec_fake_sal_rendez is also in control page, kernel will still
> call to the linked in virtual address.
> Thanks
> Zou Nan hai
Ah, that. I fixed that in my test kernel, but must have forgotten to
send a patch out. I will send out a patch.
--
Khalid
====================================================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
[EMAIL PROTECTED] Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
