Change i386 nmi handler to handle 32 bit perfmon counter MSR writes cleanly.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc-mm/arch/i386/kernel/nmi.c
===
--- linux-2.6.20-rc-mm.orig/arch/i386/
Handle these 32 bit perfmon counter MSR writes cleanly in oprofile.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc-mm/arch/i386/oprofile/op_model_ppro.c
===
--- linux-2.6.20-rc-mm.orig/arc
this case cleanly.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc-mm/arch/x86_64/kernel/nmi.c
===
--- linux-2.6.20-rc-mm.orig/arch/x86_64/kernel/nmi.c
+++ linux-2.6.20-rc-mm/arch/x86_64/kernel/nmi.c
@@
this case cleanly.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.20-rc-mm/arch/x86_64/kernel/nmi.c
===
--- linux-2.6.20-rc-mm.orig/arch/x86_64/kernel/nmi.c
+++ linux-2.6.20-rc-mm/arch/x86_64/kernel/nmi.c
@@ -214,6
Change i386 nmi handler to handle 32 bit perfmon counter MSR writes cleanly.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.20-rc-mm/arch/i386/kernel/nmi.c
===
--- linux-2.6.20-rc-mm.orig/arch/i386/kernel
Handle these 32 bit perfmon counter MSR writes cleanly in oprofile.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.20-rc-mm/arch/i386/oprofile/op_model_ppro.c
===
--- linux-2.6.20-rc-mm.orig/arch/i386
Incremental bugfix to previous 3 patch patchset of cpufreq lock rewrite.
There was one code path in cpufreq_get, that was using the write lock
in place of read and also potential recursive lock with sysfs
interface of cpuinfo_cur_freq.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTEC
Incremental bugfix to previous 3 patch patchset of cpufreq lock rewrite.
There was one code path in cpufreq_get, that was using the write lock
in place of read and also potential recursive lock with sysfs
interface of cpuinfo_cur_freq.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index
__cpufreq_target, it needs to have
policy_rwsem in write mode, which also protects it from hot plug.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc-mm/drivers/cpufreq/cpufreq_ondemand.c
===
--- linux-2.6
Restructure the delayed_work callback in ondemand.
This eliminates the need for smp_processor_id in the callback function and also
helps in proper locking and avoiding flush_workqueue when stopping the governor
(done in subsequent patch).
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTEC
:
Convert policy->lock to rwsem and move it to per_cpu area.
This rwsem will protect against both changing/accessing policy
related parameters and CPU hot plug/unplug.
Cc: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.2
:
Convert policy-lock to rwsem and move it to per_cpu area.
This rwsem will protect against both changing/accessing policy
related parameters and CPU hot plug/unplug.
Cc: Gautham R Shenoy [EMAIL PROTECTED]
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.20-rc-mm/drivers/cpufreq
Restructure the delayed_work callback in ondemand.
This eliminates the need for smp_processor_id in the callback function and also
helps in proper locking and avoiding flush_workqueue when stopping the governor
(done in subsequent patch).
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED
__cpufreq_target, it needs to have
policy_rwsem in write mode, which also protects it from hot plug.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.20-rc-mm/drivers/cpufreq/cpufreq_ondemand.c
===
--- linux-2.6.20-rc
On Wed, Dec 13, 2006 at 04:12:46PM -0800, Greg KH wrote:
> On Wed, Dec 13, 2006 at 03:34:08PM -0800, Venkatesh Pallipadi wrote:
> >
> > With WARN_ON addition to kobject_init()
> > [
> > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/dont-u
was
performance related. Is it really? If not, we should consider the below patch.
Thanks,
Venki
Now that kobject_init has a WARN_ON for refcnt, change below is needed
to avoid false positives.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc-mm/lib/
was
performance related. Is it really? If not, we should consider the below patch.
Thanks,
Venki
Now that kobject_init has a WARN_ON for refcnt, change below is needed
to avoid false positives.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.19-rc-mm/lib/kref.c
On Wed, Dec 13, 2006 at 04:12:46PM -0800, Greg KH wrote:
On Wed, Dec 13, 2006 at 03:34:08PM -0800, Venkatesh Pallipadi wrote:
With WARN_ON addition to kobject_init()
[
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/dont-use/broken-out/gregkh-driver-kobject
Add a new not_critical_when_idle parameter to queue_delayed_work_on(). This
parameter can be used to schedule work that are 'unimportant' when
CPU is idle and can be called later, when CPU eventually comes out of idle.
Use this parameter in cpufreq ondemand governor.
Signed-off-by: Venkatesh
-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc-mm/kernel/timer.c
===
--- linux-2.6.19-rc-mm.orig/kernel/timer.c 2006-12-07 10:58:15.0
-0800
+++ linux-2.6.19-rc-mm/kernel/timer.c 2006-12-07
-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.19-rc-mm/kernel/timer.c
===
--- linux-2.6.19-rc-mm.orig/kernel/timer.c 2006-12-07 10:58:15.0
-0800
+++ linux-2.6.19-rc-mm/kernel/timer.c 2006-12-07 15:34
Add a new not_critical_when_idle parameter to queue_delayed_work_on(). This
parameter can be used to schedule work that are 'unimportant' when
CPU is idle and can be called later, when CPU eventually comes out of idle.
Use this parameter in cpufreq ondemand governor.
Signed-off-by: Venkatesh
not
enable interrupts before entering idle.
Note that poll_idle() still has a this race as it has to enable interrupts
before going to idle. But, all other idle routines have the race fixed.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
---
Here is the second try. Thanks to
the race fixed.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc-mm/arch/x86_64/kernel/process.c
===
--- linux-2.6.19-rc-mm.orig/arch/x86_64/kernel/process.c
+++ linux-2.6.19-rc-mm/arch/x86_64/kernel/pro
do not
enable interrupts before entering idle.
Note that poll_idle() still has a this race as it has to enable interrupts
before going to idle. But, all other idle routines have the race fixed.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc-mm/arch/x86_64/
do not
enable interrupts before entering idle.
Note that poll_idle() still has a this race as it has to enable interrupts
before going to idle. But, all other idle routines have the race fixed.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.19-rc-mm/arch/x86_64/kernel
the race fixed.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.19-rc-mm/arch/x86_64/kernel/process.c
===
--- linux-2.6.19-rc-mm.orig/arch/x86_64/kernel/process.c
+++ linux-2.6.19-rc-mm/arch/x86_64/kernel/process.c
not
enable interrupts before entering idle.
Note that poll_idle() still has a this race as it has to enable interrupts
before going to idle. But, all other idle routines have the race fixed.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
---
Here is the second try. Thanks to Suresh
() and avoid using the error return value.
Patch fixes the issue reported at
http://www.ussg.iu.edu/hypermail/linux/kernel/0611.2/0629.html
and also other similar issue here
http://bugme.osdl.org/show_bug.cgi?id=7383 comment 53
Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]>
Signed-off-by: Ven
() and avoid using the error return value.
Patch fixes the issue reported at
http://www.ussg.iu.edu/hypermail/linux/kernel/0611.2/0629.html
and also other similar issue here
http://bugme.osdl.org/show_bug.cgi?id=7383 comment 53
Signed-off-by: Dhaval Giani [EMAIL PROTECTED]
Signed-off-by: Venkatesh
On Sun, Aug 28, 2005 at 08:09:41PM +0200, Dominik Brodowski wrote:
> Hi,
>
> On Fri, Aug 26, 2005 at 05:10:52PM -0700, Venkatesh Pallipadi wrote:
> > /*
> > -* Then we read the 'status_register' and compare the value with the
> > -* target state's 'status'
On Sun, Aug 28, 2005 at 08:09:41PM +0200, Dominik Brodowski wrote:
Hi,
On Fri, Aug 26, 2005 at 05:10:52PM -0700, Venkatesh Pallipadi wrote:
/*
-* Then we read the 'status_register' and compare the value with the
-* target state's 'status' to make sure the transition
-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.12/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
===
--- linux-2.6.12.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
2005-08-16 09:41:52.977456128 -0700
+++
Fix convert_acpiid_to_cpu function to handle cpu_index greater than 256. This
patch also prevents a warning in IA64 cross-compile of this file
(drivers/acpi/processor_core.c:517: warning: comparison is always false due
to limited range of data type).
Signed-off-by: Venkatesh Pallipadi
Fix convert_acpiid_to_cpu function to handle cpu_index greater than 256. This
patch also prevents a warning in IA64 cross-compile of this file
(drivers/acpi/processor_core.c:517: warning: comparison is always false due
to limited range of data type).
Signed-off-by: Venkatesh Pallipadi [EMAIL
-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.12/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
===
--- linux-2.6.12.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
2005-08-16 09:41:52.977456128 -0700
+++ linux
On Fri, Aug 05, 2005 at 11:53:29AM -0700, Andrew Morton wrote:
>
> That's all pretty sad stuff. I guess for now we can go back to the busy
> loop. Longer-term it would be nice if we could tune up the HPET driver in
> some manner so we can avoid this busy-wait-in-interrupt.
>
> I'm not sure who
On Fri, Aug 05, 2005 at 11:53:29AM -0700, Andrew Morton wrote:
That's all pretty sad stuff. I guess for now we can go back to the busy
loop. Longer-term it would be nice if we could tune up the HPET driver in
some manner so we can avoid this busy-wait-in-interrupt.
I'm not sure who the
with X86_PC subarch
Thanks,
Venki
i386 generic subarchitecture requires explicit dmi strings or command line
to enable bigsmp mode. The patch below removes that restriction, and
uses bigsmp as soon as it finds more than 8 logical CPUs, Intel processors
and xAPIC support.
Signed-off-by: Venkatesh
with X86_PC subarch
Thanks,
Venki
i386 generic subarchitecture requires explicit dmi strings or command line
to enable bigsmp mode. The patch below removes that restriction, and
uses bigsmp as soon as it finds more than 8 logical CPUs, Intel processors
and xAPIC support.
Signed-off-by: Venkatesh
in
above link.
Please apply.
Thanks,
Venki
i386 generic subarchitecture requires explicit dmi strings or command line
to enable bigsmp mode. The patch below removes that restriction, and
uses bigsmp as soon as it finds more than 8 logical CPUs and xAPIC support.
Signed-off-by: Venkatesh Pallipadi
in
above link.
Please apply.
Thanks,
Venki
i386 generic subarchitecture requires explicit dmi strings or command line
to enable bigsmp mode. The patch below removes that restriction, and
uses bigsmp as soon as it finds more than 8 logical CPUs and xAPIC support.
Signed-off-by: Venkatesh Pallipadi
On Fri, Jul 15, 2005 at 07:57:01PM +0200, Andi Kleen wrote:
> > I wouldn't say it is totally impossible. There are ways in which Linux can
> > work
> > without a reliable Local APIC timer. One option being - make one CPU that
> > gets
> > the external timer interrupt multicast an IPI to all the
On Fri, Jul 15, 2005 at 06:54:30PM +0100, Maciej W. Rozycki wrote:
> On Fri, 15 Jul 2005, Venkatesh Pallipadi wrote:
>
> > I wouldn't say it is totally impossible. There are ways in which Linux can
> > work
> > without a reliable Local APIC timer. One option being - mak
On Fri, Jul 15, 2005 at 07:02:24PM +0200, Andi Kleen wrote:
>
> At least on multi processor systems LAPIC has to work anyways (otherwise
> you cannot schedule other CPUs), so it is fine to use there.
>
> AFAIK there are no x86 CPUs right now that do both C3
> and SMP. If they ever do then they
On Fri, Jul 15, 2005 at 07:02:24PM +0200, Andi Kleen wrote:
At least on multi processor systems LAPIC has to work anyways (otherwise
you cannot schedule other CPUs), so it is fine to use there.
AFAIK there are no x86 CPUs right now that do both C3
and SMP. If they ever do then they will
On Fri, Jul 15, 2005 at 06:54:30PM +0100, Maciej W. Rozycki wrote:
On Fri, 15 Jul 2005, Venkatesh Pallipadi wrote:
I wouldn't say it is totally impossible. There are ways in which Linux can
work
without a reliable Local APIC timer. One option being - make one CPU that
gets
On Fri, Jul 15, 2005 at 07:57:01PM +0200, Andi Kleen wrote:
I wouldn't say it is totally impossible. There are ways in which Linux can
work
without a reliable Local APIC timer. One option being - make one CPU that
gets
the external timer interrupt multicast an IPI to all the other
of code that is causing the issue.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
diff -purN linux-2.6.13-rc1-mm1//drivers/acpi/processor_idle.c.org
linux-2.6.13-rc1-mm1//drivers/acpi/processor_idle.c
--- linux-2.6.13-rc1-mm1//drivers/acpi/processor_idle.c.org 2005-07-14
of code that is causing the issue.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
diff -purN linux-2.6.13-rc1-mm1//drivers/acpi/processor_idle.c.org
linux-2.6.13-rc1-mm1//drivers/acpi/processor_idle.c
--- linux-2.6.13-rc1-mm1//drivers/acpi/processor_idle.c.org 2005-07-14
23:19
Only use read_timer_tsc only when CPU has TSC. Thanks to Andrea for
pointing this out. Should not be issue on any platforms as all
recent systems that has HPET also has CPUs that supports TSC. The patch is
still required for correctness.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTEC
Only use read_timer_tsc only when CPU has TSC. Thanks to Andrea for
pointing this out. Should not be issue on any platforms as all
recent systems that has HPET also has CPUs that supports TSC. The patch is
still required for correctness.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED
On Fri, Apr 22, 2005 at 06:51:59PM -0700, Linus Torvalds wrote:
> On Fri, 22 Apr 2005, Venkatesh Pallipadi wrote:
> > The specifications that talk about E820 map doesn't have an upper limit
> > on the number of E820 entries. But, today's kernel has a hard limit of 32.
> > Wi
On Fri, Apr 22, 2005 at 06:51:59PM -0700, Linus Torvalds wrote:
On Fri, 22 Apr 2005, Venkatesh Pallipadi wrote:
The specifications that talk about E820 map doesn't have an upper limit
on the number of E820 entries. But, today's kernel has a hard limit of 32.
With increase in memory size, we
it for both i386 and x86-64.
Side-effect:
bss increases by ~ 2K and init.data increases by ~7.5K
on all systems, due to increase in size of static arrays.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
diff -purN linux-2.6.11/Documentation/i386/zero-page.txt.orig
linux-2.6.11/Documen
it for both i386 and x86-64.
Side-effect:
bss increases by ~ 2K and init.data increases by ~7.5K
on all systems, due to increase in size of static arrays.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
diff -purN linux-2.6.11/Documentation/i386/zero-page.txt.orig
linux-2.6.11/Documentation
it to
user.
Patch below changes both i386 and x86-64 architectures to use this
new and improved calibrate_delay_direct() routine.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
diff -purN linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer.c.orig
linux-2.6.12-rc2-mm3//arc
it to
user.
Patch below changes both i386 and x86-64 architectures to use this
new and improved calibrate_delay_direct() routine.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
diff -purN linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer.c.orig
linux-2.6.12-rc2-mm3//arch/i386/kernel
This adds another timer combination of PIT/HPET to go with
HPET/HPET, HPET/TSC and PIT/TSC!
This system that has HPET and doesn't have Legacy support, does it support
routing HPET interrupts through IOAPIC in standard routing option? If yes,
then I think adding support to route HPET interrupts
This adds another timer combination of PIT/HPET to go with
HPET/HPET, HPET/TSC and PIT/TSC!
This system that has HPET and doesn't have Legacy support, does it support
routing HPET interrupts through IOAPIC in standard routing option? If yes,
then I think adding support to route HPET interrupts
/cpuX/cache, showing various information about the
caches. Most useful field being shared_cpu_map, which says what caches are
shared among which logical cpus.
The patch adds support for both i386 and x86-64.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
--- linux-2.6.11/include/as
/cpuX/cache, showing various information about the
caches. Most useful field being shared_cpu_map, which says what caches are
shared among which logical cpus.
The patch adds support for both i386 and x86-64.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
--- linux-2.6.11/include/asm-i386
On Tue, Mar 15, 2005 at 06:36:20PM -0500, Dave Jones wrote:
> On Tue, Mar 15, 2005 at 03:24:48PM -0800, Venkatesh Pallipadi wrote:
> >
> > The attached patch adds support for using cpuid(4) instead of cpuid(2), to
> get
> > CPU cache information in a determin
/cpuX/cache, showing various information about the
caches. Most useful field being shared_cpu_map, which says what caches are
shared among which logical cpus.
The patch adds support for both i386 and x86-64.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
--- linux-2.6.11/include/as
/cpuX/cache, showing various information about the
caches. Most useful field being shared_cpu_map, which says what caches are
shared among which logical cpus.
The patch adds support for both i386 and x86-64.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
--- linux-2.6.11/include/asm-i386
On Tue, Mar 15, 2005 at 06:36:20PM -0500, Dave Jones wrote:
On Tue, Mar 15, 2005 at 03:24:48PM -0800, Venkatesh Pallipadi wrote:
The attached patch adds support for using cpuid(4) instead of cpuid(2), to
get
CPU cache information in a deterministic way for Intel CPUs, whenever
On Sat, Mar 12, 2005 at 09:46:54AM -0700, Zwane Mwaikambo wrote:
> On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
>
> > On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
> >
> > How about this patch? Also fixes one other use of rtc_lock in
> > acpi
APM: fix interrupts enabled in device_power_up"
> which should address this.
>
How about this patch? Also fixes one other use of rtc_lock in acpi/sleep/proc.c
Thanks,
Venki
rtc_lock is held during timer interrupts. So, we should block interrupts
while holding it.
Signed-off-by: Venkatesh P
? Also fixes one other use of rtc_lock in acpi/sleep/proc.c
Thanks,
Venki
rtc_lock is held during timer interrupts. So, we should block interrupts
while holding it.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
--- linux-2.6.10/arch/i386/kernel/time.c.org2005-03-12 10:38:23.0
On Sat, Mar 12, 2005 at 09:46:54AM -0700, Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
How about this patch? Also fixes one other use of rtc_lock in
acpi/sleep/proc.c
rtc_lock is held during
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
--- linux-2.6.10/arch/i386/kernel/pci-dma.c.org 2005-02-11 15:18:42.596362296
-0800
+++ linux-2.6.10/arch/i386/kernel/pci-dma.c 2005-02-11 15:19:18.446912184
-0800
@@ -89,11 +89,11 @@ int dma_declare_coherent_memory(st
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
--- linux-2.6.10/arch/i386/kernel/pci-dma.c.org 2005-02-11 15:18:42.596362296
-0800
+++ linux-2.6.10/arch/i386/kernel/pci-dma.c 2005-02-11 15:19:18.446912184
-0800
@@ -89,11 +89,11 @@ int dma_declare_coherent_memory(struct d
be generated properly.
Thanks to John Stultz and Andrew Walrond for reporting, root causing
the issue and verifying this fix.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
--- linux-2.6.10/arch/i386/kernel/time_hpet.c.org 2005-02-04
12:04:09.0 -0800
+++ linux-2.6.1
be generated properly.
Thanks to John Stultz and Andrew Walrond for reporting, root causing
the issue and verifying this fix.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
--- linux-2.6.10/arch/i386/kernel/time_hpet.c.org 2005-02-04
12:04:09.0 -0800
+++ linux-2.6.10/arch/i386
On Thu, Feb 03, 2005 at 11:30:56AM -0800, john stultz wrote:
> On Thu, 2005-02-03 at 06:28 -0800, Pallipadi, Venkatesh wrote:
> > Can you check whether only the following change makes the problem go
> > away. If yes, then it looks like a hardware issue.
> >
> > > hpet_writel(hpet_tick,
On Thu, Feb 03, 2005 at 11:30:56AM -0800, john stultz wrote:
On Thu, 2005-02-03 at 06:28 -0800, Pallipadi, Venkatesh wrote:
Can you check whether only the following change makes the problem go
away. If yes, then it looks like a hardware issue.
hpet_writel(hpet_tick, HPET_T0_CMP);
+
,
Venki
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
--- linux-2.6.10/./arch/i386/kernel/timers/timer_tsc.c.org 2005-01-05
16:06:52.0 -0800
+++ linux-2.6.10/./arch/i386/kernel/timers/timer_tsc.c 2005-01-19
12:38:20.0 -0800
@@ -552,6 +552,7 @@ static struct time
,
Venki
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
--- linux-2.6.10/./arch/i386/kernel/timers/timer_tsc.c.org 2005-01-05
16:06:52.0 -0800
+++ linux-2.6.10/./arch/i386/kernel/timers/timer_tsc.c 2005-01-19
12:38:20.0 -0800
@@ -552,6 +552,7 @@ static struct timer_opts
101 - 178 of 178 matches
Mail list logo
