Hello all,
on my system I'm having the usual (already known from Con Kolivas
earlier dynticks patches) problems with missed ticks: I have to generate
keyboard or mouse interrupts to let my system proceed with booting
(semi-)properly.
Once in X11 it's better (due to many IRQs being triggered here, I assume),
but still not perfect.
This did "work properly" (for whatever reason) with 2.6.19-rc1-mm* and got
broken once going to -rc2-mm*, IIRC. -rc4-mm1 is stock version without
any local patches (for accurate bug reporting).
x86 UP Athlon 1200, VIA chipset.
Probably some problem with VIA chipsets and APIC, PIT, ...?
Would be nice to get this to work properly, anything I should try to debug?
Andreas Mohr
00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP]
00:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (
rev 46)
00:0a.0 Multimedia audio controller: Aureal Semiconductor Vortex 2 (rev fe)
00:0c.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev
08)
00:0d.0 Multimedia audio controller: Aztech System Ltd 3328 Audio (rev 10)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/
C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 A
C97 Audio Controller (rev 50)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon
9000] (rev 01)
01:00.1 Display controller: ATI Technologies Inc Radeon RV250 [Radeon 9000] (Sec
ondary) (rev 01)
$ cat /proc/acpi/processor/CPU0/*
processor id: 0
acpi id: 0
bus mastering control: no
power management: yes
throttling control: no
limit interface: no
<not supported>
active state: C2
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 2000 usec
states:
C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00012840] duration[00000000000000000000]
*C2: type[C2] promotion[--] demotion[C1] latency[100] usage[00087632] duration[00000000002335220011]
<not supported>
# cat /proc/timer_stats
Timerstats sample period: 9.36316 s
474, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick)
4, 3172 konsole schedule_timeout (process_timeout)
21, 2547 Xorg do_setitimer (it_real_fn)
188, 3149 knotify schedule_timeout (process_timeout)
13, 0 swapper hrtimer_restart_sched_tick (hrtimer_sched_tick)
56, 3141 artsd schedule_timeout (process_timeout)
37, 1515 modprobe usb_hcd_submit_urb (rh_timer_func)
10, 3141 artsd do_setitimer (it_real_fn)
2, 2547 Xorg schedule_timeout (process_timeout)
19, 3134 kicker schedule_timeout (process_timeout)
1, 3079 ssh-agent do_setitimer (it_real_fn)
1, 3078 ssh-agent do_setitimer (it_real_fn)
5, 0 swapper __netdev_watchdog_up (dev_watchdog)
5, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)
1, 2937 preload schedule_timeout (process_timeout)
10, 3153 klipper schedule_timeout (process_timeout)
9, 3130 kwin schedule_timeout (process_timeout)
9, 3127 kwrapper do_nanosleep (hrtimer_wakeup)
3, 2481 cupsd schedule_timeout (process_timeout)
9, 2925 apache schedule_timeout (process_timeout)
1, 2496 hald schedule_timeout (process_timeout)
4, 2147 ifconfig e100_up (e100_watchdog)
4, 2513 hald-addon-stor do_nanosleep (hrtimer_wakeup)
1, 3446 bash start_this_handle (commit_timeout)
1, 3446 cat start_this_handle (commit_timeout)
1, 2905 cron do_nanosleep (hrtimer_wakeup)
2, 3122 kded schedule_timeout (process_timeout)
1, 2859 chronyd schedule_timeout (process_timeout)
1, 131 pdflush start_this_handle (commit_timeout)
1, 1 init schedule_timeout (process_timeout)
1, 0 swapper page_writeback_init (wb_timer_fn)
1, 4 events/0 do_cache_clean (delayed_work_timer_fn)
1, 1 swapper init_nonfatal_mce_checker (delayed_work_timer_fn)
1, 3120 klauncher schedule_timeout (process_timeout)
1, 1 swapper neigh_table_init_no_netlink (neigh_periodic_timer)
1, 1 swapper rekey_seq_generator (delayed_work_timer_fn)
1, 2621 nmbd schedule_timeout (process_timeout)
901 total events, 100.19 events/sec
.config excerpt (timer-related settings mostly):
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=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"
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
#
# Processor type and features
#
CONFIG_HIGH_RES_TIMERS=y
CONFIG_NO_HZ=y
# CONFIG_SMP is not set
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_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 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
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_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/hda2"
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_HOTKEY=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_SONY is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=m
# CONFIG_ACPI_SBS is not set
#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_DISPLAY_BLANK=y
CONFIG_APM_RTC_IS_GMT=y
CONFIG_APM_ALLOW_INTS=y
# CONFIG_APM_REAL_MODE_POWER_OFF is not set
On Wed, 2006-11-01 at 15:07 +0100, Andreas Mohr wrote:
> Hello all,
>
> on my system I'm having the usual (already known from Con Kolivas
> earlier dynticks patches) problems with missed ticks: I have to generate
> keyboard or mouse interrupts to let my system proceed with booting
> (semi-)properly.
> Once in X11 it's better (due to many IRQs being triggered here, I assume),
> but still not perfect.
>
> This did "work properly" (for whatever reason) with 2.6.19-rc1-mm* and got
> broken once going to -rc2-mm*, IIRC. -rc4-mm1 is stock version without
> any local patches (for accurate bug reporting).
>
> x86 UP Athlon 1200, VIA chipset.
>
> Probably some problem with VIA chipsets and APIC, PIT, ...?
>
> Would be nice to get this to work properly, anything I should try to debug?
Can you try:
http://tglx.de/projects/hrtimers/2.6.19-rc4-mm1/patch-2.6.19-rc4-mm1-hrt-dyntick1.patch
on top of -mm please? Can you mail me a boot log of that ?
Thanks,
tglx
Hi,
On Wed, Nov 01, 2006 at 10:51:56PM +0100, Thomas Gleixner wrote:
> On Wed, 2006-11-01 at 15:07 +0100, Andreas Mohr wrote:
> > x86 UP Athlon 1200, VIA chipset.
> >
> > Probably some problem with VIA chipsets and APIC, PIT, ...?
> >
> > Would be nice to get this to work properly, anything I should try to debug?
>
> Can you try:
>
> http://tglx.de/projects/hrtimers/2.6.19-rc4-mm1/patch-2.6.19-rc4-mm1-hrt-dyntick1.patch
You applied a nice lameness filter, by secretly making sure that -dyntick1
is unavailable and a new -dyntick2 took its place, right? ;)
> on top of -mm please? Can you mail me a boot log of that ?
Attached (went the extra mile and made sure to reply this night already).
It seems we have C2 APIC issues here, from a cursory glance at the log...
Note that it stalls directly after the
input: AT Translated Set 2 keyboard as /class/input/input0
line (from that point on it needs additional "support" via keyboard press).
Don't tell me my chipset is so awfully buggy that the best thing would be
to swap mainboards immediately...
Thanks!!
(especially for your nice dynticks work)
Andreas Mohr
On Thu, 2006-11-02 at 01:18 +0100, Andreas Mohr wrote:
> You applied a nice lameness filter, by secretly making sure that -dyntick1
> is unavailable and a new -dyntick2 took its place, right? ;)
:)
> It seems we have C2 APIC issues here, from a cursory glance at the log...
Yes, it stops in C2. Probably I was a bit over optimistic with the
detection. Well it detects it, but not without help from the keyboard
operator :(
> Note that it stalls directly after the
> input: AT Translated Set 2 keyboard as /class/input/input0
> line (from that point on it needs additional "support" via keyboard press).
Does it resume normal operation after the "ACPI: lapic on CPU 0 stops in
C2[C2]" message ?
It is easy to fix by marking all AMDs broken again, but I really want to
avoid this.
tglx
On Thu, 2006-11-02 at 08:31 +0100, Thomas Gleixner wrote:
> Does it resume normal operation after the "ACPI: lapic on CPU 0 stops in
> C2[C2]" message ?
>
> It is easy to fix by marking all AMDs broken again, but I really want to
> avoid this.
Doo, found a brown paperbag bug.
Index: linux-2.6.19-rc4-mm1/drivers/acpi/processor_idle.c
===================================================================
--- linux-2.6.19-rc4-mm1.orig/drivers/acpi/processor_idle.c 2006-11-02 08:01:52.000000000 +0100
+++ linux-2.6.19-rc4-mm1/drivers/acpi/processor_idle.c 2006-11-02 09:09:23.000000000 +0100
@@ -575,8 +575,8 @@ static void acpi_processor_idle(void)
*/
if (pr->power.timer_state_unstable <
pr->power.timer_broadcast_on_state) {
- pr->power.timer_state_unstable =
- pr->power.timer_broadcast_on_state;
+ pr->power.timer_broadcast_on_state =
+ pr->power.timer_state_unstable;
acpi_propagate_timer_broadcast(pr);
}
On Thu, 2006-11-02 at 09:14 +0100, Thomas Gleixner wrote:
> On Thu, 2006-11-02 at 08:31 +0100, Thomas Gleixner wrote:
> > Does it resume normal operation after the "ACPI: lapic on CPU 0 stops in
> > C2[C2]" message ?
> >
> > It is easy to fix by marking all AMDs broken again, but I really want to
> > avoid this.
>
> Doo, found a brown paperbag bug.
I uploaded a new queue with more fixups.
http://tglx.de/projects/hrtimers/2.6.19-rc4-mm1/patch-2.6.19-rc4-mm1-hrt-dyntick4.patch
tglx
Hi,
On Thu, Nov 02, 2006 at 06:22:08PM +0100, Thomas Gleixner wrote:
> I uploaded a new queue with more fixups.
Still no go, stalled after the
ACPI: (supports S0 S1 S3 S4 S5)
line this time (probably statistical fluke though).
dmesg.log.gz attached.
# uname -a
Linux andi 2.6.19-rc4-mm1-hrt-dyntick4 #1 Fri Nov 10 03:19:06 CET 2006 i686 GNU/Linux
Note that the first boot became unstable somehow (net connections stalled,
eventually it hung completely while trying to switch to another tty;
Magic SysRq reboot worked). I'm working within second boot right now.
Anything I should investigate? I'll see what I can do for now...
Thanks!
Andreas Mohr
Hi,
On Thu, Nov 02, 2006 at 08:28:12PM +0100, Andreas Mohr wrote:
> Hi,
>
> On Thu, Nov 02, 2006 at 06:22:08PM +0100, Thomas Gleixner wrote:
> > I uploaded a new queue with more fixups.
>
> Still no go, stalled after the
> ACPI: (supports S0 S1 S3 S4 S5)
> line this time (probably statistical fluke though).
> dmesg.log.gz attached.
This time with apic=debug (attached), and now we have messages such as:
lapic timer verify: delta 10754906 pmtimer 11935676 (2557644) lapic 1180770(0 1180770 1180807) on cpu 0
which means that the timer *is* unstable.
I'm starting to wonder what I could debug here...
Andreas Mohr
Hi,
[CC'd Len since he might want/be able to help despite this being VIA issue ;)]
On Thu, Nov 02, 2006 at 09:34:30PM +0100, Andreas Mohr wrote:
> This time with apic=debug (attached), and now we have messages such as:
>
> lapic timer verify: delta 10754906 pmtimer 11935676 (2557644) lapic 1180770(0 1180770 1180807) on cpu 0
>
> which means that the timer *is* unstable.
>
> I'm starting to wonder what I could debug here...
OK, I debugged it some more, and I noticed some very strange ACPI status
again...
$ cat /proc/acpi/processor/CPU0/*
processor id: 0
acpi id: 0
bus mastering control: no
power management: no
throttling control: no
limit interface: no
<not supported>
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 2000 usec
states:
<not supported>
HOWEVER (dmesg.log.gz):
ACPI: CPU0 (power states: C1[C1] C2[C2])
and
ACPI: lapic on CPU 0 stops in C2[C2]
So according to /proc/acpi/ I don't even *have* C1/C2, however
it's still being used.
Oh, wait, I just realized that of course I'm in 2.6.19-rc1-mm1 currently,
however booting into 2.6.19-rc4-mm1 *does* list C1/C2 states in /proc/acpi/,
in contrast to -rc1-mm1.
That would explain why 2.6.19-rc1-mm1 has no issues whatsoever with dynticks
- since it never even enters C1/C2!
OK, so dynticks in Linux > 2.6.19-rc1-mm1 broke because ACPI C1/C2
suddenly became available which killed my VIA APIC timer in C2.
How probable is it that the APIC timer got killed due to mis-programming
in Linux versus VIA chipset design garbage probability? I.e. do you think
there's a chance to fix C2 malfunction by going into the innards of
VIA chipsets operation?
How useful would it be to simply disable C2 operation (but not C1)
in CONFIG_NO_HZ mode after's been determined to kill APIC timer?:
lapic timer verify: delta 3435285 pmtimer 3469523 (743469) lapic 34238(0 34238 3
4338) on cpu 0
lapic timer verify: delta 6022 pmtimer 46853 (10040) lapic 40831(0 40831 40914)
on cpu 0
lapic timer verify: delta 66814 pmtimer 136000 (29143) lapic 69186(0 69186 69284
) on cpu 0
lapic timer verify: delta 19658 pmtimer 22092 (4734) lapic 2434(0 2434 2469) on
cpu 0
lapic timer verify: delta 9967 pmtimer 22624 (4848) lapic 12657(0 12657 12693) o
n cpu 0
lapic timer verify: delta 9681 pmtimer 21429 (4592) lapic 11748(0 11748 11945) o
n cpu 0
lapic timer verify: delta 59879 pmtimer 94822 (20319) lapic 34943(0 34943 35029)
on cpu 0
lapic timer verify: delta 34878 pmtimer 52668 (11286) lapic 17790(0 17790 17876)
on cpu 0
lapic timer verify: delta 32436 pmtimer 78992 (16927) lapic 46556(0 46556 46641)
on cpu 0
lapic timer verify: delta 10450 pmtimer 75002 (16072) lapic 64552(0 64552 64590)
on cpu 0
ACPI: lapic on CPU 0 stops in C2[C2]
Hmm, processor_idle.c in current -dynticks4 seems to contain code to do just
that: disable C states after they've been found harmful to timer operation?
But somehow it doesn't seem to work for me here, obviously.
If I don't get any further input on that I'll try to debug it myself soon.
http://www.linuxsymposium.org/proceedings/reprints/Reprint-Brown-OLS2004.pdf
is quite informative about APIC timer issues etc., BTW.
Andreas Mohr
On Fri, 2006-11-03 at 01:06 +0100, Andreas Mohr wrote:
> ACPI: lapic on CPU 0 stops in C2[C2]
> How probable is it that the APIC timer got killed due to mis-programming
> in Linux versus VIA chipset design garbage probability? I.e. do you think
> there's a chance to fix C2 malfunction by going into the innards of
> VIA chipsets operation?
> How useful would it be to simply disable C2 operation (but not C1)
> in CONFIG_NO_HZ mode after's been determined to kill APIC timer?:
No, we better disable local apic timer in that case. What happens if you
boot your machine with ACPI disabled ?
tglx
Hi,
On Mon, Nov 06, 2006 at 05:20:32PM +0100, Thomas Gleixner wrote:
> On Fri, 2006-11-03 at 01:06 +0100, Andreas Mohr wrote:
> > ACPI: lapic on CPU 0 stops in C2[C2]
>
> > How probable is it that the APIC timer got killed due to mis-programming
> > in Linux versus VIA chipset design garbage probability? I.e. do you think
> > there's a chance to fix C2 malfunction by going into the innards of
> > VIA chipsets operation?
> > How useful would it be to simply disable C2 operation (but not C1)
> > in CONFIG_NO_HZ mode after's been determined to kill APIC timer?:
>
> No, we better disable local apic timer in that case. What happens if you
> boot your machine with ACPI disabled ?
Oh, interesting. Why??
Anyway, acpi=off works perfectly fine (still running -rc4-mm1-dynticks4),
as does setting
max_cstate = ACPI_STATE_C1;
in acpi_processor_power_init()!
(currently writing this mail with this hack ;)
So why not simply do
max_cstate = ACPI_STATE_C1;
in case acpi_timer_check_state():
+/*
+ * Some BIOS implementations switch to C3 in the published C2 state. This seems
+ * to be a common problem on AMD boxen.
+ */
yells?
This definitely *is* the problem with my AMD Athlon BIOS, it seems...
Or is it an advantage to switch off lapic in case of C2 brokenness since
that will enable us to still safely drive C2 with dynticks despite those
BIOS bugs or what?
(if I managed to draw the right conclusions about your lapic statement,
that is...)
BTW, my GUI with dynticks seems quite a lot quicker than without.
Or is that a placebo? I don't think it is...
Thanks!
Andreas Mohr
On Monday 06 November 2006 15:58, Andreas Mohr wrote:
> > > How useful would it be to simply disable C2 operation (but not C1)
> > > in CONFIG_NO_HZ mode after's been determined to kill APIC timer?:
If the goal is saving power, then disabling dynticks will likely
be more attractive than disabling C2. Perhaps you can measure it?
eg. simply run "bltk -I" to measure idle battery life (http://sourceforge.net/projects/bltk)
But this is even more true when talking about C3 -- it certainly saves more
power than dynticks does. This is true for the example system here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2006-bltk-paper.pdf
So given that C3 on every known system that has shipped to date
breaks the LAPIC timer (and apparently this applies to C2 on these AMD boxes),
dynticks needs a solid story for co-existing with C3.
If (HPET re-programming latency is not prohibititive)
If (there is an HPET/thread)
then using the HPET/thread instead of the LAPIC timer is the way to go
else If ( there is an HPET/core, or /package)
then using the HPET for the timer interrupt to a group of threads
maybe the way to go. (interrupt needs to be re-sent to the actual
destination via IPI)
else if (PIT re-programming latency is not prohibitive)
then using PIT to cpu0 and IPI to the cpu of interest would work
else
The HW isn't well suited to dynticks,
fall back to a static HZ mode at boot-time.
Though I suppose that "static HZ" could actually be a variable
set at boot-time rather than the compile-time scheme we use today.
Eg. if a box has high-latency C-states, it certainly wants hz<=64
Boxes with just C1 will not care and would go for hz= faster
-Len
* Len Brown <[email protected]> wrote:
> So given that C3 on every known system that has shipped to date breaks
> the LAPIC timer (and apparently this applies to C2 on these AMD
> boxes), dynticks needs a solid story for co-existing with C3.
check out 2.6.19-rc4-mm2: it detects this breakage and works it around
by using the PIT as a clock-events source. That did the trick on my
laptop which has this problem too. I agree with you that degrading the
powersaving mode is not an option.
we've got a question about HPET: it seems all recent hardware has it,
but the BIOS rarely mentions it, so the Linux driver does not enable
HPET. Is there any chance to enable HPET (in the chipset?) - this would
probably be a higher-quality clock-events source than the PIT.
Ingo
Hi,
On Tue, Nov 07, 2006 at 01:41:16AM -0500, Len Brown wrote:
> On Monday 06 November 2006 15:58, Andreas Mohr wrote:
>
> > > > How useful would it be to simply disable C2 operation (but not C1)
> > > > in CONFIG_NO_HZ mode after's been determined to kill APIC timer?:
>
> If the goal is saving power, then disabling dynticks will likely
> be more attractive than disabling C2. Perhaps you can measure it?
> eg. simply run "bltk -I" to measure idle battery life (http://sourceforge.net/projects/bltk)
Surely the CMOS battery?? Seriously, no battery here anywhere ;)
Anyway, I was already afraid that I didn't have any of my *two* different
power measurement devices here, but then I found one in the drawer
(Conrad EKM 265, to be precise).
The results are (waited for values to settle down each time):
-dyntick4, C1, CONFIG_NO_HZ:
83.9W KDE idle, 95.2W bash while 1
-dyntick4, C2 (C1-only hack disabled, kernel rebuilt), CONFIG_NO_HZ off:
84.4W KDE idle, 95.4W bash while 1
-dyntick4, acpi=off (i.e. APM active), -dynticks:
85.5W KDE idle, 95.5W bash while 1
Bet you didn't see this coming...
Again, this is Athlon 1200 *desktop*, with some EPOX VIA motherboard
("8K5A3+" ??).
Note that even with dynticks disabled did I have a pause on boot where I had
to fiddle with the keyboard once to continue booting, IOW our APIC timer
probing disrupts normal interrupt processing due to C2 -> C3 AMD BIOS bug.
We might want to fix probing to not require manual generation of the next
interrupt event due to APIC timer temporarily being "dead".
> But this is even more true when talking about C3 -- it certainly saves more
> power than dynticks does. This is true for the example system here:
> http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2006-bltk-paper.pdf
>
> So given that C3 on every known system that has shipped to date
> breaks the LAPIC timer (and apparently this applies to C2 on these AMD boxes),
> dynticks needs a solid story for co-existing with C3.
Indeed, we need a good and flexible fallback mechanism.
However I would slightly slant dynticks towards being active even in cases
where it actually happens to consume *slightly* more power due to C2 disabled,
since it *seems* that CPU load is lower with dynticks
(less timer background load) / desktop timing is slightly more precise.
And we all want fast desktops that are waaaaay better than XP, right?
Andreas Mohr
On Tue, 2006-11-07 at 09:07 +0100, Ingo Molnar wrote:
> * Len Brown <[email protected]> wrote:
>
> > So given that C3 on every known system that has shipped to date breaks
> > the LAPIC timer (and apparently this applies to C2 on these AMD
> > boxes), dynticks needs a solid story for co-existing with C3.
>
> check out 2.6.19-rc4-mm2: it detects this breakage and works it around
> by using the PIT as a clock-events source. That did the trick on my
> laptop which has this problem too. I agree with you that degrading the
> powersaving mode is not an option.
Andreas tested with the latest -mm1-hrt-dyntick patches, so he has all
the checks already. The thing which worries me here is, that we detect
the breakage and use the fallback path already, but it still has this
weird effect on that system, while others just work fine. I'm cooking a
more brute force fallback right now.
tglx
* Andreas Mohr <[email protected]> wrote:
> The results are (waited for values to settle down each time):
>
> -dyntick4, C1, CONFIG_NO_HZ:
> 83.9W KDE idle, 95.2W bash while 1
> -dyntick4, C2 (C1-only hack disabled, kernel rebuilt), CONFIG_NO_HZ off:
> 84.4W KDE idle, 95.4W bash while 1
> -dyntick4, acpi=off (i.e. APM active), -dynticks:
> 85.5W KDE idle, 95.5W bash while 1
>
> Bet you didn't see this coming...
interesting that there's any savings from dynticks in this workload.
When the CPU is busy then dynticks generates the usual HZ scheduler
tick.
could you try the same measurement with a completely idle system too?
That is where dynticks has its true effects: longer idle intervals. (but
even on an idle system dynticks might not make a difference unless the
hardware can utilize the much larger and more predictable idle times
that dynticks offers.)
Ingo
Hi,
On Tue, Nov 07, 2006 at 09:25:35AM +0100, Thomas Gleixner wrote:
> Andreas tested with the latest -mm1-hrt-dyntick patches, so he has all
> the checks already. The thing which worries me here is, that we detect
> the breakage and use the fallback path already, but it still has this
> weird effect on that system, while others just work fine. I'm cooking a
> more brute force fallback right now.
That's what I didn't understand all that time:
I do get the "C2 unusable, kills APIC timer" message, so I expected the code
to not use C2, but it seems it did use it (causing hangs) and I didn't
fully analyze the code whether it truly tried to prevent C2 here
(handling was a bit opaque to me, should have analyzed it
more thoroughly to get to know exactly what happens).
And like I said, brutally hard-wiring max_cstate to C1 already fixed
dynticks things for me, so it seems as if it still touched C2 before.
Andreas Mohr
On Tue, 2006-11-07 at 10:16 +0100, Andreas Mohr wrote:
> Hi,
>
> On Tue, Nov 07, 2006 at 09:25:35AM +0100, Thomas Gleixner wrote:
> > Andreas tested with the latest -mm1-hrt-dyntick patches, so he has all
> > the checks already. The thing which worries me here is, that we detect
> > the breakage and use the fallback path already, but it still has this
> > weird effect on that system, while others just work fine. I'm cooking a
> > more brute force fallback right now.
>
> That's what I didn't understand all that time:
> I do get the "C2 unusable, kills APIC timer" message, so I expected the code
> to not use C2, but it seems it did use it (causing hangs) and I didn't
> fully analyze the code whether it truly tried to prevent C2 here
> (handling was a bit opaque to me, should have analyzed it
> more thoroughly to get to know exactly what happens).
>
> And like I said, brutally hard-wiring max_cstate to C1 already fixed
> dynticks things for me, so it seems as if it still touched C2 before.
Yes, it leaves the C states untouched, it uses (should use) PIT instead
of the local APIC timer. I'm a bit confused, why this does not work on
your box.
tglx
On Tue, 2006-11-07 at 10:28 +0100, Thomas Gleixner wrote:
> > That's what I didn't understand all that time:
> > I do get the "C2 unusable, kills APIC timer" message, so I expected the code
> > to not use C2, but it seems it did use it (causing hangs) and I didn't
> > fully analyze the code whether it truly tried to prevent C2 here
> > (handling was a bit opaque to me, should have analyzed it
> > more thoroughly to get to know exactly what happens).
> >
> > And like I said, brutally hard-wiring max_cstate to C1 already fixed
> > dynticks things for me, so it seems as if it still touched C2 before.
>
> Yes, it leaves the C states untouched, it uses (should use) PIT instead
> of the local APIC timer. I'm a bit confused, why this does not work on
> your box.
Can you try the patch below please ? I just noticed, that the local APIC
gets reprogrammed before we switch back from PIT, which is perfectly
fine, but maybe your box does not like that treatment. If this does not
help, I'm going to do the never switch back from PIT hackery which I
wanted to avoid for performance reasons.
tglx
Index: linux-2.6.19-rc4-mm1/arch/i386/kernel/apic.c
===================================================================
--- linux-2.6.19-rc4-mm1.orig/arch/i386/kernel/apic.c 2006-11-07 10:33:56.000000000 +0100
+++ linux-2.6.19-rc4-mm1/arch/i386/kernel/apic.c 2006-11-07 10:33:18.000000000 +0100
@@ -100,6 +100,7 @@ static struct clock_event_device lapic_c
*/
struct lapic_event_device {
struct clock_event_device evdev;
+ enum clock_event_mode mode;
unsigned long last_delta;
unsigned long counter;
};
@@ -224,9 +225,11 @@ static void lapic_next_event(unsigned lo
struct lapic_event_device *ldev;
ldev = container_of(evt, struct lapic_event_device, evdev);
- ldev->last_delta = delta;
- apic_write_around(APIC_TMICT, delta);
+ if (ldev->mode == CLOCK_EVT_PERIODIC) {
+ ldev->last_delta = delta;
+ apic_write_around(APIC_TMICT, delta);
+ }
}
/*
@@ -257,7 +260,7 @@ static void lapic_timer_setup(enum clock
apic_write_around(APIC_LVTT, v);
break;
}
-
+ ldev->mode = mode;
local_irq_restore(flags);
}
Hi,
On Tue, Nov 07, 2006 at 10:45:58AM +0100, Thomas Gleixner wrote:
> On Tue, 2006-11-07 at 10:28 +0100, Thomas Gleixner wrote:
> > Yes, it leaves the C states untouched, it uses (should use) PIT instead
> > of the local APIC timer. I'm a bit confused, why this does not work on
> > your box.
>
> Can you try the patch below please ? I just noticed, that the local APIC
> gets reprogrammed before we switch back from PIT, which is perfectly
> fine, but maybe your box does not like that treatment. If this does not
> help, I'm going to do the never switch back from PIT hackery which I
> wanted to avoid for performance reasons.
I applied the patch, the changes *are* in the tree and I did create and
install a new image (with CONFIG_NO_HZ re-enabled and C1 hard-wiring removed),
but it failed again, completely. The usual hang during boot with
keyboard activity required, and then it didn't even manage to finish booting
(I probably was too slow in generating the necessary amount of events).
Let me think a bit about that stuff, maybe I'll be able to figure out what's
happening on my system. Or any other ideas?
(since I would like to somehow get this resolved without less than perfect
workarounds if possible)
Andreas Mohr
On Tue, 2006-11-07 at 23:27 +0100, Andreas Mohr wrote:
> I applied the patch, the changes *are* in the tree and I did create and
> install a new image (with CONFIG_NO_HZ re-enabled and C1 hard-wiring removed),
> but it failed again, completely. The usual hang during boot with
> keyboard activity required, and then it didn't even manage to finish booting
> (I probably was too slow in generating the necessary amount of events).
>
> Let me think a bit about that stuff, maybe I'll be able to figure out what's
> happening on my system. Or any other ideas?
> (since I would like to somehow get this resolved without less than perfect
> workarounds if possible)
Yes, I'm going to drop the detection as it can never be perfect and
enforce the PIT usage on UP boxen, as it seems that the lapic / BIOS
crap is more or less unfixable. Working on a patch against rc5-mm1 right
now.
tglx
> > > > > How useful would it be to simply disable C2 operation (but not C1)
> > > > > in CONFIG_NO_HZ mode after's been determined to kill APIC timer?:
> >
> > If the goal is saving power, then disabling dynticks will likely
> > be more attractive than disabling C2. Perhaps you can measure it?
> (Conrad EKM 265, to be precise).
> The results are (waited for values to settle down each time):
>
> -dyntick4, C1, CONFIG_NO_HZ:
> 83.9W KDE idle, 95.2W bash while 1
> -dyntick4, C2 (C1-only hack disabled, kernel rebuilt), CONFIG_NO_HZ off:
> 84.4W KDE idle, 95.4W bash while 1
> -dyntick4, acpi=off (i.e. APM active), -dynticks:
> 85.5W KDE idle, 95.5W bash while 1
>
> Bet you didn't see this coming...
>
> Again, this is Athlon 1200 *desktop*, with some EPOX VIA motherboard
> ("8K5A3+" ??).
Yes, I assumed you were running on a laptop...
These three measurements tell me that there is no significant
power savings difference between these configurations on this system.
One has to wonder why the hardware vendor supports C2 on this box,
as its sole function seems to be to break the local APIC timer...
BTW. when I've had to measure small idle power differences, I've found
variance is smaller when I run at init 1.
> > But this is even more true when talking about C3 -- it certainly saves more
> > power than dynticks does. This is true for the example system here:
> > http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2006-bltk-paper.pdf
> >
> > So given that C3 on every known system that has shipped to date
> > breaks the LAPIC timer (and apparently this applies to C2 on these AMD boxes),
> > dynticks needs a solid story for co-existing with C3.
>
> Indeed, we need a good and flexible fallback mechanism.
> However I would slightly slant dynticks towards being active even in cases
> where it actually happens to consume *slightly* more power due to C2 disabled,
> since it *seems* that CPU load is lower with dynticks
> (less timer background load) / desktop timing is slightly more precise.
> And we all want fast desktops that are waaaaay better than XP, right?
1.
I don't expect dynticks to save significant power on the desktop.
(5-10% would be significant, 1% is not significant)
2.
I do expect dynticks to reduce the load on un-modified virtual guest OSs.
3.
I do expect dynticks it to reduce power on highly power managed mobile systems.
I believe that either #2 or #3 by themselves justify deploying dynticks.
cheers,
-Len
On Tuesday 07 November 2006 03:07, Ingo Molnar wrote:
> > So given that C3 on every known system that has shipped to date breaks
> > the LAPIC timer (and apparently this applies to C2 on these AMD
> > boxes), dynticks needs a solid story for co-existing with C3.
>
> check out 2.6.19-rc4-mm2: it detects this breakage and works it around
> by using the PIT as a clock-events source. That did the trick on my
> laptop which has this problem too. I agree with you that degrading the
> powersaving mode is not an option.
>
> we've got a question about HPET: it seems all recent hardware has it,
> but the BIOS rarely mentions it, so the Linux driver does not enable
> HPET. Is there any chance to enable HPET (in the chipset?) - this would
> probably be a higher-quality clock-events source than the PIT.
If Windows enumerates and uses the HPET on a box, then Linux
should be able to use the HPET on that box too.
I belive that Venki has looked at some of the HPET enumeration issues,
and maybe he has some suggestions. Is there an example system
on-hand where we know Windows works and Linux does not?
-Len
>-----Original Message-----
>From: Len Brown [mailto:[email protected]]
>Sent: Monday, November 13, 2006 10:34 PM
>To: Ingo Molnar
>Cc: Len Brown; Andreas Mohr; Thomas Gleixner;
>[email protected]; Pallipadi, Venkatesh
>Subject: Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ
>required) [2.6.18-rc4-mm1]
>
>On Tuesday 07 November 2006 03:07, Ingo Molnar wrote:
>> > So given that C3 on every known system that has shipped to
>date breaks
>> > the LAPIC timer (and apparently this applies to C2 on these AMD
>> > boxes), dynticks needs a solid story for co-existing with C3.
>>
>> check out 2.6.19-rc4-mm2: it detects this breakage and works
>it around
>> by using the PIT as a clock-events source. That did the trick on my
>> laptop which has this problem too. I agree with you that
>degrading the
>> powersaving mode is not an option.
>>
>> we've got a question about HPET: it seems all recent
>hardware has it,
>> but the BIOS rarely mentions it, so the Linux driver does not enable
>> HPET. Is there any chance to enable HPET (in the chipset?) -
>this would
>> probably be a higher-quality clock-events source than the PIT.
>
>If Windows enumerates and uses the HPET on a box, then Linux
>should be able to use the HPET on that box too.
>
>I belive that Venki has looked at some of the HPET enumeration issues,
>and maybe he has some suggestions. Is there an example system
>on-hand where we know Windows works and Linux does not?
>
There are two things that can be happening when OS does not see HPET in
ACPI.
- BIOS did enable HPET in chipset and did not communicate it to OS.
- BIOS did nothing to enable HPET in chipset.
The quirk below tries to find the HPET base address in case 1. But in
case 2 this will also fail as HPTC will be 0 below (Probably we can
still assume default base address of 0xFED00000 and probe there. But I
am still checking on that). I just added couple of chipset ids that I
could test on...
On the systems that I tested, HPTC was zero (case 2 above) and patch
below did not really help.
I am building on this patch to enable HPET in late init stage based on
the the quirk information. Will be interesting to see what this patch
says on other ICH based systems that don't have HPET info in ACPI.
Thanks,
Venki
--------------
PCI quirk to force enable HPET, even when BIOS does not report it
to OS in traditional ACPI table way.
Only handles few PCI_IDS at the moment. If we need it for wider use, we
should add all ICH7, ICH8, ICH9 (may be ICH6 as well) IDs.
Signed-off-by: Venkatesh Pallipadi <[email protected]>
Index: linux-2.6.19-rc-mm/arch/i386/kernel/quirks.c
===================================================================
--- linux-2.6.19-rc-mm.orig/arch/i386/kernel/quirks.c
+++ linux-2.6.19-rc-mm/arch/i386/kernel/quirks.c
@@ -48,3 +48,34 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_E7525_MCH, quirk_intel_irqbalance);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_E7520_MCH, quirk_intel_irqbalance);
#endif
+
+static void __init force_enable_hpet(struct pci_dev *dev)
+{
+ u32 val, rcba, addr;
+ void __iomem *base;
+
+ pci_read_config_dword(dev, 0xF0, &rcba);
+ /* use bits 31:14, 16 kB aligned */
+ base = ioremap_nocache(rcba & 0xFFFFC000, 0x4000);
+ printk("HPTC: RCBA Base is 0x%x\n", rcba & 0xFFFFC000);
+ if (base == NULL)
+ return;
+
+ /* read the Function Disable register, dword mode only */
+ val=readl(base + 0x3404);
+ printk("HPTC: RCBA 0x3404 is 0x%x\n", val);
+
+ if (!(val & 0x80))
+ return;
+
+ printk("HPTC: HPTC enabled\n");
+
+ val = val & 0x3;
+ addr = 0xFED00000 | (val << 12);
+ iounmap(base);
+ printk("HPTC: HPET located at 0x%x\n", addr);
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_ICH6_1, force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_ESB2_0, force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_ICH7_31, force_enable_hpet);
Hi,
On Tue, Nov 14, 2006 at 09:21:02AM -0800, Pallipadi, Venkatesh wrote:
> >I belive that Venki has looked at some of the HPET enumeration issues,
> >and maybe he has some suggestions. Is there an example system
> >on-hand where we know Windows works and Linux does not?
> >
>
> There are two things that can be happening when OS does not see HPET in
> ACPI.
> - BIOS did enable HPET in chipset and did not communicate it to OS.
> - BIOS did nothing to enable HPET in chipset.
I'm sure you've already seen
http://semthex.freeflux.net/blog/archive/2006/10/21/hpet-to-be-or-not-to-be.html
... or not?
Hmm, hopefully it's easy to research where to enable HPET
(if there is one at all!) on an el-cheapo VIA chipset...
Many thanks for your patch! (even though currently Intel-only)
Andreas Mohr
On Tue, Nov 14, 2006 at 06:30:54PM +0100, Andreas Mohr wrote:
> Hmm, hopefully it's easy to research where to enable HPET
> (if there is one at all!) on an el-cheapo VIA chipset...
http://forum.insanelymac.com/index.php?showtopic=31399&pid=219051&st=0&#entry219051
"The VIA VT8237 chipset also support HPET."
And this is confirmed by:
http://www.nabble.com/-PATCH--HPET:-do-not-use-64-bit-reads-t2500136.html
"However, there is no guarantee that the timer actually has 64 bits, the
specification only recommends it. My x86-64 system has a 32-bit timer
(AMD64 with a VT8237 southbridge). "
Hmm, and I'm afraid I have a VT8235 only which possibly doesn't have HPET :-P
A relatively detailed (covers Windows XP timer details) HPET etc.
x86 timers discussion is at
"[Comp-arch] x86 High Precision Event Timers support"
https://www.gelato.unsw.edu.au/archives/comp-arch/2006-June/001320.html
Andreas Mohr
>-----Original Message-----
>From: Andreas Mohr [mailto:[email protected]]
>Sent: Tuesday, November 14, 2006 9:31 AM
>To: Pallipadi, Venkatesh
>Cc: Len Brown; Ingo Molnar; Andreas Mohr; Thomas Gleixner;
>[email protected]; Van De Ven, Arjan
>Subject: Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ
>required) [2.6.18-rc4-mm1]
>
>Hi,
>
>On Tue, Nov 14, 2006 at 09:21:02AM -0800, Pallipadi, Venkatesh wrote:
>> >I belive that Venki has looked at some of the HPET
>enumeration issues,
>> >and maybe he has some suggestions. Is there an example system
>> >on-hand where we know Windows works and Linux does not?
>> >
>>
>> There are two things that can be happening when OS does not
>see HPET in
>> ACPI.
>> - BIOS did enable HPET in chipset and did not communicate it to OS.
>> - BIOS did nothing to enable HPET in chipset.
>
>I'm sure you've already seen
>http://semthex.freeflux.net/blog/archive/2006/10/21/hpet-to-be-
>or-not-to-be.html
>... or not?
Hmmm.. I hadn't seen this before..
>
>Hmm, hopefully it's easy to research where to enable HPET
>(if there is one at all!) on an el-cheapo VIA chipset...
>
>Many thanks for your patch! (even though currently Intel-only)
Yes. This should be easy to do for any chipset. It should be documented
somewhere in the chipset documentation. Atleast it is documented on ICH
specification :).
Thanks,
Venki
Hi,
On Tue, Nov 14, 2006 at 10:06:37AM -0800, Pallipadi, Venkatesh wrote:
> >Hmm, hopefully it's easy to research where to enable HPET
> >(if there is one at all!) on an el-cheapo VIA chipset...
> >
> >Many thanks for your patch! (even though currently Intel-only)
>
> Yes. This should be easy to do for any chipset. It should be documented
> somewhere in the chipset documentation. Atleast it is documented on ICH
> specification :).
OK, I just managed to get hold of both VT8237 *and* VT8235 specs.
VT8237 is documented to have HPET.
The convenient thing is that on VT8235 *exactly* that register space where
8237 has its HPET is marked as "reserved" ;)
(i.e. there's a register hole which has exactly the size of the
HPET range).
IOW, we might be lucky and 8235 already has an initial implementation of
HPET available (which even works??).
OK, so let's provide some more details:
VT8237 has a PCI device 17 function 0 part ("Bus Control and Power Management")
which has a Programmable Chip Select Control block at 0x5D to 0x6B.
Offset 0x68 is HPET Control, RW, which has an Enable bit (default Disabled)
at bit 7 (MSB).
0x69 to 0x6B is HPET Base Address, RW (lower 22 bits, 22-23 "Reserved").
VT8235 has exactly 0x68 to 0x6B "reserved", with valid registers both
before and thereafter.
There's also some register description about APIC timer,
maybe I'll gather something about my C2 headaches from there.
Andreas Mohr
Hi,
On Tue, Nov 14, 2006 at 09:30:17PM +0100, Andreas Mohr wrote:
> There's also some register description about APIC timer,
> maybe I'll gather something about my C2 headaches from there.
OK, offset 0x8C Host Bus Power Management Control has
(VT8235, but 8237 is same I think):
bit 0 Internal Clock Stop During Suspend (default 0)
bit 1 Internal Clock Stop During C3 (default 0) [internal PCI clock]
bit 2 Internal Clock Stop for PCI Idle (default 0)
[stop PCI clock when PCKRUN# high]
This wouldn't have anything whatsoever to do with my ACPI ""C2""
BIOS headaches, I assume??
Probably my BIOS has some of those bits tweaked to 1,
need to fiddle with pciutils a bit...
Somehow I'm getting the impression that we should have been
rewarding the BIOS with indifference all the time already in Linux,
given how *very useful* those chipset registers are...
Argh.
Burn ACPI, EFI, Real Mode, ..., let's go back to basics. :-P
Andreas Mohr
Hi,
On Tue, Nov 14, 2006 at 10:00:49PM +0100, Andreas Mohr wrote:
> OK, offset 0x8C Host Bus Power Management Control has
Ick, make the actual sub register 0x8D. Sorry for the noise.
And yes, VT8235 and VT8237 seem identical in this byte.
Andreas Mohr
Pallipadi, Venkatesh wrote:
> There are two things that can be happening when OS does not see HPET in
> ACPI.
> - BIOS did enable HPET in chipset and did not communicate it to OS.
> - BIOS did nothing to enable HPET in chipset.
>
> The quirk below tries to find the HPET base address in case 1. But in
> case 2 this will also fail as HPTC will be 0 below (Probably we can
> still assume default base address of 0xFED00000 and probe there. But I
> am still checking on that). I just added couple of chipset ids that I
> could test on...
>
> On the systems that I tested, HPTC was zero (case 2 above) and patch
> below did not really help.
>
> I am building on this patch to enable HPET in late init stage based on
> the the quirk information. Will be interesting to see what this patch
> says on other ICH based systems that don't have HPET info in ACPI.
In case anyone is interested, here is some information about the HPET on
nVidia MCP55:
With the recent update to BIOS Version 0609, ASUS has added HPET
Support and a Enable/Disable BIOS option for the M2N SLI Deluxe.
00:01.0 0601: 10de:0360 (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
00: de 10 60 03 0f 00 a0 00 a2 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 39 82
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: 43 10 39 82 00 f0 ff fe fa 3e ff 00 fa 3e ff 00
^^^^^^^^^^^
HPET base address
[ 0.000000] ACPI: HPET id: 0x10de8201 base: 0xfefff000
50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 ff
70: 10 00 ff ff c5 80 00 00 00 00 44 19 40 06 00 03
^^
c1 => HPET disabled
c5 => HPET enabled
80: 09 10 00 00 82 0d 00 00 c0 00 00 01 f0 00 00 00
90: 80 08 00 00 00 00 00 00 21 47 95 86 ef cd ab 00
a0: 01 00 30 c0 00 00 00 00 00 00 00 00 00 00 00 00
b0: 90 02 ef 02 00 08 5f 08 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00
HTH,
--
Tobias PGP: http://9ac7e0bc.uguu.de