Re: [PATCH [RT] 00/14] RFC - adaptive real-time locks
hm. Why is the ticket spinlock patch included in this patchset? It just skews your performance results unnecessarily. Ticket spinlocks are independent conceptually, they are already upstream in 2.6.25-rc2 and -rt will have them automatically once we rebase to .25. and if we take the ticket spinlock patch out of your series, the the size of the patchset shrinks in half and touches only 200-300 lines of code ;-) Considering the total size of the -rt patchset: 652 files changed, 23830 insertions(+), 4636 deletions(-) we can regard it a routine optimization ;-) regarding the concept: adaptive mutexes have been talked about in the past, but their advantage is not at all clear, that's why we havent done them. It's definitely not an unambigiously win-win concept. So lets get some real marketing-free benchmarking done, and we are not just interested in the workloads where a bit of polling on contended locks helps, but we are also interested in workloads where the polling hurts ... And lets please do the comparisons without the ticket spinlock patch ... Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
* Frank Ch. Eigler [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
[...] Firstly, why on earth does a full format string have to be
passed in for something as simple as a CPU id? This way we basically
codify it forever that tracing _has_ to be expensive when
enabled. [...]
FWIW, I'm not keen about the format strings either, but they don't
constitute a performance hit beyond an additional parameter. It does
not need to actually get parsed at run time.
only an additional parameter. The whole _point_ behind these markers
is for them to have minimal effect!
[...]
Secondly, the inlined overhead of trace_mark() is still WAY too large:
if (unlikely(__mark_##name.state)) {\
[...]
} \
Note that this is for the unoptimized case. The immediate-value code
is better. I have still yet to see some good measurements of how much
the overheads of the various variants are, however. It's only fair to
gather these numbers and continue the debate with them in hand.
this is a general policy matter. It is _so much easier_ to add markers
if they _can_ have near-zero overhead (as in 1-2 instructions).
Otherwise we'll keep arguing about it, especially if any is added to
performance-critical codepath. (where we are counting instructions)
Whatever became of the obvious suggestion that i outlined years ago,
to have a _single_ trace call instruction and to _patch out_ the
damn marker calls by default? [...] only leaving a ~5-byte NOP
sequence behind them (and some minimal disturbance to the variables
the tracepoint accesses). [...]
This has been answered several times before. It's because the marker
parameters have to be (conditionally) evaluated and pushed onto a call
frame. It's not just a call that would need being nop'd, but a whole
function call setup/teardown sequence, which itself can be interleaved
with adjacent code.
you are still missing my point. Firstly, the kernel is regparm built so
there's no call frame to be pushed to in most cases - we pass most
parameters in registers. (hence my stressing of minimizing the number of
parameters to an absolute minimum)
Secondly, the side-effects of a function call is what i referred to via:
[...] (and some minimal disturbance to the variables the tracepoint
accesses). [...]
really, a tracepoint obviously accesses data that is readily accessible
in that spot. Worst-case we'll have some additional register constraints
that make the code a bit less optimal.
Yes, if a trace point references data that is _not_ readily available,
then of course the preparation for the function call might not be cheap.
But that can be optimized by placing the tracepoints intelligently.
what cannot be optimized away at all are the conditional instructions
introduced by the probe points, extra parameters and the space overhead
of the function call itself.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
* Frank Ch. Eigler [EMAIL PROTECTED] wrote: [...] this is a general policy matter. It is _so much easier_ to add markers if they _can_ have near-zero overhead (as in 1-2 instructions). Otherwise we'll keep arguing about it, especially if any is added to performance-critical codepath. (where we are counting instructions) The effect of the immediate-values patch, combined with gcc CFLAGS+=-freorder-blocks, *is* to keep the overhead at 1-2 dcache-impact-free instructions. The register saves, parameter evaluation, the function call, can all be moved out of line. well, -freorder-blocks seems to be default-enabled at -O2 on gcc 4.2, so we should already be getting that, right? There's one thing that would make out-of-line tracepoints have a lot less objectionable to me: right now the 'out of line' area is put to the end of functions. That splinters the kernel image with inactive, rarely taken areas of code - blowing up its icache footprint considerably. For example sched.o has ~100 functions, with the average function size being 200 bytes. At 64 bytes L1 cacheline size that's a 10-20% icache waste already. It's true that keeping the off-site code within the function keeps total codesize slightly smaller, because the offsets (and hence the conditional jumps) are thus 8 bit - but that's below 1% and the cache-blow-up aspect is more severe in practice at 10-20%. So it would be nice if we could collect all this offline code and stuff it away into another portion of the kernel image. (or, into another portion of the object file - which would still be good enough in practice) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
* Frank Ch. Eigler [EMAIL PROTECTED] wrote: Hi - On Wed, Jan 02, 2008 at 06:01:57PM +0100, Ingo Molnar wrote: [...] well, -freorder-blocks seems to be default-enabled at -O2 on gcc 4.2, so we should already be getting that, right? Right. [...] So it would be nice if we could collect all this offline code and stuff it away into another portion of the kernel image. (or, into another portion of the object file - which would still be good enough in practice) That would be the -freorder-blocks-and-partition flag, as proposed by Arjan two Februarys ago. I don't see any traces of Andi's overriding -fno-reorder-blocks in the current linus tree, so maybe it's time to resurrect this one: http://readlist.com/lists/vger.kernel.org/linux-kernel/39/196123.html hm, that gives: Forbidden You don't have permission to access /lists/vger.kernel.org/linux-kernel/39/196123.html on this server. but yeah, i had the impression that gcc couldnt yet do this. Not a showstopper, but it would be nice to initiate the gcc side of things ... Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sched: dynamically update the root-domain span/online maps
* Gregory Haskins [EMAIL PROTECTED] wrote: Hi Steven, I posted a suspend-to-ram fix to sched-devel earlier today: http://lkml.org/lkml/2007/12/17/445 This fix should also be applied to -rt as I introduced the same regression there. Here is a version of the fix for 23-rt13. I can submit a version for 24-rc5-rt1 at your request. well since i reverted the original patch, there's no regression. The question is, do we know whether this new patch works fine wrt. s2ram? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] RCU: Preemptible-RCU
* Gautham R Shenoy [EMAIL PROTECTED] wrote: Hello everyone, This patchset is an updated version of the preemptible RCU patchset that Paul McKenney had posted it in September earlier this year that can be found here -- http://lkml.org/lkml/2007/9/10/213 This patchset incorporates the review comments from Oleg Nesterov and Steven Rostedt. The testing report of the patchset is as follows: Patch-stack: 2.6.23-rc3 + cpu-hotplug patches from http://lkml.org/lkml/2007/11/15/239 + Preempt-RCU patches. Test: RCU-Torture running parallelly with CPU-Hotplug operations. Duration: 24 hours. Architectures:x86,x86_64, ppc64. Currently it is based against the latest linux-2.6-sched-devel.git Awaiting your feedback! thanks Gautham, the patchset from you and Paul looks good to me and i've applied it to sched-devel.git to get it tested and reviewed some more. from the Nitpicking Police, there are a couple of minor style problems/warnings with the code, you can see it via: scripts/checkpatch.pl --file kernel/rcu*.c nothing serious - RCU is still one of the cleanest subsystems in the kernel: errors lines of code errors/KLOC kernel/rcuclassic.c0 575 0 kernel/rcupdate.c 1 138 7.2 kernel/rcupreempt.c0 953 0 kernel/rcupreempt_trace.c 0 330 0 kernel/rcutorture.c8 995 8.0 the eventual goal would be to match: scripts/checkpatch.pl --file kernel/sched*.[ch] output ;-) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] RCU: Preemptible-RCU
* Steven Rostedt [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007, Gautham R Shenoy wrote: Currently it is based against the latest linux-2.6-sched-devel.git Awaiting your feedback! Hi Gautham, Thanks for posting this. I believe this is the same version of preempt RCU as we have in the RT patch. It seems to be very stable. I ran the RT patch version of the RCU Preempt (just the Preempt RCU patches without RT on latest git) on a 64way box and the results seems just as good (if not slightly better) than classic RCU! I'll rerun this patch series on that box and post the results. From what I'm seening with this, is that it is ready for mainline. These patches should probably go into -mm and be ready for 2.6.25. If Andrew wants to wait for my results, I'll run them tonight. Thanks Gautham, Paul and Dipankar for all this great work! Steve, if you went with a fine comb over the code and have done a thorough review, could you send me your Reviewed-by line for this patchset? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] Preempt-RCU: Update RCU Documentation.
* Gautham R Shenoy [EMAIL PROTECTED] wrote: Preempt-RCU: Update RCU Documentation. From: Paul E. McKenney [EMAIL PROTECTED] This patch updates the RCU documentation to reflect preemptible RCU as well as recent publications. Signed-off-by: Paul E. McKenney [EMAIL PROTECTED] Gautham, this patch is missing your SoB line - could you please send it? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH Latency Tracer] don't panic on failed bootmem alloc
* Steven Rostedt [EMAIL PROTECTED] wrote: Ingo, This patch prevents a panic on a failed bootmem alloc in the initialization of the tracer buffers. thanks, good catch! Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RT balance v7
* Gregory Haskins [EMAIL PROTECTED] wrote: Ingo, This series applies on GIT commit 2254c2e0184c603f92fc9b81016ff4bb53da622d (2.6.24-rc4 (ish) git HEAD) please post patches against sched-devel.git - it has part of your previous patches included already, plus some cleanups i did to them, so this series of yours wont apply. sched-devel.git is at: git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals
* Daniel Walker [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote: fixing the top 20: There are about 25 DECLARE_MUTEX() semaphores remaining .. One is the BKL which I would guess can't be converted. The others I've looked at appear to be trivial find/replace changes to get them to use the mutex type.. Any reason those haven't been converted over? i guess talking about it instead of posting patches is a factor ;-) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals
* Daniel Walker [EMAIL PROTECTED] wrote: Actually, IMO, compat_semaphores behave like semaphores should behave, and thus the same as they behave on a non-RT kernel, and at the locations where the semaphores are now misused as mutexes on RT, we should replace them by differently-named-mutex-type-semaphores, or better: real-RT-mutexes.. The vast majority of semaphore are actually binary semaphores in the Linux kernel .. So it's easier to mass convert semaphores to mutexes, then address the ones that don't conform.. Usually they are converted to the complete API in mainline.. right now there are 3992 mutex_lock() critical sections in the kernel and only 351 down() based critical sections are left. fixing the top 20: 4 vuart_bus_priv.probe_mutex 5 connections_lock 5 irq_ptr-setting_up_sema 5 kbd-sem 5 pnp_res_mutex 5 port-port_lock 5 tq_init_sem 6 adb_handler_sem 6 dev-parent-sem 6 driver_lock 6 ha-vport_sem 7 big_buffer_sem 8 dir_f-sem 9 c-alloc_sem 11 dev-sem 11 usbvision-lock 12 c-erase_free_sem 15 u132-scheduler_lock 16 zfcp_data.config_sema 17 f-sem would remove 164 of them, so it would convert half of the remaining semaphore use in the kernel. So the job is almost finished - would anyone like to go for the final grand feat: complete removal of semaphores from the kernel? :-) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals
* Daniel Walker [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: Actually, IMO, compat_semaphores behave like semaphores should behave, and thus the same as they behave on a non-RT kernel, and at the locations where the semaphores are now misused as mutexes on RT, we should replace them by differently-named-mutex-type-semaphores, or better: real-RT-mutexes.. The vast majority of semaphore are actually binary semaphores in the Linux kernel .. So it's easier to mass convert semaphores to mutexes, then address the ones that don't conform.. Usually they are converted to the complete API in mainline.. right now there are 3992 mutex_lock() critical sections in the kernel and only 351 down() based critical sections are left. fixing the top 20: 4 vuart_bus_priv.probe_mutex 5 connections_lock 5 irq_ptr-setting_up_sema 5 kbd-sem 5 pnp_res_mutex 5 port-port_lock 5 tq_init_sem 6 adb_handler_sem 6 dev-parent-sem 6 driver_lock 6 ha-vport_sem 7 big_buffer_sem 8 dir_f-sem 9 c-alloc_sem 11 dev-sem 11 usbvision-lock 12 c-erase_free_sem 15 u132-scheduler_lock 16 zfcp_data.config_sema 17 f-sem would remove 164 of them, so it would convert half of the remaining semaphore use in the kernel. So the job is almost finished - would anyone like to go for the final grand feat: complete removal of semaphores from the kernel? :-) Sure, you want to split the list? split the list with you? Feel free to take any of those :-) dev-sem is nontrivial and probably not possible right now - and some of the others might be problematic too. But there might be fixable ones in the list. This shouldnt become like the BKL conversion - never truly finished. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2-rt1
* Steven Rostedt [EMAIL PROTECTED] wrote: Ingo, Do we still need to have the realtime-lsm.patch? It has been considered obsolete for over a year now. Can we finally remove it. yeah, we can drop it. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
* Nick Piggin [EMAIL PROTECTED] wrote: [10138.175796] [c0105de3] show_trace+0x12/0x14 [10138.180291] [c0105dfb] dump_stack+0x16/0x18 [10138.184769] [c011609f] native_smp_call_function_mask+0x138/0x13d [10138.191117] [c0117606] smp_call_function+0x1e/0x24 [10138.196210] [c012f85c] on_each_cpu+0x25/0x50 [10138.200807] [c0115c74] flush_tlb_all+0x1e/0x20 [10138.205553] [c016caaf] kmap_high+0x1b6/0x417 [10138.210118] [c011ec88] kmap+0x4d/0x4f [10138.214102] [c026a9d8] ntfs_end_buffer_async_read+0x228/0x2f9 [10138.220163] [c01a0e9e] end_bio_bh_io_sync+0x26/0x3f [10138.225352] [c01a2b09] bio_endio+0x42/0x6d [10138.229769] [c02c2a08] __end_that_request_first+0x115/0x4ac [10138.235682] [c02c2da7] end_that_request_chunk+0x8/0xa [10138.241052] [c0365943] ide_end_request+0x55/0x10a [10138.246058] [c036dae3] ide_dma_intr+0x6f/0xac [10138.250727] [c0366d83] ide_intr+0x93/0x1e0 [10138.255125] [c015afb4] handle_IRQ_event+0x5c/0xc9 Looks like ntfs is kmap()ing from interrupt context. Should be using kmap_atomic instead, I think. it's not atomic interrupt context but irq thread context - and -rt remaps kmap_atomic() to kmap() internally. the problem seems to be what Mike's patch works around: fiddling with irq flags in the ntfs code. That fiddling seems quite unnecessary at first sight. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/7] New RT Task Balancing -v2
* Steven Rostedt [EMAIL PROTECTED] wrote: Changes since V1: Updated to git tree 55b70a0300b873c0ec7ea6e33752af56f41250ce Various clean ups suggested by Gregory Haskins, Dmitry Adamushko, and Peter Zijlstra. ok, i like this new approach - nice work! I'd suggest we test it in -rt for some time and then merge it into v2.6.25? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RT] - rebalance_domains incorrect parameter
* Sven-Thorsten Dietrich [EMAIL PROTECTED] wrote: Same issue has been fixed in mainline by: diff-tree de0cf899bbf06b6f64a5dce9c59d74c41b6b4232 (from 5d2b3d3695a841231b65b55 Author: Oleg Nesterov [EMAIL PROTECTED] Date: Sun Aug 12 18:08:19 2007 +0200 signed-off-by: Sven-Thorsten Dietrich [EMAIL PROTECTED] ah, you mean we should pick up an upstream fix for -rt? We'll do that and we'll pick up much more: all the other ~100 CFS commits that happened meanwhile. (Btw., there's no need to sign off on patch forwarding or backport requests - the signoff made me first believe this is some new patch.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -rt 9/9] seqlocks: use PICK_FUNCTION
* Daniel Walker [EMAIL PROTECTED] wrote: Replace the old PICK_OP style macros with PICK_FUNCTION. Although, seqlocks has some alien code, which I also replaced as can be seen from the line count below. ok, i very much like the cleanup effects here, could you resend your latest version of this (with Peter's suggested cleanup) against -rc2-rt2 so that i can apply it? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CFS: Mark print_cfs_stats static
* Josh Triplett [EMAIL PROTECTED] wrote: sched_fair.c defines print_cfs_stats, and sched_debug.c uses it, but sched.c includes both sched_fair.c and sched_debug.c, so all the references to print_cfs_stats occur in the same compilation unit. Thus, mark print_cfs_stats static. Eliminates a sparse warning: warning: symbol 'print_cfs_stats' was not declared. Should it be static? thanks, applied. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RT 2.6.22.1-rt4 minor fixes for StGit import
* Clark Williams [EMAIL PROTECTED] wrote: Attached is a minor patch against the broken out -rt4 which fixes a couple of things that break an StGit import of the patch series. thanks, applied this to the .23-rc2 queue. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RT: Add priority-queuing and priority-inheritance to workqueue infrastructure
* Oleg Nesterov [EMAIL PROTECTED] wrote: On 08/01, Gregory Haskins wrote: On Thu, 2007-08-02 at 02:22 +0400, Oleg Nesterov wrote: No, You sure are a confident one ;) Yeah, this is a rare case when I am very sure I am right ;) I strongly believe you guys take a _completely_ wrong approach. queue_work() should _not_ take the priority of the caller into account, this is bogus. Oleg, i'd like to make it sure that the role of Gregory Haskins is clear here: he submitted some new infrastructure into the -rt tree, and i reviewed that but found it quite complex and duplicative and suggested him to think about enhancing workqueues with priority properties - which might or might not make sense. It is not the intention of the -rt project to pester any upstream maintainer with -rt issues if that upstream maintainer is not interested in it ... so please just forget about all this if you are not interested in it, we'll sort it out within -rt. Thanks, Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG RT] WARNING: at kernel/sched.c:5071 2.6.23-rc1-rt7
* Steven Rostedt [EMAIL PROTECTED] wrote: Ingo, The below ifndef, shouldn't that be ifndef CONFIG_PREEMPT_SOFTIRQS ? I hit that warning while I was running !PREEMPT_RT but with both hard and softiqs as threads. yeah, indeed - fixed. P.S. I really found out that the system becomes VERY non-responsive when you run with both hard and softirqs as threads, but with PREEMPT_NONE ;-) hm. That's not supposed to happen. Could there be some wakeup or softirq processing problem? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG RT] - rcupreempt.c:133 on 2.6.23-rc1-rt7
* Steven Rostedt [EMAIL PROTECTED] wrote: I don't have time to look further now, and it's something that isn't easily reproducible (Well, it happened once out of two boots). If you need me to look further, or need a config or dmesg (I have both), then just give me a holler. Silly me. FYI, I was running with !PREEMPT_RT, but with Hard and Softirqs as threads. Must have copied the wrong config over :-/ it's still not supposed to happen ... rcu read lock nesting that deep? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG RT] - rcupreempt.c:133 on 2.6.23-rc1-rt7
* Steven Rostedt [EMAIL PROTECTED] wrote: The code on line 133 is: WARN_ON_ONCE(current-rcu_read_lock_nesting NR_CPUS); I have NR_CPUS set to 2 since the box I'm running this on only has 2 cpus and I see no reason to waste more data structures. Is rcu read lock nesting deeper than 2? ah, silly me - that should indeed be something fixed like 128. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible error in 2.6.23-rc2-rt1 series
* Peter Williams [EMAIL PROTECTED] wrote: I've just been reviewing these patches and have spotted a possible error in the file arch/ia64/kernel/time.c in that the scope of the #ifdef on CONFIG_TIME_INTERPOLATION seems to have grown quite a lot since 2.2.23-rc1-rt7. It used to chop out one if statement and now it chops out half the file. i have not got much feedback about the ia64 -rt code. Does it even compile? The above thing could be a merge artifact - TIME_INTERPOLATION has been removed from upstream recently. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RT] Move RECURSION_LIMIT define up for more global use (take 2)
* Steven Rostedt [EMAIL PROTECTED] wrote: OK, I sent this out once before but it must have slipped under the radar. http://lkml.org/lkml/2007/6/28/325 thanks - applied. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] RT: Preemptible Function-Call-IPI Support
* Gregory Haskins [EMAIL PROTECTED] wrote: This code allows FUNCTION_CALL IPIs to become preemptible by executing them in kthread context instead of interrupt context. They are referred to as Virtual Function Call IPIs (VFCIPI) because we no longer rely on the actual FCIPI facility. Instead we schedule a thread to run. This essentially replaces the synchronous FCIPI with an async RESCHEDULE IPI. why do we need this? It's quite complex and brings little extra AFAICS. See the schedule_on_each_cpu-enhance.patch from Peter Ziljstra that lets a function to be executed on all CPUs. That should be extended (trivially) to execute a function on another CPU. That's all we need. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] RT: Preemptible Function-Call-IPI Support
[ mail re-sent with lkml Cc:-ed. _Please_ Cc: all patches to lkml too! Unless you want -rt to suffer the fate of -ck, keep upstream involved all the time. The recent /proc/interrupts-all discussion with upstream folks showed the clear benefits of that approach. ] * Gregory Haskins [EMAIL PROTECTED] wrote: This code allows FUNCTION_CALL IPIs to become preemptible by executing them in kthread context instead of interrupt context. They are referred to as Virtual Function Call IPIs (VFCIPI) because we no longer rely on the actual FCIPI facility. Instead we schedule a thread to run. This essentially replaces the synchronous FCIPI with an async RESCHEDULE IPI. why do we need this? It's quite complex and brings little extra AFAICS. See the schedule_on_each_cpu-enhance.patch from Peter Ziljstra that lets a function to be executed on all CPUs. That should be extended (trivially) to execute a function on another CPU. That's all we need. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] RT: Preemptible Function-Call-IPI Support
* Ingo Molnar [EMAIL PROTECTED] wrote: * Gregory Haskins [EMAIL PROTECTED] wrote: This code allows FUNCTION_CALL IPIs to become preemptible by executing them in kthread context instead of interrupt context. They are referred to as Virtual Function Call IPIs (VFCIPI) because we no longer rely on the actual FCIPI facility. Instead we schedule a thread to run. This essentially replaces the synchronous FCIPI with an async RESCHEDULE IPI. why do we need this? It's quite complex and brings little extra AFAICS. See the schedule_on_each_cpu-enhance.patch from Peter Ziljstra that lets a function to be executed on all CPUs. That should be extended (trivially) to execute a function on another CPU. That's all we need. as far as the prioritization of function calls goes, _that_ makes sense, but it should not be a separate API but should be done to our normal workqueue APIs. That not only extends the effects of priorities to all current workqueue using kernel subsystems, but also keeps the API more unified. We really dont want to have too many -rt specific APIs. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] RT: Preemptible Function-Call-IPI Support
* Gregory Haskins [EMAIL PROTECTED] wrote: as far as the prioritization of function calls goes, _that_ makes sense, but it should not be a separate API but should be done to our normal workqueue APIs. That not only extends the effects of priorities to all current workqueue using kernel subsystems, but also keeps the API more unified. We really dont want to have too many -rt specific APIs. I agree with you that having some kind of priority and cpu-binding specifiers for work-queues would be very cool indeed. However, note that I didn't actually introduce a new API(*), per se. I simply worked under the existing smp_call_function[_single]() API. Using the smp_call_functions is critical design factor, however. I really want clients of this function to seamlessly transition to threaded mode. [...] well, 'clients' of this function are low-level architectural bits like the scheduler and the TLB flush code which stays atomic nevertheless. smp_call_function() is _not_ a true generic framework and to 'thread' it is wrong and misplaced and leads to the kind of over-complification that your patch shows. Please work based on the workqueue APIs. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Question] Hooks for scheduler tracing (CFS)
* Ankita Garg [EMAIL PROTECTED] wrote: I'd suggest to not put a probe into a preempt-off section - put it to the beginning and to the end of schedule() to capture context-switches. _stp_print_flush() is in the systemtap-generated module, right? Maybe the problem is resolved by changing that spinlock to use raw_spinlock_t / DEFINE_RAW_SPIN_LOCK. Yes, _stp_print_flush is in the systemtap-generated kprobe module. Placing the probe at the beginning of schedule() also has the same effect. Will try by changing the spinlock to raw_spinlock_t... could you send us that module source ST generates? Perhaps there are preempt_disable() (or local_irq_disable()) calls in it too. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc1-rt2
* Daniel Walker [EMAIL PROTECTED] wrote: I don't know about the slowness, but I think the BUG warnings are from CONFIG_DEBUG_SHIRQ . Try this patch, Signed-off-by: Daniel Walker [EMAIL PROTECTED] - local_irq_save(flags); + local_irq_save_nort(flags); handler(irq, dev_id); - local_irq_restore(flags); + local_irq_restore_nort(flags); yep - makes sense - applied. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Question] Hooks for scheduler tracing (CFS)
* Ankita Garg [EMAIL PROTECTED] wrote: The probe point did get triggered, and soon after that I had the following in dmesg, leading to system hang... BUG: scheduling while atomic: softirq-rcu/3/0x0004/52, CPU#3 Call Trace: #DB [81033555] __schedule_bug+0x4b/0x4f [8128b414] __sched_text_start+0xcc/0xaaa [8100b574] dump_trace+0x248/0x25d [81068334] print_traces+0x9/0xb [8100b5e5] show_trace+0x5c/0x64 [8128c1c2] schedule+0xe4/0x104 [8128d10c] rt_spin_lock_slowlock+0xfc/0x19e [8128d9de] __rt_spin_lock+0x1f/0x21 [8128d9e9] rt_spin_lock+0x9/0xb [88387dcc] :stap_c1a10b1292b5f87a563f56d89ddfc765_606:_stp_print_flush+0x5f/0xdf [88389e41] :stap_c1a10b1292b5f87a563f56d89ddfc765_606:probe_1493+0x1f6/0x257 [8838bdc3] I'd suggest to not put a probe into a preempt-off section - put it to the beginning and to the end of schedule() to capture context-switches. _stp_print_flush() is in the systemtap-generated module, right? Maybe the problem is resolved by changing that spinlock to use raw_spinlock_t / DEFINE_RAW_SPIN_LOCK. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Question] Hooks for scheduler tracing (CFS)
* Ankita Garg [EMAIL PROTECTED] wrote:
local_irq_save(flags);
buf = _stp_chan-buf[smp_processor_id()];
if (unlikely(buf-offset + length _stp_chan-subbuf_size))
length = relay_switch_subbuf(buf, length);
memcpy(buf-data + buf-offset, data, length);
buf-offset += length;
local_irq_restore(flags);
oh, what a fine piece of s^H^H :-/ Who in their right mind calls this
from _tracing_ code:
smp_mb();
if (waitqueue_active(buf-read_wait))
/*
* Calling wake_up_interruptible() from here
* will deadlock if we happen to be logging
* from the scheduler (trying to re-grab
* rq-lock), so defer it.
*/
__mod_timer(buf-timer, jiffies + 1);
and the comment is utter rubbish: __mod_timer() can lock up just as
much. Just use an adaptive-polling method to drive the draining of the
relay buffer, instead of mucking with timers from within the tracing
code. Whoever implemented this has absolutely zero clue i have to say
...
the smp_mb() is rubbish too.
could you try the patch below, does it fix the problem?
Ingo
-
Subject: relay: fix timer madness
From: Ingo Molnar [EMAIL PROTECTED]
remove timer calls (!!!) from deep within the tracing infrastructure.
This was totally bogus code that can cause lockups and worse.
Poll the buffer every 2 jiffies for now.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
kernel/relay.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
Index: linux-rt-rebase.q/kernel/relay.c
===
--- linux-rt-rebase.q.orig/kernel/relay.c
+++ linux-rt-rebase.q/kernel/relay.c
@@ -319,6 +319,10 @@ static void wakeup_readers(unsigned long
{
struct rchan_buf *buf = (struct rchan_buf *)data;
wake_up_interruptible(buf-read_wait);
+ /*
+* Stupid polling for now:
+*/
+ mod_timer(buf-timer, jiffies + 1);
}
/**
@@ -336,6 +340,7 @@ static void __relay_reset(struct rchan_b
init_waitqueue_head(buf-read_wait);
kref_init(buf-kref);
setup_timer(buf-timer, wakeup_readers, (unsigned long)buf);
+ mod_timer(buf-timer, jiffies + 1);
} else
del_timer_sync(buf-timer);
@@ -604,15 +609,6 @@ size_t relay_switch_subbuf(struct rchan_
buf-subbufs_produced++;
buf-dentry-d_inode-i_size += buf-chan-subbuf_size -
buf-padding[old_subbuf];
- smp_mb();
- if (waitqueue_active(buf-read_wait))
- /*
-* Calling wake_up_interruptible() from here
-* will deadlock if we happen to be logging
-* from the scheduler (trying to re-grab
-* rq-lock), so defer it.
-*/
- __mod_timer(buf-timer, jiffies + 1);
}
old = buf-data;
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RT] Fix RT balancing tasks pulling
* Sébastien Dugué [EMAIL PROTECTED] wrote: Hi Ingo, Thomas, this one-liner fixes a bug in balance_rt_tasks() which sometimes manifests by having a lower prio task being scheduled while a higher prio task is sitting waiting on another runqueue. This is pretty hard to reproduce on low cpu count machines, for example, I had to have sched_football run in a loop for ~38h before it failed on a dual HT Xeon box. really nice catch! Applied. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.22.1-rt5
* Gene Heskett [EMAIL PROTECTED] wrote: Changing the root (hd0,0) to (sd0,0) failed. Grub can't parse the (sd0,0). that (hd0,0) is a BIOS identification and needs no changing. could you send me your grub.conf? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Display -rt related stats in /proc/schedstat
* Ankita Garg [EMAIL PROTECTED] wrote: Hi, This patch adds support to display captured -rt stats under /proc/schedstat. hm, could you add it to /proc/sched_debug instead? That's where all the runqueue values are showing up normally. I'm also a bit wary about introducing a new schedstats version for -rt. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Display -rt related stats in /proc/schedstat
* Ankita Garg [EMAIL PROTECTED] wrote: This patch adds support to display captured -rt stats under /proc/schedstat. hm, could you add it to /proc/sched_debug instead? That's where all the runqueue values are showing up normally. I'm also a bit wary about introducing a new schedstats version for -rt. So, I have merged my previous patch (to display rt_nr_running info in sched_debug.c) with this one. thanks, applied. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pin-pointing the root of unusual application latencies
* John Sigler [EMAIL PROTECTED] wrote: With a pair of the following in the middle: softirq--4 0 670us : call_rcu (rt_run_flush) softirq--4 0D..1 670us : __rcu_advance_callbacks (call_rcu) Any idea what went wrong in the above function trace? Why is the kernel spinning in circles that way? does your test-app have higher priority than softirq--4 ? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pin-pointing the root of unusual application latencies
* John Sigler [EMAIL PROTECTED] wrote: does your test-app have higher priority than softirq--4 ? PID 4 is [softirq-timer/0] and has priority 50 in SCHED_FIFO. My process has priority 80 in SCHED_RR. It is waiting for IRQ10. My user-space app has higher priority than everything except PID 2 which is [posix_cpu_timer] well what priority does the IRQ 10 kernel thread have? It should be prio 80 too if it's in your critical path. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.22.1-rt7 does not build here
* Dragan Noveski [EMAIL PROTECTED] wrote: hi list, i am trying to compile the 2.6.22.1-rt7 here and i get this error while running 'make make modules': ok - i've released rt8 which should have this fixed. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.22.1-rt5
* Rui Nuno Capela [EMAIL PROTECTED] wrote: Maybe I was too quick, but `make all` on is failing here: does -rt6 work better? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.22.1-rt5
i've released the v2.6.23-rc1-rt0 kernel, which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ as the rt0 name suggests it, this is a devel release, the first one after a rebase to 2.6.23-rc1. There's lots of changes and a reduction of 50 patches (we are now at 320 patches) - so code from -rt is moving upstream at a steady pace. (latest bigger chunks that moved were CFS, lockstat, most of the -hrt queue, plus various fixes) more info about the -rt patchset can be found in the RT wiki: http://rt.wiki.kernel.org to build a 2.6.22.1-rt5 tree, the following patches should be applied: http://kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.23-rc1.tar.bz2 http://redhat.com/~mingo/realtime-preempt/patch-2.6.23-rc1-rt0 Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.22.1-rt5
* Gene Heskett [EMAIL PROTECTED] wrote: The above stanza still needs some tlc. I built a 2.6.22.1-rt6 (rt5 wouldn't build) using the same old config that a make oldconfig didn't fuss about, but the reboot never completed, see the attached, heavily smunched camera shot of the panic. Kinda looks like hda/sda confusion, with rt3 (this boot), its hda*, what is it now? fstab or kernel config error? yeah, as long as your filesystems are created with a proper label, all that you need to do is to change all 'hda' to 'sda' in the new kernel's /etc/grub.conf entry. (or enable the old IDE code in the .config, under CONFIG_IDE) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.22.1-rt5
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote: apparently you caught that 3 seconds window where the .23-rc1-rt1 release script moved old patches into the older/ directory :-) Yup, good timing... :-) Hard to do again... (BTW, will you keep 2.6.22.x patches going for a while?) yeah, that's the plan: to keep .22-rt updated until .23 is released. (Thomas agrees with that approach too) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.21.5-rt19 (sched_getaffinity?)
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote:
does lockdep pinpoint anything?
Lots of stuff, and at the end the lock report for the problem.
Hopefully some of this will help... I have attached the whole bootup
sequence as logged in /var/log/messages.
yeah, it pinpointed the bug. It seems to be an interaction between
RCU-preempt (Paul Cc:-ed) and sched_mc_power_savings_store():
detach_destroy_domains() uses synchronize_sched() which uses
getaffinity, which takes sched_hotcpu_mutex, and
arch_reinit_sched_domains does it too - see the lockdep report below.
I've added a quick workaround below as well, which should keep your box
from hanging.
Ingo
=
[ INFO: possible recursive locking detected ]
[ 2.6.22-0182.rt4.3.fc7.ccrmart #1
-
sched-powersave/3251 is trying to acquire lock:
(sched_hotcpu_mutex){--..}, at: [c0424a37] sched_getaffinity+0x14/0x94
but task is already holding lock:
(sched_hotcpu_mutex){--..}, at: [c04245a5] arch_reinit_sched_domains+0xe/0x33
other info that might help us debug this:
1 lock held by sched-powersave/3251:
#0: (sched_hotcpu_mutex){--..}, at: [c04245a5]
arch_reinit_sched_domains+0xe/0x33
stack backtrace:
[c040600c] show_trace_log_lvl+0x1a/0x2f
[c0406ae8] show_trace+0x12/0x14
[c0406b50] dump_stack+0x16/0x18
[c0446f46] __lock_acquire+0x172/0xb67
[c0447d03] lock_acquire+0x56/0x6f
[c061d414] _mutex_lock+0x2b/0x38
[c0424a37] sched_getaffinity+0x14/0x94
[c0460841] __synchronize_sched+0x11/0x5f
[c0423fa8] detach_destroy_domains+0x2c/0x30
[c04245af] arch_reinit_sched_domains+0x18/0x33
[c0424606] sched_power_savings_store+0x3c/0x49
[c0424634] sched_mc_power_savings_store+0xe/0x10
[c0561f11] sysdev_class_store+0x20/0x25
[c04bbc6c] sysfs_write_file+0xaf/0xd0
[c048183c] vfs_write+0xaf/0x163
[c0481e8a] sys_write+0x3d/0x61
[c040501a] syscall_call+0x7/0xb
===
thinkpad_acpi: ThinkPad ACPI Extras v0.14
-
Index: linux-rt.q/kernel/sched.c
===
--- linux-rt.q.orig/kernel/sched.c
+++ linux-rt.q/kernel/sched.c
@@ -6699,7 +6699,6 @@ static void detach_destroy_domains(const
for_each_cpu_mask(i, *cpu_map)
cpu_attach_domain(NULL, i);
- synchronize_sched();
arch_destroy_sched_domains(cpu_map);
}
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.21.5-rt19 (sched_getaffinity?)
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote: On Tue, 2007-07-17 at 21:32 +0200, Ingo Molnar wrote: * Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote: I do get flash 9 (I know, not the best example) and tomboy to hang as reported by one of my Planet CCRMA users - flash 9 tested working on stock fedora 7 kernel - and both seem to hang in the same system call: sched_getaffinity(3528, 32, unfinished ... Full output of strace attached for both cases. hm, that's weird. Is it completely unkillable at that time? Could you do a few things: enable CONFIG_PROVE_LOCKING (lockdep), and also try to get a full task state dump via: echo t /proc/sysrq-trigger Trace attached... the process stays in D state no matter what. hm, seems to be related to: Jul 17 12:51:18 localhost kernel: sched-powersa D [f0aaf930] 0005 6584 3420 3407 which blocks the cpu-hotplug mutex: Jul 17 12:51:18 localhost kernel: Call Trace: Jul 17 12:51:18 localhost kernel: [c0603f46] schedule+0xe0/0xfa Jul 17 12:51:18 localhost kernel: [c0604d0d] rt_mutex_slowlock+0x164/0x20b Jul 17 12:51:18 localhost kernel: [c0604a5c] rt_mutex_lock+0x3c/0x3f Jul 17 12:51:18 localhost kernel: [c0423bb4] sched_getaffinity+0x14/0x94 Jul 17 12:51:18 localhost kernel: [c045a647] __synchronize_sched+0xd/0x5a Jul 17 12:51:18 localhost kernel: [c0423732] arch_reinit_sched_domains+0x18/0x33 Jul 17 12:51:18 localhost kernel: [c0423789] sched_power_savings_store+0x3c/0x49 Jul 17 12:51:18 localhost kernel: [c0552cd4] sysdev_class_store+0x1e/0x22 Jul 17 12:51:18 localhost kernel: [c04b195b] sysfs_write_file+0xa3/0xc6 Jul 17 12:51:18 localhost kernel: [c047a64a] vfs_write+0xa8/0x154 Jul 17 12:51:18 localhost kernel: [c047ac65] sys_write+0x41/0x67 Jul 17 12:51:18 localhost kernel: [c0404f7c] syscall_call+0x7/0xb and firefox blocks on the same mutex too: Jul 17 12:51:18 localhost kernel: firefox-bin D [efc44670] 0012 6368 4388 1 Jul 17 12:51:18 localhost kernel: Call Trace: Jul 17 12:51:18 localhost kernel: [c0603f46] schedule+0xe0/0xfa Jul 17 12:51:18 localhost kernel: [c0604d0d] rt_mutex_slowlock+0x164/0x20b Jul 17 12:51:18 localhost kernel: [c0604a5c] rt_mutex_lock+0x3c/0x3f Jul 17 12:51:18 localhost kernel: [c0423bb4] sched_getaffinity+0x14/0x94 Jul 17 12:51:18 localhost kernel: [c0423c53] sys_sched_getaffinity+0x1f/0x41 Jul 17 12:51:18 localhost kernel: [c0404f7c] syscall_call+0x7/0xb Jul 17 12:51:18 localhost kernel: [b7f0f410] 0xb7f0f410 does lockdep pinpoint anything? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Question] Hooks for scheduler tracing (CFS)
* Remy Bohmer [EMAIL PROTECTED] wrote: Hello Arjan, Thanks for this suggestion. (please dont top-post, ever. See: www.zipworld.com.au/~akpm/linux/patches/stuff/top-posting.txt) But I looked at Systemtap before, and as I remember, it is very flexible, but it only traces function calls. (or am I missing something?) systemtap it should be able to trace variables as well. (as long as those variables are not eliminated by gcc) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Forward port of latest RT patch (2.6.21.5-rt20) to 2.6.22 available
* Gregory Haskins [EMAIL PROTECTED] wrote: On Thu, 2007-07-12 at 14:07 +0200, Ingo Molnar wrote: * Gregory Haskins [EMAIL PROTECTED] wrote: Hi Ingo, Thomas, and the greater linux-rt community, I just wanted to let you guys know that our team has a port of the 21.5-rt20 patch for the 2.6.22 kernel available. [...] great! We had the upstream -rt port to .22 in the works too, it was just held up by the hpet breakage - which Thomas managed to fix earlier today. I've released the 2.6.22.1-rt1 patch to the usual place: http://redhat.com/~mingo/realtime-preempt/ Thats awesome, Ingo! Thanks! Could you publish a broken out version as well? We found it extremely valuable to be able to bisect this beast while working on the 21-22 port. we are working on something in this area :) Stay tuned ... Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: poison_obj latency
* Manfred Gruber [EMAIL PROTECTED] wrote: hi ! I use a arm4vt ep93xx processor with 2.6.21.5-rt18. When i run cyclictest with -i 1 and -n -p 90 -b 1000 i see some strange latencies in poison_obj. disable SLAB_DEBUG. And look into your 'dmesg' output, the -rt kernel will warn about any other kernel config options as well that are known to cause large latencies: VFS: Mounted root (ext3 filesystem) readonly. * * * * REMINDER, the following debugging option is turned on in your .config: * * * *CONFIG_SLAB* * * * it may increase runtime overhead and latencies. * * * * Freeing unused kernel memory: 324k freed Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -rt] CONFIG_PARAVIRT and CONFIG_MCOUNT don't play well together
* Chris Wright [EMAIL PROTECTED] wrote: * Steven Rostedt ([EMAIL PROTECTED]) wrote: Chris, thanks a hell of a lot for looking into this!!! -rt doesn't do much with paravirt, but since both -rt and lguest are two things I love to play with, it was really bothering me that they were not getting along. It was bugging me too, now if only I had noticed the compiler warnings ;-) if only those compiler warnings werent drowning in 1000 other compiler warnings? :-/ Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -rt] CONFIG_PARAVIRT and CONFIG_MCOUNT don't play well together
* Chris Wright [EMAIL PROTECTED] wrote: thanks! I ran into this before and asked for the fastcalls to not be removed from upstream paravirt.c but to no avail it seems. It does no harm to anyone to keep the 'fastcall' declarations and definitions for places where _actual assembly code_ depends on the calling convention. Could someone please send this upstream-wards too? Yes, I agree, it's actually documenting the subtlety of the calling convention, not just noise in the source. The upstream patch is different, I'll sort one out. great! Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RT] Don't call mcount from vsyscall_fn's
* Steven Rostedt [EMAIL PROTECTED] wrote: This bit me in the butt. I couldn't understand why my init app was segfaulting, with a kernel address, but a user RIP and RSP. Well, the RIP I think was bogus, but the kernel address was always the start of mcount. Looking deeper, I printed out what was in the RSP (even though it was a user stack). It ended up showing me that the calling address was from the VDSO area. Looking even further, I found the offending culprit, which was vread_hpet. Looking at the assembly dump, I saw the vread_hpet was calling mcount, but I could not see it in the code. Nor could I see it in hpet.i (-E option of compiling). Well, I guess Ingo is a magician when it comes to compiler tricks, and has the mcount being called by every!! function, unless you add the notrace option. This patch adds the notrace to vsyscall_fn, so that we don't have user land apps calling mcount and crashing! doh - applied. Thanks! Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.21.4-rt11
* Paul E. McKenney [EMAIL PROTECTED] wrote: 2.6.21.4-rt12 boots on 4-CPU Opteron and passes several hours of rcutorture. However, if I simply do modprobe rcutorture, the kernel threads do not spread across the CPUs as I would expect them to, even given CFS. Instead, the readers all stack up on a single CPU, and I have to use the taskset command to spread them out manually. Is there some config parameter I am missing out on? hm, what affinity do they start out with? Could they all be pinned to CPU#0 by default? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.21.4-rt11
* Paul E. McKenney [EMAIL PROTECTED] wrote: hm, what affinity do they start out with? Could they all be pinned to CPU#0 by default? They start off with affinity masks of 0xf on a 4-CPU system. I would expect them to load-balance across the four CPUs, but they stay all on the same CPU until long after I lose patience (many minutes). ugh. Would be nice to figure out why this happens. I enabled rcutorture on a dual-core CPU and all the threads are spread evenly. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.21-rt3
* Daniel Walker [EMAIL PROTECTED] wrote: I copied the patch into the first email, I did look at it which is why you got an email. Your introducing the patch , it's for you to explain why it needs to be there.. considering that the comment says hack in it, I have to wonder what the non-hack version is .. you might not have realized it, but the problem i think was the attitude you showed in the very first sentence: Where did the arm ep93xx changes come from? It looks like patch below came in with them in 2.6.21-rt6 .. AFAICS Thomas just mirrored that snotty comment back to you, and yes, when you are on the receiving end it feels nasty, doesnt it? So please restart and rephrase that into a more polite form and you might get an answer (although i certainly do not talk for Thomas). Something like: Thomas, could you give me a bit more information about why the arm ep93xx changes were done in 2.6.21-rt6? I do not seem to understand the reason behind that change. I've attached the change below. Thanks! You are asking Thomas a favor after all... Be a bit more polite when asking others, and a completely new world might open up for you :-) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
v2.6.21-rt3
i'm pleased to announce the v2.6.21-rt3 kernel, which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ more info about the -rt patchset can be found in the RT wiki: http://rt.wiki.kernel.org This is a fixes-only release assembled by Thomas Gleixner. Many PPC fixes from Sergei Shtylyov, dynticks softirq fixes from Mikulas Patocka, a CONFIG_IRQSOFF_TIMING fix from Daniel Walker and x86_64 hrt fixes from Thomas Gleixner. to build a 2.6.21-rt3 tree, the following patches should be applied: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2 http://redhat.com/~mingo/realtime-preempt/patch-2.6.21-rt3 Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
v2.6.21-rt2
i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ more info about the -rt patchset can be found in the RT wiki: http://rt.wiki.kernel.org This is a fixes-mostly release and has been assembled by Thomas Gleixner. Thanks Thomas! Here are the various changes: - ppc fixes from Tsutomu OWA - new sh -rt port from Paul Mundt Co - fixes for various problems by Steven Rostedt and Clark Williams - x86/64 high-res timers and dynticks update (Thomas Gleixner) - various fixes from Sergie Shtylyov - latency fixes from John Stultz - misc fixes to build a 2.6.21-rt2 tree, the following patches should be applied: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2 http://redhat.com/~mingo/realtime-preempt/patch-2.6.21-rt2 Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.21-rt2
* Daniel Walker [EMAIL PROTECTED] wrote: On Wed, 2007-05-16 at 20:04 +0200, Ingo Molnar wrote: i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded from the usual place: 2.6.21-rt2 ? oops, right! :-) - fixes for various problems by Steven Rostedt and Clark Williams I think you missed the fix I submitted for one of Steve's changes. http://lkml.org/lkml/2007/5/3/368 hm - trace_hardirqs_on() should never be called with irqs on - lockdep could break for example. Could you try to fix the call site instead? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.21-rt2
* Daniel Walker [EMAIL PROTECTED] wrote: http://lkml.org/lkml/2007/5/3/368 hm - trace_hardirqs_on() should never be called with irqs on - lockdep could break for example. Could you try to fix the call site instead? If that's the case why check if they're enabled inside trace_hardirqs_on() ? If that check fails you still still get the warning in my original release .. yeah, indeed you are right - it checks the soft flag. But even then, the better fix is to check for hardirqs-off first and not to flip around the preempt count check in irqs_off_preempt_count() - i.e. something like the patch below. Does this solve the warning you've triggered with irqsoff-tracing enabled? Ingo Index: linux-rt.q/kernel/latency_trace.c === --- linux-rt.q.orig/kernel/latency_trace.c +++ linux-rt.q/kernel/latency_trace.c @@ -1963,7 +1963,7 @@ void notrace trace_hardirqs_on(void) local_save_flags(flags); - if (!irqs_off_preempt_count() irqs_disabled_flags(flags)) + if (irqs_disabled_flags(flags) !irqs_off_preempt_count()) __stop_critical_timing(CALLER_ADDR0, 0 /* CALLER_ADDR1 */); } @@ -1975,7 +1975,7 @@ void notrace trace_hardirqs_off(void) local_save_flags(flags); - if (!irqs_off_preempt_count() irqs_disabled_flags(flags)) + if (irqs_disabled_flags(flags) !irqs_off_preempt_count()) __start_critical_timing(CALLER_ADDR0, 0 /* CALLER_ADDR1 */, INTERRUPT_LATENCY); } @@ -1989,7 +1989,7 @@ void notrace trace_hardirqs_on_caller(un local_save_flags(flags); - if (!irqs_off_preempt_count() irqs_disabled_flags(flags)) + if (irqs_disabled_flags(flags) !irqs_off_preempt_count()) __stop_critical_timing(caller_addr, 0 /* CALLER_ADDR1 */); } @@ -1999,7 +1999,7 @@ void notrace trace_hardirqs_off_caller(u local_save_flags(flags); - if (!irqs_off_preempt_count() irqs_disabled_flags(flags)) + if (irqs_disabled_flags(flags) !irqs_off_preempt_count()) __start_critical_timing(caller_addr, 0 /* CALLER_ADDR1 */, INTERRUPT_LATENCY); } - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.21-rt2
* Daniel Walker [EMAIL PROTECTED] wrote: I don't know. irqs_off_preempt_count() could get used someplace else, where you would want to flip the preempt_count() check .. It seems sane to combine your patch with mine .. irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) preempt_count()) You can't call __get_cpu_var() without the a positive preempt_count(), so the check seems backwards regardless of the other factors .. yeah. The whole trace_preempt_enter_idle() thing looks a bit suspect. Why cannot those architectures simply disable/enable preemption and get the same effect? It's not like we ever want to allow the preemption of the idle task. and once that is solved, irqs_off_preempt_count() can again include the hardirq and preempt count check only and doesnt have to check the idle_cpu flag. This would make the whole thing simpler and would avoid silly bugs like this. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
v2.6.21-rt1
i have released the v2.6.20-rt1 kernel, which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ more info about the -rt patchset can be found in the RT wiki: http://rt.wiki.kernel.org This is a fixes-only release. to build a 2.6.21-rt1 tree, the following patches should be applied: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2 http://redhat.com/~mingo/realtime-preempt/patch-2.6.21-rt1 Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remove repeated #define
* Guennadi Liakhovetski [EMAIL PROTECTED] wrote: Remove repeated #define Signed-off-by: G. Liakhovetski [EMAIL PROTECTED] thanks, applied. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor UDP performance using 2.6.21-rc5-rt5
* David Sperry [EMAIL PROTECTED] wrote: there are a few other things i'm working on to improve this. I've uploaded -rt9 which is the current state of affairs. Note that using -rt9 you'll likely only see IRQ-8406 overhead in the system, because i've added an optimization to do process the softirq-net-tx workload in the hardirq thread if the priority of the two is the same (which is the default behavior). But -rt9 is still work in progress that is not fully finished yet: in some cases i'm seeing 'fluctuating performance' problems on forcedeth that werent there before. I tried -rt9 and saw some odd 'fluctuating performance'. I'll try it again tomorrow when I am much closer to the box's power button. could you try -rt10? I've improved hardirq/softirq threading performance some more, and have tuned the forcedeth driver too. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor UDP performance using 2.6.21-rc5-rt5
* Dave Sperry [EMAIL PROTECTED] wrote: I checked the clock source and in both the vanilla and rt cases and they were both acpi_pm ok, thanks for double-checking that. Here's the oprofile for my vanilla case: i tried your workload and i think i managed to optimize it some more: i have uploaded the -rt8 kernel with these improvements included - could you try it? Is there any measurable improvement relative to -rt5? one more thing to improve netperf performance is to do this before running it: chrt -f -p 50 $$ this will put netperf on the same priority level as the net hardirq and the net softirq (which both default to SCHED_FIFO:50), and should result in a (much) reduced context-switch rate. Or, if networking is not latency-critical, then you could move the net hardirq and softirq threads to SCHED_BATCH, and run netperf under SCHED_BATCH as well, using: chrt -b -p 0 $$ and figuring out the active softirq hardirq thread PIDs and chrt -b -ing them too. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.21-rc5-rt6 make errors
* Rui Nuno Capela [EMAIL PROTECTED] wrote: Hi, Just tried to build 2.6.21-rc5-rt6 and it is failing on build time. Just to let you know that -rt5 was doing fine with very same .config . oops - indeed! I've uploaded -rc5-rt7 with the fix. (it includes a few other fixes as well) note that for Fedora-ish distros there's an easy yum test-kernel available from the rt-testing repo: cat /etc/yum.repos.d/rt-testing.repo [rt-testing] name=Ingo's Real-Time (-rt) test-kernel for FC6 baseurl=http://people.redhat.com/mingo/realtime-preempt/yum-testing/yum/ enabled=1 gpgcheck=0 Ctrl-D this includes Linus-git-bleeding-edge as well as the base kernel. (rt7 is based on upstream HEAD 755948cfca16c7) [the rt-testing repo currently includes the rt6 rpm, i've just started the rt7 build, it should be available in half an hour or so] Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: profile_tick not called anymore?
* Sébastien Dugué [EMAIL PROTECTED] wrote: I see that the calls to profile_tick() have been commented out in the different timer handlers. Why is this so? The only remaining place calling profile_tick() (well, in fact __profile_tick()) is the NMI watchdog ticker, but I don't enable it on my box. i'm using nmi_watchdog=2 to do profiling - if it's NMI-driven then the readprofile results are alot more informative. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.20-rt8] Neighbour table overflow.
* Guennadi Liakhovetski [EMAIL PROTECTED] wrote: could you send the patch for that? Is it upstream already? It's indeed an IrDA bug (though mainly visible under rt-preempt) and the patch has been sent to the maintainer and to stable. could you please bounce it to me too? I usually put such patches into -rt straight away and i drop them when they show up upstream. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Does the RT patch contain unrelated hunks?
* Luca Abeni [EMAIL PROTECTED] wrote: Hi all, Looking at patch-2.6.21-rc3-rt0, it seems to me that it contains a lot of unrelated stuff, such as: that's Linus' post -rc3 -git tree. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v2.6.20-rt1, yum/rpm
* K.R. Foley [EMAIL PROTECTED] wrote: Ingo Molnar wrote: i have released the v2.6.20-rt1 kernel, which can be downloaded from the usual place: I have a couple of questions regarding priorities of the softirqs, IRQ handlers, etc. With some exceptions, back in 2.6.18 and prior patches the IRQ threads were prioritized between 50 and 25 and the most of the softirqs were prioritized at 1? In newer patches it looks like they are all prioritized at 50? I was just curious what went into making these choices? I am just trying to better understand these decisions. The basically random order-of-request_irq() prioritization was causing problems (it worked for some but didnt work for others), so i got rid of trying to auto-guess some priority order. Also, now that we've got tools/scripts like set_kthread_prio and rtprio it seemed more consistent to just not attempt to prioritize interrupts and softirqs at all, but to keep them all 'in the middle' of the RT priority range. Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Two 2.6.20-rc5-rt2 issues
* Rui Nuno Capela [EMAIL PROTECTED] wrote: First one is about building for UP (CONFIG_SMP not set) on my old P4 laptop. As it seems, all my build attempts failed at the final link stage, with undefined references to paravirt_enable. After disabling CONFIG_PARAVIRT I get a similar failure, but this time for a couple kvm* symbols. [...] ok, i think i have managed to fix both bugs. I have released -rt3, please re-check whether it works any better. If it still doesnt then please send me the exact .config that fails. [...] I could only get a clean build when CONFIG_SMP is set, which is (IMHO) overkill for a machine which is neither HyperThread/SMT enabled nor multi-core. Its plain dead UP and it used to run PREEMPT_RT kernels for a long time now. btw., latest SMP kernels (2.6.18 and later) patch themselves back to UP instructions to a high degree if they run on a single CPU - that's why for example Fedora uses only an SMP kernel these days. Running a genuine UP kernel is still more efficient - but the difference shouldnt be /that/ large anymore. (if someone would like to measure it that would be interesting to see) Second one is already about running SMP, on a Dual Core2 T7200, for which the build goes fine but run-time is haunted by a crippling BUG: Call Trace: [c0102dad] __switch_to+0xcc/0x176 [c01185c8] wake_up_process+0x19/0x1b [c01fe568] acpi_ec_gpe_handler+0x1f/0x53 [c01ec6c6] acpi_ev_gpe_dispatch+0x64/0x163 [c01eca06] acpi_ev_gpe_detect+0x94/0xd7 hm, this is a -rt specific thing that i hoped to have worked around but apparently not. The ACPI code uses a waitqueue in its idle routine (argh!) which cannot by done sanely on PREEMPT_RT. In -rt3 i've added a more conservative (but still ugly and incorrect) hack - could you try it, does -rt3 work any better? Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 00/10] ARM patch series for -rt15
* Robert Schwebel [EMAIL PROTECTED] wrote: Thomas, this is our current series to make -rt work on ARM, currently based on 2.6.19-rt15. The clockevent patches are already merged in 2.6.20-rc1 via Russell, so they are provided here only for completeness. I'm going to update the latency plots recently posted on the OSADL list when I'm back in the office on monday, to check if the longer latencies on i.MX are still there. FYI, i've added your queue to -rt, it should show up in -rt16. (The only minor complication was that some of the patches in the patch-queue were -p0, some were -p1 formatted. In general we prefer -p1 patches.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel 2.6.19 -rt11 make failure on UP
* Ingo Molnar [EMAIL PROTECTED] wrote:
* cinetic bellini [EMAIL PROTECTED] wrote:
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `do_IRQ':
: undefined reference to `irq_show_regs_callback'
make: *** [.tmp_vmlinux1] Error 1
I am not sure if I have to enable local APIC. So I tryed different
configurations but always with out success.
yeah, enabling APIC support should work around this build problem.
the patch below should fix it too.
Ingo
Index: linux/arch/i386/kernel/irq.c
===
--- linux.orig/arch/i386/kernel/irq.c
+++ linux/arch/i386/kernel/irq.c
@@ -76,7 +76,9 @@ fastcall notrace unsigned int do_IRQ(str
u32 *isp;
#endif
+#ifdef CONFIG_X86_LOCAL_APIC
irq_show_regs_callback(smp_processor_id(), regs);
+#endif
if (unlikely((unsigned)irq = NR_IRQS)) {
printk(KERN_EMERG %s: cannot handle IRQ %d\n,
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
