Re: [4/5] 2.6.21-rc4: known regressions (v2)
Update: I tested 2.6.21-rc5 with the following settings # CONFIG_NO_HZ is not set CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set 1. Without additional kernel options After systems comes out of suspend to ram, I observed the following behaviour (I used s2ram from console): 1. The first disk access takes much longer than with 2.6.20 2. System clock does not advance (date always reports the same time) 3. After an attempt to switch to X, X starts drawing some windows and then hangs All 3 issues are new and did not occur under 2.6.20, so this is a regression. 2. Setting clocksource=acpi_pm After resume from RAM 1. The first disk access takes much longer than with 2.6.20 2. System clock seems to advance properly 3. After an attempt to switch to X, X works correctly So it seems that clocksource=acpi_pm can be used as a work-around. What does this tell us? I'm also not happy with how clocksource=acpi_pm performs - the system seems to be jerky, stalling for fractions of seconds now and them. TODO: test without CONFIG_HPET_TIMER. -- MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Update: I tested 2.6.21-rc5 with the following settings # CONFIG_NO_HZ is not set CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set 1. Without additional kernel options After systems comes out of suspend to ram, I observed the following behaviour (I used s2ram from console): 1. The first disk access takes much longer than with 2.6.20 2. System clock does not advance (date always reports the same time) 3. After an attempt to switch to X, X starts drawing some windows and then hangs All 3 issues are new and did not occur under 2.6.20, so this is a regression. 2. Setting clocksource=acpi_pm After resume from RAM 1. The first disk access takes much longer than with 2.6.20 2. System clock seems to advance properly 3. After an attempt to switch to X, X works correctly So it seems that clocksource=acpi_pm can be used as a work-around. What does this tell us? I'm also not happy with how clocksource=acpi_pm performs - the system seems to be jerky, stalling for fractions of seconds now and them. TODO: test without CONFIG_HPET_TIMER. -- MST - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 13:16 +0200, Ingo Molnar wrote: > * Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > > Sorry, now I'm confused. > > > Could you pls list the full set of tests you want me to run, > > > and what information to collect from each of them? > > > > 1. Test: > > I suspect step 0 would be use Linus' latest tree, ontop of -rc4: > > http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-rc4-git11.bz2 > > to make sure all post-rc4 time fixes are included. Ick, yes: The missing bits are here: http://tglx.de/private/tglx/2.6.21-rc4-pending/acpi-pm-fix.patch http://tglx.de/private/tglx/2.6.21-rc4-pending/fix-tsc-watchdog.patch tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
* Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > Sorry, now I'm confused. > > Could you pls list the full set of tests you want me to run, > > and what information to collect from each of them? > > 1. Test: I suspect step 0 would be use Linus' latest tree, ontop of -rc4: http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-rc4-git11.bz2 to make sure all post-rc4 time fixes are included. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 12:25 +0200, Michael S. Tsirkin wrote: > Sorry, now I'm confused. > Could you pls list the full set of tests you want me to run, > and what information to collect from each of them? 1. Test: add clocksource=acpi_pm to command line with your current kernel config. Check, whether the resume madness is gone 2. Test Disable CONFIG_HPET_* in the kernel config and retest Please capture both logs from boot to resume. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
> Quoting Thomas Gleixner <[EMAIL PROTECTED]>: > Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2) > > On Sun, 2007-03-25 at 12:15 +0200, Michael S. Tsirkin wrote: > > > Quoting Thomas Gleixner <[EMAIL PROTECTED]>: > > > Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2) > > > > > > On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote: > > > > > Can you please test the following: > > > > > > > > > > Add "clocksource=acpi_pm" to the kernel commandline. > > > > > > > > > > If this does not change anything, then disable CONFIG_HPET and retry. > > > > > > > > I have: > > > > $ grep CONFIG_HPET .config > > > > CONFIG_HPET_TIMER=y > > > > CONFIG_HPET_EMULATE_RTC=y > > > > # CONFIG_HPET is not set > > > > > > > > so I think all these tests were done with CONFIG_HPET=n. > > > > > > Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC > > > > Okay ... although they are in defconfig for i386, and they did not create > > problems in 2.6.20. > > I know, but we are looking for a regression and the hpet related code > _has_ changed. > > > > > Given this, does it still make sense to test clocksource=acpi_pm? > > > > > > Yes. > > > > With or without CONFIG_HPET_TIMER? > > with, as a first test. Sorry, now I'm confused. Could you pls list the full set of tests you want me to run, and what information to collect from each of them? -- MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 12:15 +0200, Michael S. Tsirkin wrote: > > Quoting Thomas Gleixner <[EMAIL PROTECTED]>: > > Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2) > > > > On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote: > > > > Can you please test the following: > > > > > > > > Add "clocksource=acpi_pm" to the kernel commandline. > > > > > > > > If this does not change anything, then disable CONFIG_HPET and retry. > > > > > > I have: > > > $ grep CONFIG_HPET .config > > > CONFIG_HPET_TIMER=y > > > CONFIG_HPET_EMULATE_RTC=y > > > # CONFIG_HPET is not set > > > > > > so I think all these tests were done with CONFIG_HPET=n. > > > > Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC > > Okay ... although they are in defconfig for i386, and they did not create > problems in 2.6.20. I know, but we are looking for a regression and the hpet related code _has_ changed. > > > Given this, does it still make sense to test clocksource=acpi_pm? > > > > Yes. > > With or without CONFIG_HPET_TIMER? with, as a first test. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
> Quoting Thomas Gleixner <[EMAIL PROTECTED]>: > Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2) > > On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote: > > > Can you please test the following: > > > > > > Add "clocksource=acpi_pm" to the kernel commandline. > > > > > > If this does not change anything, then disable CONFIG_HPET and retry. > > > > I have: > > $ grep CONFIG_HPET .config > > CONFIG_HPET_TIMER=y > > CONFIG_HPET_EMULATE_RTC=y > > # CONFIG_HPET is not set > > > > so I think all these tests were done with CONFIG_HPET=n. > > Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC Okay ... although they are in defconfig for i386, and they did not create problems in 2.6.20. > > Given this, does it still make sense to test clocksource=acpi_pm? > > Yes. With or without CONFIG_HPET_TIMER? -- MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote: > > Can you please test the following: > > > > Add "clocksource=acpi_pm" to the kernel commandline. > > > > If this does not change anything, then disable CONFIG_HPET and retry. > > I have: > $ grep CONFIG_HPET .config > CONFIG_HPET_TIMER=y > CONFIG_HPET_EMULATE_RTC=y > # CONFIG_HPET is not set > > so I think all these tests were done with CONFIG_HPET=n. Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC > Given this, does it still make sense to test clocksource=acpi_pm? Yes. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
> > - Without CONFIG_NO_HZ > > I last tested this with cd05a1f818073a623455a58e756c5b419fc98db9. > > After systems comes out of suspend to ram, I observed the following > > behaviour (I used s2ram from console): > > 1. The first disk access takes much longer than with 2.6.20 > > 2. System clock does not advance (date always reports the same time) > > 3. After an attempt to switch to X, X starts drawing some windows and > > then hangs > > > > All 3 issues are new and did not occur under 2.6.20, so this is a > > regression. > > Attached is a full dmesg from boot to resume. > > There is not much interesting to see in the log. > > Can you please test the following: > > Add "clocksource=acpi_pm" to the kernel commandline. > > If this does not change anything, then disable CONFIG_HPET and retry. I have: $ grep CONFIG_HPET .config CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set so I think all these tests were done with CONFIG_HPET=n. Given this, does it still make sense to test clocksource=acpi_pm? I attach my .config for reference. -- MST # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc4 # Wed Mar 21 18:12:22 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-work" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_NR_CPUS=8 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 09:11 +0200, Michael S. Tsirkin wrote: > > I lost track of Michaels various nested problems. > > > > Michael can you please give a summary on _all_ entries in the > > regressions list against Linus latest ? > > I tested 2 different configurations on my T60: > - With CONFIG_NO_HZ enabled. > I tested this on -rc1, and have not retested with CONFIG_NO_HZ since. > Observed behaviour: the system would not come out of suspend to RAM. > After I press Fn/F4 the crescent LED starts blinking so it seems Linux > started > doing something. > This is a problem but not a regression as such, since CONFIG_NO_HZ is new > in 2.6.21. It needs to be fixed before 2.6.21 final nevertheless. > - Without CONFIG_NO_HZ > I last tested this with cd05a1f818073a623455a58e756c5b419fc98db9. > After systems comes out of suspend to ram, I observed the following > behaviour (I used s2ram from console): > 1. The first disk access takes much longer than with 2.6.20 > 2. System clock does not advance (date always reports the same time) > 3. After an attempt to switch to X, X starts drawing some windows and then > hangs > > All 3 issues are new and did not occur under 2.6.20, so this is a > regression. > Attached is a full dmesg from boot to resume. There is not much interesting to see in the log. Can you please test the following: Add "clocksource=acpi_pm" to the kernel commandline. If this does not change anything, then disable CONFIG_HPET and retry. One thing in the log is indeed scary: [2.959150] Calibrating delay using timer specific routine.. 20089.12 BogoMIPS (lpj=100445639) This is after the reboot, but it is not related to your problem. This is a different problem, which needs urgent attention. Adrian, can you open a seperate entry for this please ? It is not a new thing, this can be observed with older kernels as well, but it needs to be addressed. It probably needs a similar solution as I did for the local apic timer calibration. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 09:11 +0200, Michael S. Tsirkin wrote: I lost track of Michaels various nested problems. Michael can you please give a summary on _all_ entries in the regressions list against Linus latest ? I tested 2 different configurations on my T60: - With CONFIG_NO_HZ enabled. I tested this on -rc1, and have not retested with CONFIG_NO_HZ since. Observed behaviour: the system would not come out of suspend to RAM. After I press Fn/F4 the crescent LED starts blinking so it seems Linux started doing something. This is a problem but not a regression as such, since CONFIG_NO_HZ is new in 2.6.21. It needs to be fixed before 2.6.21 final nevertheless. - Without CONFIG_NO_HZ I last tested this with cd05a1f818073a623455a58e756c5b419fc98db9. After systems comes out of suspend to ram, I observed the following behaviour (I used s2ram from console): 1. The first disk access takes much longer than with 2.6.20 2. System clock does not advance (date always reports the same time) 3. After an attempt to switch to X, X starts drawing some windows and then hangs All 3 issues are new and did not occur under 2.6.20, so this is a regression. Attached is a full dmesg from boot to resume. There is not much interesting to see in the log. Can you please test the following: Add clocksource=acpi_pm to the kernel commandline. If this does not change anything, then disable CONFIG_HPET and retry. One thing in the log is indeed scary: [2.959150] Calibrating delay using timer specific routine.. 20089.12 BogoMIPS (lpj=100445639) This is after the reboot, but it is not related to your problem. This is a different problem, which needs urgent attention. Adrian, can you open a seperate entry for this please ? It is not a new thing, this can be observed with older kernels as well, but it needs to be addressed. It probably needs a similar solution as I did for the local apic timer calibration. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
- Without CONFIG_NO_HZ I last tested this with cd05a1f818073a623455a58e756c5b419fc98db9. After systems comes out of suspend to ram, I observed the following behaviour (I used s2ram from console): 1. The first disk access takes much longer than with 2.6.20 2. System clock does not advance (date always reports the same time) 3. After an attempt to switch to X, X starts drawing some windows and then hangs All 3 issues are new and did not occur under 2.6.20, so this is a regression. Attached is a full dmesg from boot to resume. There is not much interesting to see in the log. Can you please test the following: Add clocksource=acpi_pm to the kernel commandline. If this does not change anything, then disable CONFIG_HPET and retry. I have: $ grep CONFIG_HPET .config CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set so I think all these tests were done with CONFIG_HPET=n. Given this, does it still make sense to test clocksource=acpi_pm? I attach my .config for reference. -- MST # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc4 # Wed Mar 21 18:12:22 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-work # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_NR_CPUS=8 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote: Can you please test the following: Add clocksource=acpi_pm to the kernel commandline. If this does not change anything, then disable CONFIG_HPET and retry. I have: $ grep CONFIG_HPET .config CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set so I think all these tests were done with CONFIG_HPET=n. Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC Given this, does it still make sense to test clocksource=acpi_pm? Yes. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Quoting Thomas Gleixner [EMAIL PROTECTED]: Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2) On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote: Can you please test the following: Add clocksource=acpi_pm to the kernel commandline. If this does not change anything, then disable CONFIG_HPET and retry. I have: $ grep CONFIG_HPET .config CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set so I think all these tests were done with CONFIG_HPET=n. Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC Okay ... although they are in defconfig for i386, and they did not create problems in 2.6.20. Given this, does it still make sense to test clocksource=acpi_pm? Yes. With or without CONFIG_HPET_TIMER? -- MST - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 12:15 +0200, Michael S. Tsirkin wrote: Quoting Thomas Gleixner [EMAIL PROTECTED]: Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2) On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote: Can you please test the following: Add clocksource=acpi_pm to the kernel commandline. If this does not change anything, then disable CONFIG_HPET and retry. I have: $ grep CONFIG_HPET .config CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set so I think all these tests were done with CONFIG_HPET=n. Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC Okay ... although they are in defconfig for i386, and they did not create problems in 2.6.20. I know, but we are looking for a regression and the hpet related code _has_ changed. Given this, does it still make sense to test clocksource=acpi_pm? Yes. With or without CONFIG_HPET_TIMER? with, as a first test. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Quoting Thomas Gleixner [EMAIL PROTECTED]: Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2) On Sun, 2007-03-25 at 12:15 +0200, Michael S. Tsirkin wrote: Quoting Thomas Gleixner [EMAIL PROTECTED]: Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2) On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote: Can you please test the following: Add clocksource=acpi_pm to the kernel commandline. If this does not change anything, then disable CONFIG_HPET and retry. I have: $ grep CONFIG_HPET .config CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set so I think all these tests were done with CONFIG_HPET=n. Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC Okay ... although they are in defconfig for i386, and they did not create problems in 2.6.20. I know, but we are looking for a regression and the hpet related code _has_ changed. Given this, does it still make sense to test clocksource=acpi_pm? Yes. With or without CONFIG_HPET_TIMER? with, as a first test. Sorry, now I'm confused. Could you pls list the full set of tests you want me to run, and what information to collect from each of them? -- MST - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 12:25 +0200, Michael S. Tsirkin wrote: Sorry, now I'm confused. Could you pls list the full set of tests you want me to run, and what information to collect from each of them? 1. Test: add clocksource=acpi_pm to command line with your current kernel config. Check, whether the resume madness is gone 2. Test Disable CONFIG_HPET_* in the kernel config and retest Please capture both logs from boot to resume. Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
* Thomas Gleixner [EMAIL PROTECTED] wrote: Sorry, now I'm confused. Could you pls list the full set of tests you want me to run, and what information to collect from each of them? 1. Test: I suspect step 0 would be use Linus' latest tree, ontop of -rc4: http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-rc4-git11.bz2 to make sure all post-rc4 time fixes are included. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 13:16 +0200, Ingo Molnar wrote: * Thomas Gleixner [EMAIL PROTECTED] wrote: Sorry, now I'm confused. Could you pls list the full set of tests you want me to run, and what information to collect from each of them? 1. Test: I suspect step 0 would be use Linus' latest tree, ontop of -rc4: http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-rc4-git11.bz2 to make sure all post-rc4 time fixes are included. Ick, yes: The missing bits are here: http://tglx.de/private/tglx/2.6.21-rc4-pending/acpi-pm-fix.patch http://tglx.de/private/tglx/2.6.21-rc4-pending/fix-tsc-watchdog.patch tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On 24/03/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote: > On 23/03/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > > > Subject: soft lockup detected on CPU#0 > > > References : http://lkml.org/lkml/2007/3/3/152 > > > Submitter : Michal Piotrowski <[EMAIL PROTECTED]> > > > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > > > Ingo Molnar <[EMAIL PROTECTED]> > > > Status : unknown > > > > Michal, > > > > any news on that one ? > > > > You said the same problem exists in 2.6.20.1. Has this been resolved in > > 2.6.20.2/3 > > Yes, I tried 2.6.20.4 and it works fine. Is it solved in Linus latest too ? Yes, it's solved. Adrian, please remove this bug from known regressions list. It's fixed in the latest -git and -stable. Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote: > On 23/03/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > > > Subject: soft lockup detected on CPU#0 > > > References : http://lkml.org/lkml/2007/3/3/152 > > > Submitter : Michal Piotrowski <[EMAIL PROTECTED]> > > > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > > > Ingo Molnar <[EMAIL PROTECTED]> > > > Status : unknown > > > > Michal, > > > > any news on that one ? > > > > You said the same problem exists in 2.6.20.1. Has this been resolved in > > 2.6.20.2/3 > > Yes, I tried 2.6.20.4 and it works fine. Is it solved in Linus latest too ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Hi, On 23/03/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > Subject: soft lockup detected on CPU#0 > References : http://lkml.org/lkml/2007/3/3/152 > Submitter : Michal Piotrowski <[EMAIL PROTECTED]> > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > Ingo Molnar <[EMAIL PROTECTED]> > Status : unknown Michal, any news on that one ? You said the same problem exists in 2.6.20.1. Has this been resolved in 2.6.20.2/3 Yes, I tried 2.6.20.4 and it works fine. Thanks, tglx Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Emil, On Fri, 2007-03-23 at 20:22 +0100, Thomas Gleixner wrote: > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > > Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time > > References : http://bugzilla.kernel.org/show_bug.cgi?id=8100 > > Submitter : Emil Karlson <[EMAIL PROTECTED]> > > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > > Status : problem is being debugged > > The problem is not reproducible on any of my machines. > I've uploaded a patch against 2.6.21-rc4 to http://tglx.de/private/tglx/2.6.21-rc4-trace/2.6.21-rc4-trace.patch.bz2 It contains all changes in Linus tree since -rc4 plus the two pending fixes (http://tglx.de/private/tglx/2.6.21-rc4-pending/) along with a backport of the latency tracer from the realtime preemption patch. Can you please apply the patch on top of -rc4 and build it with the configuration, which exposes this strange behaviour. Please enable also CONFIG_LATENCY_TRACE in the Kernel hacking menu. When the problem is visible, then run trace-it (http://tglx.de/private/tglx/2.6.21-rc4-trace/trace-it.c) as root: # trace-it >trace.txt This captures roughly one second of kernel code pathes. Please stick trace.txt into Bugzilla. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Emil, On Fri, 2007-03-23 at 20:22 +0100, Thomas Gleixner wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time References : http://bugzilla.kernel.org/show_bug.cgi?id=8100 Submitter : Emil Karlson [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged The problem is not reproducible on any of my machines. I've uploaded a patch against 2.6.21-rc4 to http://tglx.de/private/tglx/2.6.21-rc4-trace/2.6.21-rc4-trace.patch.bz2 It contains all changes in Linus tree since -rc4 plus the two pending fixes (http://tglx.de/private/tglx/2.6.21-rc4-pending/) along with a backport of the latency tracer from the realtime preemption patch. Can you please apply the patch on top of -rc4 and build it with the configuration, which exposes this strange behaviour. Please enable also CONFIG_LATENCY_TRACE in the Kernel hacking menu. When the problem is visible, then run trace-it (http://tglx.de/private/tglx/2.6.21-rc4-trace/trace-it.c) as root: # trace-it trace.txt This captures roughly one second of kernel code pathes. Please stick trace.txt into Bugzilla. Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Hi, On 23/03/07, Thomas Gleixner [EMAIL PROTECTED] wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: soft lockup detected on CPU#0 References : http://lkml.org/lkml/2007/3/3/152 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Status : unknown Michal, any news on that one ? You said the same problem exists in 2.6.20.1. Has this been resolved in 2.6.20.2/3 Yes, I tried 2.6.20.4 and it works fine. Thanks, tglx Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote: On 23/03/07, Thomas Gleixner [EMAIL PROTECTED] wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: soft lockup detected on CPU#0 References : http://lkml.org/lkml/2007/3/3/152 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Status : unknown Michal, any news on that one ? You said the same problem exists in 2.6.20.1. Has this been resolved in 2.6.20.2/3 Yes, I tried 2.6.20.4 and it works fine. Is it solved in Linus latest too ? tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On 24/03/07, Thomas Gleixner [EMAIL PROTECTED] wrote: On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote: On 23/03/07, Thomas Gleixner [EMAIL PROTECTED] wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: soft lockup detected on CPU#0 References : http://lkml.org/lkml/2007/3/3/152 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Status : unknown Michal, any news on that one ? You said the same problem exists in 2.6.20.1. Has this been resolved in 2.6.20.2/3 Yes, I tried 2.6.20.4 and it works fine. Is it solved in Linus latest too ? Yes, it's solved. Adrian, please remove this bug from known regressions list. It's fixed in the latest -git and -stable. Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 14:54 -0700, Linus Torvalds wrote: > > On Fri, 23 Mar 2007, john stultz wrote: > > > > The incorrect clocksource selection is resolved w/ this patch: > > http://lkml.org/lkml/2007/3/22/287 > > > > There is still an issue of why the PIT clocksource hangs, but for the > > moment the issue its worked-around. > > Hmm.. I haven't seen it until now. Is it waiting for something? Not really. Just waiting for Andrew to pick it up and push it on. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 23:43 +0100, Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote:
> > Thomas Gleixner wrote:
> > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > >> Subject: gettimeofday increments too slowly
> > >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
> > >> Submitter : David L <[EMAIL PROTECTED]>
> > >> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]>
> > >> commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
> > >> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
> > >> Status : problem is being debugged
> > >
> > > Patch available: http://lkml.org/lkml/2007/3/22/301
> > >
> > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4
> > >
> >
> > For the other issue raised there, clock running too slow, I now
> > realize there is a similar report:
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626
>
> That's a different one, AFAICT. Davids problem is probably caused by me
> breaking the TSC watchdog.
>
> /me orders paperbags prophylactically and goes back to look at the code
David,
can you please test the patch below ?
tglx
->
Subject: [PATCH] clocksource: Fix thinko in watchdog selection
The watchdog implementation excludes low res / non continuous
clocksources from being selected as a watchdog reference
unintentionally.
Allow using jiffies/PIT as a watchdog reference as long as no better
clocksource is available. This is necessary to detect TSC breakage on
systems, which have no pmtimer/hpet.
The main goal of the initial patch (preventing to switch to highres/nohz
when no reliable fallback clocksource is available) is still guaranteed
by the checks in clocksource_watchdog().
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 5b0e46b..fe5c7db 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -151,7 +151,8 @@ static void clocksource_check_watchdog(struct clocksource
*cs)
watchdog_timer.expires = jiffies + WATCHDOG_INTERVAL;
add_timer(_timer);
}
- } else if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS) {
+ } else {
+ if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS)
cs->flags |= CLOCK_SOURCE_VALID_FOR_HRES;
if (!watchdog || cs->rating > watchdog->rating) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Adrian Bunk wrote: >>> >> For the other issue raised there, clock running too slow, I now >> realize there is a similar report: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 > > It shouldn't be the same issue: > 2.6.20-1.2925.fc6 is based in 2.6.20.3-rc1 while this issue is a > 2.6.21-rc regression. > Or do the -rc kernels include parts of the -rt patchsets? > Sometimes problems leak from the next kernel version into -stable via the stable kernel patches. Other times the bug may have been there all along but nobody had found it yet... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, Mar 23, 2007 at 06:23:17PM -0400, Chuck Ebbert wrote: > Thomas Gleixner wrote: > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > >> Subject: gettimeofday increments too slowly > >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 > >> Submitter : David L <[EMAIL PROTECTED]> > >> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > >> commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 > >> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > >> Status : problem is being debugged > > > > Patch available: http://lkml.org/lkml/2007/3/22/301 > > > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 > > > > For the other issue raised there, clock running too slow, I now > realize there is a similar report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 It shouldn't be the same issue: 2.6.20-1.2925.fc6 is based in 2.6.20.3-rc1 while this issue is a 2.6.21-rc regression. Or do the -rc kernels include parts of the -rt patchsets? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote: > Thomas Gleixner wrote: > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > >> Subject: gettimeofday increments too slowly > >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 > >> Submitter : David L <[EMAIL PROTECTED]> > >> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > >> commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 > >> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > >> Status : problem is being debugged > > > > Patch available: http://lkml.org/lkml/2007/3/22/301 > > > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 > > > > For the other issue raised there, clock running too slow, I now > realize there is a similar report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 That's a different one, AFAICT. Davids problem is probably caused by me breaking the TSC watchdog. /me orders paperbags prophylactically and goes back to look at the code tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Thomas Gleixner wrote: > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: >> Subject: gettimeofday increments too slowly >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 >> Submitter : David L <[EMAIL PROTECTED]> >> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> >> commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 >> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> >> Status : problem is being debugged > > Patch available: http://lkml.org/lkml/2007/3/22/301 > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 > For the other issue raised there, clock running too slow, I now realize there is a similar report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 23 Mar 2007, john stultz wrote: > > The incorrect clocksource selection is resolved w/ this patch: > http://lkml.org/lkml/2007/3/22/287 > > There is still an issue of why the PIT clocksource hangs, but for the > moment the issue its worked-around. Hmm.. I haven't seen it until now. Is it waiting for something? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > This email lists some known regressions in Linus' tree compared to 2.6.20. > > If you find your name in the Cc header, you are either submitter of one > of the bugs, maintainer of an affectected subsystem or driver, a patch > of you caused a breakage or I'm considering you in any other way > possibly involved with one or more of these issues. > > Due to the huge amount of recipients, please trim the Cc when answering. > Subject: boot hangs during IDE detection (clocksource) > References : http://lkml.org/lkml/2007/3/19/465 > Submitter : Bob Tracy <[EMAIL PROTECTED]> > Caused-By : John Stultz <[EMAIL PROTECTED]> > commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd > Handled-By : John Stultz <[EMAIL PROTECTED]> > Status : problem is being debugged The incorrect clocksource selection is resolved w/ this patch: http://lkml.org/lkml/2007/3/22/287 There is still an issue of why the PIT clocksource hangs, but for the moment the issue its worked-around. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > Subject: soft lockup detected on CPU#0 > References : http://lkml.org/lkml/2007/3/3/152 > Submitter : Michal Piotrowski <[EMAIL PROTECTED]> > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > Ingo Molnar <[EMAIL PROTECTED]> > Status : unknown Michal, any news on that one ? You said the same problem exists in 2.6.20.1. Has this been resolved in 2.6.20.2/3 Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > Subject: Dynticks and High resolution Timer hanging the system > workaround: clocksource=acpi_pm > References : http://lkml.org/lkml/2007/3/7/504 > Submitter : Stephane Casset <[EMAIL PROTECTED]> > Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > Status : unknown Stephane, does the problem still exists with Linus latest ? Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
>
> Due to the huge amount of recipients, please trim the Cc when answering.
>
>
> Subject: system doesn't come out of suspend (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]>
> Soeren Sonnenburg <[EMAIL PROTECTED]>
> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
> Ingo Molnar <[EMAIL PROTECTED]>
> Tejun Heo <[EMAIL PROTECTED]>
> Rafael J. Wysocki <[EMAIL PROTECTED]>
> Status : problem is being debugged
>
>
> Subject: first disk access after resume takes several minutes
> ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> References : http://lkml.org/lkml/2007/3/8/117
> Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]>
> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
> Ingo Molnar <[EMAIL PROTECTED]>
> Status : problem is being debugged
I lost track of Michaels various nested problems.
Michael can you please give a summary on _all_ entries in the
regressions list against Linus latest ?
Thanks,
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time > References : http://bugzilla.kernel.org/show_bug.cgi?id=8100 > Submitter : Emil Karlson <[EMAIL PROTECTED]> > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > Status : problem is being debugged The problem is not reproducible on any of my machines. Emil, is it still there with Linus latest ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, Mar 23, 2007 at 08:15:38PM +0100, Thomas Gleixner wrote: > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > > Subject: gettimeofday increments too slowly > > References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 > > Submitter : David L <[EMAIL PROTECTED]> > > Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > > commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 > > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > > Status : problem is being debugged > > Patch available: http://lkml.org/lkml/2007/3/22/301 > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 As far as I understood it, this patch only fixed the bogomips issue caused by commit e9e2cdb412412326c4827fc78ba27f410d837e6e, but not the gettimeofday issue caused by commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 ? > tglx cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 20:15 +0100, Thomas Gleixner wrote: > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > > Subject: gettimeofday increments too slowly > > References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 > > Submitter : David L <[EMAIL PROTECTED]> > > Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > > commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 > > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > > Status : problem is being debugged > > Patch available: http://lkml.org/lkml/2007/3/22/301 > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 Oops. That fixed only the one half of the problem. The timeofday one persists. John, any idea ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > Subject: gettimeofday increments too slowly > References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 > Submitter : David L <[EMAIL PROTECTED]> > Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > Status : problem is being debugged Patch available: http://lkml.org/lkml/2007/3/22/301 commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[4/5] 2.6.21-rc4: known regressions (v2)
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject: system doesn't come out of suspend (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]>
Soeren Sonnenburg <[EMAIL PROTECTED]>
Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
Ingo Molnar <[EMAIL PROTECTED]>
Tejun Heo <[EMAIL PROTECTED]>
Rafael J. Wysocki <[EMAIL PROTECTED]>
Status : problem is being debugged
Subject: first disk access after resume takes several minutes
('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]>
Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
Ingo Molnar <[EMAIL PROTECTED]>
Status : problem is being debugged
Subject: Dynticks and High resolution Timer hanging the system
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/7/504
Submitter : Stephane Casset <[EMAIL PROTECTED]>
Caused-By : Thomas Gleixner <[EMAIL PROTECTED]>
Status : unknown
Subject: soft lockup detected on CPU#0
References : http://lkml.org/lkml/2007/3/3/152
Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
Ingo Molnar <[EMAIL PROTECTED]>
Status : unknown
Subject: gettimeofday increments too slowly
References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
Submitter : David L <[EMAIL PROTECTED]>
Caused-By : Thomas Gleixner <[EMAIL PROTECTED]>
commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
Status : problem is being debugged
Subject: boot hangs during IDE detection (clocksource)
References : http://lkml.org/lkml/2007/3/19/465
Submitter : Bob Tracy <[EMAIL PROTECTED]>
Caused-By : John Stultz <[EMAIL PROTECTED]>
commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
Handled-By : John Stultz <[EMAIL PROTECTED]>
Status : problem is being debugged
Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time
References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
Submitter : Emil Karlson <[EMAIL PROTECTED]>
Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
Status : problem is being debugged
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: gettimeofday increments too slowly References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 Submitter : David L [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged Patch available: http://lkml.org/lkml/2007/3/22/301 commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 20:15 +0100, Thomas Gleixner wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: gettimeofday increments too slowly References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 Submitter : David L [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged Patch available: http://lkml.org/lkml/2007/3/22/301 commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 Oops. That fixed only the one half of the problem. The timeofday one persists. John, any idea ? tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time References : http://bugzilla.kernel.org/show_bug.cgi?id=8100 Submitter : Emil Karlson [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged The problem is not reproducible on any of my machines. Emil, is it still there with Linus latest ? tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, Mar 23, 2007 at 08:15:38PM +0100, Thomas Gleixner wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: gettimeofday increments too slowly References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 Submitter : David L [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged Patch available: http://lkml.org/lkml/2007/3/22/301 commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 As far as I understood it, this patch only fixed the bogomips issue caused by commit e9e2cdb412412326c4827fc78ba27f410d837e6e, but not the gettimeofday issue caused by commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 ? tglx cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject: system doesn't come out of suspend (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Soeren Sonnenburg [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Ingo Molnar [EMAIL PROTECTED]
Tejun Heo [EMAIL PROTECTED]
Rafael J. Wysocki [EMAIL PROTECTED]
Status : problem is being debugged
Subject: first disk access after resume takes several minutes
('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Ingo Molnar [EMAIL PROTECTED]
Status : problem is being debugged
I lost track of Michaels various nested problems.
Michael can you please give a summary on _all_ entries in the
regressions list against Linus latest ?
Thanks,
tglx
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: Dynticks and High resolution Timer hanging the system workaround: clocksource=acpi_pm References : http://lkml.org/lkml/2007/3/7/504 Submitter : Stephane Casset [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] Status : unknown Stephane, does the problem still exists with Linus latest ? Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: soft lockup detected on CPU#0 References : http://lkml.org/lkml/2007/3/3/152 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Status : unknown Michal, any news on that one ? You said the same problem exists in 2.6.20.1. Has this been resolved in 2.6.20.2/3 Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: boot hangs during IDE detection (clocksource) References : http://lkml.org/lkml/2007/3/19/465 Submitter : Bob Tracy [EMAIL PROTECTED] Caused-By : John Stultz [EMAIL PROTECTED] commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd Handled-By : John Stultz [EMAIL PROTECTED] Status : problem is being debugged The incorrect clocksource selection is resolved w/ this patch: http://lkml.org/lkml/2007/3/22/287 There is still an issue of why the PIT clocksource hangs, but for the moment the issue its worked-around. thanks -john - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 23 Mar 2007, john stultz wrote: The incorrect clocksource selection is resolved w/ this patch: http://lkml.org/lkml/2007/3/22/287 There is still an issue of why the PIT clocksource hangs, but for the moment the issue its worked-around. Hmm.. I haven't seen it until now. Is it waiting for something? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Thomas Gleixner wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: gettimeofday increments too slowly References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 Submitter : David L [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged Patch available: http://lkml.org/lkml/2007/3/22/301 commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 For the other issue raised there, clock running too slow, I now realize there is a similar report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote: Thomas Gleixner wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: gettimeofday increments too slowly References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 Submitter : David L [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged Patch available: http://lkml.org/lkml/2007/3/22/301 commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 For the other issue raised there, clock running too slow, I now realize there is a similar report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 That's a different one, AFAICT. Davids problem is probably caused by me breaking the TSC watchdog. /me orders paperbags prophylactically and goes back to look at the code tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, Mar 23, 2007 at 06:23:17PM -0400, Chuck Ebbert wrote: Thomas Gleixner wrote: On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: Subject: gettimeofday increments too slowly References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 Submitter : David L [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged Patch available: http://lkml.org/lkml/2007/3/22/301 commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 For the other issue raised there, clock running too slow, I now realize there is a similar report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 It shouldn't be the same issue: 2.6.20-1.2925.fc6 is based in 2.6.20.3-rc1 while this issue is a 2.6.21-rc regression. Or do the -rc kernels include parts of the -rt patchsets? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
Adrian Bunk wrote: For the other issue raised there, clock running too slow, I now realize there is a similar report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 It shouldn't be the same issue: 2.6.20-1.2925.fc6 is based in 2.6.20.3-rc1 while this issue is a 2.6.21-rc regression. Or do the -rc kernels include parts of the -rt patchsets? Sometimes problems leak from the next kernel version into -stable via the stable kernel patches. Other times the bug may have been there all along but nobody had found it yet... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 23:43 +0100, Thomas Gleixner wrote:
On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote:
Thomas Gleixner wrote:
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: gettimeofday increments too slowly
References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
Submitter : David L [EMAIL PROTECTED]
Caused-By : Thomas Gleixner [EMAIL PROTECTED]
commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Status : problem is being debugged
Patch available: http://lkml.org/lkml/2007/3/22/301
commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4
For the other issue raised there, clock running too slow, I now
realize there is a similar report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626
That's a different one, AFAICT. Davids problem is probably caused by me
breaking the TSC watchdog.
/me orders paperbags prophylactically and goes back to look at the code
David,
can you please test the patch below ?
tglx
-
Subject: [PATCH] clocksource: Fix thinko in watchdog selection
The watchdog implementation excludes low res / non continuous
clocksources from being selected as a watchdog reference
unintentionally.
Allow using jiffies/PIT as a watchdog reference as long as no better
clocksource is available. This is necessary to detect TSC breakage on
systems, which have no pmtimer/hpet.
The main goal of the initial patch (preventing to switch to highres/nohz
when no reliable fallback clocksource is available) is still guaranteed
by the checks in clocksource_watchdog().
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 5b0e46b..fe5c7db 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -151,7 +151,8 @@ static void clocksource_check_watchdog(struct clocksource
*cs)
watchdog_timer.expires = jiffies + WATCHDOG_INTERVAL;
add_timer(watchdog_timer);
}
- } else if (cs-flags CLOCK_SOURCE_IS_CONTINUOUS) {
+ } else {
+ if (cs-flags CLOCK_SOURCE_IS_CONTINUOUS)
cs-flags |= CLOCK_SOURCE_VALID_FOR_HRES;
if (!watchdog || cs-rating watchdog-rating) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 14:54 -0700, Linus Torvalds wrote: On Fri, 23 Mar 2007, john stultz wrote: The incorrect clocksource selection is resolved w/ this patch: http://lkml.org/lkml/2007/3/22/287 There is still an issue of why the PIT clocksource hangs, but for the moment the issue its worked-around. Hmm.. I haven't seen it until now. Is it waiting for something? Not really. Just waiting for Andrew to pick it up and push it on. thanks -john - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[4/5] 2.6.21-rc4: known regressions (v2)
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject: system doesn't come out of suspend (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Soeren Sonnenburg [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Ingo Molnar [EMAIL PROTECTED]
Tejun Heo [EMAIL PROTECTED]
Rafael J. Wysocki [EMAIL PROTECTED]
Status : problem is being debugged
Subject: first disk access after resume takes several minutes
('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Ingo Molnar [EMAIL PROTECTED]
Status : problem is being debugged
Subject: Dynticks and High resolution Timer hanging the system
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/7/504
Submitter : Stephane Casset [EMAIL PROTECTED]
Caused-By : Thomas Gleixner [EMAIL PROTECTED]
Status : unknown
Subject: soft lockup detected on CPU#0
References : http://lkml.org/lkml/2007/3/3/152
Submitter : Michal Piotrowski [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Ingo Molnar [EMAIL PROTECTED]
Status : unknown
Subject: gettimeofday increments too slowly
References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
Submitter : David L [EMAIL PROTECTED]
Caused-By : Thomas Gleixner [EMAIL PROTECTED]
commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Status : problem is being debugged
Subject: boot hangs during IDE detection (clocksource)
References : http://lkml.org/lkml/2007/3/19/465
Submitter : Bob Tracy [EMAIL PROTECTED]
Caused-By : John Stultz [EMAIL PROTECTED]
commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
Handled-By : John Stultz [EMAIL PROTECTED]
Status : problem is being debugged
Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time
References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
Submitter : Emil Karlson [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Status : problem is being debugged
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
