* 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ messages in thread
end of thread, other threads:[~2007-03-07 14:55 UTC | newest] Thread overview: 25+ 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).