On Thu, 29 Nov 2007, Russell King - ARM Linux wrote:
> If people insist on adding the mask/unmask crap to it, the function
> might as well be deleted and be an alias for handle_level_IRQ. Because
> that's _precisely_ what you lot are turning it into.
>
> Ah, and looking at the changes to the file
On Tue, 2006-12-05 at 08:16 -0800, Darren Hart wrote:
> On Tuesday 05 December 2006 07:27, Vucsics Krisztian wrote:
> > Hi Darren,
> >
> > > http://www.kernel.org/pub/linux/kernel/people/dvhart/realtime/tests/
> >
> > I've downloaded your testcases but some of them cannot be compiled, e.g.
> > fun
On Tue, 2006-12-05 at 20:02 +, cinetic bellini wrote:
>
Please configure your MUA to make line breaks at 78 characters. Thanks.
> I uses the the RT patch on different x86 platforms (rt cyclictest).
> On Pentium 4 systems I got perfect results: around 50us jitter.
> On older platforms like
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 driv
On Sat, 2006-12-09 at 21:28 +, Rui Nuno Capela wrote:
> Hi all,
>
> Sorry for the interrupt, but all my 2.6.19-rt11 builds very fail early on
> boot. It doesn't matter if its UP or SMP. This is a sample of what I could
> capture on one case via serial console:
Can you please disable CONFIG_HP
On Fri, 2006-12-15 at 23:37 +0100, Robert Schwebel wrote:
> plain text document attachment
> (high-res-timers-dynticks-enable-arm-support.patch)
> From: Luotao Fu <[EMAIL PROTECTED]>
>
> Turns hrt config options on for arm. It does this unconditionally
> so it currently breaks platforms that don't
On Fri, 2006-12-15 at 21:53 +0100, Pavel Pisa wrote:
> Index: linux-2.6.19-rt/include/asm-arm/atomic.h
> ===
> --- linux-2.6.19-rt.orig/include/asm-arm/atomic.h
> +++ linux-2.6.19-rt/include/asm-arm/atomic.h
> @@ -188,10 +188,10 @@ sta
On Fri, 2006-12-15 at 23:37 +0100, Robert Schwebel wrote:
> /*
> * Static I/O mappings that are needed for all EP93xx platforms
> @@ -99,18 +102,15 @@ void __init ep93xx_map_io(void)
>
> static int ep93xx_timer_interrupt(
On Fri, 2006-12-15 at 23:37 +0100, Robert Schwebel wrote:
>
> - offset = __raw_readl(EP93XX_TIMER4_VALUE_LOW) - last_jiffy_time;
> +static struct clocksource clocksource_ep93xx = {
> + .name = "ep93xx timer2",
You use timer4, why is it called timer2 ? Also please avoid spaces i
On Fri, 2006-12-15 at 23:37 +0100, Robert Schwebel wrote:
> /*
> * IRQ handler for the timer
> */
> static irqreturn_t
> netx_timer_interrupt(int irq, void *dev_id)
> {
> - write_seqlock(&xtime_lock);
> -
> - timer_tick();
> -
> - write_sequnlock(&xtime_lock);
> -
> /* ack
On Fri, 2006-12-15 at 23:37 +0100, Robert Schwebel wrote:
> +
> +static void imx_set_mode(enum clock_event_mode mode, struct
> clock_event_device *evt)
> +{
> + clockevent_mode = mode;
> +}
Please fill in the correct set mode functionality.
tglx
-
To unsubscribe from this list: sen
On Fri, 2006-12-15 at 23:37 +0100, Robert Schwebel wrote:
> +static void ep93xx_set_mode(enum clock_event_mode mode, struct
> clock_event_device *evt)
> +{
> + clockevent_mode = mode;
> +}
Please implement set mode correctly.
tglx
-
To unsubscribe from this list: send the line "uns
On Fri, 2006-12-15 at 23:36 +0100, Robert Schwebel 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
How are the clock event patches merged ? Clock events are not in
2.6.20-rc1
>
On Thu, 2007-01-04 at 14:15 +0100, Steven Scholz wrote:
> Robert Schwebel wrote:
> > On Thu, Jan 04, 2007 at 12:43:11PM +0100, Steven Scholz wrote:
> >> Will I need a special version of glibc or libpthread? NTPL?
> >> I am using a cross tool chain gcc-3.4.4-glibc-2.3.5 for i686 built with
> >> "cro
On Thu, 2007-01-04 at 12:43 +0100, Steven Scholz wrote:
> So I recon it has something to do with the rootfs I am using (created with
> PTXdist).
Can you try to use a standard root filesystem (fedora, debian or
whatever you have handy) ?
tglx
-
To unsubscribe from this list: send the lin
On Thu, 2007-01-04 at 14:31 +0100, Steven Scholz wrote:
> > cyclictest does not need any extra functionality. You only need a new
> > glibc if you want to use priority inheritance mutexes.
>
> Ok. Then any idea how I could find out why sigwait() is blocking?
Can you strace cyclictest and send me
On Thu, 2007-01-04 at 16:01 +0100, Steven Scholz wrote:
> > cyclictest does not need any extra functionality. You only need a new
> > glibc if you want to use priority inheritance mutexes.
>
> So IIUC the cyclictest should run and give results even on kernels with no
> real time, preempt, lowlaten
Steven,
On Sun, 2007-01-07 at 13:51 +0100, Steven Scholz wrote:
> > There is neither a call of timer_create() nor of timer_settime(). So the
> > posix timer is not setup, which results in the endless wait for the
> > signal.
>
> cyclictest runs fine on my SuSE 10.0 host system. But: there are *no
Steven,
On Sun, 2007-01-07 at 15:38 +0100, Steven Scholz wrote:
> strace ./cyclictest -t 1 -p 80 -i 1 -l 10 -v 2> cyclictest.txt
You need to run "strace -f " otherwise you don't get the thread
strace.
> >> Has it to with using TLS?
> > No.
> IIUC TLS is only usefull for SMP systems?
Th
Guennadi,
On Tue, 2007-01-16 at 16:46 +0100, Guennadi Liakhovetski wrote:
> I noticed that the above function in kernel/rtmutex.c has changed a lot,
> and I do have a problem in that function under some realtime load.
Which problem do you have ? Can you describe it a bit more detailed ? Do
you
On Wed, 2007-01-17 at 11:46 +0100, Guennadi Liakhovetski wrote:
> Unable to handle kernel paging request at virtual address 00025d87
Memory corruption ?
> PC is at task_blocks_on_rt_mutex+0xb8/0x2a8
Can you decode the exact code line, so we know what it tries to access ?
> (yes, tainted, you kn
Wolfgang,
On Sun, 2007-02-11 at 13:39 +0100, Wolfgang Grandegger wrote:
> As I see it, 2.6.20-rt3 has the same issues (have now attached the
> missing make output). I fixed them manually and are now able to boot and
> run the 2.6.20-rt5 on my Icecube board. Nevertheless, cyclictest returns
> hi
On Sun, 2007-02-11 at 17:37 +0100, Wolfgang Grandegger wrote:
> > Yup, I did not come around to do the fixups. Is top on my todo list
> > though.
>
> Apart from that, I also realized that it's not possible to enable
> HIGH_RES_TIMERS, because GENERIC_CLOCKEVENTS is not selected or
> available fo
On Mon, 2007-02-19 at 18:00 +0100, Wolfgang Grandegger wrote:
> Hello,
>
> sometimes I get the following message when calling ktime_get_real() from
> my interrupt handler:
SMP machine ?
> BUG: time warp detected!
> prev > now, 104357354c79dfed > 1043573435312fb2:
> = 4685606971 delta, on CPU#0
On Tue, 2007-02-20 at 13:10 -0500, Alex Khripin wrote:
> I have seen a similar event as well on -rt5; SMP kernel but on a P4 with
> hyperthreading disabled.
Alex, Wolfgang,
does this happen with -rt9 too ?
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-use
On Wed, 2007-02-21 at 19:41 +0100, Wolfgang Grandegger wrote:
> Thomas Gleixner wrote:
> > On Tue, 2007-02-20 at 13:10 -0500, Alex Khripin wrote:
> >> I have seen a similar event as well on -rt5; SMP kernel but on a P4 with
> >> hyperthreading disabled.
> >
>
On Wed, 2007-05-16 at 12:12 +0200, Robert Schwebel wrote:
> > > Once again. On this piece of hardware there is no other useful timer as
> > > the
> > > PIT.
> >
> > Cyclictest tell me this:
> >
> > "WARNING: High resolution timers not available"
> >
> > also if i add "clocksource=pit" in the k
On Fri, 2007-05-18 at 10:39 +0300, emin ak wrote:
> Hi,
> I have tried to compile -rt3 patch for ppc (mpc8540ads) and it failed
> with undefined referance errors on ppc/kernel/asm-offsets.c. Here is
> the compiler outputs:
arch/ppc is known to be broken. Does it even compile on 2.6.21 vanilla ?
Please do not top post !
On Fri, 2007-05-18 at 11:10 +0300, emin ak wrote:
> Yes, 2.6.21 was compiled and boot successfully for ppc, Is 85xx family
> supported for powerpc arch?
I don't know. You might ask the folks on the ppc mailing list.
tglx
-
To unsubscribe from this list: send th
On Sat, 2007-05-19 at 00:15 -0700, Darren Hart wrote:
> When trying to boot with the maxcpus=1 option, the -rt kernel seems to hang
> somewhere in acpi_processor_init().
>
> I tested mainline 2.6.21 and it does boot with maxcpus=1. 2.6.20-rt8,
> 2.6.21-rt1, 2, and 4 all hang at:
>
> Calling in
On Mon, 2007-05-21 at 13:11 -0700, Daniel Walker wrote:
> Where did the arm ep93xx changes come from?
Grown out of my nose probably.
> It looks like patch below
> came in with them in 2.6.21-rt6 ..
So what ?
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-us
On Mon, 2007-05-21 at 13:25 -0700, Daniel Walker wrote:
> On Mon, 2007-05-21 at 22:24 +0200, Thomas Gleixner wrote:
> > On Mon, 2007-05-21 at 13:11 -0700, Daniel Walker wrote:
> > > Where did the arm ep93xx changes come from?
> >
> > Grown out of my nose probably.
On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote:
> Is there anything I can do better to help myself figuring out this
> issue? As this is a modern laptop such things like a serial console are
> unavailable, but it would be nice to track things up over netconsole
> perhaps?
>
> I just nee
On Thu, 2007-06-07 at 09:35 +0200, Alessio Igor Bogani wrote:
> Hi,
>
> I'm trying to compile 2.6.22 kernel with patch-2.6.21.3-rt9.
I have no idea, why you insist to run the 2.6.21 patch on 2.6.22-rc.
> I have this error but i don't understand what type of error it is.
> Someone can explain me
On Fri, 2007-06-08 at 13:08 +0300, Oleg Kechin wrote:
> Sorry, OMAP5910 CPU is ARM 925 (v4).
> Thank you, Daniel, it's disapear.
> There is stil a bit unclearness for me. When I set config other than
> PREEMPT_RT this bug occure again.
> May be it's ok - if someone want -rt patch on ARM arch, he wi
On Wed, 2007-06-06 at 01:44 +0100, Rui Nuno Capela wrote:
> Just for the heads-up, I'm still suffering from this same illness, and
> it seems even worse (big freeze happens earlier) on 2.6.21.3-rt9.
>
> There's no way around. On one box it works flawlessly (desktop,
> [EMAIL PROTECTED]) while on t
On Fri, 2007-06-08 at 19:21 +0100, Rui Nuno Capela wrote:
> >> There's no way around. On one box it works flawlessly (desktop,
> >> [EMAIL PROTECTED]) while on the patient one (laptop, core2 T7200) it bricks
> >> silently.
> >
> > Sorry for responding late. To have some idea where the breakage come
On Sun, 2007-06-10 at 10:34 +, Oleksandr Natalenko wrote:
> > http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.4.tar.bz2
> > http://people.redhat.com/mingo/realtime-preempt/patch-2.6.21.4-rt11
> kernel/built-in.o: In function `__schedule':
> (.sched.text+0xe0): undefined reference t
On Mon, 2007-06-11 at 20:36 +0100, Rui Nuno Capela wrote:
> > I'm spinning -rt10 with a couple of fixes. Should be out sometimes
> > tomorrow. If the problem persists, we need to dig deeper.
> >
>
> Uhoh. I'm sorry to tell, but the problem is still creeping on
> 2.6.21.4-rt11 and -rt12 :(
>
> So
On Mon, 2007-06-11 at 21:50 +0100, Rui Nuno Capela wrote:
> Thomas,
>
> Yes, "maxcpus=1" seems to keep it running, but then I render my Core2
> just half-baked ;)
Yes, I know :(
/me goes into desperate mode
Is this a DELL laptop ?
tglx
-
To unsubscribe from this list: send the line "
On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote:
> Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL
> PROTECTED]
Yeah, there are Dell ones which have similar or worse symptoms.
> Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already
> know :)
Ok. I
On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote:
> On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote:
> > On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote:
> > > Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL
> > > PRO
On Wed, 2007-06-13 at 09:58 +0200, Peter Feuerer wrote:
> That would be a very fast and easy to implement solution, but then I
> have to touch the kernel again. I wanted not to do that.
>
> > But i guess a better variant would be to adopt the IIO framework
> > for your purpose (http://lkml.org/lkm
On Wed, 2007-06-13 at 10:31 +0200, Peter Feuerer wrote:
> > > Great, seems like that's what I'm searching for. I will have a deeper
> > > look into this. Because if this is going to be in the mainline kernel, I
> > > don't have to touch the kernel at all.
> >
> > You have to touch it. You still ne
On Sun, 2007-06-17 at 11:15 -0500, Nelson Castillo wrote:
> > http://rt.wiki.kernel.org
>
> Not for ARM yet :(
>
> What should I try for the ARM architecture?
ARM has a lot of sub architectures and not all of them are supported
yet.
> There are many choices and
> I don't know what is the
On Sun, 2007-06-17 at 11:49 -0500, Nelson Castillo wrote:
> > > There are many choices and
> > > I don't know what is the more friendly. By friendly I mean the one that
> > > is likely to be merged and that cooperate with you.
> >
> > Which choices do you mean ?
>
> I mean implementations. I've se
Katsuya-San,
On Tue, 2007-06-19 at 01:14 +0900, Katsuya MATSUBARA wrote:
> > It lacks support for the generic timeofday and clock event layers, which
> > causes the compile breakage.
>
> I am working on Renesas SuperH platforms.
> I faced the similar compile errors
> because 2.6.21.X in SH doe
On Thu, 2007-06-21 at 17:06 +0200, Alessio Igor Bogani wrote:
> Hi to all,
>
> Sorry for my poor english.
Hey no reason to excuse your self. It's not your fault that you are not
a native speaker and that the computer industry has chosen English as
the preferred language.
I can feel with you :)
On Thu, 2007-06-21 at 13:31 +0200, Michal Schmidt wrote:
> OK, I fixed the spacing in both occurences.
>
> Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
>
> --- arch/i386/kernel/io_apic.c.orig 2007-06-19 08:40:05.0 -0400
> +++ arch/i386/kernel/io_apic.c2007-06-21 06:51:16.00
Flavio,
first off, please use a mail client which does proper line wraps at
column 78, when sending mail to mailing lists, or configure your mail
client to do so.
On Fri, 2007-06-22 at 20:05 +0200, fla83tn wrote:
> Hi to all,
> I'm a Computer Science student who has patched the linux-2.6.19 for
>
On Fri, 2007-06-22 at 14:36 -0700, Masayuki Nakagawa wrote:
> So, I suggest a following change.
> The change is to set the flag bit appropriately in __inet6_hash().
>
> Signed-off-by: Masayuki Nakagawa <[EMAIL PROTECTED]>
Thanks, applied.
tglx
-
To unsubscribe from this list: send the
I'm pleased to announce the v2.6.21.5-rt19 kernel on behalf of Ingo.
It can be downloaded from the usual place:
http://people.redhat.com/mingo/realtime-preempt/
More info about the -rt patch set can be found in the RT wiki:
http://rt.wiki.kernel.org
Changes since 2.6.21.5-rt18:
On Wed, 2007-07-11 at 16:47 +0200, Sébastien Dugué wrote:
> The following patch fixes this by re-enabling the RT overload detection
> for the CFS. It may not be the right solution, maybe it should be incorporated
> into the other load balancing mechanisms. I did not digg deep enough yet
> to make
On Wed, 2007-07-11 at 20:58 -0400, Gregory Haskins wrote:
> Note also that we find that the resulting kernel does not boot on some
> T60p thinkpads without "acpi=off". We are still investigating the root
> cause here.
Try "nohpet" for now. I'm investigating it on the -hrt side as well.
Daniel,
On Thu, 2007-07-12 at 09:33 -0700, Daniel Walker wrote:
> On Thu, 2007-07-12 at 17:37 +0200, Ingo Molnar wrote:
> > We are pleased to announce something we've been working on for some
> > time: a finegrained, split-up patch queue of the -rt kernel patch. From
> > now on (as of 2.6.22.1-r
On Thu, 2007-07-12 at 10:02 -0700, Daniel Walker wrote:
> On Thu, 2007-07-12 at 19:01 +0200, Thomas Gleixner wrote:
>
> > We know very well and Ingo nowhere said, that this is not a perfect
> > queue, but it was and still is _our_ work base and we opened it up for
> &g
Joachim,
On Thu, 2007-07-12 at 20:40 +0200, Joachim Deguara wrote:
> x86_64-apic-whitex86_64-apic-whitespace-comment-and-remove-unused-code.patch
> x86_64-timec-fix-whitespace-wreckage.patch
> #GOOD
> x86_64-consolidate-tsc-calibration.patch
> #Not Bisectable
> x86_64-preparatory-apic-set-lvtt.pat
On Fri, 2007-07-13 at 16:25 +1000, Peter Williams wrote:
> > we are working on something in this area :) Stay tuned ...
>
> I've just been reviewing these patches and have spotted an error in the
> file mm/slob.c at lines 500-501 whereby a non existent variable "c" is
> referenced. The attached p
On Fri, 2007-07-13 at 04:43 -0400, Gene Heskett wrote:
> >> we are working on something in this area :) Stay tuned ...
> >
> >I've just been reviewing these patches and have spotted an error in the
> >file mm/slob.c at lines 500-501 whereby a non existent variable "c" is
> >referenced. The attache
we are pleased to announce the v2.6.22.1-rt3 kernel
Attention!
Ingo is off for a long weekend and therefor the download location for
this release is:
http://www.tglx.de/projects/preempt-rt/2.6.22.1
more info about the -rt patchset can be found in the RT wiki:
http://rt.wiki.kernel.org
On Fri, 2007-07-13 at 13:36 +0200, Remy Bohmer wrote:
> Thomas,
>
> > http://www.tglx.de/projects/preempt-rt/2.6.22.1
>
> This is a dead link...
> It should be: http://www.tglx.de/projects/preempt-rt/2.6.22.1-rt3/
Grmbl, the publishing script choked.
tglx
-
To unsubscribe from this l
On Fri, 2007-07-13 at 10:52 -0700, Kevin Hilman wrote:
> Thomas, Ingo,
>
> Here's a handful of small fixes for -rt3. They are either ARM-related
> fixups or compile fixes for various .config combinations.
>
> The first couple I already reported, but here they're all together.
Kevin, please chec
On Thu, 2007-07-19 at 20:37 -0700, Daniel Walker wrote:
> The broken out series is here,
> ftp://source.mvista.com/pub/dwalker/rt/patch-2.6.22.1-rt4-dw1.tar.gz
I'll pick that up soon.
Thanks,
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body o
On Mon, 2007-07-23 at 14:30 -0700, Daniel Walker wrote:
> Yeah, the quicklist patch wasn't fully tested .. The delta patch below
> is what I had to change to get it working ..
My bad. I pushed the wrong queue to Ingo.
-ENOTENOUGHSLEEP
This is the delta. We'll do a -rt6 tomorrow morning.
On Tue, 2007-07-24 at 00:05 +0200, Thomas Gleixner wrote:
> On Mon, 2007-07-23 at 14:30 -0700, Daniel Walker wrote:
> > Yeah, the quicklist patch wasn't fully tested .. The delta patch below
> > is what I had to change to get it working ..
>
> My bad. I push
On Wed, 2007-07-25 at 19:00 +0200, Juergen Beisert wrote:
> [c0245db0] [c01bdb98] rt_spin_lock_slowlock+0x4c/0x224 (unreliable)
> [c0245e10] [c011823c] uart_start+0x24/0x48
> [c0245e30] [c0113ff4] n_tty_receive_buf+0x170/0xfd4
> [c0245ef0] [c010f0dc] flush_to_ldisc+0xe0/0x130
> [c0245f20] [c011b51c
On Thu, 2007-08-16 at 20:58 -0700, Daniel Walker wrote:
> On Thu, 2007-08-16 at 21:37 -0300, Luis Claudio R. Goncalves wrote:
> > Fixes spurious system load spikes observed in /proc/loadavgrt, as described
> > in:
> >
> > Bug 253103: /proc/loadavgrt issues weird results
> > https://bugzilla.r
On Fri, 2007-08-17 at 09:24 -0700, Daniel Walker wrote:
> > > It would be nice if you explained better what the code defect was, and
> > > how you fixed it .. One could extract that from the code, but it's nice
> > > if it's backed up with a text description.. Also you should CC lkml next
> > > tim
On Fri, 2007-08-17 at 14:43 -0700, Daniel Walker wrote:
> On Fri, 2007-08-17 at 23:37 +0200, Thomas Gleixner wrote:
>
> > You really start to annoy me. There was a detailed bug description and
> > the code defect is easy to see. If you neither have the interest nor the
>
On Fri, 2007-08-17 at 15:43 -0700, Daniel Walker wrote:
> Again here I make a simple request and I'm "scaring off developers" ..
> What your doing right now is scaring off developers ..
s/developers/one person who seeks to be scared off/
> > Keep this tone up and you are right on the way to make
We're pleased to announce the release of the v2.6.23-rc4-rt1 kernel,
which can be downloaded from a new place:
http://www.kernel.org/pub/linux/kernel/projects/rt/
The move to kernel.org is experimental for now, we'll keep it if it
works out fine.
Changes since 2.6.23-rc2-rt2:
- update to -
On Fri, 2007-08-31 at 17:01 -0700, Daniel Walker wrote:
> > - UP compile fixes back merged (Kevin Hilman / Steven Rostedt)
> > - various latency tracer fixes (Steven Rostedt)
>
> I'm not sure which latency tracing fixes these are, but Steven's
> get_monotonic_cycles() changes are racy .. It might
On Tue, 2007-09-18 at 10:05 +0200, Andi Kleen wrote:
> > > I disagree for the oops case. You want the simplest possible code
> > > here.
> >
> > If that's true for real time , should be true for mainline right?
>
> You mean it shouldn't use lockdep etc. there? Yes good point. I can change
> tha
On Wed, 2007-09-26 at 15:44 -0400, Steven Rostedt wrote:
> > No wonder here: the -rt patch already has much of this code since around
> > 2.6.21. They have been submitted by me, mostly... and this patchset is
> > against the Linus' tree.
>
> That would explain it ;-)
>
> I was searching the
On Sun, 30 Sep 2007, Robert Schwebel wrote:
> On Sun, Sep 30, 2007 at 09:07:19PM +0530, Jaswinder Singh wrote:
> > Here are my results on Intel Pentium 4 :
> >
> > Command line : ./cyclictest -t 1 -p 80 -i 1 -l 1 -q
>
> Can you post the output of /proc/timer_list?
The output of /sys/devi
On Mon, 1 Oct 2007, Robert Schwebel wrote:
> On Mon, Oct 01, 2007 at 12:00:58AM +0200, Thomas Gleixner wrote:
> > > Can you post the output of /proc/timer_list?
> >
> > The output of
> > /sys/devices/system/clocksource/clocksource0/available_clocksource
&g
On Mon, 1 Oct 2007, Andi Kleen wrote:
> On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
> > Thanks to tglx and ghaskins for all the help in tracking down a very
> > early nmi_watchdog crash on certain x86_64 machines.
>
> The patch is totally bogus. irq 0 doesn't say anything about whet
On Mon, 1 Oct 2007, Andi Kleen wrote:
> On Monday 01 October 2007 20:54:21 Thomas Gleixner wrote:
> > On Mon, 1 Oct 2007, Andi Kleen wrote:
> >
> > > On Wednesday 26 September 2007 20:03:12 David Bahi wrote:
> > > > Thanks to tglx and ghaskins for
ase when the
cpu local timer handler has been invoked. This keeps the cpu local
handler decision and invocation in the common code and allows x86 to
handle the nmi watchdog accounting correctly.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/apic.c b/arch
On Mon, 1 Oct 2007, Andi Kleen wrote:
>
> > IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
> > next CPU, but the check in NMI watchdog for CPU == 0 would not longer
> > work.
>
> That cannot happen right now because cpu_disable() on both i386/x86-64
> reject CPU #0. So
On Tue, 2 Oct 2007, Andi Kleen wrote:
>
> > OTOH, the accounting hook would allow us to remove the IRQ#0 -> CPU#0
> > restriction. Not sure whether it's worth the trouble.
>
> Some SIS chipsets hang the machine when you migrate irq 0 to another
> CPU. It's better to keep that Also I wouldn't be s
On Tue, 2 Oct 2007, Andi Kleen wrote:
> > Agreed.
> >
> > I just got a x8664-hrt report, where I found the following oddity:
> >
> > 0: 1197 172881 IO-APIC-edge timer
> >
> > That's one of those infamous AMD C1E boxen. Strange, all my systems have
> > IRQ#0 on CPU#0 and nowher
On Wed, 3 Oct 2007, Paul Mackerras wrote:
> Tony Breeds writes:
>
> > @@ -982,6 +906,10 @@ void __init time_init(void)
> >
> > write_sequnlock_irqrestore(&xtime_lock, flags);
> >
> > + /* Register the clocksource, if we're not running on iSeries */
> > + if (!firmware_has_feature(FW_F
On Fri, 5 Oct 2007, Gregory Haskins wrote:
> This series may help debugging certain circumstances where the serial
> console is unreponsive (e.g. RT51+ spinner, or scheduler problem). It changes
> the serial8250 driver to use IRQF_NODELAY so that interrupts execute in irq
> context instead of a kt
On Thu, 4 Oct 2007, Pallipadi, Venkatesh wrote:
> >-Original Message-
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of
> >Thomas Gleixner
> >Sent: Monday, October 01, 2007 11:19 PM
> >To: Andi Kleen
> >Cc: Arjan van de
On Mon, 8 Oct 2007, Jaswinder Singh wrote:
> On 10/8/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >
> > Not sure what you mean by this, since interrupt handlers are run as
> > threads and are fully preemptible.
> >
> I think by nested or reentrant interrupt handling technique you can
> further r
On Mon, 8 Oct 2007, Jaswinder Singh wrote:
> Hello Robert,
>
> On 10/8/07, Robert Schwebel <[EMAIL PROTECTED]> wrote:
> > On Sun, Oct 07, 2007 at 06:20:29PM +0530, Jaswinder Singh wrote:
> > > I am also getting :
> > > [EMAIL PROTECTED] cycletest]# ./cyclictest -t 1 -p80 -n -i 1 -l 1
> >
On Tue, 9 Oct 2007, John Sigler wrote:
> Hello everyone,
>
> I'm using a -rt kernel with high resolution timer support.
> http://rt.wiki.kernel.org/index.php/Main_Page
> Linux version 2.6.22.1-rt9 ([EMAIL PROTECTED]) (gcc version 3.4.6) #1 PREEMPT
> RT Tue
> Oct 9 10:02:45 CEST 2007
>
> I enable
On Tue, 9 Oct 2007, John Sigler wrote:
> Alessio Igor Bogani wrote:
> > On Tue, 2007-10-09 at 11:06 +0200, John Sigler wrote:
> > [...]
> > > I enabled high resolution timer support and disabled ACPI support.
> > [...]
> >
> > http://www.mail-archive.com/linux-rt-users@vger.kernel.org/msg00375.h
On Tue, 9 Oct 2007, Alessio Igor Bogani wrote:
> On Tue, 2007-10-09 at 11:22 +0200, Thomas Gleixner wrote:
> [...]
> > We do not trust TSC at all. Never ever.
>
> I found in the code at arch/i386/kernel/tsc.c that there is a exception
> for Geode LX (the famous OLPC). ;-
On Tue, 9 Oct 2007, Dragan Noveski wrote:
> hallo, i am using the 2.6.22.1-rt9 kernel too, and it runs pretty good for me,
> but following this thread i got very unsure, if the hrtimer is being used
> here.
> .resolution: 1 nsecs
Yes, it switched to high resolution (1 nsec). Otherwise it would sh
On Mon, 15 Oct 2007, Daniel Walker wrote:
> On Mon, 2007-10-15 at 14:14 -0400, Steven Rostedt wrote:
>
> > > This is the second fix for this .. The first was in this email (over a
> > > month ago)
> > >
> > > http://lkml.org/lkml/2007/8/31/318
> >
> > You're right I missed that. (I even read it).
On Thu, 8 Nov 2007, Bernhard Kuhn wrote:
> Luís Henriques wrote:
>
> > Maybe I didn't completely understood your question, but... if there is a
> > problem with SMP efficiency (I do not really know, but believe you :) ) with
> > priority ceiling (PC) implementation, this problem should have been a
93 matches
Mail list logo
