All of lore.kernel.org
 help / color / mirror / Atom feed
* v2.6.19-rt6, yum/rpm
@ 2006-12-05 17:11 Ingo Molnar
  2006-12-07 11:33 ` K.R. Foley
                   ` (3 more replies)
  0 siblings, 4 replies; 26+ messages in thread
From: Ingo Molnar @ 2006-12-05 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-rt-users
  Cc: Mike Galbraith, Clark Williams, Sergei Shtylyov, Thomas Gleixner,
	Fernando Lopez-Lezcano, Giandomenico De Tullio

i have released the 2.6.19-rt6 tree, which can be downloaded from the 
usual place:

    http://redhat.com/~mingo/realtime-preempt/

more info about the -rt patchset can be found on the RT wiki:

  http://rt.wiki.kernel.org

this is a fixes-only release. Changes since -rt1:

 - fix !PREEMPT_RT build error (reported by Mike Galbraith)

 - tracer build fix (from Mike Galbraith) 

 - latest KVM (Kernel Virtual Machine) branch from Avi Kivity

 - itimer starvation fix (Thomas Gleixner)

 - tracer: fix 32-bit cycles regression (reported by Sergei Shtylyov)

 - kernel-rt-devel fix on i686: include asm-x86_64 to allow external 
   modules (such as FUSE) to build. (reported by Giandomenico De Tullio)

 - hrtimers: fix resume bug in migrate_hrtimers() causing possible 
   memory corruption

 - hrtimers: fix jiffy update order in hrtimer_notify_resume() to avoid 
   time warp after resume

 - lockdep: fix irq-disabling buglet causing boot lockup

 - seqlock: fix lockdep naming macro

 - acpi: keep all other ACPI locks non-raw (some ACPI critical sections 
   use the SLAB allocator, which is preemptible in -rt)

 - netconsole: fix rtl8139_poll_controller() to use _nosync disable

 - acpi: mark acpi_gbl_hardware_lock as raw, can be used in C3 idle code

 - acpi: fix irq-enable code in drivers/acpi/ec.c (

 - x86_64: fix SysRq-L (show all regs via NMI) feature

 - new debug helper: ignore_loglevel boot option

 - new debug helper: debug_direct_keyboard boot option

 - new debug helper: show nmi print callbacks from do_IRQ too

 - debug_direct_keyboard fix: turn off lockdep while this hack is 
   utilized

 - mark pci_config_lock raw, to fix boot crash

 - disable HPET for now, it's not working reliably and causes hangs

 - x86_64: fix dump_stack() smp_processor_id() warnings

 - make NMI watchdog asserts nondestructive

 - i686: restore /proc/interrupts output to upstream format

 - fix boot hang due across warm reboots

 - fix set_workqueue_thread_prio() bug resulting in boot hang

 - e1000: update to driver 7.3.15-k2 to fix latency problem

 - tracer updates: use the gtod clocksource for timestamping, to 
   increase the reliability of latency traces

 - tracer feature: trace_use_raw_cycles to force the use of TSC even 
   if it's not reliable

to build a 2.6.19-rt6 tree, the following patches should be applied:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.tar.bz2
  http://redhat.com/~mingo/realtime-preempt/patch-2.6.19-rt6

the -rt YUM repository for Fedora Core 6 and 5, for architectures x86_64 
and i686 can be activated via:

   cd /etc/yum.repos.d
   wget http://people.redhat.com/~mingo/realtime-preempt/rt.repo

   yum install kernel-rt.x86_64   # on x86_64
   yum install kernel-rt          # on i686

   yum update kernel-rt           # refresh - or enable yum-updatesd

(note: it will take 15-30 minutes from now on for the yum repository to 
be updated to -rt6)

as usual, bugreports, fixes and suggestions are welcome,

	Ingo

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-05 17:11 v2.6.19-rt6, yum/rpm Ingo Molnar
@ 2006-12-07 11:33 ` K.R. Foley
  2006-12-07 12:13   ` Ingo Molnar
  2006-12-07 20:45 ` Fernando Lopez-Lezcano
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 26+ messages in thread
From: K.R. Foley @ 2006-12-07 11:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, linux-rt-users, Mike Galbraith, Clark Williams,
	Sergei Shtylyov, Thomas Gleixner, Fernando Lopez-Lezcano,
	Giandomenico De Tullio

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

Ingo Molnar wrote:
> i have released the 2.6.19-rt6 tree, which can be downloaded from the 
> usual place:
> 

Attached patch fixes rtc histogram. Looks like it got broken around
2.6.18-rt?, probably during the merge for 2.6.18?

-- 
	kr

[-- Attachment #2: rtcfix1.patch --]
[-- Type: text/x-patch, Size: 755 bytes --]

--- linux-2.6.19/drivers/char/rtc.c.orig	2006-12-06 21:46:16.000000000 -0600
+++ linux-2.6.19/drivers/char/rtc.c	2006-12-06 21:46:48.000000000 -0600
@@ -427,9 +427,9 @@ irqreturn_t rtc_interrupt(int irq, void 
 	if (rtc_callback)
 		rtc_callback->func(rtc_callback->private_data);
 	spin_unlock(&rtc_task_lock);
-	wake_up_interruptible(&rtc_wait);
 
-	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+	rtc_wake_event();
+	wake_up_interruptible(&rtc_wait);
 
 	return IRQ_HANDLED;
 }
@@ -1328,7 +1328,6 @@ static void rtc_dropped_irq(unsigned lon
 	printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
 
 	/* Now we have new data */
-	rtc_wake_event();
 	wake_up_interruptible(&rtc_wait);
 
 	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 11:33 ` K.R. Foley
@ 2006-12-07 12:13   ` Ingo Molnar
  2006-12-07 15:54     ` K.R. Foley
  0 siblings, 1 reply; 26+ messages in thread
From: Ingo Molnar @ 2006-12-07 12:13 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, linux-rt-users, Mike Galbraith, Clark Williams,
	Sergei Shtylyov, Thomas Gleixner, Fernando Lopez-Lezcano,
	Giandomenico De Tullio


* K.R. Foley <kr@cybsft.com> wrote:

> Ingo Molnar wrote:
> > i have released the 2.6.19-rt6 tree, which can be downloaded from the 
> > usual place:
> 
> Attached patch fixes rtc histogram. Looks like it got broken around 
> 2.6.18-rt?, probably during the merge for 2.6.18?

thanks, applied. I have undone some rtc hacks in the 2.6.18 merge, i 
guess this collateral damage of that.

	Ingo

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 12:13   ` Ingo Molnar
@ 2006-12-07 15:54     ` K.R. Foley
  2006-12-07 16:57       ` Ingo Molnar
  0 siblings, 1 reply; 26+ messages in thread
From: K.R. Foley @ 2006-12-07 15:54 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, linux-rt-users, Mike Galbraith, Clark Williams,
	Sergei Shtylyov, Thomas Gleixner, Fernando Lopez-Lezcano,
	Giandomenico De Tullio

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

Ingo Molnar wrote:

The attached patch is necessary to build 2.6.19-rt8 without KEXEC
enabled. Without KEXEC enabled crash.c doesn't get included. I believe
this is correct.

-- 
   kr

[-- Attachment #2: nmifix1.patch --]
[-- Type: text/x-patch, Size: 378 bytes --]

--- linux-2.6.19/arch/i386/kernel/nmi.c.orig	2006-12-07 09:35:22.000000000 -0600
+++ linux-2.6.19/arch/i386/kernel/nmi.c	2006-12-07 09:36:04.000000000 -0600
@@ -935,7 +935,9 @@ void nmi_show_all_regs(void)
 	for_each_online_cpu(i)
 		nmi_show_regs[i] = 1;
 
+#ifdef CONFIG_KEXEC
 	smp_send_nmi_allbutself();
+#endif
 
 	for_each_online_cpu(i) {
 		while (nmi_show_regs[i] == 1)

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 15:54     ` K.R. Foley
@ 2006-12-07 16:57       ` Ingo Molnar
  2006-12-07 19:40         ` K.R. Foley
  0 siblings, 1 reply; 26+ messages in thread
From: Ingo Molnar @ 2006-12-07 16:57 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, linux-rt-users, Mike Galbraith, Clark Williams,
	Sergei Shtylyov, Thomas Gleixner, Fernando Lopez-Lezcano,
	Giandomenico De Tullio


* K.R. Foley <kr@cybsft.com> wrote:

> Ingo Molnar wrote:
> 
> The attached patch is necessary to build 2.6.19-rt8 without KEXEC 
> enabled. Without KEXEC enabled crash.c doesn't get included. I believe 
> this is correct.

ah, indeed. I went for a slightly different approach - see the patch 
below. Sending an NMI to all CPUs is not something that is tied to 
KEXEC, it belongs into nmi.c.

	Ingo

Index: linux/arch/i386/kernel/crash.c
===================================================================
--- linux.orig/arch/i386/kernel/crash.c
+++ linux/arch/i386/kernel/crash.c
@@ -132,14 +132,6 @@ static int crash_nmi_callback(struct not
 	return 1;
 }
 
-void smp_send_nmi_allbutself(void)
-{
-	cpumask_t mask = cpu_online_map;
-	cpu_clear(safe_smp_processor_id(), mask);
-	if (!cpus_empty(mask))
-		send_IPI_mask(mask, NMI_VECTOR);
-}
-
 static struct notifier_block crash_nmi_nb = {
 	.notifier_call = crash_nmi_callback,
 };
Index: linux/arch/i386/kernel/nmi.c
===================================================================
--- linux.orig/arch/i386/kernel/nmi.c
+++ linux/arch/i386/kernel/nmi.c
@@ -1133,6 +1133,14 @@ int proc_nmi_enabled(struct ctl_table *t
 
 #endif
 
+void smp_send_nmi_allbutself(void)
+{
+	cpumask_t mask = cpu_online_map;
+	cpu_clear(safe_smp_processor_id(), mask);
+	if (!cpus_empty(mask))
+		send_IPI_mask(mask, NMI_VECTOR);
+}
+
 EXPORT_SYMBOL(nmi_active);
 EXPORT_SYMBOL(nmi_watchdog);
 EXPORT_SYMBOL(avail_to_resrv_perfctr_nmi);
Index: linux/arch/x86_64/kernel/crash.c
===================================================================
--- linux.orig/arch/x86_64/kernel/crash.c
+++ linux/arch/x86_64/kernel/crash.c
@@ -127,11 +127,6 @@ static int crash_nmi_callback(struct not
 	return 1;
 }
 
-void smp_send_nmi_allbutself(void)
-{
-	send_IPI_allbutself(NMI_VECTOR);
-}
-
 /*
  * This code is a best effort heuristic to get the
  * other cpus to stop executing. So races with
Index: linux/arch/x86_64/kernel/nmi.c
===================================================================
--- linux.orig/arch/x86_64/kernel/nmi.c
+++ linux/arch/x86_64/kernel/nmi.c
@@ -1015,6 +1015,11 @@ int proc_nmi_enabled(struct ctl_table *t
 
 #endif
 
+void smp_send_nmi_allbutself(void)
+{
+	send_IPI_allbutself(NMI_VECTOR);
+}
+
 EXPORT_SYMBOL(nmi_active);
 EXPORT_SYMBOL(nmi_watchdog);
 EXPORT_SYMBOL(avail_to_resrv_perfctr_nmi);



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 16:57       ` Ingo Molnar
@ 2006-12-07 19:40         ` K.R. Foley
  2006-12-07 20:04           ` Ingo Molnar
  0 siblings, 1 reply; 26+ messages in thread
From: K.R. Foley @ 2006-12-07 19:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, linux-rt-users, Mike Galbraith, Clark Williams,
	Sergei Shtylyov, Thomas Gleixner, Fernando Lopez-Lezcano,
	Giandomenico De Tullio

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
>> Ingo Molnar wrote:
>>
>> The attached patch is necessary to build 2.6.19-rt8 without KEXEC 
>> enabled. Without KEXEC enabled crash.c doesn't get included. I believe 
>> this is correct.
> 
> ah, indeed. I went for a slightly different approach - see the patch 
> below. Sending an NMI to all CPUs is not something that is tied to 
> KEXEC, it belongs into nmi.c.
> 
> 	Ingo

Much better I think. It still requires the patch below, which includes
mach_ipi.h, to build here.


-- 
   kr

[-- Attachment #2: nmifix2.patch --]
[-- Type: text/x-patch, Size: 315 bytes --]

--- linux-2.6.19/arch/i386/kernel/nmi.c.orig	2006-12-07 13:03:12.000000000 -0600
+++ linux-2.6.19/arch/i386/kernel/nmi.c	2006-12-07 13:03:21.000000000 -0600
@@ -30,6 +30,7 @@
 #include <asm/intel_arch_perfmon.h>
 
 #include "mach_traps.h"
+#include <mach_ipi.h>
 
 int unknown_nmi_panic;
 int nmi_watchdog_enabled;

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 19:40         ` K.R. Foley
@ 2006-12-07 20:04           ` Ingo Molnar
  0 siblings, 0 replies; 26+ messages in thread
From: Ingo Molnar @ 2006-12-07 20:04 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, linux-rt-users, Mike Galbraith, Clark Williams,
	Sergei Shtylyov, Thomas Gleixner, Fernando Lopez-Lezcano,
	Giandomenico De Tullio


* K.R. Foley <kr@cybsft.com> wrote:

> > ah, indeed. I went for a slightly different approach - see the patch 
> > below. Sending an NMI to all CPUs is not something that is tied to 
> > KEXEC, it belongs into nmi.c.
> > 
> > 	Ingo
> 
> Much better I think. It still requires the patch below, which includes 
> mach_ipi.h, to build here.

yeah, and an #ifdef CONFIG_SMP to build on UP :-/

	Ingo

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-05 17:11 v2.6.19-rt6, yum/rpm Ingo Molnar
  2006-12-07 11:33 ` K.R. Foley
@ 2006-12-07 20:45 ` Fernando Lopez-Lezcano
  2006-12-07 20:58   ` Ingo Molnar
  2006-12-08 19:40 ` Ethernet transmit timeouts, was: " Dirk Behme
  2006-12-15 16:18 ` Sergei Shtylyov
  3 siblings, 1 reply; 26+ messages in thread
From: Fernando Lopez-Lezcano @ 2006-12-07 20:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, linux-kernel, linux-rt-users, Mike Galbraith,
	Clark Williams, Sergei Shtylyov, Thomas Gleixner,
	Giandomenico De Tullio

On Tue, 2006-12-05 at 18:11 +0100, Ingo Molnar wrote:
> i have released the 2.6.19-rt6 tree, which can be downloaded from the 
> usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> more info about the -rt patchset can be found on the RT wiki:
> 
>   http://rt.wiki.kernel.org
> 
> this is a fixes-only release. Changes since -rt1:
[MUNCH]

A first non-scientific feedback report. 

Much better performance in terms of xruns with Jackd. Hardly any at all
as it should be. I'm starting to test -rt8 right now. 

Now, I still don't have an smp machine to test so the improvement could
be because I'm just running 64 bit up instead of smp. Or it could have
been the hardware on that other machine that had some problem (either
because it was starting to fail or because the kernel drivers for that
hardware were somehow triggering the xruns). 

Anyway, looks good!
Thanks.
-- Fernando



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 20:45 ` Fernando Lopez-Lezcano
@ 2006-12-07 20:58   ` Ingo Molnar
  2006-12-07 21:07     ` Fernando Lopez-Lezcano
  2006-12-07 21:20     ` Arjan van de Ven
  0 siblings, 2 replies; 26+ messages in thread
From: Ingo Molnar @ 2006-12-07 20:58 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: linux-kernel, linux-rt-users, Mike Galbraith, Clark Williams,
	Sergei Shtylyov, Thomas Gleixner, Giandomenico De Tullio


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> Much better performance in terms of xruns with Jackd. Hardly any at 
> all as it should be. I'm starting to test -rt8 right now.
> 
> Now, I still don't have an smp machine to test so the improvement 
> could be because I'm just running 64 bit up instead of smp. Or it 
> could have been the hardware on that other machine that had some 
> problem (either because it was starting to fail or because the kernel 
> drivers for that hardware were somehow triggering the xruns).

i think it's the UP vs. SMP difference. We are chasing some SMP 
latencies right now that trigger on boxes that have deeper C sleep 
states. idle=poll seems to work around those problems.

	Ingo

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 20:58   ` Ingo Molnar
@ 2006-12-07 21:07     ` Fernando Lopez-Lezcano
  2006-12-07 21:42       ` Fernando Lopez-Lezcano
  2006-12-07 21:20     ` Arjan van de Ven
  1 sibling, 1 reply; 26+ messages in thread
From: Fernando Lopez-Lezcano @ 2006-12-07 21:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, linux-kernel, linux-rt-users, Mike Galbraith,
	Clark Williams, Sergei Shtylyov, Thomas Gleixner,
	Giandomenico De Tullio

On Thu, 2006-12-07 at 21:58 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:
> 
> > Much better performance in terms of xruns with Jackd. Hardly any at 
> > all as it should be. I'm starting to test -rt8 right now.
> > 
> > Now, I still don't have an smp machine to test so the improvement 
> > could be because I'm just running 64 bit up instead of smp. Or it 
> > could have been the hardware on that other machine that had some 
> > problem (either because it was starting to fail or because the kernel 
> > drivers for that hardware were somehow triggering the xruns).
> 
> i think it's the UP vs. SMP difference. We are chasing some SMP 
> latencies right now that trigger on boxes that have deeper C sleep 
> states. idle=poll seems to work around those problems.

Oh well, it looked too good, anyway, it is winter here so the extra
heating should be fine :-)

I'll try to get something to test smp again...
-- Fernando



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 20:58   ` Ingo Molnar
  2006-12-07 21:07     ` Fernando Lopez-Lezcano
@ 2006-12-07 21:20     ` Arjan van de Ven
  2006-12-07 21:44       ` Ingo Molnar
  1 sibling, 1 reply; 26+ messages in thread
From: Arjan van de Ven @ 2006-12-07 21:20 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Fernando Lopez-Lezcano, linux-kernel, linux-rt-users,
	Mike Galbraith, Clark Williams, Sergei Shtylyov, Thomas Gleixner,
	Giandomenico De Tullio

On Thu, 2006-12-07 at 21:58 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:
> 
> > Much better performance in terms of xruns with Jackd. Hardly any at 
> > all as it should be. I'm starting to test -rt8 right now.
> > 
> > Now, I still don't have an smp machine to test so the improvement 
> > could be because I'm just running 64 bit up instead of smp. Or it 
> > could have been the hardware on that other machine that had some 
> > problem (either because it was starting to fail or because the kernel 
> > drivers for that hardware were somehow triggering the xruns).
> 
> i think it's the UP vs. SMP difference. We are chasing some SMP 
> latencies right now that trigger on boxes that have deeper C sleep 
> states. idle=poll seems to work around those problems.

well C-states do cause latencies... as advertized in
the /proc/acpi/processor/CPU0/power file.

You can prevent linux from going into c-states that just take too long,
by setting the latency you can tolerate via the
set_acceptable_latency(). You can see the active maximum latency via the
same power file...

(right now audio playback is the main user of this api; of other parts
should use it too lets talk about it)


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 21:07     ` Fernando Lopez-Lezcano
@ 2006-12-07 21:42       ` Fernando Lopez-Lezcano
  0 siblings, 0 replies; 26+ messages in thread
From: Fernando Lopez-Lezcano @ 2006-12-07 21:42 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, linux-kernel, linux-rt-users, Mike Galbraith,
	Clark Williams, Sergei Shtylyov, Thomas Gleixner,
	Giandomenico De Tullio

On Thu, 2006-12-07 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
> On Thu, 2006-12-07 at 21:58 +0100, Ingo Molnar wrote:
> > * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:
> > 
> > > Much better performance in terms of xruns with Jackd. Hardly any at 
> > > all as it should be. I'm starting to test -rt8 right now.
> > > 
> > > Now, I still don't have an smp machine to test so the improvement 
> > > could be because I'm just running 64 bit up instead of smp. Or it 
> > > could have been the hardware on that other machine that had some 
> > > problem (either because it was starting to fail or because the kernel 
> > > drivers for that hardware were somehow triggering the xruns).
> > 
> > i think it's the UP vs. SMP difference. We are chasing some SMP 
> > latencies right now that trigger on boxes that have deeper C sleep 
> > states. idle=poll seems to work around those problems.
> 
> Oh well, it looked too good, anyway, it is winter here so the extra
> heating should be fine :-)

Hmmm, when I was testing on smp I was running with the speed set to the
top speed of the processors (through the small gnome cpuspeed applet). I
imagine that the C states would not have been the problem...

-- Fernando



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-07 21:20     ` Arjan van de Ven
@ 2006-12-07 21:44       ` Ingo Molnar
  0 siblings, 0 replies; 26+ messages in thread
From: Ingo Molnar @ 2006-12-07 21:44 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Fernando Lopez-Lezcano, linux-kernel, linux-rt-users,
	Mike Galbraith, Clark Williams, Sergei Shtylyov, Thomas Gleixner,
	Giandomenico De Tullio


* Arjan van de Ven <arjan@infradead.org> wrote:

> > i think it's the UP vs. SMP difference. We are chasing some SMP 
> > latencies right now that trigger on boxes that have deeper C sleep 
> > states. idle=poll seems to work around those problems.
> 
> well C-states do cause latencies... as advertized in the 
> /proc/acpi/processor/CPU0/power file.

no, this is a plain logic bug somewhere, not a hardware latency. 
Sometimes the latency is in the seconds range, etc.

	Ingo

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Ethernet transmit timeouts, was: v2.6.19-rt6, yum/rpm
  2006-12-05 17:11 v2.6.19-rt6, yum/rpm Ingo Molnar
  2006-12-07 11:33 ` K.R. Foley
  2006-12-07 20:45 ` Fernando Lopez-Lezcano
@ 2006-12-08 19:40 ` Dirk Behme
  2006-12-08 20:15   ` Thomas Gleixner
  2006-12-09  4:26   ` Ethernet transmit timeouts, was: v2.6.19-rt6, yum/rpm Bruce Ashfield
  2006-12-15 16:18 ` Sergei Shtylyov
  3 siblings, 2 replies; 26+ messages in thread
From: Dirk Behme @ 2006-12-08 19:40 UTC (permalink / raw)
  Cc: linux-rt-users

Ingo Molnar wrote:
> this is a fixes-only release. Changes since -rt1:
...
>  - e1000: update to driver 7.3.15-k2 to fix latency problem

Any hint what the "latency problem" was here?

On ARM926 with patch-2.6.19-rt10 we use SMC91C94 ethernet 
(smc91x.c). With rt10 applied we get NETDEV WATCHDOG 
transmit timouts (see below) while using NFS. We don't get 
them without rt patch.

Dirk

Btw: Any idea why /proc/interrupts doesn't look like Figure 
8 of http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO ? 
The [........N/  0] info is missing here.


eth0: SMC91C94 (rev 9) at c2850300 IRQ 160 [nowait]
eth0: Ethernet addr: 00:0e:99:02:02:42

# cat /proc/interrupts
            CPU0
...
  93:          0         MPU  DMA
  94:          0         MPU  DMA
160:         28        GPIO  eth0
164:          1        GPIO  spi2.0
197:          0        GPIO  serial wakeup
...

# madplay /mnt/nfs/foo.mp3
...
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
nfs: server 192.0.0.1 not responding, still trying
nfs: server 192.0.0.1 not responding, still trying
NETDEV WATCHDOG: eth0: transmit timed out
nfs: server 192.0.0.1 not responding, still trying
NETDEV WATCHDOG: eth0: transmit timed out
nfs: server 192.0.0.1 not responding, still trying
nfs: server 192.0.0.1 not responding, still trying
nfs: server 192.0.0.1 not responding, still trying
NETDEV WATCHDOG: eth0: transmit timed out

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Ethernet transmit timeouts, was: v2.6.19-rt6, yum/rpm
  2006-12-08 19:40 ` Ethernet transmit timeouts, was: " Dirk Behme
@ 2006-12-08 20:15   ` Thomas Gleixner
  2006-12-09  7:53     ` Ethernet transmit timeouts Dirk Behme
  2006-12-09  4:26   ` Ethernet transmit timeouts, was: v2.6.19-rt6, yum/rpm Bruce Ashfield
  1 sibling, 1 reply; 26+ messages in thread
From: Thomas Gleixner @ 2006-12-08 20:15 UTC (permalink / raw)
  To: Dirk Behme; +Cc: linux-rt-users

On Fri, 2006-12-08 at 20:40 +0100, Dirk Behme wrote:
> eth0: SMC91C94 (rev 9) at c2850300 IRQ 160 [nowait]
> eth0: Ethernet addr: 00:0e:99:02:02:42
>
> nfs: server 192.0.0.1 not responding, still trying
> NETDEV WATCHDOG: eth0: transmit timed out

That's not a latency. The transmit side of the driver seems not to work.
Can you please enable debugging in the SMC driver and provide the
output, maybe it's possible to deduce the cause of the problem from
that. Also please enable CONFIG_PROVE_LOCKING in the kernel hacking
section.

	tglx

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Ethernet transmit timeouts, was: v2.6.19-rt6, yum/rpm
  2006-12-08 19:40 ` Ethernet transmit timeouts, was: " Dirk Behme
  2006-12-08 20:15   ` Thomas Gleixner
@ 2006-12-09  4:26   ` Bruce Ashfield
  1 sibling, 0 replies; 26+ messages in thread
From: Bruce Ashfield @ 2006-12-09  4:26 UTC (permalink / raw)
  To: Dirk Behme; +Cc: linux-rt-users

On 12/8/06, Dirk Behme <dirk.behme@googlemail.com> wrote:
> Ingo Molnar wrote:
> > this is a fixes-only release. Changes since -rt1:
> ...
> >  - e1000: update to driver 7.3.15-k2 to fix latency problem
>
> Any hint what the "latency problem" was here?
>
> On ARM926 with patch-2.6.19-rt10 we use SMC91C94 ethernet
> (smc91x.c). With rt10 applied we get NETDEV WATCHDOG
> transmit timouts (see below) while using NFS. We don't get
> them without rt patch.

I've seen the same problem on the ARM versatile926 with the
2.6.14 vintage RT patches. My problem was due to the generic
IRQ changes and I could reproduce the problem with just those
patches applied.

A brew of the following two patches got the versatile's TX
interrupts firing again:

http://lkml.org/lkml/2005/12/12/69
http://lkml.org/lkml/2005/12/12/72

Obviously those are a bit old now and I haven't gotten around
to trying the board with the 2.6.19-rt patches (no suitable
counter for instrumentation), so I haven't checked for myself
to see if the problem still exists.

>
> Dirk
>
> Btw: Any idea why /proc/interrupts doesn't look like Figure
> 8 of http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO ?
> The [........N/  0] info is missing here.
>
>
> eth0: SMC91C94 (rev 9) at c2850300 IRQ 160 [nowait]
> eth0: Ethernet addr: 00:0e:99:02:02:42
>
> # cat /proc/interrupts
>             CPU0
> ...
>   93:          0         MPU  DMA
>   94:          0         MPU  DMA
> 160:         28        GPIO  eth0
> 164:          1        GPIO  spi2.0
> 197:          0        GPIO  serial wakeup
> ...
>
> # madplay /mnt/nfs/foo.mp3
> ...
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> nfs: server 192.0.0.1 not responding, still trying
> nfs: server 192.0.0.1 not responding, still trying
> NETDEV WATCHDOG: eth0: transmit timed out
> nfs: server 192.0.0.1 not responding, still trying
> NETDEV WATCHDOG: eth0: transmit timed out
> nfs: server 192.0.0.1 not responding, still trying
> nfs: server 192.0.0.1 not responding, still trying
> nfs: server 192.0.0.1 not responding, still trying
> NETDEV WATCHDOG: eth0: transmit timed out
> -
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Ethernet transmit timeouts
  2006-12-08 20:15   ` Thomas Gleixner
@ 2006-12-09  7:53     ` Dirk Behme
  2006-12-10  8:27       ` Ingo Molnar
  0 siblings, 1 reply; 26+ messages in thread
From: Dirk Behme @ 2006-12-09  7:53 UTC (permalink / raw)
  To: tglx; +Cc: linux-rt-users

Thomas Gleixner wrote:
> On Fri, 2006-12-08 at 20:40 +0100, Dirk Behme wrote:
> 
>>eth0: SMC91C94 (rev 9) at c2850300 IRQ 160 [nowait]
>>eth0: Ethernet addr: 00:0e:99:02:02:42
>>
>>nfs: server 192.0.0.1 not responding, still trying
>>NETDEV WATCHDOG: eth0: transmit timed out
> 
> 
> That's not a latency. The transmit side of the driver seems not to work.
> Can you please enable debugging in the SMC driver and provide the
> output, maybe it's possible to deduce the cause of the problem from
> that. 

Seems that enabling SMC debugging slows down system in a way 
that my testcase (playing MP3 via NFS) doesn't work any more.

> Also please enable CONFIG_PROVE_LOCKING in the kernel hacking
> section.

Looks like CONFIG_PROVE_LOCKING isn't available on ARM? 
PROVE_LOCKING depens on STACKTRACE_SUPPORT && 
LOCKDEP_SUPPORT. These are available only on i386, x86_64 
and MIPS?

Will now try Bruces' proposal and play with IRQ flags.

Thanks

Dirk

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Ethernet transmit timeouts
  2006-12-09  7:53     ` Ethernet transmit timeouts Dirk Behme
@ 2006-12-10  8:27       ` Ingo Molnar
  0 siblings, 0 replies; 26+ messages in thread
From: Ingo Molnar @ 2006-12-10  8:27 UTC (permalink / raw)
  To: Dirk Behme; +Cc: tglx, linux-rt-users


* Dirk Behme <dirk.behme@googlemail.com> wrote:

> > Also please enable CONFIG_PROVE_LOCKING in the kernel hacking 
> > section.
> 
> Looks like CONFIG_PROVE_LOCKING isn't available on ARM? PROVE_LOCKING 
> depens on STACKTRACE_SUPPORT && LOCKDEP_SUPPORT. These are available 
> only on i386, x86_64 and MIPS?

iirc RMK had prototype lockdep code for ARM - maybe ask him for that?

	Ingo

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-05 17:11 v2.6.19-rt6, yum/rpm Ingo Molnar
                   ` (2 preceding siblings ...)
  2006-12-08 19:40 ` Ethernet transmit timeouts, was: " Dirk Behme
@ 2006-12-15 16:18 ` Sergei Shtylyov
  2006-12-15 16:19   ` Ingo Molnar
  3 siblings, 1 reply; 26+ messages in thread
From: Sergei Shtylyov @ 2006-12-15 16:18 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, linux-rt-users, Thomas Gleixner

Hello everybody.

Ingo Molnar wrote:

> i have released the 2.6.19-rt6 tree, which can be downloaded from the 
> usual place:

>     http://redhat.com/~mingo/realtime-preempt/

[...]

> as usual, bugreports, fixes and suggestions are welcome,

    Be aware that even with the newest -rt patch, the PowerPC TOD vsyscalls 
are still broken, i.e. glibc may return imprecise/incorrect results for the 
related calls -- despite arch/powerpc/kernel/time.c has been at last fixed to 
at least compile, the PowerPC clocksource patch removed the important part of 
TOD vsyscall support, and this hasn't been dealt with.  I've sent to Thomas 
Gleixner a patch removing the affected vsyscalls altogether for the time being 
in the early November (unfortunately, I came to know of the breakage too late, 
and hadn't time to deal with it propery due to othr woes), however, I'm not 
seeing any of my patches (I've also done PowerPC clockevents support) merged 
to -rt (or otherwise published). Most of the patches can be found in the 
linuxppc-dev list archives, for the interested...

> 	Ingo

WBR, Sergei

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-15 16:18 ` Sergei Shtylyov
@ 2006-12-15 16:19   ` Ingo Molnar
  2007-02-01 15:52     ` Sergei Shtylyov
  0 siblings, 1 reply; 26+ messages in thread
From: Ingo Molnar @ 2006-12-15 16:19 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linux-kernel, linux-rt-users, Thomas Gleixner


* Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:

> >as usual, bugreports, fixes and suggestions are welcome,
> 
>    Be aware that even with the newest -rt patch, the PowerPC TOD 
> vsyscalls are still broken, i.e. glibc may return imprecise/incorrect 
> results for the related calls -- despite arch/powerpc/kernel/time.c 
> has been at last fixed to at least compile, the PowerPC clocksource 
> patch removed the important part of TOD vsyscall support, and this 
> hasn't been dealt with.  I've sent to Thomas Gleixner a patch removing 
> the affected vsyscalls altogether for the time being in the early 
> November (unfortunately, I came to know of the breakage too late, and 
> hadn't time to deal with it propery due to othr woes), however, I'm 
> not seeing any of my patches (I've also done PowerPC clockevents 
> support) merged to -rt (or otherwise published). Most of the patches 
> can be found in the linuxppc-dev list archives, for the interested...

could you resend them to me please?

	Ingo

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2006-12-15 16:19   ` Ingo Molnar
@ 2007-02-01 15:52     ` Sergei Shtylyov
  2007-02-01 17:38       ` Ingo Molnar
  0 siblings, 1 reply; 26+ messages in thread
From: Sergei Shtylyov @ 2007-02-01 15:52 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, linux-rt-users, Thomas Gleixner

Hello.

Ingo Molnar wrote:

>>>as usual, bugreports, fixes and suggestions are welcome,

>>   Be aware that even with the newest -rt patch, the PowerPC TOD 
>>vsyscalls are still broken, i.e. glibc may return imprecise/incorrect 
>>results for the related calls -- despite arch/powerpc/kernel/time.c 
>>has been at last fixed to at least compile, the PowerPC clocksource 
>>patch removed the important part of TOD vsyscall support, and this 
>>hasn't been dealt with.  I've sent to Thomas Gleixner a patch removing 
>>the affected vsyscalls altogether for the time being in the early 
>>November (unfortunately, I came to know of the breakage too late, and 
>>hadn't time to deal with it propery due to othr woes), however, I'm 
>>not seeing any of my patches (I've also done PowerPC clockevents 
>>support) merged to -rt (or otherwise published). Most of the patches 
>>can be found in the linuxppc-dev list archives, for the interested...

> could you resend them to me please?

    Seeing that GENERIC_TIME has been thrown out from the -rt patch, it makes 
no sense now (even if I had time -- I also decided to leave this to Thomas as 
the HRT maintainer). Concerning this change: tghe patch that comments out 
recalc_time_offset() call in arch/powerpc/kernel/time.c must have be thrown 
out as well since it's breaking TOD vsyscall support now.

> 	Ingo

WBR, Sergei

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2007-02-01 15:52     ` Sergei Shtylyov
@ 2007-02-01 17:38       ` Ingo Molnar
  2007-02-01 17:49         ` Ingo Molnar
  0 siblings, 1 reply; 26+ messages in thread
From: Ingo Molnar @ 2007-02-01 17:38 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linux-kernel, linux-rt-users, Thomas Gleixner


* Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:

> >could you resend them to me please?
> 
>    Seeing that GENERIC_TIME has been thrown out from the -rt patch, 
> [...]

hm, i did that accidentally during a rebase. That was certainly not 
meant to be a persistent condition.

	Ingo


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2007-02-01 17:38       ` Ingo Molnar
@ 2007-02-01 17:49         ` Ingo Molnar
  2007-02-01 18:01           ` Sergei Shtylyov
  0 siblings, 1 reply; 26+ messages in thread
From: Ingo Molnar @ 2007-02-01 17:49 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linux-kernel, linux-rt-users, Thomas Gleixner


* Ingo Molnar <mingo@elte.hu> wrote:

> * Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> 
> > >could you resend them to me please?
> > 
> >    Seeing that GENERIC_TIME has been thrown out from the -rt patch, 
> > [...]
> 
> hm, i did that accidentally during a rebase. That was certainly not 
> meant to be a persistent condition.

ok, the delta below is what i've managed to restore from your PPC 
patches so far. Looks like this was truly a comedy of errors: i 
accidentally dropped the big ppc-gtod patch, which made your later fix 
patches not apply, etc., etc. The one below still likely wont build 
right away, but should be a more useful base for you and for Thomas too.

	Ingo

--------------->
Index: linux/Makefile
===================================================================
--- linux.orig/Makefile
+++ linux/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 20
-EXTRAVERSION =-rc7-rt3
+EXTRAVERSION =-rc7-rt4
 NAME = Homicidal Dwarf Hamster
 
 # *DOCUMENTATION*
Index: linux/arch/powerpc/Kconfig
===================================================================
--- linux.orig/arch/powerpc/Kconfig
+++ linux/arch/powerpc/Kconfig
@@ -26,6 +26,10 @@ config MMU
 	bool
 	default y
 
+config GENERIC_TIME
+	bool
+	default y
+
 config GENERIC_HARDIRQS
 	bool
 	default y
Index: linux/arch/powerpc/kernel/time.c
===================================================================
--- linux.orig/arch/powerpc/kernel/time.c
+++ linux/arch/powerpc/kernel/time.c
@@ -119,8 +119,6 @@ EXPORT_SYMBOL_GPL(rtc_lock);
 u64 tb_to_ns_scale;
 unsigned tb_to_ns_shift;
 
-struct gettimeofday_struct do_gtod;
-
 extern struct timezone sys_tz;
 static long timezone_offset;
 
@@ -378,160 +376,6 @@ static __inline__ void timer_check_rtc(v
         }
 }
 
-/*
- * This version of gettimeofday has microsecond resolution.
- */
-static inline void __do_gettimeofday(struct timeval *tv)
-{
-	unsigned long sec, usec;
-	u64 tb_ticks, xsec;
-	struct gettimeofday_vars *temp_varp;
-	u64 temp_tb_to_xs, temp_stamp_xsec;
-
-	/*
-	 * These calculations are faster (gets rid of divides)
-	 * if done in units of 1/2^20 rather than microseconds.
-	 * The conversion to microseconds at the end is done
-	 * without a divide (and in fact, without a multiply)
-	 */
-	temp_varp = do_gtod.varp;
-
-	/* Sampling the time base must be done after loading
-	 * do_gtod.varp in order to avoid racing with update_gtod.
-	 */
-	data_barrier(temp_varp);
-	tb_ticks = get_tb() - temp_varp->tb_orig_stamp;
-	temp_tb_to_xs = temp_varp->tb_to_xs;
-	temp_stamp_xsec = temp_varp->stamp_xsec;
-	xsec = temp_stamp_xsec + mulhdu(tb_ticks, temp_tb_to_xs);
-	sec = xsec / XSEC_PER_SEC;
-	usec = (unsigned long)xsec & (XSEC_PER_SEC - 1);
-	usec = SCALE_XSEC(usec, 1000000);
-
-	tv->tv_sec = sec;
-	tv->tv_usec = usec;
-}
-
-void do_gettimeofday(struct timeval *tv)
-{
-	if (__USE_RTC()) {
-		/* do this the old way */
-		unsigned long flags, seq;
-		unsigned int sec, nsec, usec;
-
-		do {
-			seq = read_seqbegin_irqsave(&xtime_lock, flags);
-			sec = xtime.tv_sec;
-			nsec = xtime.tv_nsec + tb_ticks_since(tb_last_jiffy);
-		} while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
-		usec = nsec / 1000;
-		while (usec >= 1000000) {
-			usec -= 1000000;
-			++sec;
-		}
-		tv->tv_sec = sec;
-		tv->tv_usec = usec;
-		return;
-	}
-	__do_gettimeofday(tv);
-}
-
-EXPORT_SYMBOL(do_gettimeofday);
-
-/*
- * There are two copies of tb_to_xs and stamp_xsec so that no
- * lock is needed to access and use these values in
- * do_gettimeofday.  We alternate the copies and as long as a
- * reasonable time elapses between changes, there will never
- * be inconsistent values.  ntpd has a minimum of one minute
- * between updates.
- */
-static inline void update_gtod(u64 new_tb_stamp, u64 new_stamp_xsec,
-			       u64 new_tb_to_xs)
-{
-	unsigned temp_idx;
-	struct gettimeofday_vars *temp_varp;
-
-	temp_idx = (do_gtod.var_idx == 0);
-	temp_varp = &do_gtod.vars[temp_idx];
-
-	temp_varp->tb_to_xs = new_tb_to_xs;
-	temp_varp->tb_orig_stamp = new_tb_stamp;
-	temp_varp->stamp_xsec = new_stamp_xsec;
-	smp_mb();
-	do_gtod.varp = temp_varp;
-	do_gtod.var_idx = temp_idx;
-
-	/*
-	 * tb_update_count is used to allow the userspace gettimeofday code
-	 * to assure itself that it sees a consistent view of the tb_to_xs and
-	 * stamp_xsec variables.  It reads the tb_update_count, then reads
-	 * tb_to_xs and stamp_xsec and then reads tb_update_count again.  If
-	 * the two values of tb_update_count match and are even then the
-	 * tb_to_xs and stamp_xsec values are consistent.  If not, then it
-	 * loops back and reads them again until this criteria is met.
-	 * We expect the caller to have done the first increment of
-	 * vdso_data->tb_update_count already.
-	 */
-	vdso_data->tb_orig_stamp = new_tb_stamp;
-	vdso_data->stamp_xsec = new_stamp_xsec;
-	vdso_data->tb_to_xs = new_tb_to_xs;
-	vdso_data->wtom_clock_sec = wall_to_monotonic.tv_sec;
-	vdso_data->wtom_clock_nsec = wall_to_monotonic.tv_nsec;
-	smp_wmb();
-	++(vdso_data->tb_update_count);
-}
-
-/*
- * When the timebase - tb_orig_stamp gets too big, we do a manipulation
- * between tb_orig_stamp and stamp_xsec. The goal here is to keep the
- * difference tb - tb_orig_stamp small enough to always fit inside a
- * 32 bits number. This is a requirement of our fast 32 bits userland
- * implementation in the vdso. If we "miss" a call to this function
- * (interrupt latency, CPU locked in a spinlock, ...) and we end up
- * with a too big difference, then the vdso will fallback to calling
- * the syscall
- */
-static __inline__ void timer_recalc_offset(u64 cur_tb)
-{
-	unsigned long offset;
-	u64 new_stamp_xsec;
-	u64 tlen, t2x;
-	u64 tb, xsec_old, xsec_new;
-	struct gettimeofday_vars *varp;
-
-	if (__USE_RTC())
-		return;
-	tlen = current_tick_length();
-	offset = cur_tb - do_gtod.varp->tb_orig_stamp;
-	if (tlen == last_tick_len && offset < 0x80000000u)
-		return;
-	if (tlen != last_tick_len) {
-		t2x = mulhdu(tlen << TICKLEN_SHIFT, ticklen_to_xs);
-		last_tick_len = tlen;
-	} else
-		t2x = do_gtod.varp->tb_to_xs;
-	new_stamp_xsec = (u64) xtime.tv_nsec * XSEC_PER_SEC;
-	do_div(new_stamp_xsec, 1000000000);
-	new_stamp_xsec += (u64) xtime.tv_sec * XSEC_PER_SEC;
-
-	++vdso_data->tb_update_count;
-	smp_mb();
-
-	/*
-	 * Make sure time doesn't go backwards for userspace gettimeofday.
-	 */
-	tb = get_tb();
-	varp = do_gtod.varp;
-	xsec_old = mulhdu(tb - varp->tb_orig_stamp, varp->tb_to_xs)
-		+ varp->stamp_xsec;
-	xsec_new = mulhdu(tb - cur_tb, t2x) + new_stamp_xsec;
-	if (xsec_new < xsec_old)
-		new_stamp_xsec += xsec_old - xsec_new;
-
-	update_gtod(cur_tb, new_stamp_xsec, t2x);
-}
-
 #ifdef CONFIG_SMP
 unsigned long notrace profile_pc(struct pt_regs *regs)
 {
@@ -581,11 +425,7 @@ static void iSeries_tb_recal(void)
 				tb_ticks_per_sec   = new_tb_ticks_per_sec;
 				calc_cputime_factors();
 				div128_by_32( XSEC_PER_SEC, 0, tb_ticks_per_sec, &divres );
-				do_gtod.tb_ticks_per_sec = tb_ticks_per_sec;
 				tb_to_xs = divres.result_low;
-				do_gtod.varp->tb_to_xs = tb_to_xs;
-				vdso_data->tb_ticks_per_sec = tb_ticks_per_sec;
-				vdso_data->tb_to_xs = tb_to_xs;
 			}
 			else {
 				printk( "Titan recalibrate: FAILED (difference > 4 percent)\n"
@@ -756,77 +596,6 @@ unsigned long long sched_clock(void)
 	return mulhdu(get_tb(), tb_to_ns_scale) << tb_to_ns_shift;
 }
 
-int do_settimeofday(struct timespec *tv)
-{
-	time_t wtm_sec, new_sec = tv->tv_sec;
-	long wtm_nsec, new_nsec = tv->tv_nsec;
-	unsigned long flags;
-	u64 new_xsec;
-	unsigned long tb_delta;
-
-	if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
-		return -EINVAL;
-
-	write_seqlock_irqsave(&xtime_lock, flags);
-
-	/*
-	 * Updating the RTC is not the job of this code. If the time is
-	 * stepped under NTP, the RTC will be updated after STA_UNSYNC
-	 * is cleared.  Tools like clock/hwclock either copy the RTC
-	 * to the system time, in which case there is no point in writing
-	 * to the RTC again, or write to the RTC but then they don't call
-	 * settimeofday to perform this operation.
-	 */
-#ifdef CONFIG_PPC_ISERIES
-	if (firmware_has_feature(FW_FEATURE_ISERIES) && first_settimeofday) {
-		iSeries_tb_recal();
-		first_settimeofday = 0;
-	}
-#endif
-
-	/* Make userspace gettimeofday spin until we're done. */
-	++vdso_data->tb_update_count;
-	smp_mb();
-
-	/*
-	 * Subtract off the number of nanoseconds since the
-	 * beginning of the last tick.
-	 */
-	tb_delta = tb_ticks_since(tb_last_jiffy);
-	tb_delta = mulhdu(tb_delta, do_gtod.varp->tb_to_xs); /* in xsec */
-	new_nsec -= SCALE_XSEC(tb_delta, 1000000000);
-
-	wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - new_sec);
-	wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - new_nsec);
-
- 	set_normalized_timespec(&xtime, new_sec, new_nsec);
-	set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
-
-	/* In case of a large backwards jump in time with NTP, we want the 
-	 * clock to be updated as soon as the PLL is again in lock.
-	 */
-	last_rtc_update = new_sec - 658;
-
-	ntp_clear();
-
-	new_xsec = xtime.tv_nsec;
-	if (new_xsec != 0) {
-		new_xsec *= XSEC_PER_SEC;
-		do_div(new_xsec, NSEC_PER_SEC);
-	}
-	new_xsec += (u64)xtime.tv_sec * XSEC_PER_SEC;
-	update_gtod(tb_last_jiffy, new_xsec, do_gtod.varp->tb_to_xs);
-
-	vdso_data->tz_minuteswest = sys_tz.tz_minuteswest;
-	vdso_data->tz_dsttime = sys_tz.tz_dsttime;
-
-	write_sequnlock_irqrestore(&xtime_lock, flags);
-	clock_was_set();
-	return 0;
-}
-
-EXPORT_SYMBOL(do_settimeofday);
-
 static int __init get_freq(char *name, int cells, unsigned long *val)
 {
 	struct device_node *cpu;
@@ -993,20 +762,6 @@ void __init time_init(void)
 
 	xtime.tv_sec = tm;
 	xtime.tv_nsec = 0;
-	do_gtod.varp = &do_gtod.vars[0];
-	do_gtod.var_idx = 0;
-	do_gtod.varp->tb_orig_stamp = tb_last_jiffy;
-	__get_cpu_var(last_jiffy) = tb_last_jiffy;
-	do_gtod.varp->stamp_xsec = (u64) xtime.tv_sec * XSEC_PER_SEC;
-	do_gtod.tb_ticks_per_sec = tb_ticks_per_sec;
-	do_gtod.varp->tb_to_xs = tb_to_xs;
-	do_gtod.tb_to_us = tb_to_us;
-
-	vdso_data->tb_orig_stamp = tb_last_jiffy;
-	vdso_data->tb_update_count = 0;
-	vdso_data->tb_ticks_per_sec = tb_ticks_per_sec;
-	vdso_data->stamp_xsec = (u64) xtime.tv_sec * XSEC_PER_SEC;
-	vdso_data->tb_to_xs = tb_to_xs;
 
 	time_freq = 0;
 
@@ -1019,7 +774,6 @@ void __init time_init(void)
 	set_dec(tb_ticks_per_jiffy);
 }
 
-
 #define FEBRUARY	2
 #define	STARTOFTIME	1970
 #define SECDAY		86400L
@@ -1164,3 +918,36 @@ void div128_by_32(u64 dividend_high, u64
 	dr->result_low  = ((u64)y << 32) + z;
 
 }
+
+/* PowerPC clocksource code */
+
+#include <linux/clocksource.h>
+
+static cycle_t timebase_read(void)
+{
+	return (cycle_t)get_tb();
+}
+
+struct clocksource clocksource_timebase = {
+	.name		= "timebase",
+	.rating		= 200,
+	.read		= timebase_read,
+	.mask		= (cycle_t)-1,
+	.mult		= 0,
+	.shift		= 22,
+	.is_continuous	= 1,
+};
+
+
+/* XXX - this should be calculated or properly externed! */
+static int __init init_timebase_clocksource(void)
+{
+	if (__USE_RTC())
+		return -ENODEV;
+
+	clocksource_timebase.mult = clocksource_hz2mult(tb_ticks_per_sec,
+					clocksource_timebase.shift);
+	return clocksource_register(&clocksource_timebase);
+}
+
+module_init(init_timebase_clocksource);
Index: linux/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linux/arch/powerpc/platforms/cell/interrupt.c
@@ -90,6 +90,7 @@ static struct irq_chip iic_chip = {
 	.typename = " CELL-IIC ",
 	.mask = iic_mask,
 	.unmask = iic_unmask,
+	.ack = iic_eoi,
 	.eoi = iic_eoi,
 };
 
Index: linux/arch/powerpc/platforms/iseries/irq.c
===================================================================
--- linux.orig/arch/powerpc/platforms/iseries/irq.c
+++ linux/arch/powerpc/platforms/iseries/irq.c
@@ -279,6 +279,7 @@ static struct irq_chip iseries_pic = {
 	.shutdown	= iseries_shutdown_IRQ,
 	.unmask		= iseries_enable_IRQ,
 	.mask		= iseries_disable_IRQ,
+	.ack		= iseries_end_IRQ,
 	.eoi		= iseries_end_IRQ
 };
 
Index: linux/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux.orig/arch/powerpc/platforms/pseries/xics.c
+++ linux/arch/powerpc/platforms/pseries/xics.c
@@ -456,6 +456,7 @@ static struct irq_chip xics_pic_direct =
 	.startup = xics_startup,
 	.mask = xics_mask_irq,
 	.unmask = xics_unmask_irq,
+	.ack = xics_eoi_direct,
 	.eoi = xics_eoi_direct,
 	.set_affinity = xics_set_affinity
 };
@@ -466,6 +467,7 @@ static struct irq_chip xics_pic_lpar = {
 	.startup = xics_startup,
 	.mask = xics_mask_irq,
 	.unmask = xics_unmask_irq,
+	.ack = xics_eoi_lpar,
 	.eoi = xics_eoi_lpar,
 	.set_affinity = xics_set_affinity
 };
Index: linux/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux.orig/arch/powerpc/sysdev/mpic.c
+++ linux/arch/powerpc/sysdev/mpic.c
@@ -767,6 +767,7 @@ static int mpic_set_irq_type(unsigned in
 static struct irq_chip mpic_irq_chip = {
 	.mask		= mpic_mask_irq,
 	.unmask		= mpic_unmask_irq,
+	.ack		= mpic_end_irq,
 	.eoi		= mpic_end_irq,
 	.set_type	= mpic_set_irq_type,
 };
Index: linux/drivers/mtd/nand/cafe.c
===================================================================
--- linux.orig/drivers/mtd/nand/cafe.c
+++ linux/drivers/mtd/nand/cafe.c
@@ -597,7 +597,8 @@ static int __devinit cafe_nand_probe(str
 		cafe_writel(cafe, 0xffffffff, NAND_TIMING3);
 	}
 	cafe_writel(cafe, 0xffffffff, NAND_IRQ_MASK);
-	err = request_irq(pdev->irq, &cafe_nand_interrupt, SA_SHIRQ, "CAFE NAND", mtd);
+	err = request_irq(pdev->irq, &cafe_nand_interrupt, IRQF_SHARED,
+			"CAFE NAND", mtd);
 	if (err) {
 		dev_warn(&pdev->dev, "Could not register IRQ %d\n", pdev->irq);
 
Index: linux/kernel/latency_trace.c
===================================================================
--- linux.orig/kernel/latency_trace.c
+++ linux/kernel/latency_trace.c
@@ -1774,8 +1774,8 @@ check_critical_timing(int cpu, struct cp
 #ifndef CONFIG_CRITICAL_LATENCY_HIST
 	if (!preempt_thresh && preempt_max_latency > delta) {
 		printk("bug: updating %016Lx > %016Lx?\n",
-			preempt_max_latency, delta);
-		printk("  [%016Lx %016Lx %016Lx]\n", T0, T1, T2);
+			(u64)preempt_max_latency, (u64)delta);
+		printk("  [%016Lx %016Lx %016Lx]\n", (u64)T0, (u64)T1, (u64)T2);
 	}
 #endif
 


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2007-02-01 17:49         ` Ingo Molnar
@ 2007-02-01 18:01           ` Sergei Shtylyov
  2007-03-07 14:55               ` Sergei Shtylyov
  0 siblings, 1 reply; 26+ messages in thread
From: Sergei Shtylyov @ 2007-02-01 18:01 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, linux-rt-users, Thomas Gleixner

Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:

>>* Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:

>>>>could you resend them to me please?

>>>   Seeing that GENERIC_TIME has been thrown out from the -rt patch, 
>>>[...]

>>hm, i did that accidentally during a rebase. That was certainly not 
>>meant to be a persistent condition.

> ok, the delta below is what i've managed to restore from your PPC 
> patches so far. Looks like this was truly a comedy of errors: i 
> accidentally dropped the big ppc-gtod patch,

   I can't take credit for this one -- it's (and the vsyscall breakage :-) 
courtesy of John Stultz.

> which made your later fix 
> patches not apply, etc., etc. The one below still likely wont build 
> right away, but should be a more useful base for you and for Thomas too.

> 	Ingo
> 
> --------------->
> Index: linux/Makefile
> ===================================================================
> --- linux.orig/Makefile
> +++ linux/Makefile
> @@ -1,7 +1,7 @@
>  VERSION = 2
>  PATCHLEVEL = 6
>  SUBLEVEL = 20
> -EXTRAVERSION =-rc7-rt3
> +EXTRAVERSION =-rc7-rt4
>  NAME = Homicidal Dwarf Hamster
>  
>  # *DOCUMENTATION*
> Index: linux/arch/powerpc/Kconfig
> ===================================================================
> --- linux.orig/arch/powerpc/Kconfig
> +++ linux/arch/powerpc/Kconfig
> @@ -26,6 +26,10 @@ config MMU
>  	bool
>  	default y
>  
> +config GENERIC_TIME
> +	bool
> +	default y
> +
>  config GENERIC_HARDIRQS
>  	bool
>  	default y
> Index: linux/arch/powerpc/kernel/time.c
> ===================================================================
> --- linux.orig/arch/powerpc/kernel/time.c
> +++ linux/arch/powerpc/kernel/time.c
> @@ -119,8 +119,6 @@ EXPORT_SYMBOL_GPL(rtc_lock);
>  u64 tb_to_ns_scale;
>  unsigned tb_to_ns_shift;
>  
> -struct gettimeofday_struct do_gtod;
> -
>  extern struct timezone sys_tz;
>  static long timezone_offset;
>  
> @@ -378,160 +376,6 @@ static __inline__ void timer_check_rtc(v
>          }
>  }
>  
> -/*
> - * This version of gettimeofday has microsecond resolution.
> - */
> -static inline void __do_gettimeofday(struct timeval *tv)
> -{
> -	unsigned long sec, usec;
> -	u64 tb_ticks, xsec;
> -	struct gettimeofday_vars *temp_varp;
> -	u64 temp_tb_to_xs, temp_stamp_xsec;
> -
> -	/*
> -	 * These calculations are faster (gets rid of divides)
> -	 * if done in units of 1/2^20 rather than microseconds.
> -	 * The conversion to microseconds at the end is done
> -	 * without a divide (and in fact, without a multiply)
> -	 */
> -	temp_varp = do_gtod.varp;
> -
> -	/* Sampling the time base must be done after loading
> -	 * do_gtod.varp in order to avoid racing with update_gtod.
> -	 */
> -	data_barrier(temp_varp);
> -	tb_ticks = get_tb() - temp_varp->tb_orig_stamp;
> -	temp_tb_to_xs = temp_varp->tb_to_xs;
> -	temp_stamp_xsec = temp_varp->stamp_xsec;
> -	xsec = temp_stamp_xsec + mulhdu(tb_ticks, temp_tb_to_xs);
> -	sec = xsec / XSEC_PER_SEC;
> -	usec = (unsigned long)xsec & (XSEC_PER_SEC - 1);
> -	usec = SCALE_XSEC(usec, 1000000);
> -
> -	tv->tv_sec = sec;
> -	tv->tv_usec = usec;
> -}
> -
> -void do_gettimeofday(struct timeval *tv)
> -{
> -	if (__USE_RTC()) {
> -		/* do this the old way */
> -		unsigned long flags, seq;
> -		unsigned int sec, nsec, usec;
> -
> -		do {
> -			seq = read_seqbegin_irqsave(&xtime_lock, flags);
> -			sec = xtime.tv_sec;
> -			nsec = xtime.tv_nsec + tb_ticks_since(tb_last_jiffy);
> -		} while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
> -		usec = nsec / 1000;
> -		while (usec >= 1000000) {
> -			usec -= 1000000;
> -			++sec;
> -		}
> -		tv->tv_sec = sec;
> -		tv->tv_usec = usec;
> -		return;
> -	}
> -	__do_gettimeofday(tv);
> -}
> -
> -EXPORT_SYMBOL(do_gettimeofday);
> -
> -/*
> - * There are two copies of tb_to_xs and stamp_xsec so that no
> - * lock is needed to access and use these values in
> - * do_gettimeofday.  We alternate the copies and as long as a
> - * reasonable time elapses between changes, there will never
> - * be inconsistent values.  ntpd has a minimum of one minute
> - * between updates.
> - */
> -static inline void update_gtod(u64 new_tb_stamp, u64 new_stamp_xsec,
> -			       u64 new_tb_to_xs)
> -{
> -	unsigned temp_idx;
> -	struct gettimeofday_vars *temp_varp;
> -
> -	temp_idx = (do_gtod.var_idx == 0);
> -	temp_varp = &do_gtod.vars[temp_idx];
> -
> -	temp_varp->tb_to_xs = new_tb_to_xs;
> -	temp_varp->tb_orig_stamp = new_tb_stamp;
> -	temp_varp->stamp_xsec = new_stamp_xsec;
> -	smp_mb();
> -	do_gtod.varp = temp_varp;
> -	do_gtod.var_idx = temp_idx;
> -
> -	/*
> -	 * tb_update_count is used to allow the userspace gettimeofday code
> -	 * to assure itself that it sees a consistent view of the tb_to_xs and
> -	 * stamp_xsec variables.  It reads the tb_update_count, then reads
> -	 * tb_to_xs and stamp_xsec and then reads tb_update_count again.  If
> -	 * the two values of tb_update_count match and are even then the
> -	 * tb_to_xs and stamp_xsec values are consistent.  If not, then it
> -	 * loops back and reads them again until this criteria is met.
> -	 * We expect the caller to have done the first increment of
> -	 * vdso_data->tb_update_count already.
> -	 */
> -	vdso_data->tb_orig_stamp = new_tb_stamp;
> -	vdso_data->stamp_xsec = new_stamp_xsec;
> -	vdso_data->tb_to_xs = new_tb_to_xs;
> -	vdso_data->wtom_clock_sec = wall_to_monotonic.tv_sec;
> -	vdso_data->wtom_clock_nsec = wall_to_monotonic.tv_nsec;
> -	smp_wmb();
> -	++(vdso_data->tb_update_count);
> -}
> -
> -/*
> - * When the timebase - tb_orig_stamp gets too big, we do a manipulation
> - * between tb_orig_stamp and stamp_xsec. The goal here is to keep the
> - * difference tb - tb_orig_stamp small enough to always fit inside a
> - * 32 bits number. This is a requirement of our fast 32 bits userland
> - * implementation in the vdso. If we "miss" a call to this function
> - * (interrupt latency, CPU locked in a spinlock, ...) and we end up
> - * with a too big difference, then the vdso will fallback to calling
> - * the syscall
> - */
> -static __inline__ void timer_recalc_offset(u64 cur_tb)
> -{
> -	unsigned long offset;
> -	u64 new_stamp_xsec;
> -	u64 tlen, t2x;
> -	u64 tb, xsec_old, xsec_new;
> -	struct gettimeofday_vars *varp;
> -
> -	if (__USE_RTC())
> -		return;
> -	tlen = current_tick_length();
> -	offset = cur_tb - do_gtod.varp->tb_orig_stamp;
> -	if (tlen == last_tick_len && offset < 0x80000000u)
> -		return;
> -	if (tlen != last_tick_len) {
> -		t2x = mulhdu(tlen << TICKLEN_SHIFT, ticklen_to_xs);
> -		last_tick_len = tlen;
> -	} else
> -		t2x = do_gtod.varp->tb_to_xs;
> -	new_stamp_xsec = (u64) xtime.tv_nsec * XSEC_PER_SEC;
> -	do_div(new_stamp_xsec, 1000000000);
> -	new_stamp_xsec += (u64) xtime.tv_sec * XSEC_PER_SEC;
> -
> -	++vdso_data->tb_update_count;
> -	smp_mb();
> -
> -	/*
> -	 * Make sure time doesn't go backwards for userspace gettimeofday.
> -	 */
> -	tb = get_tb();
> -	varp = do_gtod.varp;
> -	xsec_old = mulhdu(tb - varp->tb_orig_stamp, varp->tb_to_xs)
> -		+ varp->stamp_xsec;
> -	xsec_new = mulhdu(tb - cur_tb, t2x) + new_stamp_xsec;
> -	if (xsec_new < xsec_old)
> -		new_stamp_xsec += xsec_old - xsec_new;
> -
> -	update_gtod(cur_tb, new_stamp_xsec, t2x);
> -}
> -
>  #ifdef CONFIG_SMP
>  unsigned long notrace profile_pc(struct pt_regs *regs)
>  {
> @@ -581,11 +425,7 @@ static void iSeries_tb_recal(void)
>  				tb_ticks_per_sec   = new_tb_ticks_per_sec;
>  				calc_cputime_factors();
>  				div128_by_32( XSEC_PER_SEC, 0, tb_ticks_per_sec, &divres );
> -				do_gtod.tb_ticks_per_sec = tb_ticks_per_sec;
>  				tb_to_xs = divres.result_low;
> -				do_gtod.varp->tb_to_xs = tb_to_xs;
> -				vdso_data->tb_ticks_per_sec = tb_ticks_per_sec;
> -				vdso_data->tb_to_xs = tb_to_xs;
>  			}
>  			else {
>  				printk( "Titan recalibrate: FAILED (difference > 4 percent)\n"
> @@ -756,77 +596,6 @@ unsigned long long sched_clock(void)
>  	return mulhdu(get_tb(), tb_to_ns_scale) << tb_to_ns_shift;
>  }
>  
> -int do_settimeofday(struct timespec *tv)
> -{
> -	time_t wtm_sec, new_sec = tv->tv_sec;
> -	long wtm_nsec, new_nsec = tv->tv_nsec;
> -	unsigned long flags;
> -	u64 new_xsec;
> -	unsigned long tb_delta;
> -
> -	if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
> -		return -EINVAL;
> -
> -	write_seqlock_irqsave(&xtime_lock, flags);
> -
> -	/*
> -	 * Updating the RTC is not the job of this code. If the time is
> -	 * stepped under NTP, the RTC will be updated after STA_UNSYNC
> -	 * is cleared.  Tools like clock/hwclock either copy the RTC
> -	 * to the system time, in which case there is no point in writing
> -	 * to the RTC again, or write to the RTC but then they don't call
> -	 * settimeofday to perform this operation.
> -	 */
> -#ifdef CONFIG_PPC_ISERIES
> -	if (firmware_has_feature(FW_FEATURE_ISERIES) && first_settimeofday) {
> -		iSeries_tb_recal();
> -		first_settimeofday = 0;
> -	}
> -#endif
> -
> -	/* Make userspace gettimeofday spin until we're done. */
> -	++vdso_data->tb_update_count;
> -	smp_mb();
> -
> -	/*
> -	 * Subtract off the number of nanoseconds since the
> -	 * beginning of the last tick.
> -	 */
> -	tb_delta = tb_ticks_since(tb_last_jiffy);
> -	tb_delta = mulhdu(tb_delta, do_gtod.varp->tb_to_xs); /* in xsec */
> -	new_nsec -= SCALE_XSEC(tb_delta, 1000000000);
> -
> -	wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - new_sec);
> -	wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - new_nsec);
> -
> - 	set_normalized_timespec(&xtime, new_sec, new_nsec);
> -	set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
> -
> -	/* In case of a large backwards jump in time with NTP, we want the 
> -	 * clock to be updated as soon as the PLL is again in lock.
> -	 */
> -	last_rtc_update = new_sec - 658;
> -
> -	ntp_clear();
> -
> -	new_xsec = xtime.tv_nsec;
> -	if (new_xsec != 0) {
> -		new_xsec *= XSEC_PER_SEC;
> -		do_div(new_xsec, NSEC_PER_SEC);
> -	}
> -	new_xsec += (u64)xtime.tv_sec * XSEC_PER_SEC;
> -	update_gtod(tb_last_jiffy, new_xsec, do_gtod.varp->tb_to_xs);
> -
> -	vdso_data->tz_minuteswest = sys_tz.tz_minuteswest;
> -	vdso_data->tz_dsttime = sys_tz.tz_dsttime;
> -
> -	write_sequnlock_irqrestore(&xtime_lock, flags);
> -	clock_was_set();
> -	return 0;
> -}
> -
> -EXPORT_SYMBOL(do_settimeofday);
> -
>  static int __init get_freq(char *name, int cells, unsigned long *val)
>  {
>  	struct device_node *cpu;
> @@ -993,20 +762,6 @@ void __init time_init(void)
>  
>  	xtime.tv_sec = tm;
>  	xtime.tv_nsec = 0;
> -	do_gtod.varp = &do_gtod.vars[0];
> -	do_gtod.var_idx = 0;
> -	do_gtod.varp->tb_orig_stamp = tb_last_jiffy;
> -	__get_cpu_var(last_jiffy) = tb_last_jiffy;
> -	do_gtod.varp->stamp_xsec = (u64) xtime.tv_sec * XSEC_PER_SEC;
> -	do_gtod.tb_ticks_per_sec = tb_ticks_per_sec;
> -	do_gtod.varp->tb_to_xs = tb_to_xs;
> -	do_gtod.tb_to_us = tb_to_us;
> -
> -	vdso_data->tb_orig_stamp = tb_last_jiffy;
> -	vdso_data->tb_update_count = 0;
> -	vdso_data->tb_ticks_per_sec = tb_ticks_per_sec;
> -	vdso_data->stamp_xsec = (u64) xtime.tv_sec * XSEC_PER_SEC;
> -	vdso_data->tb_to_xs = tb_to_xs;
>  
>  	time_freq = 0;
>  
> @@ -1019,7 +774,6 @@ void __init time_init(void)
>  	set_dec(tb_ticks_per_jiffy);
>  }
>  
> -
>  #define FEBRUARY	2
>  #define	STARTOFTIME	1970
>  #define SECDAY		86400L
> @@ -1164,3 +918,36 @@ void div128_by_32(u64 dividend_high, u64
>  	dr->result_low  = ((u64)y << 32) + z;
>  
>  }
> +
> +/* PowerPC clocksource code */
> +
> +#include <linux/clocksource.h>
> +
> +static cycle_t timebase_read(void)
> +{
> +	return (cycle_t)get_tb();
> +}
> +
> +struct clocksource clocksource_timebase = {
> +	.name		= "timebase",
> +	.rating		= 200,
> +	.read		= timebase_read,
> +	.mask		= (cycle_t)-1,
> +	.mult		= 0,
> +	.shift		= 22,
> +	.is_continuous	= 1,
> +};
> +
> +
> +/* XXX - this should be calculated or properly externed! */
> +static int __init init_timebase_clocksource(void)
> +{
> +	if (__USE_RTC())
> +		return -ENODEV;
> +
> +	clocksource_timebase.mult = clocksource_hz2mult(tb_ticks_per_sec,
> +					clocksource_timebase.shift);
> +	return clocksource_register(&clocksource_timebase);
> +}
> +
> +module_init(init_timebase_clocksource);

    Erm, there was one more patch implementing read_prersistent_clock()...

> Index: linux/arch/powerpc/platforms/cell/interrupt.c
> ===================================================================
> --- linux.orig/arch/powerpc/platforms/cell/interrupt.c
> +++ linux/arch/powerpc/platforms/cell/interrupt.c
> @@ -90,6 +90,7 @@ static struct irq_chip iic_chip = {
>  	.typename = " CELL-IIC ",
>  	.mask = iic_mask,
>  	.unmask = iic_unmask,
> +	.ack = iic_eoi,
>  	.eoi = iic_eoi,
>  };
>  
> Index: linux/arch/powerpc/platforms/iseries/irq.c
> ===================================================================
> --- linux.orig/arch/powerpc/platforms/iseries/irq.c
> +++ linux/arch/powerpc/platforms/iseries/irq.c
> @@ -279,6 +279,7 @@ static struct irq_chip iseries_pic = {
>  	.shutdown	= iseries_shutdown_IRQ,
>  	.unmask		= iseries_enable_IRQ,
>  	.mask		= iseries_disable_IRQ,
> +	.ack		= iseries_end_IRQ,
>  	.eoi		= iseries_end_IRQ
>  };
>  
> Index: linux/arch/powerpc/platforms/pseries/xics.c
> ===================================================================
> --- linux.orig/arch/powerpc/platforms/pseries/xics.c
> +++ linux/arch/powerpc/platforms/pseries/xics.c
> @@ -456,6 +456,7 @@ static struct irq_chip xics_pic_direct =
>  	.startup = xics_startup,
>  	.mask = xics_mask_irq,
>  	.unmask = xics_unmask_irq,
> +	.ack = xics_eoi_direct,
>  	.eoi = xics_eoi_direct,
>  	.set_affinity = xics_set_affinity
>  };
> @@ -466,6 +467,7 @@ static struct irq_chip xics_pic_lpar = {
>  	.startup = xics_startup,
>  	.mask = xics_mask_irq,
>  	.unmask = xics_unmask_irq,
> +	.ack = xics_eoi_lpar,
>  	.eoi = xics_eoi_lpar,
>  	.set_affinity = xics_set_affinity
>  };
> Index: linux/arch/powerpc/sysdev/mpic.c
> ===================================================================
> --- linux.orig/arch/powerpc/sysdev/mpic.c
> +++ linux/arch/powerpc/sysdev/mpic.c
> @@ -767,6 +767,7 @@ static int mpic_set_irq_type(unsigned in
>  static struct irq_chip mpic_irq_chip = {
>  	.mask		= mpic_mask_irq,
>  	.unmask		= mpic_unmask_irq,
> +	.ack		= mpic_end_irq,
>  	.eoi		= mpic_end_irq,
>  	.set_type	= mpic_set_irq_type,
>  };

    These changes have been refused in favor of "fasetoi" flow fix.

> Index: linux/drivers/mtd/nand/cafe.c
> ===================================================================
> --- linux.orig/drivers/mtd/nand/cafe.c
> +++ linux/drivers/mtd/nand/cafe.c
> @@ -597,7 +597,8 @@ static int __devinit cafe_nand_probe(str
>  		cafe_writel(cafe, 0xffffffff, NAND_TIMING3);
>  	}
>  	cafe_writel(cafe, 0xffffffff, NAND_IRQ_MASK);
> -	err = request_irq(pdev->irq, &cafe_nand_interrupt, SA_SHIRQ, "CAFE NAND", mtd);
> +	err = request_irq(pdev->irq, &cafe_nand_interrupt, IRQF_SHARED,
> +			"CAFE NAND", mtd);
>  	if (err) {
>  		dev_warn(&pdev->dev, "Could not register IRQ %d\n", pdev->irq);
>  

    Certainly not mine. :-)

> Index: linux/kernel/latency_trace.c
> ===================================================================
> --- linux.orig/kernel/latency_trace.c
> +++ linux/kernel/latency_trace.c
> @@ -1774,8 +1774,8 @@ check_critical_timing(int cpu, struct cp
>  #ifndef CONFIG_CRITICAL_LATENCY_HIST
>  	if (!preempt_thresh && preempt_max_latency > delta) {
>  		printk("bug: updating %016Lx > %016Lx?\n",
> -			preempt_max_latency, delta);
> -		printk("  [%016Lx %016Lx %016Lx]\n", T0, T1, T2);
> +			(u64)preempt_max_latency, (u64)delta);
> +		printk("  [%016Lx %016Lx %016Lx]\n", (u64)T0, (u64)T1, (u64)T2);
>  	}
>  #endif

    IIRC, this is a fragment of my another refused patch (maybe the first take 
on it?)... Should be outdated now.

WBR, Sergei

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
  2007-02-01 18:01           ` Sergei Shtylyov
@ 2007-03-07 14:55               ` Sergei Shtylyov
  0 siblings, 0 replies; 26+ messages in thread
From: Sergei Shtylyov @ 2007-03-07 14:55 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, linux-rt-users, Thomas Gleixner, linuxppc-dev

Hello, I wrote:

>>>>> could you resend them to me please?

>>>>   Seeing that GENERIC_TIME has been thrown out from the -rt patch, 
>>>> [...]

>>> hm, i did that accidentally during a rebase. That was certainly not 
>>> meant to be a persistent condition.

>> ok, the delta below is what i've managed to restore from your PPC 
>> patches so far. Looks like this was truly a comedy of errors: i 
>> accidentally dropped the big ppc-gtod patch,

[...]

>>     Ingo

>> Index: linux/arch/powerpc/platforms/cell/interrupt.c
>> ===================================================================
>> --- linux.orig/arch/powerpc/platforms/cell/interrupt.c
>> +++ linux/arch/powerpc/platforms/cell/interrupt.c
>> @@ -90,6 +90,7 @@ static struct irq_chip iic_chip = {
>>      .typename = " CELL-IIC ",
>>      .mask = iic_mask,
>>      .unmask = iic_unmask,
>> +    .ack = iic_eoi,
>>      .eoi = iic_eoi,
>>  };
>>  
>> Index: linux/arch/powerpc/platforms/iseries/irq.c
>> ===================================================================
>> --- linux.orig/arch/powerpc/platforms/iseries/irq.c
>> +++ linux/arch/powerpc/platforms/iseries/irq.c
>> @@ -279,6 +279,7 @@ static struct irq_chip iseries_pic = {
>>      .shutdown    = iseries_shutdown_IRQ,
>>      .unmask        = iseries_enable_IRQ,
>>      .mask        = iseries_disable_IRQ,
>> +    .ack        = iseries_end_IRQ,
>>      .eoi        = iseries_end_IRQ
>>  };
>>  
>> Index: linux/arch/powerpc/platforms/pseries/xics.c
>> ===================================================================
>> --- linux.orig/arch/powerpc/platforms/pseries/xics.c
>> +++ linux/arch/powerpc/platforms/pseries/xics.c
>> @@ -456,6 +456,7 @@ static struct irq_chip xics_pic_direct =
>>      .startup = xics_startup,
>>      .mask = xics_mask_irq,
>>      .unmask = xics_unmask_irq,
>> +    .ack = xics_eoi_direct,
>>      .eoi = xics_eoi_direct,
>>      .set_affinity = xics_set_affinity
>>  };
>> @@ -466,6 +467,7 @@ static struct irq_chip xics_pic_lpar = {
>>      .startup = xics_startup,
>>      .mask = xics_mask_irq,
>>      .unmask = xics_unmask_irq,
>> +    .ack = xics_eoi_lpar,
>>      .eoi = xics_eoi_lpar,
>>      .set_affinity = xics_set_affinity
>>  };
>> Index: linux/arch/powerpc/sysdev/mpic.c
>> ===================================================================
>> --- linux.orig/arch/powerpc/sysdev/mpic.c
>> +++ linux/arch/powerpc/sysdev/mpic.c
>> @@ -767,6 +767,7 @@ static int mpic_set_irq_type(unsigned in
>>  static struct irq_chip mpic_irq_chip = {
>>      .mask        = mpic_mask_irq,
>>      .unmask        = mpic_unmask_irq,
>> +    .ack        = mpic_end_irq,
>>      .eoi        = mpic_end_irq,
>>      .set_type    = mpic_set_irq_type,
>>  };

>    These changes have been refused in favor of "fasetoi" flow fix.

    Ugh, seeing them 2.6.20-rt8 still -- *please* remove, they're now useless 
and quite ugly...

>> Index: linux/kernel/latency_trace.c
>> ===================================================================
>> --- linux.orig/kernel/latency_trace.c
>> +++ linux/kernel/latency_trace.c
>> @@ -1774,8 +1774,8 @@ check_critical_timing(int cpu, struct cp
>>  #ifndef CONFIG_CRITICAL_LATENCY_HIST
>>      if (!preempt_thresh && preempt_max_latency > delta) {
>>          printk("bug: updating %016Lx > %016Lx?\n",
>> -            preempt_max_latency, delta);
>> -        printk("  [%016Lx %016Lx %016Lx]\n", T0, T1, T2);
>> +            (u64)preempt_max_latency, (u64)delta);
>> +        printk("  [%016Lx %016Lx %016Lx]\n", (u64)T0, (u64)T1, (u64)T2);
>>      }
>>  #endif

>    IIRC, this is a fragment of my another refused patch (maybe the first 
> take on it?)... Should be outdated now.

    Ugh, I'm seeing this one in 2.6.20-rt8 still... *Please* remove it -- it's 
*useless* with the current -rt code.

WBR, Sergei

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: v2.6.19-rt6, yum/rpm
@ 2007-03-07 14:55               ` Sergei Shtylyov
  0 siblings, 0 replies; 26+ messages in thread
From: Sergei Shtylyov @ 2007-03-07 14:55 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linuxppc-dev, Thomas Gleixner, linux-kernel, linux-rt-users

Hello, I wrote:

>>>>> could you resend them to me please?

>>>>   Seeing that GENERIC_TIME has been thrown out from the -rt patch, 
>>>> [...]

>>> hm, i did that accidentally during a rebase. That was certainly not 
>>> meant to be a persistent condition.

>> ok, the delta below is what i've managed to restore from your PPC 
>> patches so far. Looks like this was truly a comedy of errors: i 
>> accidentally dropped the big ppc-gtod patch,

[...]

>>     Ingo

>> Index: linux/arch/powerpc/platforms/cell/interrupt.c
>> ===================================================================
>> --- linux.orig/arch/powerpc/platforms/cell/interrupt.c
>> +++ linux/arch/powerpc/platforms/cell/interrupt.c
>> @@ -90,6 +90,7 @@ static struct irq_chip iic_chip = {
>>      .typename = " CELL-IIC ",
>>      .mask = iic_mask,
>>      .unmask = iic_unmask,
>> +    .ack = iic_eoi,
>>      .eoi = iic_eoi,
>>  };
>>  
>> Index: linux/arch/powerpc/platforms/iseries/irq.c
>> ===================================================================
>> --- linux.orig/arch/powerpc/platforms/iseries/irq.c
>> +++ linux/arch/powerpc/platforms/iseries/irq.c
>> @@ -279,6 +279,7 @@ static struct irq_chip iseries_pic = {
>>      .shutdown    = iseries_shutdown_IRQ,
>>      .unmask        = iseries_enable_IRQ,
>>      .mask        = iseries_disable_IRQ,
>> +    .ack        = iseries_end_IRQ,
>>      .eoi        = iseries_end_IRQ
>>  };
>>  
>> Index: linux/arch/powerpc/platforms/pseries/xics.c
>> ===================================================================
>> --- linux.orig/arch/powerpc/platforms/pseries/xics.c
>> +++ linux/arch/powerpc/platforms/pseries/xics.c
>> @@ -456,6 +456,7 @@ static struct irq_chip xics_pic_direct =
>>      .startup = xics_startup,
>>      .mask = xics_mask_irq,
>>      .unmask = xics_unmask_irq,
>> +    .ack = xics_eoi_direct,
>>      .eoi = xics_eoi_direct,
>>      .set_affinity = xics_set_affinity
>>  };
>> @@ -466,6 +467,7 @@ static struct irq_chip xics_pic_lpar = {
>>      .startup = xics_startup,
>>      .mask = xics_mask_irq,
>>      .unmask = xics_unmask_irq,
>> +    .ack = xics_eoi_lpar,
>>      .eoi = xics_eoi_lpar,
>>      .set_affinity = xics_set_affinity
>>  };
>> Index: linux/arch/powerpc/sysdev/mpic.c
>> ===================================================================
>> --- linux.orig/arch/powerpc/sysdev/mpic.c
>> +++ linux/arch/powerpc/sysdev/mpic.c
>> @@ -767,6 +767,7 @@ static int mpic_set_irq_type(unsigned in
>>  static struct irq_chip mpic_irq_chip = {
>>      .mask        = mpic_mask_irq,
>>      .unmask        = mpic_unmask_irq,
>> +    .ack        = mpic_end_irq,
>>      .eoi        = mpic_end_irq,
>>      .set_type    = mpic_set_irq_type,
>>  };

>    These changes have been refused in favor of "fasetoi" flow fix.

    Ugh, seeing them 2.6.20-rt8 still -- *please* remove, they're now useless 
and quite ugly...

>> Index: linux/kernel/latency_trace.c
>> ===================================================================
>> --- linux.orig/kernel/latency_trace.c
>> +++ linux/kernel/latency_trace.c
>> @@ -1774,8 +1774,8 @@ check_critical_timing(int cpu, struct cp
>>  #ifndef CONFIG_CRITICAL_LATENCY_HIST
>>      if (!preempt_thresh && preempt_max_latency > delta) {
>>          printk("bug: updating %016Lx > %016Lx?\n",
>> -            preempt_max_latency, delta);
>> -        printk("  [%016Lx %016Lx %016Lx]\n", T0, T1, T2);
>> +            (u64)preempt_max_latency, (u64)delta);
>> +        printk("  [%016Lx %016Lx %016Lx]\n", (u64)T0, (u64)T1, (u64)T2);
>>      }
>>  #endif

>    IIRC, this is a fragment of my another refused patch (maybe the first 
> take on it?)... Should be outdated now.

    Ugh, I'm seeing this one in 2.6.20-rt8 still... *Please* remove it -- it's 
*useless* with the current -rt code.

WBR, Sergei

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2007-03-07 14:55 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-05 17:11 v2.6.19-rt6, yum/rpm Ingo Molnar
2006-12-07 11:33 ` K.R. Foley
2006-12-07 12:13   ` Ingo Molnar
2006-12-07 15:54     ` K.R. Foley
2006-12-07 16:57       ` Ingo Molnar
2006-12-07 19:40         ` K.R. Foley
2006-12-07 20:04           ` Ingo Molnar
2006-12-07 20:45 ` Fernando Lopez-Lezcano
2006-12-07 20:58   ` Ingo Molnar
2006-12-07 21:07     ` Fernando Lopez-Lezcano
2006-12-07 21:42       ` Fernando Lopez-Lezcano
2006-12-07 21:20     ` Arjan van de Ven
2006-12-07 21:44       ` Ingo Molnar
2006-12-08 19:40 ` Ethernet transmit timeouts, was: " Dirk Behme
2006-12-08 20:15   ` Thomas Gleixner
2006-12-09  7:53     ` Ethernet transmit timeouts Dirk Behme
2006-12-10  8:27       ` Ingo Molnar
2006-12-09  4:26   ` Ethernet transmit timeouts, was: v2.6.19-rt6, yum/rpm Bruce Ashfield
2006-12-15 16:18 ` Sergei Shtylyov
2006-12-15 16:19   ` Ingo Molnar
2007-02-01 15:52     ` Sergei Shtylyov
2007-02-01 17:38       ` Ingo Molnar
2007-02-01 17:49         ` Ingo Molnar
2007-02-01 18:01           ` Sergei Shtylyov
2007-03-07 14:55             ` Sergei Shtylyov
2007-03-07 14:55               ` Sergei Shtylyov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.