search for: jiffies_64

...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: ffffffff8140b000 8 OBJECT GLOBAL DEFAULT 8 jiffies_64 But s...

...s at a very low rate, the time between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2 and the test for timer_after_eq() will be incorrect. Credit will not be replenished and the guest may become unable to send packets (e.g., if prior to the long gap, all credit was exhausted). Use jiffies_64 variant to mitigate this problem for 32bit Dom0. Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Wei Liu <wei.liu2@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Jason Luan <jianhai.luan@oracle.com> --- drivers/net/xen-netback/common.h | 1 +...

...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 DEFAULT 8 jiffies > 11730: ffffffff8140b000 8 OBJECT GLOBAL...

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

...ch/x86_64/kernel/vmlinux.lds.S b/arch/x86_64/kernel/vmlinux.lds.S index 7c4de31..ef418b3 100644 --- a/arch/x86_64/kernel/vmlinux.lds.S +++ b/arch/x86_64/kernel/vmlinux.lds.S @@ -13,6 +13,12 @@ OUTPUT_FORMAT("elf64-x86-64", "elf64-x86 OUTPUT_ARCH(i386:x86-64) ENTRY(phys_startup_64) jiffies_64 = jiffies; +PHDRS { + text PT_LOAD FLAGS(5); /* R_E */ + data PT_LOAD FLAGS(7); /* RWE */ + user PT_LOAD FLAGS(7); /* RWE */ + note PT_NOTE FLAGS(4); /* R__ */ +} SECTIONS { . = __START_KERNEL; @@ -31,7 +37,7 @@ SECTIONS KPROBES_TEXT *(.fixup) *(.gnu.warning) - } = 0x9090 + } :text = 0x9...

...,9 +109,6 @@ unsigned long long sched_clock(void) { unsigned long long this_offset; - if (unlikely(custom_sched_clock)) - return (*custom_sched_clock)(); - /* * Fall back to jiffies if there's no TSC available: */ @@ -119,7 +117,7 @@ unsigned long long sched_clock(void) return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ); /* read the Time Stamp Counter: */ - rdtscll(this_offset); + get_scheduled_cycles(this_offset); /* return the value in ns */ return cycles_2_ns(this_offset); diff -r d58e6ddfdfa9 arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.c Thu Feb 15 23:52:4...

...,9 +109,6 @@ unsigned long long sched_clock(void) { unsigned long long this_offset; - if (unlikely(custom_sched_clock)) - return (*custom_sched_clock)(); - /* * Fall back to jiffies if there's no TSC available: */ @@ -119,7 +117,7 @@ unsigned long long sched_clock(void) return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ); /* read the Time Stamp Counter: */ - rdtscll(this_offset); + get_scheduled_cycles(this_offset); /* return the value in ns */ return cycles_2_ns(this_offset); diff -r d58e6ddfdfa9 arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.c Thu Feb 15 23:52:4...

...e) >> CYC2NS_SCALE_FACTOR; -} - /* * Scheduler clock - returns current time in nanosec units. */ -unsigned long long sched_clock(void) +unsigned long long native_sched_clock(void) { unsigned long long this_offset; @@ -110,11 +105,23 @@ unsigned long long sched_clock(void) return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ); /* read the Time Stamp Counter: */ - get_scheduled_cycles(this_offset); + rdtscll(this_offset); /* return the value in ns */ return cycles_2_ns(this_offset); } + +/* We need to define a real function for sched_clock, to override the + weak defaul...

...e) >> CYC2NS_SCALE_FACTOR; -} - /* * Scheduler clock - returns current time in nanosec units. */ -unsigned long long sched_clock(void) +unsigned long long native_sched_clock(void) { unsigned long long this_offset; @@ -110,11 +105,23 @@ unsigned long long sched_clock(void) return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ); /* read the Time Stamp Counter: */ - get_scheduled_cycles(this_offset); + rdtscll(this_offset); /* return the value in ns */ return cycles_2_ns(this_offset); } + +/* We need to define a real function for sched_clock, to override the + weak defaul...

Hi Rusty, I had a look over your 011-paravirt-head.S.patch. I'm struggling to come up with a list of any benefits over having separate entrypoints for each hypervisor. Multiple entry pros: * allows maximum startup flexibility for any given hypervisor * for Xen at least, it's pretty simple * the "what hypervisor am I under" question is answered trivially cons:

...mention this because it is probably going to * be easy to add this, and then PHDRS will be feature-complete). */ PHDRS { kernel PT_LOAD; note PT_NOTE; } /* Assignments can appear as a command in their own right (outside of a * SECTIONS command). This is equivalent to `--defsym`. */ jiffies = jiffies_64; The SECTIONS command contains the bulk of the functionality of linker scripts. The ldscript primer above already gave an overview of the main functionality needed, but here is a detailed list of the specific capabilities that are needed: - Must be able to create sections in the output. - Must b...

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

Hi Andrew, This patch series adds to the end of the existing i386-gdt-cleanups patches: allow-per-cpu-variables-to-be-page-aligned.patch i386-gdt-cleanups-use-per-cpu-variables-for-gdt-pda.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot-fix.patch i386-gdt-cleanups-clean-up-cpu_init.patch

Hi Andrew, This patch series adds to the end of the existing i386-gdt-cleanups patches: allow-per-cpu-variables-to-be-page-aligned.patch i386-gdt-cleanups-use-per-cpu-variables-for-gdt-pda.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot-fix.patch i386-gdt-cleanups-clean-up-cpu_init.patch

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which