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 and commit c459ce8b5a7d933a3bcf6915ab17ac1e036e2ac4 The mails were Jul 14 Christian Kande Initialization order problem and Aug 07 Luck, Tony [RFC] Fix early access to per-cpu variables thread. -- yamahata _______________________________________________ Xen-ia64-devel mailing list Xenemail@example.com http://lists.xensource.com/xen-ia64-devel