On Tue, Apr 21, 2009 at 11:19:06AM +0900, Isaku Yamahata wrote:
> On Tue, Apr 21, 2009 at 10:27:02AM +0900, Akio Takebe wrote:
> > Hi,
> > 
> > The following changeset broke booting xen-ia64 on some kinds of ia64 boxes.
> > http://xenbits.xensource.com/ext/ia64/xen-unstable.hg/rev/3fd8f9b34941
> > 
> > The tasklet_schedule call raise_softirq().
> > Because raise_softirq() use per_cpu, if we access per_cpu before cpu_init()
> > the behavior would be unexpected.
> > 
> > I make the following patch for this investigation.
> > It can boot xen-ia64 on the ia64 boxes.
> > I'm not sure why Tiger4 can boot the latest xen-ia64.
> > I didn't find a good-looking solution, what do you think about it?
> Unfortunately, it happened to boot on my tiger4 so that I pushed out
> the change set.
> I Understood the issue. Looking into the boot sequence, it seems
> to somewhat difficult to move down init_console() after cpu_init()
> and remove all the printk() before cpu_init().
> Hmm, it needs some consideration.
> BTW, is there similar issue on ia64 linux case before?

Yes, there was.
commit 10617bbe84628eb18ab5f723d3ba35005adde143
commit c459ce8b5a7d933a3bcf6915ab17ac1e036e2ac4

The mails were
Jul 14 Christian Kande Initialization order problem
Aug 07 Luck, Tony      [RFC] Fix early access to per-cpu variables

Xen-ia64-devel mailing list

Reply via email to