* Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Ingo Molnar <mingo@xxxxxxx> writes: > > > * Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > > > >> > >> for x86, with radix tree based irq_to_desc(), > >> removing arch_probe_nr_irqs is intentional. so we get more irq that could be used. > >> > >> wonder if the udev for some of your test system have irq number limitation? > > > > was ancient udev: udev-095-17.fc6. > > Something doesn't add up. Nowhere in the udev source is there a > single mention of irq. > > gsi have fixed interrupt numbers so that would not change. > > The dynamic irqs are allocated starting from the high gsi > and working up. > > The irq numbers that get allocated should not have changed, > unless this was actually a bug fix in this configuration. > > The other possibility is that somehow arch_probe_nr_irqs() > was returning a number greater than NR_IRQS. > > Ingo do you have any idea what NR_IRQS or nr_irqs were/are on > that failing machine? Sorry, not - and the merge window doesnt leave much time to revisit the problem right now. But the failures were very real and 100% caused by this: they resulted in non-existent /dev/sda* nodes and resulting fsck failure by rc. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|