search for: ch10lev1sec3

...ot syncing: IO-APIC + timer doesn't work!" is also clear. timer_irq_works(void) never returns 1: https://github.com/torvalds/linux/blob/d966564fcdc19e13eb6ba1fbe6b8101070339c3d/arch/x86/kernel/apic/io_apic.c#L1641 I think it happens because of jiffies (http://www.makelinux.net/books/lkd2/ch10lev1sec3#ch10fig01) It should have the same address as jiffies_64: https://github.com/torvalds/linux/blob/b66484cd74706fa8681d051840fe4b18a3da40ff/arch/x86/kernel/vmlinux.lds.S#L41 And that is true for BFD linked binary: 10595: ffffffff8140b000 8 OBJECT GLOBAL DEFAULT 8 jiffies 11730: ffffffff81...

...39;t work!" is also clear. > > timer_irq_works(void) never returns 1: > https://github.com/torvalds/linux/blob/d966564fcdc19e13eb6ba1fbe6b810 > 1070339c3d/arch/x86/kernel/apic/io_apic.c#L1641 > > I think it happens because of jiffies (http://www.makelinux.net/ > books/lkd2/ch10lev1sec3#ch10fig01) > > It should have the same address as jiffies_64: > https://github.com/torvalds/linux/blob/b66484cd74706fa8681d051840fe4b > 18a3da40ff/arch/x86/kernel/vmlinux.lds.S#L41 > > And that is true for BFD linked binary: > 10595: ffffffff8140b000 8 OBJECT GLOBAL DEFAU...

Thanks for your ideas, Sean ! >The bug is not likely to be corrupted data in the decompressed output (that is just calling into a gzip routine or something). You shouldn't have to dump/printf->trace from memory during boot to see that data since the "real" kernel binary that is being decompressed into that memory region is probably already somewhere > in your build tree