* 2.6.15-ck1 @ 2006-01-04 1:00 Con Kolivas 2006-01-04 19:05 ` 2.6.15-ck1 Dave Jones 2006-01-05 17:58 ` 2.6.15-ck1 Tomasz Torcz 0 siblings, 2 replies; 39+ messages in thread From: Con Kolivas @ 2006-01-04 1:00 UTC (permalink / raw) To: ck list; +Cc: linux kernel mailing list [-- Attachment #1: Type: text/plain, Size: 1905 bytes --] These are patches designed to improve system responsiveness and interactivity. It is configurable to any workload but the default ck patch is aimed at the desktop and cks is available with more emphasis on serverspace. Apply to 2.6.15 http://ck.kolivas.org/patches/2.6/2.6.15/2.6.15-ck1/patch-2.6.15-ck1.bz2 or server version http://ck.kolivas.org/patches/cks/patch-2.6.15-cks1.bz2 web: http://kernel.kolivas.org all patches: http://ck.kolivas.org/patches/ Split patches available. Changes from 2.6.14-ck8 Added: +2.6.15-dynticks-060101.patch +dynticks-disable_smp_config.patch Latest version of the dynticks patch. This is proving stable and effective on virtually all uniprocessor machines and will benefit systems that desire power savings. SMP kernels (even on UP machines) still misbehave so this config option is not available by default for this stable kernel. Removed: -smp-nice-support7.diff SMP Nice support is now merged in the mainline kernel -patch-2.6.14.5.bz2 Merged Modified: -2.6.14_to_staircase12.1.diff -sched-staircase12.1_12.2.patch -sched-staircase12.2_13.patch +sched-staircase13.2.patch Rolled up the staircase changes and added microoptimisations -schedbatch2.9.diff +schedbatch2.10.diff Microoptimisation -2614ck8-version.diff +2615ck1-version.patch Version Full patchlist: sched-staircase13.2.patch schedrange.diff schedbatch2.10.diff sched-iso3.2.patch 1g_lowmem1_i386.diff defaultcfq.diff isobatch_ionice2.diff rt_ionice.diff pdflush-tweaks.patch hz-default_values.patch hz-no_default_250.patch mm-swap_prefetch-19.patch vm-mapped.diff vm-lots_watermark.diff vm-background_scan-1.diff mm-kswapd_inherit_prio.patch mm-prio_dependant_scan.patch mm-batch_prio.patch 2.6.15-dynticks-060101.patch dynticks-disable_smp_config.patch 2615ck1-version.patch Cheers, Con [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 1:00 2.6.15-ck1 Con Kolivas @ 2006-01-04 19:05 ` Dave Jones 2006-01-04 19:57 ` 2.6.15-ck1 Dave Jones ` (3 more replies) 2006-01-05 17:58 ` 2.6.15-ck1 Tomasz Torcz 1 sibling, 4 replies; 39+ messages in thread From: Dave Jones @ 2006-01-04 19:05 UTC (permalink / raw) To: Con Kolivas; +Cc: ck list, linux kernel mailing list On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > +2.6.15-dynticks-060101.patch > +dynticks-disable_smp_config.patch > Latest version of the dynticks patch. This is proving stable and effective on > virtually all uniprocessor machines and will benefit systems that desire > power savings. SMP kernels (even on UP machines) still misbehave so this > config option is not available by default for this stable kernel. I've been curious for some time if this would actually show any measurable power savings. So I hooked up my laptop to a gizmo[1] that shows how much power is being sucked. both before, and after, it shows my laptop when idle is pulling 21W. So either the savings here are <1W (My device can't measure more accurately than a single watt), or this isn't actually buying us anything at all, or something needs tuning. Dave [1] http://www.thinkgeek.com/gadgets/electronic/7657/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 19:05 ` 2.6.15-ck1 Dave Jones @ 2006-01-04 19:57 ` Dave Jones 2006-01-04 20:33 ` 2.6.15-ck1 Arjan van de Ven 2006-01-04 23:10 ` 2.6.15-ck1 Con Kolivas 2006-01-04 20:38 ` 2.6.15-ck1 Grant Coady ` (2 subsequent siblings) 3 siblings, 2 replies; 39+ messages in thread From: Dave Jones @ 2006-01-04 19:57 UTC (permalink / raw) To: Con Kolivas, ck list, linux kernel mailing list On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote: > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > +2.6.15-dynticks-060101.patch > > +dynticks-disable_smp_config.patch > > Latest version of the dynticks patch. This is proving stable and effective on > > virtually all uniprocessor machines and will benefit systems that desire > > power savings. SMP kernels (even on UP machines) still misbehave so this > > config option is not available by default for this stable kernel. > > I've been curious for some time if this would actually show any measurable > power savings. So I hooked up my laptop to a gizmo[1] that shows how much > power is being sucked. > > both before, and after, it shows my laptop when idle is pulling 21W. > So either the savings here are <1W (My device can't measure more accurately > than a single watt), or this isn't actually buying us anything at all, or > something needs tuning. Ah interesting. It needs to be totally idle for a period of time before anything starts to happen at all. After about a minute of doing nothing, it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 etc.. Goes no lower than 18W, and only occasionally peaks above the old idle power usage. Not bad at all. Causing any activity at all puts it back to the 'have to wait a while for things to start happening' state again. Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 19:57 ` 2.6.15-ck1 Dave Jones @ 2006-01-04 20:33 ` Arjan van de Ven 2006-01-04 21:22 ` 2.6.15-ck1 Dave Jones ` (3 more replies) 2006-01-04 23:10 ` 2.6.15-ck1 Con Kolivas 1 sibling, 4 replies; 39+ messages in thread From: Arjan van de Ven @ 2006-01-04 20:33 UTC (permalink / raw) To: Dave Jones; +Cc: Con Kolivas, ck list, linux kernel mailing list On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote: > On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote: > > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > > +2.6.15-dynticks-060101.patch > > > +dynticks-disable_smp_config.patch > > > Latest version of the dynticks patch. This is proving stable and effective on > > > virtually all uniprocessor machines and will benefit systems that desire > > > power savings. SMP kernels (even on UP machines) still misbehave so this > > > config option is not available by default for this stable kernel. > > > > I've been curious for some time if this would actually show any measurable > > power savings. So I hooked up my laptop to a gizmo[1] that shows how much > > power is being sucked. > > > > both before, and after, it shows my laptop when idle is pulling 21W. > > So either the savings here are <1W (My device can't measure more accurately > > than a single watt), or this isn't actually buying us anything at all, or > > something needs tuning. > > Ah interesting. It needs to be totally idle for a period of time before > anything starts to happen at all. After about a minute of doing nothing, > it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 etc.. sounds like we need some sort of profiler or benchmarker or at least a tool that helps finding out which timers are regularly firing, with the aim at either grouping them or trying to reduce their disturbance in some form. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 20:33 ` 2.6.15-ck1 Arjan van de Ven @ 2006-01-04 21:22 ` Dave Jones 2006-01-04 21:40 ` [ck] 2.6.15-ck1 Radoslaw Szkodzinski ` (2 subsequent siblings) 3 siblings, 0 replies; 39+ messages in thread From: Dave Jones @ 2006-01-04 21:22 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Con Kolivas, ck list, linux kernel mailing list On Wed, Jan 04, 2006 at 09:33:56PM +0100, Arjan van de Ven wrote: > > Ah interesting. It needs to be totally idle for a period of time before > > anything starts to happen at all. After about a minute of doing nothing, > > it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 etc.. > > > sounds like we need some sort of profiler or benchmarker or at least a > tool that helps finding out which timers are regularly firing, with the > aim at either grouping them or trying to reduce their disturbance in > some form. And the winner (by a *big* margin) is... USB. rh_timer_func() gets called quite a *lot*. (Looks like every 250ms) cursor_timer_handler() too. *blinky blinky* X causes lots of hits to it_real_fn() (incidentally, the power fluctuation only happens when at the console. When in X, it never happens, so we're probably hitting this a little too often in that case). lots of apps cause process_timeout to be hit frequently. Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ck] Re: 2.6.15-ck1 2006-01-04 20:33 ` 2.6.15-ck1 Arjan van de Ven 2006-01-04 21:22 ` 2.6.15-ck1 Dave Jones @ 2006-01-04 21:40 ` Radoslaw Szkodzinski 2006-01-05 0:12 ` 2.6.15-ck1 Con Kolivas 2006-01-05 1:22 ` 2.6.15-ck1 Andi Kleen 2006-01-05 1:50 ` 2.6.15-ck1 Tony Lindgren 3 siblings, 1 reply; 39+ messages in thread From: Radoslaw Szkodzinski @ 2006-01-04 21:40 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Dave Jones, ck list, linux kernel mailing list [-- Attachment #1: Type: text/plain, Size: 716 bytes --] Arjan van de Ven wrote: > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote: > > sounds like we need some sort of profiler or benchmarker or at least a > tool that helps finding out which timers are regularly firing, with the > aim at either grouping them or trying to reduce their disturbance in > some form. > You mean something like a modification to timer debugging patch to record the last time the timer fired, right? Timertop could then detect the pattern and provide frequency, standard deviation and other statistical data. It would be much more expensive to test of course. -- GPG Key id: 0xD1F10BA2 Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 AstralStorm [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 252 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 21:40 ` [ck] 2.6.15-ck1 Radoslaw Szkodzinski @ 2006-01-05 0:12 ` Con Kolivas 2006-01-05 0:27 ` 2.6.15-ck1 Dave Jones 0 siblings, 1 reply; 39+ messages in thread From: Con Kolivas @ 2006-01-05 0:12 UTC (permalink / raw) To: ck Cc: Radoslaw Szkodzinski, Arjan van de Ven, Dave Jones, linux kernel mailing list On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote: > Arjan van de Ven wrote: > > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote: > > > > sounds like we need some sort of profiler or benchmarker or at least a > > tool that helps finding out which timers are regularly firing, with the > > aim at either grouping them or trying to reduce their disturbance in > > some form. > > You mean something like a modification to timer debugging patch to > record the last time the timer fired, right? > Timertop could then detect the pattern and provide frequency, standard > deviation and other statistical data. > It would be much more expensive to test of course. I don't think the timer debugging patch needs to give out any more info. The userspace tool should be able to do this with the amount of info the timer debugging patch is giving already. Cheers, Con ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 0:12 ` 2.6.15-ck1 Con Kolivas @ 2006-01-05 0:27 ` Dave Jones 2006-01-05 0:49 ` 2.6.15-ck1 Con Kolivas 0 siblings, 1 reply; 39+ messages in thread From: Dave Jones @ 2006-01-05 0:27 UTC (permalink / raw) To: Con Kolivas Cc: ck, Radoslaw Szkodzinski, Arjan van de Ven, linux kernel mailing list On Thu, Jan 05, 2006 at 11:12:51AM +1100, Con Kolivas wrote: > On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote: > > Arjan van de Ven wrote: > > > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote: > > > > > > sounds like we need some sort of profiler or benchmarker or at least a > > > tool that helps finding out which timers are regularly firing, with the > > > aim at either grouping them or trying to reduce their disturbance in > > > some form. > > > > You mean something like a modification to timer debugging patch to > > record the last time the timer fired, right? > > Timertop could then detect the pattern and provide frequency, standard > > deviation and other statistical data. > > It would be much more expensive to test of course. > > I don't think the timer debugging patch needs to give out any more info. The > userspace tool should be able to do this with the amount of info the timer > debugging patch is giving already. In the absense of a pointer to a userspace tool, I found the following handy. (It also fixes a bug where it was printing garbage as process names). [this is just an opencoded print_address(). I would have used that but it printk's instead of sprintf's to a buffer which made it useless for use by seq_print] With this, it prints output like.. cfq_idle_slice_timer+0x0/0xb3 4 0 <kthread> ... process_timeout+0x0/0x5 1025 147 pdflush process_timeout+0x0/0x5 1701 3 watchdog/0 it_real_fn+0x0/0x5a 1907 2309 Xorg process_timeout+0x0/0x5 2896 2356 gdmgreeter process_timeout+0x0/0x5 3634 1940 python i8042_timer_func+0x0/0xb 8699 0 <no data> rh_timer_func+0x0/0x5 16499 4 There's still 1 case though it seems where some timers get garbage printed as their ->comm If I get motivation to hack on this some more, I'll look further into it, but this gets me 99% of the way there. (Actually, it's missing timers launched on behalf of init it seems (they all have a pid of '1'. Wonder why init hasn't got a sane ->comm though). Dave diff -urpN --exclude-from=/home/davej/.exclude linux-2.6.15/kernel/timer_top.c timertop/kernel/timer_top.c --- linux-2.6.15/kernel/timer_top.c 2006-01-04 19:20:41.000000000 -0500 +++ timertop/kernel/timer_top.c 2006-01-04 18:37:35.000000000 -0500 @@ -27,12 +27,13 @@ #include <linux/spinlock.h> #include <linux/sched.h> #include <linux/seq_file.h> +#include <linux/kallsyms.h> #include <asm/uaccess.h> #define VERSION "Timer Top v0.9.8" struct timer_top_info { - unsigned int func_pointer; + unsigned long func_pointer; unsigned long counter; pid_t pid; char comm[TASK_COMM_LEN]; @@ -88,7 +89,11 @@ int account_timer(unsigned long function if ((task_info->pid > 0) && (task_info->pid < PID_MAX_LIMIT)) { pid_info = task_info->pid; strncpy(name, task_info->comm, sizeof(task_info->comm)); + } else { + strcpy(name, "<kthread>"); } + } else { + strcpy(name,"<no data>"); } if (update_top_info(function, pid_info)) @@ -138,12 +143,30 @@ static struct proc_dir_entry *top_info_f static int proc_read_top_info(struct seq_file *m, void *v) { struct timer_top_info *top; + char *modname; + const char *name; + unsigned long offset, size; + char namebuf[KSYM_NAME_LEN+1]; + char buffer[sizeof("%s+%#lx/%#lx [%s]") + KSYM_NAME_LEN + + 2*(BITS_PER_LONG*3/10) + MODULE_NAME_LEN + 1]; seq_printf(m, "Function counter - %s\n", VERSION); list_for_each_entry(top, timer_list, list) { - seq_printf(m, "%x %lu %d %s\n", top->func_pointer, - top->counter, top->pid, top->comm); + + name = kallsyms_lookup(top->func_pointer, &size, &offset, &modname, namebuf); + if (!name) + sprintf(buffer, "0x%lx", top->func_pointer); + else { + if (modname) + sprintf(buffer, "%s+%#lx/%#lx [%s]", name, offset, + size, modname); + else + sprintf(buffer, "%s+%#lx/%#lx", name, offset, size); + } + + seq_printf(m, "%s %lu %d %s\n", + buffer, top->counter, top->pid, top->comm ? top->comm : "<>"); } if (!top_root.record) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 0:27 ` 2.6.15-ck1 Dave Jones @ 2006-01-05 0:49 ` Con Kolivas 2006-01-05 1:14 ` 2.6.15-ck1 Dave Jones 0 siblings, 1 reply; 39+ messages in thread From: Con Kolivas @ 2006-01-05 0:49 UTC (permalink / raw) To: Dave Jones Cc: ck, Radoslaw Szkodzinski, Arjan van de Ven, linux kernel mailing list On Thursday 05 January 2006 11:27, Dave Jones wrote: > On Thu, Jan 05, 2006 at 11:12:51AM +1100, Con Kolivas wrote: > > On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote: > > > Arjan van de Ven wrote: > > > > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote: > > > > > > > > sounds like we need some sort of profiler or benchmarker or at least > > > > a tool that helps finding out which timers are regularly firing, > > > > with the aim at either grouping them or trying to reduce their > > > > disturbance in some form. > > > > > > You mean something like a modification to timer debugging patch to > > > record the last time the timer fired, right? > > > Timertop could then detect the pattern and provide frequency, standard > > > deviation and other statistical data. > > > It would be much more expensive to test of course. > > > > I don't think the timer debugging patch needs to give out any more info. > > The userspace tool should be able to do this with the amount of info the > > timer debugging patch is giving already. > > In the absense of a pointer to a userspace tool, I found the following > handy. (It also fixes a bug where it was printing garbage as process > names). Timertop and pmstats are here: http://ck.kolivas.org/patches/dyn-ticks/ Cheers, Con ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 0:49 ` 2.6.15-ck1 Con Kolivas @ 2006-01-05 1:14 ` Dave Jones 0 siblings, 0 replies; 39+ messages in thread From: Dave Jones @ 2006-01-05 1:14 UTC (permalink / raw) To: Con Kolivas Cc: ck, Radoslaw Szkodzinski, Arjan van de Ven, linux kernel mailing list On Thu, Jan 05, 2006 at 11:49:17AM +1100, Con Kolivas wrote: > On Thursday 05 January 2006 11:27, Dave Jones wrote: > > On Thu, Jan 05, 2006 at 11:12:51AM +1100, Con Kolivas wrote: > > > On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote: > > > > Arjan van de Ven wrote: > > > > > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote: > > > > > > > > > > sounds like we need some sort of profiler or benchmarker or at least > > > > > a tool that helps finding out which timers are regularly firing, > > > > > with the aim at either grouping them or trying to reduce their > > > > > disturbance in some form. > > > > > > > > You mean something like a modification to timer debugging patch to > > > > record the last time the timer fired, right? > > > > Timertop could then detect the pattern and provide frequency, standard > > > > deviation and other statistical data. > > > > It would be much more expensive to test of course. > > > > > > I don't think the timer debugging patch needs to give out any more info. > > > The userspace tool should be able to do this with the amount of info the > > > timer debugging patch is giving already. > > > > In the absense of a pointer to a userspace tool, I found the following > > handy. (It also fixes a bug where it was printing garbage as process > > names). > > Timertop and pmstats are here: > http://ck.kolivas.org/patches/dyn-ticks/ me no likee. it's very pretty, but it feels awkward to drive. Even after I'd stopped it dancing long enough to read, its output format seemed odd. With the diff I did, I just piped it through sort -n -k2 | tail to see the interesting parts. Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 20:33 ` 2.6.15-ck1 Arjan van de Ven 2006-01-04 21:22 ` 2.6.15-ck1 Dave Jones 2006-01-04 21:40 ` [ck] 2.6.15-ck1 Radoslaw Szkodzinski @ 2006-01-05 1:22 ` Andi Kleen 2006-01-05 1:36 ` 2.6.15-ck1 Con Kolivas ` (2 more replies) 2006-01-05 1:50 ` 2.6.15-ck1 Tony Lindgren 3 siblings, 3 replies; 39+ messages in thread From: Andi Kleen @ 2006-01-05 1:22 UTC (permalink / raw) To: Arjan van de Ven; +Cc: ck list, linux kernel mailing list, vojtech Arjan van de Ven <arjan@infradead.org> writes: > sounds like we need some sort of profiler or benchmarker or at least a > tool that helps finding out which timers are regularly firing, with the > aim at either grouping them or trying to reduce their disturbance in > some form. I did one some time ago for my own noidletick patch. Can probably dig it out again. It just profiled which timers interrupted idle. Executive summary for my laptop: worst was the keyboard driver (it ran some polling driver to work around some hardware bug, but fired very often) , followed by the KDE desktop (should be mostly fixed now, I complained) and the X server and some random kernel drivers. I haven't checked recently if keyboard has been fixed by now. -Andi ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 1:22 ` 2.6.15-ck1 Andi Kleen @ 2006-01-05 1:36 ` Con Kolivas 2006-01-05 6:04 ` 2.6.15-ck1 Dave Jones 2006-01-05 6:42 ` 2.6.15-ck1 Vojtech Pavlik 2 siblings, 0 replies; 39+ messages in thread From: Con Kolivas @ 2006-01-05 1:36 UTC (permalink / raw) To: Andi Kleen; +Cc: Arjan van de Ven, ck list, linux kernel mailing list, vojtech On Thu, 5 Jan 2006 12:22 pm, Andi Kleen wrote: > Arjan van de Ven <arjan@infradead.org> writes: > > sounds like we need some sort of profiler or benchmarker or at least a > > tool that helps finding out which timers are regularly firing, with the > > aim at either grouping them or trying to reduce their disturbance in > > some form. > > I did one some time ago for my own noidletick patch. Can probably dig > it out again. It just profiled which timers interrupted idle. > > Executive summary for my laptop: worst was the keyboard driver (it ran > some polling driver to work around some hardware bug, but fired very > often) , followed by the KDE desktop (should be mostly > fixed now, I complained) and the X server and some random kernel > drivers. > > I haven't checked recently if keyboard has been fixed by now. I checked with Vojtech some time ago and he said we could change the polling from HZ/20 to about HZ/5 which I have included in the rolled up dynticks patch already. Not that 20 HZ is very frequent, but anything that splits up timer intervals potentially by 20 more adds up. Cheers, Con ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 1:22 ` 2.6.15-ck1 Andi Kleen 2006-01-05 1:36 ` 2.6.15-ck1 Con Kolivas @ 2006-01-05 6:04 ` Dave Jones 2006-01-05 6:42 ` 2.6.15-ck1 Vojtech Pavlik 2 siblings, 0 replies; 39+ messages in thread From: Dave Jones @ 2006-01-05 6:04 UTC (permalink / raw) To: Andi Kleen; +Cc: Arjan van de Ven, ck list, linux kernel mailing list, vojtech On Thu, Jan 05, 2006 at 02:22:37AM +0100, Andi Kleen wrote: > Arjan van de Ven <arjan@infradead.org> writes: > > > > sounds like we need some sort of profiler or benchmarker or at least a > > tool that helps finding out which timers are regularly firing, with the > > aim at either grouping them or trying to reduce their disturbance in > > some form. > > I did one some time ago for my own noidletick patch. Can probably dig > it out again. It just profiled which timers interrupted idle. > > Executive summary for my laptop: worst was the keyboard driver (it ran > some polling driver to work around some hardware bug, but fired very > often) , followed by the KDE desktop (should be mostly > fixed now, I complained) and the X server and some random kernel > drivers. > > I haven't checked recently if keyboard has been fixed by now. it was a little further down the list from the others I posted, but it is still there fairly high in the list of offenders, even though I wasn't touching keyboard/mouse (in fact, it was several feet away from me, I had ssh'd to it for tests). Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 1:22 ` 2.6.15-ck1 Andi Kleen 2006-01-05 1:36 ` 2.6.15-ck1 Con Kolivas 2006-01-05 6:04 ` 2.6.15-ck1 Dave Jones @ 2006-01-05 6:42 ` Vojtech Pavlik 2006-01-05 6:55 ` [ck] 2.6.15-ck1 Con Kolivas 2006-01-05 15:19 ` 2.6.15-ck1 Andi Kleen 2 siblings, 2 replies; 39+ messages in thread From: Vojtech Pavlik @ 2006-01-05 6:42 UTC (permalink / raw) To: Andi Kleen; +Cc: Arjan van de Ven, ck list, linux kernel mailing list On Thu, Jan 05, 2006 at 02:22:37AM +0100, Andi Kleen wrote: > Arjan van de Ven <arjan@infradead.org> writes: > > > > sounds like we need some sort of profiler or benchmarker or at least a > > tool that helps finding out which timers are regularly firing, with the > > aim at either grouping them or trying to reduce their disturbance in > > some form. > > I did one some time ago for my own noidletick patch. Can probably dig > it out again. It just profiled which timers interrupted idle. > > Executive summary for my laptop: worst was the keyboard driver (it ran > some polling driver to work around some hardware bug, but fired very > often) , followed by the KDE desktop (should be mostly > fixed now, I complained) and the X server and some random kernel > drivers. > > I haven't checked recently if keyboard has been fixed by now. It's not. At this moment it's impossible to remove without significant surgery to the driver, because it'd prevent hotplugging and many KVMs from working. I can rather easily make the timer frequency variable. Would be 1 second idle ticks OK? -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ck] Re: 2.6.15-ck1 2006-01-05 6:42 ` 2.6.15-ck1 Vojtech Pavlik @ 2006-01-05 6:55 ` Con Kolivas 2006-01-05 15:19 ` 2.6.15-ck1 Andi Kleen 1 sibling, 0 replies; 39+ messages in thread From: Con Kolivas @ 2006-01-05 6:55 UTC (permalink / raw) To: ck Cc: Vojtech Pavlik, Andi Kleen, linux kernel mailing list, Arjan van de Ven On Thursday 05 January 2006 17:42, Vojtech Pavlik wrote: > On Thu, Jan 05, 2006 at 02:22:37AM +0100, Andi Kleen wrote: > > Arjan van de Ven <arjan@infradead.org> writes: > > > sounds like we need some sort of profiler or benchmarker or at least a > > > tool that helps finding out which timers are regularly firing, with the > > > aim at either grouping them or trying to reduce their disturbance in > > > some form. > > > > I did one some time ago for my own noidletick patch. Can probably dig > > it out again. It just profiled which timers interrupted idle. > > > > Executive summary for my laptop: worst was the keyboard driver (it ran > > some polling driver to work around some hardware bug, but fired very > > often) , followed by the KDE desktop (should be mostly > > fixed now, I complained) and the X server and some random kernel > > drivers. > > > > I haven't checked recently if keyboard has been fixed by now. > > It's not. At this moment it's impossible to remove without significant > surgery to the driver, because it'd prevent hotplugging and many KVMs > from working. > > I can rather easily make the timer frequency variable. Would be 1 second > idle ticks OK? Sure. The lower the better, and HZ with dynticks bottoms out at 14HZ. Cheers, Con ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 6:42 ` 2.6.15-ck1 Vojtech Pavlik 2006-01-05 6:55 ` [ck] 2.6.15-ck1 Con Kolivas @ 2006-01-05 15:19 ` Andi Kleen 2006-01-05 16:30 ` 2.6.15-ck1 Vojtech Pavlik 1 sibling, 1 reply; 39+ messages in thread From: Andi Kleen @ 2006-01-05 15:19 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Arjan van de Ven, ck list, linux kernel mailing list On Thursday 05 January 2006 07:42, Vojtech Pavlik wrote: > > I haven't checked recently if keyboard has been fixed by now. > > It's not. At this moment it's impossible to remove without significant > surgery to the driver, because it'd prevent hotplugging and many KVMs > from working. Sorry? You say you can't do hot plugging in the keyboard driver without a polling timer? That sounds quite bogus to me. A zillion other OS do keyboards fine without polling timers. -Andi ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 15:19 ` 2.6.15-ck1 Andi Kleen @ 2006-01-05 16:30 ` Vojtech Pavlik 2006-01-05 16:39 ` 2.6.15-ck1 Andi Kleen 0 siblings, 1 reply; 39+ messages in thread From: Vojtech Pavlik @ 2006-01-05 16:30 UTC (permalink / raw) To: Andi Kleen; +Cc: Arjan van de Ven, ck list, linux kernel mailing list On Thu, Jan 05, 2006 at 04:19:16PM +0100, Andi Kleen wrote: > On Thursday 05 January 2006 07:42, Vojtech Pavlik wrote: > > > > I haven't checked recently if keyboard has been fixed by now. > > > > It's not. At this moment it's impossible to remove without significant > > surgery to the driver, because it'd prevent hotplugging and many KVMs > > from working. > > Sorry? You say you can't do hot plugging in the keyboard driver > without a polling timer? > > That sounds quite bogus to me. A zillion other OS do keyboards > fine without polling timers. I can either have the polling timer, or the IRQs acquired all the time. The later needs significant changes to the driver - I currently enable the IRQs only if a device is present. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 16:30 ` 2.6.15-ck1 Vojtech Pavlik @ 2006-01-05 16:39 ` Andi Kleen 2006-01-05 17:13 ` 2.6.15-ck1 Dmitry Torokhov 0 siblings, 1 reply; 39+ messages in thread From: Andi Kleen @ 2006-01-05 16:39 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Arjan van de Ven, ck list, linux kernel mailing list On Thursday 05 January 2006 17:30, Vojtech Pavlik wrote: > On Thu, Jan 05, 2006 at 04:19:16PM +0100, Andi Kleen wrote: > > On Thursday 05 January 2006 07:42, Vojtech Pavlik wrote: > > > > > > I haven't checked recently if keyboard has been fixed by now. > > > > > > It's not. At this moment it's impossible to remove without significant > > > surgery to the driver, because it'd prevent hotplugging and many KVMs > > > from working. > > > > Sorry? You say you can't do hot plugging in the keyboard driver > > without a polling timer? > > > > That sounds quite bogus to me. A zillion other OS do keyboards > > fine without polling timers. > > I can either have the polling timer, or the IRQs acquired all the time. > The later needs significant changes to the driver - I currently enable > the IRQs only if a device is present. You mean you run the timer to avoid aquiring the interrupt early? -Andi ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 16:39 ` 2.6.15-ck1 Andi Kleen @ 2006-01-05 17:13 ` Dmitry Torokhov 2006-01-05 17:28 ` 2.6.15-ck1 Andi Kleen 0 siblings, 1 reply; 39+ messages in thread From: Dmitry Torokhov @ 2006-01-05 17:13 UTC (permalink / raw) To: Andi Kleen Cc: Vojtech Pavlik, Arjan van de Ven, ck list, linux kernel mailing list On 1/5/06, Andi Kleen <ak@suse.de> wrote: > On Thursday 05 January 2006 17:30, Vojtech Pavlik wrote: > > On Thu, Jan 05, 2006 at 04:19:16PM +0100, Andi Kleen wrote: > > > On Thursday 05 January 2006 07:42, Vojtech Pavlik wrote: > > > > > > > > I haven't checked recently if keyboard has been fixed by now. > > > > > > > > It's not. At this moment it's impossible to remove without significant > > > > surgery to the driver, because it'd prevent hotplugging and many KVMs > > > > from working. > > > > > > Sorry? You say you can't do hot plugging in the keyboard driver > > > without a polling timer? > > > > > > That sounds quite bogus to me. A zillion other OS do keyboards > > > fine without polling timers. > > > > I can either have the polling timer, or the IRQs acquired all the time. > > The later needs significant changes to the driver - I currently enable > > the IRQs only if a device is present. > > You mean you run the timer to avoid aquiring the interrupt early? > Yes, until some driver claims serio port interrupt is not acquired and thus available for others. I would say we could bump the timer as high as 5 seconds for hotplugging. It may give delay with some KVMs, but only first time you switch to the box in question. -- Dmitry ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 17:13 ` 2.6.15-ck1 Dmitry Torokhov @ 2006-01-05 17:28 ` Andi Kleen 0 siblings, 0 replies; 39+ messages in thread From: Andi Kleen @ 2006-01-05 17:28 UTC (permalink / raw) To: dtor_core Cc: Vojtech Pavlik, Arjan van de Ven, ck list, linux kernel mailing list On Thursday 05 January 2006 18:13, Dmitry Torokhov wrote: > Yes, until some driver claims serio port interrupt is not acquired and > thus available for others. > > I would say we could bump the timer as high as 5 seconds for > hotplugging. It may give delay with some KVMs, but only first time you > switch to the box in question. I would say you just should aquire the interrupt always. Running a timer instead of just using the perfectly fine interrupt looks simply like a design bug, not a feature. -Andi ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 20:33 ` 2.6.15-ck1 Arjan van de Ven ` (2 preceding siblings ...) 2006-01-05 1:22 ` 2.6.15-ck1 Andi Kleen @ 2006-01-05 1:50 ` Tony Lindgren 3 siblings, 0 replies; 39+ messages in thread From: Tony Lindgren @ 2006-01-05 1:50 UTC (permalink / raw) To: Arjan van de Ven Cc: Dave Jones, Con Kolivas, ck list, linux kernel mailing list * Arjan van de Ven <arjan@infradead.org> [060104 12:34]: > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote: > > On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote: > > > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > > > +2.6.15-dynticks-060101.patch > > > > +dynticks-disable_smp_config.patch > > > > Latest version of the dynticks patch. This is proving stable and effective on > > > > virtually all uniprocessor machines and will benefit systems that desire > > > > power savings. SMP kernels (even on UP machines) still misbehave so this > > > > config option is not available by default for this stable kernel. > > > > > > I've been curious for some time if this would actually show any measurable > > > power savings. So I hooked up my laptop to a gizmo[1] that shows how much > > > power is being sucked. > > > > > > both before, and after, it shows my laptop when idle is pulling 21W. > > > So either the savings here are <1W (My device can't measure more accurately > > > than a single watt), or this isn't actually buying us anything at all, or > > > something needs tuning. > > > > Ah interesting. It needs to be totally idle for a period of time before > > anything starts to happen at all. After about a minute of doing nothing, > > it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 etc.. > > > sounds like we need some sort of profiler or benchmarker or at least a > tool that helps finding out which timers are regularly firing, with the > aim at either grouping them or trying to reduce their disturbance in > some form. Take a look at timertop for that. Tony ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 19:57 ` 2.6.15-ck1 Dave Jones 2006-01-04 20:33 ` 2.6.15-ck1 Arjan van de Ven @ 2006-01-04 23:10 ` Con Kolivas 2006-01-05 1:57 ` 2.6.15-ck1 Tony Lindgren 2006-01-05 18:47 ` [ck] 2.6.15-ck1 Kevin Radloff 1 sibling, 2 replies; 39+ messages in thread From: Con Kolivas @ 2006-01-04 23:10 UTC (permalink / raw) To: Dave Jones; +Cc: ck list, linux kernel mailing list, Arjan van de Ven On Thursday 05 January 2006 06:57, Dave Jones wrote: > On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote: > > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > > +2.6.15-dynticks-060101.patch > > > +dynticks-disable_smp_config.patch > > > Latest version of the dynticks patch. This is proving stable and > > > effective on virtually all uniprocessor machines and will benefit > > > systems that desire power savings. SMP kernels (even on UP machines) > > > still misbehave so this config option is not available by default for > > > this stable kernel. > > > > I've been curious for some time if this would actually show any > > measurable power savings. So I hooked up my laptop to a gizmo[1] that > > shows how much power is being sucked. > > > > both before, and after, it shows my laptop when idle is pulling 21W. > > So either the savings here are <1W (My device can't measure more > > accurately than a single watt), or this isn't actually buying us > > anything at all, or something needs tuning. > > Ah interesting. It needs to be totally idle for a period of time before > anything starts to happen at all. After about a minute of doing nothing, > it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 > etc.. > > Goes no lower than 18W, and only occasionally peaks above the old idle > power usage. Not bad at all. > > Causing any activity at all puts it back to the 'have to wait a while > for things to start happening' state again. Thanks for testing it. Indeed skipping the ticks alone does not really save any significant amount of power. The real chance for power savings comes from using this period for smarter C state programming. The other thing as you've noticed is that timers need to be curbed or minimised to get the maximum benefit and the ondemand governor alone, which unfortunately shows up as something not obvious in timertop, polls at 140HZ itself - fiddling with ondemand/ settings in sys can drop this but slows the rate at which it adapts. I've basically stopped doing any development on dynticks at this time because I simply do not know enough about the interaction between the IO Apic and what is happening on SMP. The code to handle SMP seems sane, but I'll need outside help to cope with whatever the IO APIC is doing. UP is working fine, but it won't be long before truckloads of SMP laptops are here. Cheers, Con ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 23:10 ` 2.6.15-ck1 Con Kolivas @ 2006-01-05 1:57 ` Tony Lindgren 2006-01-05 18:47 ` [ck] 2.6.15-ck1 Kevin Radloff 1 sibling, 0 replies; 39+ messages in thread From: Tony Lindgren @ 2006-01-05 1:57 UTC (permalink / raw) To: Con Kolivas Cc: Dave Jones, ck list, linux kernel mailing list, Arjan van de Ven * Con Kolivas <kernel@kolivas.org> [060104 15:23]: > On Thursday 05 January 2006 06:57, Dave Jones wrote: > > On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote: > > > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > > > +2.6.15-dynticks-060101.patch > > > > +dynticks-disable_smp_config.patch > > > > Latest version of the dynticks patch. This is proving stable and > > > > effective on virtually all uniprocessor machines and will benefit > > > > systems that desire power savings. SMP kernels (even on UP machines) > > > > still misbehave so this config option is not available by default for > > > > this stable kernel. > > > > > > I've been curious for some time if this would actually show any > > > measurable power savings. So I hooked up my laptop to a gizmo[1] that > > > shows how much power is being sucked. > > > > > > both before, and after, it shows my laptop when idle is pulling 21W. > > > So either the savings here are <1W (My device can't measure more > > > accurately than a single watt), or this isn't actually buying us > > > anything at all, or something needs tuning. > > > > Ah interesting. It needs to be totally idle for a period of time before > > anything starts to happen at all. After about a minute of doing nothing, > > it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 > > etc.. > > > > Goes no lower than 18W, and only occasionally peaks above the old idle > > power usage. Not bad at all. > > > > Causing any activity at all puts it back to the 'have to wait a while > > for things to start happening' state again. > > Thanks for testing it. Indeed skipping the ticks alone does not really save > any significant amount of power. The real chance for power savings comes from > using this period for smarter C state programming. The other thing as you've > noticed is that timers need to be curbed or minimised to get the maximum > benefit and the ondemand governor alone, which unfortunately shows up as > something not obvious in timertop, polls at 140HZ itself - fiddling with > ondemand/ settings in sys can drop this but slows the rate at which it > adapts. Device specific power states will help with getting power savings too. Tony ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ck] Re: 2.6.15-ck1 2006-01-04 23:10 ` 2.6.15-ck1 Con Kolivas 2006-01-05 1:57 ` 2.6.15-ck1 Tony Lindgren @ 2006-01-05 18:47 ` Kevin Radloff 2006-01-12 18:51 ` Daniel Petrini 1 sibling, 1 reply; 39+ messages in thread From: Kevin Radloff @ 2006-01-05 18:47 UTC (permalink / raw) To: Con Kolivas Cc: Dave Jones, ck list, linux kernel mailing list, Arjan van de Ven On 1/4/06, Con Kolivas <kernel@kolivas.org> wrote: > Thanks for testing it. Indeed skipping the ticks alone does not really save > any significant amount of power. The real chance for power savings comes from > using this period for smarter C state programming. The other thing as you've > noticed is that timers need to be curbed or minimised to get the maximum > benefit and the ondemand governor alone, which unfortunately shows up as > something not obvious in timertop, polls at 140HZ itself - fiddling with > ondemand/ settings in sys can drop this but slows the rate at which it > adapts. For what it's worth (and I haven't done any actual power usage tests), on my 1.1GHz Pentium M laptop the gkrellm CPU speed meter (gkrellm-x86info) shows the CPU going down to around 30MHz thanks to the recent C-state patches (speeds under the minimum of 600MHz reflect C3 usage). On the other hand, without dynticks the speed hangs out around 60MHz, which as far as I know reflects the maximum possible C3 usage with HZ = 1000. So really I'm guessing that the difference in power consumption isn't really improved much, given that on my Pentium M idle time is spent in C2, and if C3 is possible it's used quite extensively regardless. Of course, this may point to who the people who could really benefit from dynticks are--those with long latencies for higher C states. But in that sense, dynticks would seem to be of use more for legacy systems, since everyone is moving towards CPUs with better power-saving capabilities, no? I'm not knowledgeable about the specifics.. just thinking out loud, really. ;) Perhaps fixing the biggest offenders of timer (mis?)use would benefit everyone all-around. I haven't really been able to identify who those are though, given the lack of sorting in timertop and its seemingly-haphazard ordering of data (or is it there and I've missed it?). -- Kevin 'radsaq' Radloff radsaq@gmail.com http://thesaq.com/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ck] Re: 2.6.15-ck1 2006-01-05 18:47 ` [ck] 2.6.15-ck1 Kevin Radloff @ 2006-01-12 18:51 ` Daniel Petrini 0 siblings, 0 replies; 39+ messages in thread From: Daniel Petrini @ 2006-01-12 18:51 UTC (permalink / raw) To: Kevin Radloff Cc: Con Kolivas, Dave Jones, ck list, linux kernel mailing list, Arjan van de Ven On 1/5/06, Kevin Radloff <radsaq@gmail.com> wrote: > On 1/4/06, Con Kolivas <kernel@kolivas.org> wrote: > > Perhaps fixing the biggest offenders of timer (mis?)use would benefit > everyone all-around. I haven't really been able to identify who those > are though, given the lack of sorting in timertop and its > seemingly-haphazard ordering of data (or is it there and I've missed > it?). > Timertop itself tries to not steals to much cpu whereas tries to be less intrusive as possible. So ordering is not available yet. But one can have a backgroud aquisition of data using: timertop -t 50 There will be 50 s of aquisition saved in a text file so that you can do some post-processing and order it properly. Daniel Petrini -- INdT - Manaus ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 19:05 ` 2.6.15-ck1 Dave Jones 2006-01-04 19:57 ` 2.6.15-ck1 Dave Jones @ 2006-01-04 20:38 ` Grant Coady 2006-01-04 20:56 ` 2.6.15-ck1 Dave Jones 2006-01-12 22:11 ` 2.6.15-ck1 Adam Belay 2006-01-14 3:42 ` 2.6.15-ck1 Philipp Rumpf 3 siblings, 1 reply; 39+ messages in thread From: Grant Coady @ 2006-01-04 20:38 UTC (permalink / raw) To: Dave Jones; +Cc: Con Kolivas, ck list, linux kernel mailing list On Wed, 4 Jan 2006 14:05:54 -0500, Dave Jones <davej@redhat.com> wrote: >On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > +2.6.15-dynticks-060101.patch > > +dynticks-disable_smp_config.patch > > Latest version of the dynticks patch. This is proving stable and effective on > > virtually all uniprocessor machines and will benefit systems that desire > > power savings. SMP kernels (even on UP machines) still misbehave so this > > config option is not available by default for this stable kernel. > >I've been curious for some time if this would actually show any measurable >power savings. So I hooked up my laptop to a gizmo[1] that shows how much >power is being sucked. > >both before, and after, it shows my laptop when idle is pulling 21W. >So either the savings here are <1W (My device can't measure more accurately >than a single watt), or this isn't actually buying us anything at all, or >something needs tuning. Or the laptop was still recharging the battery in both cases? Grant. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 20:38 ` 2.6.15-ck1 Grant Coady @ 2006-01-04 20:56 ` Dave Jones 0 siblings, 0 replies; 39+ messages in thread From: Dave Jones @ 2006-01-04 20:56 UTC (permalink / raw) To: gcoady; +Cc: Con Kolivas, ck list, linux kernel mailing list On Thu, Jan 05, 2006 at 07:38:29AM +1100, Grant Coady wrote: > On Wed, 4 Jan 2006 14:05:54 -0500, Dave Jones <davej@redhat.com> wrote: > > >On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > > +2.6.15-dynticks-060101.patch > > > +dynticks-disable_smp_config.patch > > > Latest version of the dynticks patch. This is proving stable and effective on > > > virtually all uniprocessor machines and will benefit systems that desire > > > power savings. SMP kernels (even on UP machines) still misbehave so this > > > config option is not available by default for this stable kernel. > > > >I've been curious for some time if this would actually show any measurable > >power savings. So I hooked up my laptop to a gizmo[1] that shows how much > >power is being sucked. > > > >both before, and after, it shows my laptop when idle is pulling 21W. > >So either the savings here are <1W (My device can't measure more accurately > >than a single watt), or this isn't actually buying us anything at all, or > >something needs tuning. > > Or the laptop was still recharging the battery in both cases? No, I made sure it was fully charged (and the charging light was off) before I started tests. I was tricked by the fact that you have to wait a while before things start happening. Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 19:05 ` 2.6.15-ck1 Dave Jones 2006-01-04 19:57 ` 2.6.15-ck1 Dave Jones 2006-01-04 20:38 ` 2.6.15-ck1 Grant Coady @ 2006-01-12 22:11 ` Adam Belay 2006-01-12 23:03 ` 2.6.15-ck1 Dave Jones 2006-01-14 3:42 ` 2.6.15-ck1 Philipp Rumpf 3 siblings, 1 reply; 39+ messages in thread From: Adam Belay @ 2006-01-12 22:11 UTC (permalink / raw) To: Dave Jones, Con Kolivas, ck list, linux kernel mailing list On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote: > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > +2.6.15-dynticks-060101.patch > > +dynticks-disable_smp_config.patch > > Latest version of the dynticks patch. This is proving stable and effective on > > virtually all uniprocessor machines and will benefit systems that desire > > power savings. SMP kernels (even on UP machines) still misbehave so this > > config option is not available by default for this stable kernel. > > I've been curious for some time if this would actually show any measurable > power savings. So I hooked up my laptop to a gizmo[1] that shows how much > power is being sucked. > > both before, and after, it shows my laptop when idle is pulling 21W. > So either the savings here are <1W (My device can't measure more accurately > than a single watt), or this isn't actually buying us anything at all, or > something needs tuning. > > Dave I've done quite a bit of testing with dynticks and various c-state strategies. On my thinkpad T42, dynticks can save about .5 W (as read from the ACPI battery interface, but hey it's a good ballpark measurement). This is when compared to 250HZ and the stock ACPI c-state code. Both tests were running at the lowest processor frequency (600 MHZ). The savings were much greater when running at 1.7 GHZ or when comparing to a HZ value of 1000. Also the advantage was closer to 1 W when X was not running. It might be possible to do even a little better. Currently, I'm developing a new ACPI idle policy that tries to take advantage of the long time we may be able to spend in a C3 state. Thanks, Adam ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-12 22:11 ` 2.6.15-ck1 Adam Belay @ 2006-01-12 23:03 ` Dave Jones 2006-01-13 0:42 ` 2.6.15-ck1 Adam Belay 2006-01-16 20:28 ` 2.6.15-ck1 Ben Slusky 0 siblings, 2 replies; 39+ messages in thread From: Dave Jones @ 2006-01-12 23:03 UTC (permalink / raw) To: Adam Belay, Con Kolivas, ck list, linux kernel mailing list On Thu, Jan 12, 2006 at 05:11:33PM -0500, Adam Belay wrote: > > I've been curious for some time if this would actually show any measurable > > power savings. So I hooked up my laptop to a gizmo[1] that shows how much > > power is being sucked. > > > > both before, and after, it shows my laptop when idle is pulling 21W. > > So either the savings here are <1W (My device can't measure more accurately > > than a single watt), or this isn't actually buying us anything at all, or > > something needs tuning. > > I've done quite a bit of testing with dynticks and various c-state strategies. > On my thinkpad T42, dynticks can save about .5 W (as read from the ACPI battery > interface, but hey it's a good ballpark measurement). In the follow-ups to my above message, I found that it was actually working, and dropped from 21W down to as low as 18W in some cases, but USB and the input layer are firing off timers very regularly, so it bounces around all over the place. > It might be possible to do even a little better. Currently, I'm developing a > new ACPI idle policy that tries to take advantage of the long time we may > be able to spend in a C3 state. As soon as that usb timer hits (every 250ms iirc) you'll bounce back out of any low-power state you may be in. It's a bit craptastic that we do this, even if we don't have any USB devices plugged in. Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-12 23:03 ` 2.6.15-ck1 Dave Jones @ 2006-01-13 0:42 ` Adam Belay 2006-01-13 0:46 ` 2.6.15-ck1 Dave Jones 2006-01-16 20:28 ` 2.6.15-ck1 Ben Slusky 1 sibling, 1 reply; 39+ messages in thread From: Adam Belay @ 2006-01-13 0:42 UTC (permalink / raw) To: Dave Jones, Con Kolivas, ck list, linux kernel mailing list On Thu, Jan 12, 2006 at 06:03:15PM -0500, Dave Jones wrote: > On Thu, Jan 12, 2006 at 05:11:33PM -0500, Adam Belay wrote: > > It might be possible to do even a little better. Currently, I'm developing a > > new ACPI idle policy that tries to take advantage of the long time we may > > be able to spend in a C3 state. > > As soon as that usb timer hits (every 250ms iirc) you'll bounce back out > of any low-power state you may be in. It's a bit craptastic that we do > this, even if we don't have any USB devices plugged in. > > Dave I agree that's annoying, but isn't 250ms not often enough to make any significant difference as far as power management is concerned? Generally some bus master activity will come along in a shorter time frame, causing a jump out of C3. Thanks, Adam ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-13 0:42 ` 2.6.15-ck1 Adam Belay @ 2006-01-13 0:46 ` Dave Jones 0 siblings, 0 replies; 39+ messages in thread From: Dave Jones @ 2006-01-13 0:46 UTC (permalink / raw) To: Adam Belay, Con Kolivas, ck list, linux kernel mailing list On Thu, Jan 12, 2006 at 07:42:36PM -0500, Adam Belay wrote: > > > It might be possible to do even a little better. Currently, I'm developing a > > > new ACPI idle policy that tries to take advantage of the long time we may > > > be able to spend in a C3 state. > > > > As soon as that usb timer hits (every 250ms iirc) you'll bounce back out > > of any low-power state you may be in. It's a bit craptastic that we do > > this, even if we don't have any USB devices plugged in. > > I agree that's annoying, but isn't 250ms not often enough to make any > significant difference as far as power management is concerned? > Generally some bus master activity will come along in a shorter time frame, > causing a jump out of C3. All I know is that when I removed the usb modules, the power usage stopped fluctuating as often, and it spent longer times hovering around the 18-19W mark instead of bouncing anywhere between 18-22W. Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-12 23:03 ` 2.6.15-ck1 Dave Jones 2006-01-13 0:42 ` 2.6.15-ck1 Adam Belay @ 2006-01-16 20:28 ` Ben Slusky 1 sibling, 0 replies; 39+ messages in thread From: Ben Slusky @ 2006-01-16 20:28 UTC (permalink / raw) To: Dave Jones, Adam Belay, Con Kolivas, ck list, linux kernel mailing list On Thu, 12 Jan 2006 18:03:15 -0500, Dave Jones wrote: > As soon as that usb timer hits (every 250ms iirc) you'll bounce back out > of any low-power state you may be in. It's a bit craptastic that we do > this, even if we don't have any USB devices plugged in. Is your USB controller an OHCI? If so, try reverting this patch: <URL:http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110313153001002&w=2> Apparently some mfrs' OHCI controllers need this patch to function sanely, but mine (in a Libretto L5) won't suspend after this change, and works great without it. HTH, - -Ben -- Ben Slusky | The only "intuitive" inter- sluskyb@paranoiacs.org | face is the nipple. After sluskyb@stwing.org | that, it's all learned. PGP keyID ADA44B3B | -Bruce Ediger ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 19:05 ` 2.6.15-ck1 Dave Jones ` (2 preceding siblings ...) 2006-01-12 22:11 ` 2.6.15-ck1 Adam Belay @ 2006-01-14 3:42 ` Philipp Rumpf 2006-01-14 4:41 ` 2.6.15-ck1 Dave Jones 3 siblings, 1 reply; 39+ messages in thread From: Philipp Rumpf @ 2006-01-14 3:42 UTC (permalink / raw) To: Dave Jones, Con Kolivas, ck list, linux kernel mailing list Out of curiosity, why didn't you do the monitoring using /proc/acpi/battery/.../{state,info} (while running off battery)? I think that should have much finer granularity, and avoid various capacitors that might be in the way and explain the effect you noticed. I also tried something that sounds like dynticks a couple of years back, but found that TCP timers made the really long idle times I was looking for (my idea was actually to use the RTC to wake up the CPU) impossible. prumpf On 1/4/06, Dave Jones <davej@redhat.com> wrote: > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > +2.6.15-dynticks-060101.patch > > +dynticks-disable_smp_config.patch > > Latest version of the dynticks patch. This is proving stable and effective on > > virtually all uniprocessor machines and will benefit systems that desire > > power savings. SMP kernels (even on UP machines) still misbehave so this > > config option is not available by default for this stable kernel. > > I've been curious for some time if this would actually show any measurable > power savings. So I hooked up my laptop to a gizmo[1] that shows how much > power is being sucked. > > both before, and after, it shows my laptop when idle is pulling 21W. > So either the savings here are <1W (My device can't measure more accurately > than a single watt), or this isn't actually buying us anything at all, or > something needs tuning. > > Dave > > [1] http://www.thinkgeek.com/gadgets/electronic/7657/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-14 3:42 ` 2.6.15-ck1 Philipp Rumpf @ 2006-01-14 4:41 ` Dave Jones 2006-01-14 13:06 ` [ck] 2.6.15-ck1 Jens Axboe 0 siblings, 1 reply; 39+ messages in thread From: Dave Jones @ 2006-01-14 4:41 UTC (permalink / raw) To: Philipp Rumpf; +Cc: Con Kolivas, ck list, linux kernel mailing list On Fri, Jan 13, 2006 at 09:42:26PM -0600, Philipp Rumpf wrote: > Out of curiosity, why didn't you do the monitoring using > /proc/acpi/battery/.../{state,info} (while running off battery)? I > think that should have much finer granularity, and avoid various > capacitors that might be in the way and explain the effect you > noticed. ACPI battery reporting seems hit-or-miss at times. Sometimes it seems to not update for ages, and then suddenly there's a burst when suddenly 5% of the battery drains in seconds. As an overall 'how much battery is left' thing it seems ok, but I don't trust it for accurate measurements of power drain. Whether this is a firmware deficiency causing us not to see regular interrupts, or a problem with the acpi parser I don't know. Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ck] Re: 2.6.15-ck1 2006-01-14 4:41 ` 2.6.15-ck1 Dave Jones @ 2006-01-14 13:06 ` Jens Axboe 0 siblings, 0 replies; 39+ messages in thread From: Jens Axboe @ 2006-01-14 13:06 UTC (permalink / raw) To: Dave Jones, Philipp Rumpf, Con Kolivas, ck list, linux kernel mailing list On Fri, Jan 13 2006, Dave Jones wrote: > On Fri, Jan 13, 2006 at 09:42:26PM -0600, Philipp Rumpf wrote: > > Out of curiosity, why didn't you do the monitoring using > > /proc/acpi/battery/.../{state,info} (while running off battery)? I > > think that should have much finer granularity, and avoid various > > capacitors that might be in the way and explain the effect you > > noticed. > > ACPI battery reporting seems hit-or-miss at times. > Sometimes it seems to not update for ages, and then suddenly > there's a burst when suddenly 5% of the battery drains in > seconds. As an overall 'how much battery is left' thing it seems > ok, but I don't trust it for accurate measurements of power drain. > > Whether this is a firmware deficiency causing us not to see > regular interrupts, or a problem with the acpi parser I don't know. Or could very well be a problem with your battery. -- Jens Axboe ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-04 1:00 2.6.15-ck1 Con Kolivas 2006-01-04 19:05 ` 2.6.15-ck1 Dave Jones @ 2006-01-05 17:58 ` Tomasz Torcz 2006-01-05 23:22 ` 2.6.15-ck1 Con Kolivas 1 sibling, 1 reply; 39+ messages in thread From: Tomasz Torcz @ 2006-01-05 17:58 UTC (permalink / raw) To: Con Kolivas; +Cc: ck list, linux kernel mailing list On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > Added: > +2.6.15-dynticks-060101.patch On practically unused (booted and logged in into GNOME, one terminal emulator, clock gdesklet ticking) desktop system -- Sempron 2500+, pmstats show between 450 and 600 Hz. Is this normal? -- Tomasz Torcz Only gods can safely risk perfection, zdzichu@irc.-nie.spam-.pl it's a dangerous thing for a man. -- Alia ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 17:58 ` 2.6.15-ck1 Tomasz Torcz @ 2006-01-05 23:22 ` Con Kolivas 2006-01-07 13:16 ` 2.6.15-ck1 Tomasz Torcz 0 siblings, 1 reply; 39+ messages in thread From: Con Kolivas @ 2006-01-05 23:22 UTC (permalink / raw) To: Tomasz Torcz; +Cc: ck list, linux kernel mailing list On Fri, 6 Jan 2006 04:58 am, Tomasz Torcz wrote: > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > Added: > > +2.6.15-dynticks-060101.patch > > On practically unused (booted and logged in into GNOME, one terminal > emulator, clock gdesklet ticking) desktop system -- Sempron 2500+, > pmstats show between 450 and 600 Hz. Is this normal? Chances are your hardware is one that doesn't play well with dynticks then. Compile in the timer info and use the timertop utility to see if there really is something increasing your timer activity to 450HZ and if there isn't then it's a problem with dynticks and your hardware. This is the problem I'm currently seeing on SMP configs (too many HZ) and I have yet to figure out what it is about the IO APIC that makes this happen. Cheers, Con ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 2.6.15-ck1 2006-01-05 23:22 ` 2.6.15-ck1 Con Kolivas @ 2006-01-07 13:16 ` Tomasz Torcz [not found] ` <9268368b0601131119n639c345cgcf2a5dadd7cb423c@mail.gmail.com> 0 siblings, 1 reply; 39+ messages in thread From: Tomasz Torcz @ 2006-01-07 13:16 UTC (permalink / raw) To: Con Kolivas [-- Attachment #1.1: Type: text/plain, Size: 3622 bytes --] On Fri, Jan 06, 2006 at 10:22:45AM +1100, Con Kolivas wrote: > On Fri, 6 Jan 2006 04:58 am, Tomasz Torcz wrote: > > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote: > > > Added: > > > +2.6.15-dynticks-060101.patch > > > > On practically unused (booted and logged in into GNOME, one terminal > > emulator, clock gdesklet ticking) desktop system -- Sempron 2500+, > > pmstats show between 450 and 600 Hz. Is this normal? > > Chances are your hardware is one that doesn't play well with dynticks then. Let me elaborate. Hardware is desktop system, nforce2 chipset based UP motherboard. CPU is Sempron 2500+. SATA disk, matrox card with fbcon, Intel e1000 networking. > Compile in the timer info and use the timertop utility to see if there really > is something increasing your timer activity to 450HZ and if there isn't then > it's a problem with dynticks and your hardware. This is the problem I'm > currently seeing on SMP configs (too many HZ) and I have yet to figure out > what it is about the IO APIC that makes this happen. Typical output look like: Timer Top v 0.9.8 Ticks: 470 Period: 1 s (Up/Dn) Skip Low Hz(z): Y Clear(c) PID Command Freq(Hz) Count Function Address 10946 timertop 1 14 process_timeout c0121e08 4480 netspeed_applet 1 52 process_timeout c0121e08 4132 gam_server 35 2011 process_timeout c0121e08 4321 python 47 2751 process_timeout c0121e08 5614 mrxvt 1 196 process_timeout c0121e08 4486 mono 9 531 process_timeout c0121e08 3605 X 16 1137 it_real_fn c011deff 4463 mixer_applet2 10 526 process_timeout c0121e08 18 -- 4 210 (module) e2a3409b 9936 ekg2 2 104 process_timeout c0121e08 5257 mrxvt 3 175 process_timeout c0121e08 0 - 3 250 i8042_timer_func c0230f2b 10139 powernowd 1 56 process_timeout c0121e08 0 - 1 10 (module) c1a13ed0 10705 mrxvt 2 168 process_timeout c0121e08 4485 multiload-apple 3 190 process_timeout c0121e08 5194 postmaster 4 290 process_timeout c0121e08 0 - 2 126 (module) cf85af40 0 - 1 46 neigh_periodic_time c02a474a 3511 ntpd 1 54 it_real_fn c011deff 4561 mono 2 108 process_timeout c0121e08 3 watchdog/0 1 56 process_timeout c0121e08 5247 tail 1 57 process_timeout c0121e08 gam_server uses inotify, but regardless polls some socket very frequently. Python process is driving gDesklets, two of them are updating every second -- a clock and disk bandwidth meter. mixer_applet is doing someting stupid, but GNOME developers are aware of problem. I'm attaching: - dmesg from vanilla 2.6.15 - dmesg from 2.6.15-ck1 - .config from 2.6.15-ck1 Hope this helps somehow to locate the problem. -- Tomasz Torcz "God, root, what's the difference?" zdzichu@irc.-nie.spam-.pl "God is more forgiving." [-- Attachment #1.2: config.gz --] [-- Type: application/x-gunzip, Size: 10947 bytes --] [-- Attachment #1.3: dmesg-2.6.15 --] [-- Type: text/plain, Size: 13228 bytes --] Linux version 2.6.15 (zdzichu@mother) (gcc version 3.4.5) #50 Tue Jan 3 15:46:54 CET 2006 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f400 (usable) BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 126960 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:0 DMI 2.2 present. ACPI: RSDP (v000 Nvidia ) @ 0x000f6b00 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff79c0 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000 ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000) Built 1 zonelists Kernel command line: ro resume=/dev/sda2 video=matroxfb:vesa:0x11A mapped APIC to ffffd000 (fee00000) mapped IOAPIC to ffffc000 (fec00000) Initializing CPU#0 CPU 0 irqstacks, hard=c0408000 soft=c0407000 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1747.095 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 513972k/524224k available (2114k kernel code, 9696k reserved, 788k data, 172k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3497.64 BogoMIPS (lpj=6995291) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000020 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: AMD Sempron(tm) stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1 checking if image is initramfs... it is Freeing initrd memory: 1380k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfb420, last bus=2 PCI: Using configuration type 1 ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) PCI: nForce2 C1 Halt Disconnect fixup Boot video device is 0000:02:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled. ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled. ACPI: PCI Interrupt Link [APC4] (IRQs *19), disabled. ACPI: PCI Interrupt Link [APCE] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled. ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled. Generic PHY: Registered new driver SCSI subsystem initialized PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Bridge: 0000:00:08.0 IO window: 9000-afff MEM window: e9000000-eaffffff PREFETCH window: 30000000-300fffff PCI: Bridge: 0000:00:1e.0 IO window: disabled. MEM window: e6000000-e8ffffff PREFETCH window: e4000000-e5ffffff PCI: Setting latency timer of device 0000:00:08.0 to 64 Machine check exception polling timer started. audit: initializing netlink socket (disabled) audit(1136538385.208:1): initialized Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [APC4] -> GSI 19 (level, high) -> IRQ 16 matroxfb: Matrox G550 detected PInS memtype = 5 matroxfb: MTRR's turned on matroxfb: 1280x1024x16bpp (virtual: 1280x6553) matroxfb: framebuffer at 0xE4000000, mapped to 0xe0880000, size 33554432 Console: switching to colour frame buffer device 160x64 fb0: MATROX frame buffer device matroxfb_crtc2: secondary head of fb0 was registered as fb1 ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Fan [FAN] (on) ACPI: Thermal Zone [THRM] (32 C) Real Time Clock Driver v1.12 Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected NVIDIA nForce2 chipset agpgart: AGP aperture is 64M @ 0xe0000000 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com LXT970: Registered new driver LXT971: Registered new driver tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> Linux video capture interface: v1.00 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NFORCE2: IDE controller at PCI slot 0000:00:09.0 NFORCE2: chipset revision 162 NFORCE2: not 100% native mode: will probe irqs later NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: _NEC DVD_RW ND-3540A, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... Probing IDE interface ide1... hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 libata version 1.20 loaded. sata_sil 0000:01:0b.0: version 0.9 ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 ACPI: PCI Interrupt 0000:01:0b.0[A] -> Link [APC3] -> GSI 18 (level, high) -> IRQ 17 ata1: SATA max UDMA/100 cmd 0xE081C080 ctl 0xE081C08A bmdma 0xE081C000 irq 17 ata2: SATA max UDMA/100 cmd 0xE081C0C0 ctl 0xE081C0CA bmdma 0xE081C008 irq 17 ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f ata1: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48 ata1(0): applying Seagate errata fix ata1: dev 0 configured for UDMA/100 scsi0 : sata_sil ata2: no device found (phy stat 00000000) scsi1 : sata_sil Vendor: ATA Model: ST3200822AS Rev: 3.01 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) SCSI device sda: drive cache: write back SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda mice: PS/2 mouse device common for all mice device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC). ALSA device list: No soundcards found. NET: Registered protocol family 2 input: AT Translated Set 2 keyboard as /class/input/input0 IP route cache hash table entries: 8192 (order: 3, 32768 bytes) TCP established hash table entries: 32768 (order: 5, 131072 bytes) TCP bind hash table entries: 32768 (order: 5, 131072 bytes) TCP: Hash tables configured (established 32768 bind 32768) TCP reno registered ip_conntrack version 2.4 (4095 buckets, 32760 max) - 212 bytes per conntrack ip_tables: (C) 2000-2002 Netfilter core team input: ImPS/2 Generic Wheel Mouse as /class/input/input1 TCP bic registered Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered powernow-k8: Processor cpuid 681 not supported Using IPI Shortcut mode ACPI wakeup devices: HUB0 HUB1 USB0 USB1 USB2 F139 MMAC MMCI UAR1 ACPI: (supports S0 S3 S4 S5) Freeing unused kernel memory: 172k freed ReiserFS: dm-3: found reiserfs format "3.6" with standard journal ReiserFS: dm-3: using ordered data mode ReiserFS: dm-3: journal params: device dm-3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: dm-3: checking transaction log (dm-3) ReiserFS: dm-3: Using r5 hash to sort names Adding 996020k swap on /dev/sda2. Priority:2 extents:1 across:996020k cdrom: open failed. bttv: driver version 0.9.16 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] parport0: irq 7 detected lp0: using parport0 (polling). cpufreq: Detected nForce2 chipset revision C1 cpufreq: FSB changing is maybe unstable and can lead to crashes and data loss. cpufreq: FSB currently at 165 MHz, FID 10.5 usbcore: registered new driver usbfs usbcore: registered new driver hub Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. cdrom: open failed. ReiserFS: dm-1: found reiserfs format "3.6" with standard journal ReiserFS: dm-1: using ordered data mode ReiserFS: dm-1: journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: dm-1: checking transaction log (dm-1) ReiserFS: dm-1: Using r5 hash to sort names ReiserFS: dm-2: found reiserfs format "3.6" with standard journal ReiserFS: dm-2: using journaled data mode ReiserFS: dm-2: journal params: device dm-2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: dm-2: checking transaction log (dm-2) ReiserFS: dm-2: Using r5 hash to sort names [-- Attachment #1.4: dmesg-2.6.15-ck1 --] [-- Type: text/plain, Size: 13460 bytes --] Linux version 2.6.15-ck1 (zdzichu@mother) (gcc version 3.4.5) #51 Thu Jan 5 18:40:03 CET 2006 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f400 (usable) BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 126960 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:0 DMI 2.2 present. ACPI: RSDP (v000 Nvidia ) @ 0x000f6b00 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff79c0 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000 ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000) Built 1 zonelists Kernel command line: ro resume=/dev/sda2 video=matroxfb:vesa:0x11A mapped APIC to ffffd000 (fee00000) mapped IOAPIC to ffffc000 (fec00000) Initializing CPU#0 CPU 0 irqstacks, hard=c040a000 soft=c0409000 PID hash table entries: 2048 (order: 11, 32768 bytes) Using 3579 PM timer ticks per jiffy Detected 1747.251 MHz processor. Using pmtmr for high-res timesource dyn-tick: Found suitable timer: pmtmr Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 513964k/524224k available (2118k kernel code, 9704k reserved, 792k data, 172k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3496.14 BogoMIPS (lpj=1748073) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000020 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: AMD Sempron(tm) stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1 checking if image is initramfs... it is Freeing initrd memory: 1380k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfb420, last bus=2 PCI: Using configuration type 1 ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) PCI: nForce2 C1 Halt Disconnect fixup Boot video device is 0000:02:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled. ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled. ACPI: PCI Interrupt Link [APC4] (IRQs *19), disabled. ACPI: PCI Interrupt Link [APCE] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled. ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled. Generic PHY: Registered new driver SCSI subsystem initialized PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Bridge: 0000:00:08.0 IO window: 9000-afff MEM window: e9000000-eaffffff PREFETCH window: 30000000-300fffff PCI: Bridge: 0000:00:1e.0 IO window: disabled. MEM window: e6000000-e8ffffff PREFETCH window: e4000000-e5ffffff PCI: Setting latency timer of device 0000:00:08.0 to 64 Machine check exception polling timer started. audit: initializing netlink socket (disabled) audit(1136633499.911:1): initialized Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [APC4] -> GSI 19 (level, high) -> IRQ 16 matroxfb: Matrox G550 detected PInS memtype = 5 matroxfb: MTRR's turned on matroxfb: 1280x1024x16bpp (virtual: 1280x6553) matroxfb: framebuffer at 0xE4000000, mapped to 0xe0880000, size 33554432 Console: switching to colour frame buffer device 160x64 fb0: MATROX frame buffer device matroxfb_crtc2: secondary head of fb0 was registered as fb1 ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Fan [FAN] (on) ACPI: Thermal Zone [THRM] (31 C) Real Time Clock Driver v1.12 Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected NVIDIA nForce2 chipset agpgart: AGP aperture is 64M @ 0xe0000000 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com LXT970: Registered new driver LXT971: Registered new driver tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> Linux video capture interface: v1.00 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NFORCE2: IDE controller at PCI slot 0000:00:09.0 NFORCE2: chipset revision 162 NFORCE2: not 100% native mode: will probe irqs later NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: _NEC DVD_RW ND-3540A, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... Probing IDE interface ide1... hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 libata version 1.20 loaded. sata_sil 0000:01:0b.0: version 0.9 ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 ACPI: PCI Interrupt 0000:01:0b.0[A] -> Link [APC3] -> GSI 18 (level, high) -> IRQ 17 ata1: SATA max UDMA/100 cmd 0xE081C080 ctl 0xE081C08A bmdma 0xE081C000 irq 17 ata2: SATA max UDMA/100 cmd 0xE081C0C0 ctl 0xE081C0CA bmdma 0xE081C008 irq 17 ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f ata1: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48 ata1(0): applying Seagate errata fix ata1: dev 0 configured for UDMA/100 scsi0 : sata_sil ata2: no device found (phy stat 00000000) scsi1 : sata_sil Vendor: ATA Model: ST3200822AS Rev: 3.01 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) SCSI device sda: drive cache: write back SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda mice: PS/2 mouse device common for all mice device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC). ALSA device list: No soundcards found. NET: Registered protocol family 2 IP route cache hash table entries: 8192 (order: 3, 32768 bytes) TCP established hash table entries: 32768 (order: 5, 131072 bytes) TCP bind hash table entries: 32768 (order: 5, 131072 bytes) TCP: Hash tables configured (established 32768 bind 32768) TCP reno registered ip_conntrack version 2.4 (4095 buckets, 32760 max) - 212 bytes per conntrack input: AT Translated Set 2 keyboard as /class/input/input0 ip_tables: (C) 2000-2002 Netfilter core team TCP bic registered Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered powernow-k8: Processor cpuid 681 not supported Using IPI Shortcut mode dyn-tick: Disabling APIC timer, using PIT reprogramming dyn-tick: Maximum ticks to skip limited to 54 dyn-tick: Enabling dynamic tick timer v060101 ACPI wakeup devices: HUB0 HUB1 USB0 USB1 USB2 F139 MMAC MMCI UAR1 ACPI: (supports S0 S3 S4 S5) Freeing unused kernel memory: 172k freed input: ImPS/2 Generic Wheel Mouse as /class/input/input1 ReiserFS: dm-3: found reiserfs format "3.6" with standard journal ReiserFS: dm-3: using ordered data mode ReiserFS: dm-3: journal params: device dm-3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: dm-3: checking transaction log (dm-3) ReiserFS: dm-3: Using r5 hash to sort names Adding 996020k swap on /dev/sda2. Priority:2 extents:1 across:996020k cdrom: open failed. bttv: driver version 0.9.16 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] parport0: irq 7 detected lp0: using parport0 (polling). cpufreq: Detected nForce2 chipset revision C1 cpufreq: FSB changing is maybe unstable and can lead to crashes and data loss. cpufreq: FSB currently at 166 MHz, FID 10.5 usbcore: registered new driver usbfs usbcore: registered new driver hub Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. cdrom: open failed. ReiserFS: dm-1: found reiserfs format "3.6" with standard journal ReiserFS: dm-1: using ordered data mode ReiserFS: dm-1: journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: dm-1: checking transaction log (dm-1) ReiserFS: dm-1: Using r5 hash to sort names ReiserFS: dm-2: found reiserfs format "3.6" with standard journal ReiserFS: dm-2: using journaled data mode ReiserFS: dm-2: journal params: device dm-2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: dm-2: checking transaction log (dm-2) ReiserFS: dm-2: Using r5 hash to sort names [-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <9268368b0601131119n639c345cgcf2a5dadd7cb423c@mail.gmail.com>]
* Re: 2.6.15-ck1 [not found] ` <9268368b0601131119n639c345cgcf2a5dadd7cb423c@mail.gmail.com> @ 2006-01-14 20:54 ` Tomasz Torcz 0 siblings, 0 replies; 39+ messages in thread From: Tomasz Torcz @ 2006-01-14 20:54 UTC (permalink / raw) To: Daniel Petrini; +Cc: linux-kernel On Fri, Jan 13, 2006 at 03:19:29PM -0400, Daniel Petrini wrote: > Hi Tomasz, > > Just to make sure if there isn't any timer that is not visible in the > screen (unlikely but...). Can you run timertop with background > acquisition: > > timertop -t 100 > > And analyse the output to verify if there isn't timers with that frequency? Nothing suspicious: Timer Top v 0.9.8 No. PID Command Count Function Address 1 4072 multiload-apple 3 process_timeout c0121e08 2 3602 X 17 it_real_fn c011deff 3 3985 python 45 process_timeout c0121e08 4 4492 postmaster 7 process_timeout c0121e08 5 3931 nautilus 1 process_timeout c0121e08 6 4074 mono 9 process_timeout c0121e08 7 4059 mixer_applet2 7 process_timeout c0121e08 8 4713 mrxvt 3 process_timeout c0121e08 9 0 - 4 i8042_timer_func c0230f2b 10 1 mono 1 watermark_wakeup c013f6f5 11 18 mono 3 (module) e2a3409b 12 4122 mono 2 process_timeout c0121e08 13 0 - 1 (module) e2bc2381 14 0 - 1 wb_timer_fn c013acc0 15 0 - 3 delayed_work_timer_fn c0126a96 16 0 - 1 blk_unplug_timeout c01ccc1b 17 0 - 1 (module) d0697f40 18 3 watchdog/0 1 process_timeout c0121e08 19 4067 netspeed_applet 1 process_timeout c0121e08 20 4069 cpufreq-applet 1 process_timeout c0121e08 21 3796 gnome-screensav 1 process_timeout c0121e08 22 4540 httpd 1 process_timeout c0121e08 23 3512 ntpd 1 it_real_fn c011deff 24 17603 timertop 1 process_timeout c0121e08 -- Tomasz Torcz "Never underestimate the bandwidth of a station zdzichu@irc.-nie.spam-.pl wagon filled with backup tapes." -- Jim Gray ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2006-01-16 20:28 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-04 1:00 2.6.15-ck1 Con Kolivas 2006-01-04 19:05 ` 2.6.15-ck1 Dave Jones 2006-01-04 19:57 ` 2.6.15-ck1 Dave Jones 2006-01-04 20:33 ` 2.6.15-ck1 Arjan van de Ven 2006-01-04 21:22 ` 2.6.15-ck1 Dave Jones 2006-01-04 21:40 ` [ck] 2.6.15-ck1 Radoslaw Szkodzinski 2006-01-05 0:12 ` 2.6.15-ck1 Con Kolivas 2006-01-05 0:27 ` 2.6.15-ck1 Dave Jones 2006-01-05 0:49 ` 2.6.15-ck1 Con Kolivas 2006-01-05 1:14 ` 2.6.15-ck1 Dave Jones 2006-01-05 1:22 ` 2.6.15-ck1 Andi Kleen 2006-01-05 1:36 ` 2.6.15-ck1 Con Kolivas 2006-01-05 6:04 ` 2.6.15-ck1 Dave Jones 2006-01-05 6:42 ` 2.6.15-ck1 Vojtech Pavlik 2006-01-05 6:55 ` [ck] 2.6.15-ck1 Con Kolivas 2006-01-05 15:19 ` 2.6.15-ck1 Andi Kleen 2006-01-05 16:30 ` 2.6.15-ck1 Vojtech Pavlik 2006-01-05 16:39 ` 2.6.15-ck1 Andi Kleen 2006-01-05 17:13 ` 2.6.15-ck1 Dmitry Torokhov 2006-01-05 17:28 ` 2.6.15-ck1 Andi Kleen 2006-01-05 1:50 ` 2.6.15-ck1 Tony Lindgren 2006-01-04 23:10 ` 2.6.15-ck1 Con Kolivas 2006-01-05 1:57 ` 2.6.15-ck1 Tony Lindgren 2006-01-05 18:47 ` [ck] 2.6.15-ck1 Kevin Radloff 2006-01-12 18:51 ` Daniel Petrini 2006-01-04 20:38 ` 2.6.15-ck1 Grant Coady 2006-01-04 20:56 ` 2.6.15-ck1 Dave Jones 2006-01-12 22:11 ` 2.6.15-ck1 Adam Belay 2006-01-12 23:03 ` 2.6.15-ck1 Dave Jones 2006-01-13 0:42 ` 2.6.15-ck1 Adam Belay 2006-01-13 0:46 ` 2.6.15-ck1 Dave Jones 2006-01-16 20:28 ` 2.6.15-ck1 Ben Slusky 2006-01-14 3:42 ` 2.6.15-ck1 Philipp Rumpf 2006-01-14 4:41 ` 2.6.15-ck1 Dave Jones 2006-01-14 13:06 ` [ck] 2.6.15-ck1 Jens Axboe 2006-01-05 17:58 ` 2.6.15-ck1 Tomasz Torcz 2006-01-05 23:22 ` 2.6.15-ck1 Con Kolivas 2006-01-07 13:16 ` 2.6.15-ck1 Tomasz Torcz [not found] ` <9268368b0601131119n639c345cgcf2a5dadd7cb423c@mail.gmail.com> 2006-01-14 20:54 ` 2.6.15-ck1 Tomasz Torcz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).