Ingo Molnar wrote:
> * K.R. Foley <[EMAIL PROTECTED]> wrote:
>
>> Ingo Molnar wrote:
>>> * K.R. Foley <[EMAIL PROTECTED]> wrote:
>>>
>>>> Ingo,
>>>>
>>>> I believe that patch-2.6.21.3-rt9 is misnamed. It applies
Ingo Molnar wrote:
> * K.R. Foley <[EMAIL PROTECTED]> wrote:
>
>> Ingo,
>>
>> I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to
>> 2.6.21 but seems to contain stuff that is already in 2.6.21.3.
>
> yes - it includes all of 2.6.21.3.
Ingo,
I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to
2.6.21 but seems to contain stuff that is already in 2.6.21.3.
--
kr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
# This variable contains the list of modules to be loaded
> # once the main filesystem is active
> #
> MODULES_LOADED_ON_BOOT=""
>
>
> Just came across this one - maybe it`s worth taking a look:
> http://en.opensuse.org/SDB:Waiting_for_Mandatory_Device
>
> regards
> roland
&g
Ingo Molnar wrote:
> i'm pleased to announce the v2.6.21-rt3 kernel, which can be downloaded
> from the usual place:
>
This is actually regarding v2.6.21-rt5 but I don't remember seeing an
announcement for that one. The attached patch is necessary if you happen
to have RTC_HISTOGRAM enabled, whi
Ingo Molnar wrote:
> * 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 t
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
Chen, Tim C wrote:
> Ingo,
>
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
> kernel and noticed several slowdowns. The test machine is a 2 socket
> woodcrest machine with your default configuration.
>
> Netperf TCP Streaming was slower by 40% ( 1 server and 1 client
> ea
Chen, Tim C wrote:
> Ingo,
>
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
> kernel and noticed several slowdowns. The test machine is a 2 socket
> woodcrest machine with your default configuration.
>
> Netperf TCP Streaming was slower by 40% ( 1 server and 1 client
> ea
Remy Bohmer wrote:
> Hello,
>
> For your Information, I get the following compile error when
> CONFIG_NO_HZ is NOT configured on 2.6.19.1-rt14:
>
> --
> CC kernel/sched.o
> kernel/sched.c: In function '__schedule':
> kernel/sched.c:4135:
Ingo Molnar wrote:
> * K.R. Foley <[EMAIL PROTECTED]> wrote:
>
>> Ingo Molnar wrote:
>>
>> The attached patch is necessary to build 2.6.19-rt8 without KEXEC
>> enabled. Without KEXEC enabled crash.c doesn't get included. I believe
>> this is
Ingo Molnar wrote:
The attached patch is necessary to build 2.6.19-rt8 without KEXEC
enabled. Without KEXEC enabled crash.c doesn't get included. I believe
this is correct.
--
kr
--- linux-2.6.19/arch/i386/kernel/nmi.c.orig 2006-12-07 09:35:22.0 -0600
+++ linux-2.6.19/arch/i386/kernel
Ingo Molnar wrote:
> i have released the 2.6.19-rt6 tree, which can be downloaded from the
> usual place:
>
Attached patch fixes rtc histogram. Looks like it got broken around
2.6.18-rt?, probably during the merge for 2.6.18?
--
kr
--- linux-2.6.19/drivers/char/rtc.c.orig 2006-12-06 21
Steven Rostedt wrote:
> On Fri, 2005-08-26 at 16:17 -0500, K.R. Foley wrote:
>
>>2.6.13-rc7-rt3 won't compile without the simple patch below.
>>
>
> - __raw_spin_lock(old_owner->task->pi_lock);
> + __raw_spin_lock(&old_owner->t
2.6.13-rc7-rt3 won't compile without the simple patch below.
--
kr
--- linux-2.6.13/kernel/rt.c.orig 2005-08-26 15:51:35.0 -0500
+++ linux-2.6.13/kernel/rt.c 2005-08-26 15:51:55.0 -0500
@@ -672,7 +672,7 @@
struct rt_mutex_waiter *w;
struct plist *curr1;
- __raw_spin_lock(
Ingo,
Without the attached patch 2.6.13-rc6-rt15 won't compile for me with
CONFIG_HIGH_RES_TIMERS not configured.
--
kr
--- linux-2.6.13/include/linux/timer.h.orig 2005-08-24 11:15:22.0 -0500
+++ linux-2.6.13/include/linux/timer.h 2005-08-24 11:15:35.0 -0500
@@ -76,6 +76,7 @
Ingo Molnar wrote:
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
On Wed, 2005-08-17 at 10:24 -0400, Steven Rostedt wrote:
OK the output from netconsole still seems like netconsole itself is
causing some problems. But I think it is also showing this lockup. I'll
recompile my kernel as UP and
Esben Nielsen wrote:
On Wed, 27 Jul 2005, K.R. Foley wrote:
Esben Nielsen wrote:
On Wed, 27 Jul 2005, Ingo Molnar wrote:
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
Perfectly understood. I've had two customers ask me to increase the
priorities for them, but those w
Esben Nielsen wrote:
On Wed, 27 Jul 2005, Ingo Molnar wrote:
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
Perfectly understood. I've had two customers ask me to increase the
priorities for them, but those where custom kernels, and a config
option wasn't necessary. But since I've had custom
Ingo Molnar wrote:
* K.R. Foley <[EMAIL PROTECTED]> wrote:
On X86 -51-36 won't build with CONFIG_BLOCKER=Y without the attached
patch.
thanks. I changed the include to asm/rtc.h, this should give what PPC
wants to have, and should work on all architectures. Released the
Ingo Molnar wrote:
* john cooper <[EMAIL PROTECTED]> wrote:
Ingo,
Attached is a patch for 51-28 which brings PPC up to date for
2.6.12 PREEMPT_RT. My goal was to get a more recent vintage of this
work building and minimally booting for PPC. Yet this has been stable
even under our inter
I had the following happen last night while running while running Con's
Interbench. Looking back through my log, I do see one other case where
the same BUG triggered from running updatedb (2.6.12-RT-V0.7.51-31), but
it didn't have all of the ext3 errors that followed this one. I really
don't ha
randy_dunlap wrote:
Hi,
Someone asked me about a tool like this and I didn't know of one,
so I made this little script.
'patchview' merges a patch file and a source tree to a set of
temporary modified files. This enables better patch (re)viewing
and more viewable context. (hopefully)
Are the
Karsten Wiese wrote:
Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:
* Karsten Wiese <[EMAIL PROTECTED]> wrote:
Have I corrected the other path of ioapic early initialization, which
had lacked virtual-address setup before ioapic_data[ioapic] was to be
filled in -51-28? Please test atta
Ingo Molnar wrote:
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
>
>>Have I corrected the other path of ioapic early initialization, which
>>had lacked virtual-address setup before ioapic_data[ioapic] was to be
>>filled in -51-28? Please test attached patch on top of -51-29 or
>>later. Also o
K.R. Foley wrote:
K.R. Foley wrote:
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before
'__attribut
K.R. Foley wrote:
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before
'__attribute__'
sound/os
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
sound/oss/emu10k1/midi.c:4
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
I missed getting -51-29 but just booted up -51-30 and all is well.
Thanks. Just out of curiosity, what was changed between -51-28, 29,
and 30?
-51-29 had new IO-APIC optimizations - and i reverted them in -51-30.
Ingo
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token
Here's the offending line:
48 static DEFINE_SPINLOCK(midi_
Ingo Molnar wrote:
* K.R. Foley <[EMAIL PROTECTED]> wrote:
Ingo Molnar wrote:
* Daniel Walker <[EMAIL PROTECTED]> wrote:
I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on,
would actually cause spurious interrupts. It was odd cause it's
suppose t
Ingo Molnar wrote:
* Daniel Walker <[EMAIL PROTECTED]> wrote:
I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on,
would actually cause spurious interrupts. It was odd cause it's
suppose to stop them .. If there was a lot of interrupt traffic on one
IRQ , it would cause inte
Ingo Molnar wrote:
* K.R. Foley <[EMAIL PROTECTED]> wrote:
Ingo,
I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when
running the RT patches. The problem manifests itself as if the key
were stuck but happens far too quickly for that to be the case. I
realize th
Doug Maxey wrote:
On Fri, 08 Jul 2005 21:13:26 +0200, Ingo Molnar wrote:
* K.R. Foley <[EMAIL PROTECTED]> wrote:
Ingo,
I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when
running the RT patches. The problem manifests itself as if the key
were stuck but happens f
Dave Neuer wrote:
On 7/8/05, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* K.R. Foley <[EMAIL PROTECTED]> wrote:
Ingo,
I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when
running the RT patches.
2.6.12 doesn't seem to have the
problem at all, only wh
Sorry Ingo. Missed cc'ing lkml the first time.
Ingo,
I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when
running the RT patches. The problem manifests itself as if the key were
stuck but happens far too quickly for that to be the case. I realize
that the statements above are f
I am having a problem getting my Dell Precision 620 with dual PIII 933's
and 512 Mb memory to boot 2.6.12-rc3. The problem seems to be the
aic7899. The aic7899 driver is compiled into the kernel along with the
rest of scsi. I have had to compile in the scsi for every version of
2.6.12-x, but th
Linus Torvalds wrote:
On Fri, 22 Apr 2005, K.R. Foley wrote:
This simple patch fixes a compile error in the ultrastor driver. Patch
was originally submitted by Barry K. Nathan as referenced here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111391774018717&w=2
I just regenerated it agai
This simple patch fixes a compile error in the ultrastor driver. Patch
was originally submitted by Barry K. Nathan as referenced here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111391774018717&w=2
I just regenerated it against your current git tree. Please apply.
--
kr
Signed-off
Tom Duffy wrote:
On Thu, 2005-04-14 at 12:29 -0400, [EMAIL PROTECTED] wrote:
In testing with 2.6.12-rc1 and -rc2, we've been encountering an issue
on SMP machines with the loading of scsi_mod and sd_mod modules. The
sd_mod load fails with unresolved symbols. It appears to be a race
condition based
Ingo,
It would seem that in the latest patch RT-V0.7.45-00 we have reverted
back to removing the define of jbd_debug which the attached patch
(against one of the 2.6.11 versions) fixed.
--
kr
--- linux-2.6.11/include/linux/jbd.h.orig 2005-03-16 09:18:51.0
-0600
+++ linux-2.6.11
Lee Revell wrote:
On Fri, 2005-04-08 at 15:26 -0500, K.R. Foley wrote:
Lee Revell wrote:
Meh, I'll try again, maybe it's some weird NFS problem.
Lee
Hmm. Maybe. I should probably mention that I am doing an FC3 install via
NFS from my older SMP system right now while also building
Lee Revell wrote:
On Fri, 2005-04-08 at 15:15 -0500, K.R. Foley wrote:
Lee Revell wrote:
On Fri, 2005-04-08 at 16:22 +0100, Rui Nuno Capela wrote:
Our first victim!! :-)
No kidding!?
V0.7.44-02 does not even compile for me. It appears to be full of merge
errors.
I must be in the twilight zone
Jon Smirl wrote:
On Apr 1, 2005 7:17 AM, K.R. Foley <[EMAIL PROTECTED]> wrote:
I have an old Dell Precision 620 workstation with dual PIII 933's and
512 Mb memory. It also uses AIC-7899P U160/m SCSI controllers with one
U160 drive (boot drive) and one slower 18 Gb. I have been r
Gene Heskett wrote:
On Friday 01 April 2005 13:27, K.R. Foley wrote:
Gene Heskett wrote:
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output: ---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching
Gene Heskett wrote:
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts output:
---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hu
I have an old Dell Precision 620 workstation with dual PIII 933's and
512 Mb memory. It also uses AIC-7899P U160/m SCSI controllers with one
U160 drive (boot drive) and one slower 18 Gb. I have been running many
different variants of the kernel on this system for quite some time with
much succe
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
hm, another thing: i think call_rcu() needs to take the read-lock.
Right now it assumes that it has the data structure private, but
that's only statistically true on PREEMPT_RT: another CPU may ha
Lee Revell wrote:
On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
i have released the -V0.7.41-00 Real-Time Preemption patch (merged to
2.6.12-rc1), which can be downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
3ms latency in the NFS client code. Workload was a k
Lee Revell wrote:
On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
the biggest change in this patch is the merge of Paul E. McKenney's
preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it
is still quite experimental at this stage, it allowed the removal of
locking cruft (ma
Ingo Molnar wrote:
hi Frank - sorry about the late reply, was busy with other things. Your
ppc patches look mostly mergeable, with some small details still open:
* Frank Rowand <[EMAIL PROTECTED]> wrote:
The patches are:
1/5 ppc_rt.patch - the core realtime functionality for PPC
what is
Steven Rostedt wrote:
+#ifdef CONFIG_PREEMPT_RT
+#define PICK_SPIN_LOCK(otype,bit,name) spin_##otype(&bh->b_##name##_lock)
+#else
+#define PICK_SPIN_LOCK(otype,bit,name) bit_spin_##otype(bit,bh->b_state);
+#endif
+
Oops, extra semicolon on the non RT side.
I'll try again.
-- Steve
Haven't tried it
Lee Revell wrote:
OK, I have run some simple tests with JACK, Hydrogen, and 2.6.11.
2.6.11 does not seem to be much of an improvement over 2.6.10. It may
in fact be slightly worse. This was what I expected, as it appears that
a number of latency fixes in the VM got preempted by the 4-level page
t
Ingo Molnar wrote:
i have released the -V0.7.35-00 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
The two dozen split out latency patches (including PREEMPT_BKL) that
were in -mm are in BK now, so i've rebased the -RT patchset
Ingo Molnar wrote:
i have released the -V0.7.35-00 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
The two dozen split out latency patches (including PREEMPT_BKL) that
were in -mm are in BK now, so i've rebased the -RT patchset
55 matches
Mail list logo
