On Thu, 2010-08-19 at 01:21 +0200, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > - The very same kernel image does not break when booted via tftp here. > > It really seems to need a boot of the kernel image from the hard drive > > to get the issue. However, having the rootfs over NFS or on the hdd does > > not seem to make any difference. This could be the sign of a mishandled > > early access fault, which would be confirmed by your trace showing that > > the double fault handler is called. > > Probably the sign that how the NIC is configured causes the interrupt or > not when re-enabling hardware interrupt: when network booting, the > bootloader or BIOS PXE loader leaves the NIC correctly disabled so that > no interupt can be generated. >
Actually, the issue is that some device is raising an IRQ before the kernel enters mem_init and raises a fault to test the write protect feature. At this point, the kernel did disable interrupts at CPU level (we do have an early local_irq_disable_hw() hanging around in start_kernel() to ensure that anyway). However, it might happen that the fault virtualization code introduced by the pipeline spuriously re-enables them, causing havoc. At this stage of the init process (i.e. when checking whether the CPU honors the wp bit), we just can't take any interrupt yet, since the pipeline did not fully initialize, and the kernel did not even install its own handlers or configured the PIC. -- Philippe. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
