Regression 2.6.27 - 2.6.28

2009-01-25 Thread Jörg-Volker Peetz 
Hi,

with kernel 2.6.28 and 2.6.28.1 while in X with active DPMS screen off (xset
dpms force off) the CPU does not go into C3 state when idle.
With 2.6.27.10 and 2.6.27.12 the CPU does fall into C3 state when idle as
observed with powertop 1.11.

Hardware is a laptop with AMD Turion 64 MT-40, ATI RS480, IXP SB400, Radeon
XPRESS 200M chip set.

System is Debian testing (libc 2.7, gcc 4.3.2, X.Org Server 1.4.2, radeon module
4.3.0) with self-compiled kernels from kernel.org (.config appended).

This happens also on an older laptop with Intel Pentium 4 mobile and Radeon
Mobility 7500.

Do I need a newer version of the X server?
-- 
Regards, Jörg-Volker.

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28.1
# Sun Jan 18 22:04:33 2009
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=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_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
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_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_GROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY 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
CONFIG_CLASSIC_RCU=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_VSMP is not set
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_MEMTEST 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
#

Re: Regression 2.6.27 - 2.6.28

2009-01-27 Thread Jörg-Volker Peetz 
Michel Dänzer wrote:
 On Sun, 2009-01-25 at 20:03 +0100, Jörg-Volker Peetz wrote:
 with kernel 2.6.28 and 2.6.28.1 while in X with active DPMS screen off (xset
 dpms force off) the CPU does not go into C3 state when idle.
 With 2.6.27.10 and 2.6.27.12 the CPU does fall into C3 state when idle as
 observed with powertop 1.11.
 
 Was the DRI already enabled with the 2.6.27 kernels? If yes, you may
 need to use git bisect to find the change that introduced the problem.
 

DRI was enabled both on 2.6.27 and 2.6.28.

Today I also checked another hardware, a laptop with Pentium M CPU, Intel
chipset ICH6, and ATI M22 [Mobility Radeon X300]. Similar behavior: while in X
with active DPMS screen off (xset dpms force off) there are nearly 60
wakeups/s instead of 3 wakeups/s with DPMS disabled.

I've not done a git bisect before. It will take me a while.

-- 
Best regards,
Jörg-Volker.



--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Regression 2.6.27 - 2.6.28

2009-01-29 Thread Jörg-Volker Peetz 
Michel Dänzer wrote:
 On Tue, 2009-01-27 at 21:38 +0100, Jörg-Volker Peetz wrote:
 Michel Dänzer wrote:
 On Sun, 2009-01-25 at 20:03 +0100, Jörg-Volker Peetz wrote:
 with kernel 2.6.28 and 2.6.28.1 while in X with active DPMS screen off 
 (xset
 dpms force off) the CPU does not go into C3 state when idle.
 With 2.6.27.10 and 2.6.27.12 the CPU does fall into C3 state when idle as
 observed with powertop 1.11.
 Was the DRI already enabled with the 2.6.27 kernels? If yes, you may
 need to use git bisect to find the change that introduced the problem.

 DRI was enabled both on 2.6.27 and 2.6.28.

 Today I also checked another hardware, a laptop with Pentium M CPU, Intel
 chipset ICH6, and ATI M22 [Mobility Radeon X300]. Similar behavior: while in 
 X
 with active DPMS screen off (xset dpms force off) there are nearly 60
 wakeups/s instead of 3 wakeups/s with DPMS disabled.

 I've not done a git bisect before. It will take me a while.
 
 FWIW, I think it's most likely related to commit
 0a3e67a4caac273a3bfc4ced3da364830b1ab241 ('drm: Rework vblank-wait
 handling to allow interrupt reduction.') and friends. Can you try
 reverting that and seeing if the problem still happens?
 

You were right. I did the git bisect good 2.6.27 bad 2.6.28 and the outcome is


0a3e67a4caac273a3bfc4ced3da364830b1ab241 is first bad commit
commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241
Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Tue Sep 30 12:14:26 2008 -0700

snip

:04 04 6693836add0abd0b32db5f43d8c17d55942e2668
f7bd6a7e56d54686ae9fc6dffb3c2af7358dd787 M  drivers
:04 04 87727cb4e9481ec26a9f950a1165589b98e924a2
204fcec78ac96cf9d591527cebbc5f95367bea9c M  include


My system is

Debian 5.0 (lenny)

libc62.7-18
gcc  4.3.2-1.1
libgl1-mesa-dri  7.0.3-7
libdrm2  2.3.1-2
xserver-xorg-video-radeon1:6.9.0-1+lenny4

To measure the wakeups I used powertop 1.11

-- 
Best regards,
Jörg-Volker.


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Regression 2.6.27 - 2.6.28

2009-01-30 Thread Jörg-Volker Peetz 
Michel Dänzer wrote:
 On Thu, 2009-01-29 at 20:04 +0100, Jörg-Volker Peetz wrote:
 Michel Dänzer wrote:
 On Tue, 2009-01-27 at 21:38 +0100, Jörg-Volker Peetz wrote:
 Michel Dänzer wrote:
 On Sun, 2009-01-25 at 20:03 +0100, Jörg-Volker Peetz wrote:
 with kernel 2.6.28 and 2.6.28.1 while in X with active DPMS screen off 
 (xset
 dpms force off) the CPU does not go into C3 state when idle.
 With 2.6.27.10 and 2.6.27.12 the CPU does fall into C3 state when idle as
 observed with powertop 1.11.
 Was the DRI already enabled with the 2.6.27 kernels? If yes, you may
 need to use git bisect to find the change that introduced the problem.

 DRI was enabled both on 2.6.27 and 2.6.28.

 Today I also checked another hardware, a laptop with Pentium M CPU, Intel
 chipset ICH6, and ATI M22 [Mobility Radeon X300]. Similar behavior: while 
 in X
 with active DPMS screen off (xset dpms force off) there are nearly 60
 wakeups/s instead of 3 wakeups/s with DPMS disabled.

 I've not done a git bisect before. It will take me a while.
 FWIW, I think it's most likely related to commit
 0a3e67a4caac273a3bfc4ced3da364830b1ab241 ('drm: Rework vblank-wait
 handling to allow interrupt reduction.') and friends. Can you try
 reverting that and seeing if the problem still happens?

 You were right. I did the git bisect good 2.6.27 bad 2.6.28 and the 
 outcome is


 0a3e67a4caac273a3bfc4ced3da364830b1ab241 is first bad commit
 
 Thanks for taking the time to confirm this!
 
 
 I think this may actually be an X driver issue though; apparently it's
 telling the kernel that the CRTC is disabled, but the CRTC is obviously
 still generating vertical blank interrupts.
 
 xserver-xorg-video-radeon1:6.9.0-1+lenny4
 
 Can you try if the problem persists with current xf86-video-ati Git or
 at least the 6.10.0 release? If so, does disabling the
 radeon_crtc_modeset_ioctl() calls in legacy_crtc_dpms() in
 xf86-video-ati/src/legacy_crtc.c avoid the problem?
 
 (Alex, do you know or can you find out under what circumstances exactly
 the CRTC frame counter registers reset to 0?)
 
 

You were right again:

With

  git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati

I received version xf86-video-ati-6.10.0-56-g3a6e958, as git describe tells.
In xf86-video-ati I did

  ./autogen.sh
  make

and replaced /usr/lib/xorg/modules/drivers/radeon_drv.so and
/usr/lib/xorg/modules/multimedia/theatre*_drv.so on my system by the just
compiled ones.

After restart of the X server the following lines appeared in 
/var/log/Xorg.0.log:

 ...
compiled for 1.4.2, module version = 6.10.0
 ...
(--) RADEON(0): Chipset: ATI Radeon Mobility X300 (M22) 5460 (PCIE) (ChipID =
0x5460)
 ...
   (II) RADEON(0): Direct rendering enabled
 ...

The number of wakeups still raised to over 60/s after xset dpms force off.

But with radeon_crtc_modeset_ioctl() calls in legacy_crtc_dpms() in
xf86-video-ati/src/legacy_crtc.c disabled like this:

$ diff legacy_crtc.c legacy_crtc.c.orig
671,672c671,672
 /*if (mode == DPMSModeOff)
   radeon_crtc_modeset_ioctl(crtc, FALSE); */
---
 if (mode == DPMSModeOff)
   radeon_crtc_modeset_ioctl(crtc, FALSE);
710c710
   /* radeon_crtc_modeset_ioctl(crtc, TRUE); */
---
   radeon_crtc_modeset_ioctl(crtc, TRUE);

the wakeups stayed below 5/s after xset dpms force off.

-- 
Best regards,
Jörg-Volker.


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel