On Thu, 2008-07-31 at 14:00 +0200, Sebastien Dugue wrote: > On Thu, 31 Jul 2008 21:40:56 +1000 Michael Ellerman <[EMAIL PROTECTED]> wrote: > > > > This boot ordering stuff is pretty hairy, so I might have missed > > something, but this is how the code is ordered AFAICT: > > > > start_kernel() > > init_IRQ() > > ... > > local_irq_enable() > > ... > > rest_init() > > kernel_thread() > > kernel_init() > > smp_prepare_cpus() > > smp_xics_probe() (via > > smp_ops->probe()) > > > > > > What's stopping us from taking an irq between local_irq_enable() and > > smp_xics_probe() ? Is it just that no one's request_irq()'ed them yet? > > It's hairy, I agree, but as you've mentioned no one has done a request_irq() > at that point. The first one to do it is smp_xics_probe() for the IPI.
Hmm, I don't think that's strong enough. I can trivially cause irqs to fire during a kexec reboot just by mashing the keyboard. And during a kdump boot all sorts of stuff could be firing. Even during a clean boot, from firmware, I don't think we can guarantee that nothing's going to fire. .. after a bit of testing .. It seems it actually works (sort of). xics_remap_irq() calls irq_radix_revmap_lookup(), which calls: ptr = radix_tree_lookup(&host->revmap_data.tree, hwirq); And because host->revmap_data.tree was zalloc'ed we trip on the first check here: cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
