On Sat, 2007-07-14 at 12:49 +0200, Maarten Maathuis wrote:
> Were can -rt3 be found?
http://lkml.org/lkml/2007/7/13/159
> On 7/13/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> > > I have determined that version 2.6.22.1-rt2 freeze a
Were can -rt3 be found?
On 7/13/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> I have determined that version 2.6.22.1-rt2 freeze after:
>
> NET: Register protocol family 2
>
> This is very early in the boot stage, and i cannot determin
Maarten Maathuis wrote:
I have determined that version 2.6.22.1-rt2 freeze after:
NET: Register protocol family 2
This is very early in the boot stage, and i cannot determine what
exactly causes it.
It happens if either high resolution timers or dynamic ticks are active.
There's a race in th
On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> I have determined that version 2.6.22.1-rt2 freeze after:
>
> NET: Register protocol family 2
>
> This is very early in the boot stage, and i cannot determine what
> exactly causes it.
>
> It happens if either high resolution timers or
[EMAIL PROTECTED]:~$ uname -r
2.6.19.1-rt15_00
And I'm totally thrilled since this is the first -rt kernel that I've
tried and been able to boot since .16-rt29. Yay!
[EMAIL PROTECTED]:~$ zcat /proc/config.gz | egrep "HZ.*=y"
CONFIG_HZ_1000=y
100 revs; min: 5008 max: 5034 avg: 5015
100 revs; mi
On Fri, 15 Dec 2006, Ingo Molnar wrote:
>
> so these results look pretty normal to me.
Ingo, Did you run this with high res turned off? That will simulate his
scenerio more so.
> Modified code attached below.
> (Change the '#if 1' to '#if 0' to get the select() measurement.)
Your code is almo
* tike64 <[EMAIL PROTECTED]> wrote:
> I made my test code visible if you want to take a look: www dot
> riihineva dot no-ip dot org uphill public uphill test-rt.c
on x86, with nanosleep i get:
# ./test-rt
100 revs; min: 5026 max: 5099 avg: 5062
100 revs; min: 5031 max: 5105 avg: 5065
100 re
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> So you got a big jitter using nanosleep??? If that's the case, could
> you post the times you got. I'll also boot a kernel with the latest
> -rt patch, without highres compiled, and see if I can reproduce the
> same on x86.
You're very kind! Here you go
On Thu, 14 Dec 2006, tike64 wrote:
> Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > ...
> > it's ok for the timer to be a little over, but it must never be a
> > little under.
> > ...
> > So we make sure the timer goes off in (n+1) ms, and not just (n).
Oops, that should have read (n+1) 10ms, or
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> ...
> it's ok for the timer to be a little over, but it must never be a
> little under.
> ...
> So we make sure the timer goes off in (n+1) ms, and not just (n).
Ok, this makes sense - thanks.
What confuses / confused me is that I have 4 combinations:
w
On Thu, 14 Dec 2006, tike64 wrote:
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > tike64 <[EMAIL PROTECTED]> wrote:
> > > Ok, understood; I tried this:
> > >
> > > t = raw_timer();
> > > ts.tv_nsec = 500;
> > > ts.tv_sec = 0;
> > > nanosleep(&ts, 0);
> > > t = raw_timer() - t;
> > >
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> tike64 <[EMAIL PROTECTED]> wrote:
> > Ok, understood; I tried this:
> >
> > t = raw_timer();
> > ts.tv_nsec = 500;
> > ts.tv_sec = 0;
> > nanosleep(&ts, 0);
> > t = raw_timer() - t;
> >
> > It is better but I still see 8ms occasiona
* tike64 <[EMAIL PROTECTED]> wrote:
> Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > Also, have you tried this with a nanosleep instead of a select.
> > Select's timeout is just that, a timeout. It's not suppose to be
> > accurate, as long as it doesn't expire early. The reason I state
> > this,
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Also, have you tried this with a nanosleep instead of a select.
> Select's timeout is just that, a timeout. It's not suppose to be
> accurate, as long as it doesn't expire early. The reason I state
> this, is that select uses a different mechanism than n
For -rt issues, please CC Ingo Molnar, and for High Res issues, please
CC Thomas Gleixner.
On Fri, 2006-12-01 at 01:07 -0800, tike64 wrote:
> > Hi,
> >
> > Without the support of High Resolution Timer
> > supported, the timer resolution wouldn't change.
>
> Ok, I understand that. I was not expe
> Hi,
>
> Without the support of High Resolution Timer
> supported, the timer resolution wouldn't change.
Ok, I understand that. I was not expecting more
resolution. I expected only that I would get more
precise 10ms delays. What confuses me is that the
delays roughly doubled.
> With high-resolu
From: tike64 <[EMAIL PROTECTED]>
Subject: realtime-preempt and arm
Date: Wed, 29 Nov 2006 00:57:05 -0800 (PST)
> Hi all,
>
> I'm trying the realtime-preempt patch-2.6.18-rt6 on
> lh7a400 arm system with little success. In a test
> program I try 5 ms timeout with select() b
Hi all,
I'm trying the realtime-preempt patch-2.6.18-rt6 on
lh7a400 arm system with little success. In a test
program I try 5 ms timeout with select() but get 20 ms
avg or 26 ms max. When the framebuffer scrolls, the
max delay goes up to 59 ms. With a vanilla kernel I
get 10 ms (because of
* Serge Noiraud <[EMAIL PROTECTED]> wrote:
> mardi 16 Août 2005 13:41, Mr Machine wrote/a écrit :
> > i get this error during compile of pci drivers:
> I have the same problem with rt1 and rt2.
i have fixed this in -rt4 (just uploaded).
> One 'bizarre' thing : If I patch directly 2.6.13.rc6 wi
* Mr Machine <[EMAIL PROTECTED]> wrote:
> i get this error during compile of pci drivers:
> if this helps, here's the realtime configuration section from my
> .config file:
could you send me the full .config file? That's the easiest way for me
to reproduce your build problem.
Ingo
-
mardi 16 Août 2005 13:41, Mr Machine wrote/a écrit :
> i get this error during compile of pci drivers:
>
>CC drivers/pci/access.o
>CC drivers/pci/bus.o
>CC drivers/pci/probe.o
>CC drivers/pci/remove.o
>CC drivers/pci/pci.o
>CC drivers/pci/quirks
i get this error during compile of pci drivers:
CC drivers/pci/access.o
CC drivers/pci/bus.o
CC drivers/pci/probe.o
CC drivers/pci/remove.o
CC drivers/pci/pci.o
CC drivers/pci/quirks.o
drivers/pci/quirks.c: In function ‘quirk_via_irq’:
drivers/pci/quirks.
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-08-04 at 15:52 +0200, Ingo Molnar wrote:
>
> > would be nice to clean up the impact of the latency-histogram code some
> > more though: e.g. the #ifdef jungle check_critical_timing() is
> > disgusting. Could be cleaned up by always reco
On Thu, 2005-08-04 at 15:52 +0200, Ingo Molnar wrote:
> would be nice to clean up the impact of the latency-histogram code some
> more though: e.g. the #ifdef jungle check_critical_timing() is
> disgusting. Could be cleaned up by always recording the latency_type
> being currently traced into a
* Yang Yi <[EMAIL PROTECTED]> wrote:
> > looks pretty good! I'll look at merging your patch after KS/OLS.
>
> Do you have any trouble while you merge that latency logger patch?
i've merged it to the -52-11 patch that, and i've uploaded it a couple
of minutes ago.
i have done a number of clean
>> Hi, Ingo
>>
>> This patch can record interrupt-off latency, preemption-off latency
>> and wakeup latency in a big history array, in the meanwhile, it
>> dummies up printks produced by these latency timing.
>looks pretty good! I'll look at merging your patch after KS/OLS.
>
> Ingo
Hi,
Daniel Walker wrote:
You can resolve it if you enable SMP .
Daniel
thanx - that's done it.
shayne
On Mon, 2005-08-01 at 08:18 +1000, Shayne O'Connor wrote:
trying to compile 2.6.13.rc4 with ingo's RT patch
(realtime-preempt-2.6.13-rc4-RT-V0.7.52-07) but keep get
Greetings Ingo;
I had to back away from this patch series in order to burn some cd's
about a week ago, the symptoms were that X got really slow, and then
hangs, but it does rapidly respond to a ctl-alt-backspace exit. I've
since built and tested -28, -33, -37 & am now on -38, and all seem to
Ingo,
I get the following compile error when using your patch
realtime-preempt-2.6.12-final-V0.7.51-33 on a x86_64 SMP system.
arch/x86_64/kernel/smpboot.c: 191: error: section of 'tsc_sync_lock'
conflicts with previous declaration.
It compiles fine if I don't set CONFIG_SMP=y,
* yangyi <[EMAIL PROTECTED]> wrote:
> Hi, Ingo
>
> This patch can record interrupt-off latency, preemption-off latency
> and wakeup latency in a big history array, in the meanwhile, it
> dummies up printks produced by these latency timing.
looks pretty good! I'll look at merging your patch af
Hi, Ingo
This patch can record interrupt-off latency, preemption-off latency and
wakeup latency in a big history array, in the meanwhile, it dummies up
printks produced
by these latency timing.
This patch adds three options: "Log interrupts-off critical section
latency", "Log non-preemptible cri
Vladimir V. Saveliev wrote:
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12/reiser4-for-2.6.12-realtime-preempt-2.6.12-final-V0.7.51-29.patch.gz
It applies to 2.6.12 +
http://people.redhat.com/mingo/realtime-preempt/older/realtime-preempt-2.6.12-final-V0.7.51-29
Ah, this is just what I
ssues, since he is the one maintaining the patch.
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12/reiser4-for-2.6.12-realtime-preempt-2.6.12-final-V0.7.51-29.patch.gz
It applies to 2.6.12 +
http://people.redhat.com/mingo/realtime-preempt/older/realtime-preempt-2.6.12-final-V0.7.51-29
-
To
On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
>
> I naively changed these two calls from
>
> init_MUTEX_LOCKED(&name);
>
> to
>
> init_MUTEX(&name);
> down(&name);
>
> but I'm not sure if that's right. I guess I'll see when I try to boot it!
No, since it probably wont be "uped" by
On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
> but I'm not sure if that's right. I guess I'll see when I try to boot it!
>
The standard fix is to make it a compat_semaphore. See the list
archives for details.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
Lee Revell wrote:
Maybe you could apply the broken out reiser4 patches from -mm and the
realtime preempt patches. Testing with PREEMPT_DESKTOP and latency
tracing enabled will tell you whether reiser4 has any latency hot spots.
I'm trying this now and it's not exactly trivial; t
Iain Duncan wrote:
yeah, i got this as well ... hasn't seemed to have any noticeable
effects, though.
Huh? Does that mean the kernel image is built anyway? I was under the
impression that it meant it didn't finish compiling? Am I confused?
If the error was in building a module that you do
Lee Revell wrote:
>On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
>
>
>>Ingo Molnar's realtime-preempt patches used to be based on the -mm
>>kernels, but now they appear to be based on the mainline kernels, so
>>they don't support reiser4 (
On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
> Ingo Molnar's realtime-preempt patches used to be based on the -mm
> kernels, but now they appear to be based on the mainline kernels, so
> they don't support reiser4 (at least until reiser4 is merged into
> main
Ingo Molnar's realtime-preempt patches used to be based on the -mm
kernels, but now they appear to be based on the mainline kernels, so
they don't support reiser4 (at least until reiser4 is merged into
mainline, which is looking uncertain as I understand it).
Is realtime-preempt-
> I've tried whether having nmi_watchdog has any influence, to no
> distinguishable result; readprofile always says zero times. And
> I'm sure I have LOCAL_APIC=y (see attached config.gz)
Damn, forgot the attachement. Here it goes.
Sorry.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
config-2.6
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> After several trials, with CONFIG_PROFILING=y and profile=1
>> nmi_watchdog=2 as boot parameters, I'm almost convinced I'm doing
>> something wrong :)
>>
>> - `readprofile` always just outputs one line:
>>
>> 0 total
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> After several trials, with CONFIG_PROFILING=y and profile=1
> nmi_watchdog=2 as boot parameters, I'm almost convinced I'm doing
> something wrong :)
>
> - `readprofile` always just outputs one line:
>
> 0 total
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> OTOH, I'll take this chance to show you something that is annoying me
>> for quite some time. Just look to the attached chart where I've marked
>> the spot with an arrow and a question mark. Its just one example of a
>> strange behavior/phenomenon
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> OTOH, I'll take this chance to show you something that is annoying me
>> for quite some time. Just look to the attached chart where I've marked
>> the spot with an arrow and a question mark. Its just one example of a
>> strange behavior/phenomenon
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> OTOH, I'll take this chance to show you something that is annoying me
> for quite some time. Just look to the attached chart where I've marked
> the spot with an arrow and a question mark. Its just one example of a
> strange behavior/phenomenon wh
>> -- - -
>> RT-V0.7.51-13 RT-V0.7.49-01
>> -- - -
>
>> Delay Maximum . . . . . . . . : 333 295 usecs
>> Cycle Maximum . . . . . . . .
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> OK.
>
> Just for the heads up, here goes todays summary results regarding my
> jack_test4.2 test suite against 2.6.12 kernels configured with
> PREEMPT_RT, but... now with 99.9% certainty :)
thanks for the testing!
> --
OK.
Just for the heads up, here goes todays summary results regarding
my jack_test4.2 test suite against 2.6.12 kernels configured with
PREEMPT_RT, but... now with 99.9% certainty :)
-- - -
RT-V0.7.51-13 RT-V0.
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> Hi all,
>>
>> These are one of my latest consolidated results while using (my)
>> jack_test4.2 suite, against a couple of 2.6.12 kernels patched for
>> PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop.
>>
>> See anything funny?
>
> hm, you dont seem
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i have just done a jack_test4.1 run, and indeed larger latencies seem
> to have crept in. (But i forgot to chrt the sound IRQ above the
> network IRQ, so i'll retest.)
with the sound irq chrt-ed to prio 90 the latencies look pretty good:
***
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> These are one of my latest consolidated results while using (my)
> jack_test4.2 suite, against a couple of 2.6.12 kernels patched for
> PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop.
>
> See anything funny?
hm, you dont seem to have
> Hi all,
>
> These are one of my latest consolidated results while using (my)
> jack_test4.2 suite, against a couple of 2.6.12 kernels patched for
> PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop.
>
> See anything funny?
>
> As it seems, the kernel latency performance is in some unfortunate
> regre
Hi all,
These are one of my latest consolidated results while using (my)
jack_test4.2 suite, against a couple of 2.6.12 kernels patched for
PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop.
See anything funny?
As it seems, the kernel latency performance is in some unfortunate
regression, and I'm ex
On Tue, 2005-07-05 at 18:13 -0700, William Weston wrote:
> Audio without xruns is an RT requirement, IMHO ;-}
>
This isn't even an opinion, it's a fact. If you are capturing data and
your audio handling thread does not get scheduled in (periods_per_buffer
- 1) * period_time time units, you lose
table but:
>
> 1) My logs are filled with Apic errors all like this
>
> Jul 5 04:30:01 linux kernel: APIC error on CPU0: 02(02)
>
> every 2 seconds, or minute, at random. I've never seen these messages
> before with vanilla kernels,
> so it's a bit weird.
Ha
Compilation stops at this point:
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
CHK include/linux/compile.h
CHK usr/initramfs_list
CC net/ipv4/netfilter/ip_conntrack_proto_tcp.o
net/ipv4/netfilter/ip_conntrack_proto_tcp.c: In function
`tcp_print_conntrack':
net/ipv4/
* Frank Rowand <[EMAIL PROTECTED]> wrote:
> I looked at all the architectures and found that the disparity of the
> type of the "lock" field in struct rwlock_t is even larger than I had
> indicated in my earlier email. I am attaching a proof of concept
> patch to handle this. If this looks l
Ingo Molnar wrote:
* Frank Rowand <[EMAIL PROTECTED]> wrote:
< more stuff deleted >
I'm working on the architecture support for realtime on PPC64 now. If
the lock field of struct raw_rwlock_t is a long instead of int then
/proc/meminfo shows MemFree decreasing from 485608 kB to 485352 kB.
Do yo
* Frank Rowand <[EMAIL PROTECTED]> wrote:
> < more stuff deleted >
>
> I'm working on the architecture support for realtime on PPC64 now. If
> the lock field of struct raw_rwlock_t is a long instead of int then
> /proc/meminfo shows MemFree decreasing from 485608 kB to 485352 kB.
>
> Do you h
Frank Rowand wrote:
Ingo Molnar wrote:
hi Frank - sorry about the late reply, was busy with other things. Your
My turn to be late, but now I'm back from vacation :-).
ppc patches look mostly mergeable, with some small details still open:
* Frank Rowand <[EMAIL PROTECTED]> wrote:
The patches are:
Hi,
I just noticed you've accepted a patch from Yang Yi dealing with interrupts
in the e1000 drivers on a PREEMPT_RT kernel. I did not yet understood the
problem but I blindly applied the same fix on the tg3 driver to get rid of the
following message :
network driver disabled interrupts: tg3_star
* Yang Yi <[EMAIL PROTECTED]> wrote:
> Hi ,Ingo
>
> this patch fixes e1000 driver disable interrupt bug when enabling
> "Complete Preemption (Realtime)".
thanks - applied it to the 41-12 tree.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
* Sven Dietrich <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> this patch turns off the preemptable BKL when
> either PREEMPT_VOLUNTARY or PREEMPT_NONE is selected.
thanks, added it to my tree.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
vious.
Thus it is also OK that you left this chunk out of your patch.
to drive things forward, i've applied the first 3 patches (except the
rt_lock.h chunk from the first patch), and released it as part of the
40-03 patch:
http://redhat.com/~mingo/realtime-preempt/
so that you can send foll
* K.R. Foley <[EMAIL PROTECTED]> wrote:
> >to drive things forward, i've applied the first 3 patches (except the
> >rt_lock.h chunk from the first patch), and released it as part of the
> >40-03 patch:
> >
> > http://redhat.com/~mingo/realtime-preemp
(except the
rt_lock.h chunk from the first patch), and released it as part of the
40-03 patch:
http://redhat.com/~mingo/realtime-preempt/
Is no one else having trouble compiling this one? The attached one liner
reverses a one line in the above patch.
kr
--- linux-2.6.11/include/linux/jbd.h.orig 20
except the
rt_lock.h chunk from the first patch), and released it as part of the
40-03 patch:
http://redhat.com/~mingo/realtime-preempt/
so that you can send followup patches based on this. Patches #4 and #5
are routed via the upstream PPC tree, so -RT should not carry them,
right?
I
On Fri, Mar 11, 2005 at 10:36:07AM +0100, Ingo Molnar wrote:
>
> * Scott Wood <[EMAIL PROTECTED]> wrote:
>
> > - p->prio = effective_prio(p);
> > + /* Don't overwrite an inherited RT priority with the static
> > + RT priority. */
> > +
> > + if (!rt_task(p))
> > + p->prio = e
* Scott Wood <[EMAIL PROTECTED]> wrote:
> - p->prio = effective_prio(p);
> + /* Don't overwrite an inherited RT priority with the static
> +RT priority. */
> +
> + if (!rt_task(p))
> + p->prio = effective_prio(p);
are you sure this is needed? The -RT code currentl
The following patch (against realtime-preempt v0.7.39-02) makes
setscheduler calls behave properly with respect to priority
inheritance. If a task's priority is raised, it will be propagated
to tasks on which it is blocked. If it is lowered, it will check
whether there's a higher pri
Ingo,
I have updated my patch of 16 Feb 2005 that adds realtime support for PowerPC
(32 bit only). The patches will be sent in following emails.
The patch series applies over Ingo's real-time preempt patch:
http://people.redhat.com/mingo/realtime-preempt/realtime-preempt-2.6.11-rc4-V0.7.
Hi ,Ingo
this patch fixes e1000 driver disable interrupt bug when enabling
"Complete Preemption (Realtime)".
Type: Defect Fix
Disposition: submitted to LKML
Signed-off-by: Yi Yang <[EMAIL PROTECTED]>
Description: When enabling Complete Real-time Preemption, e1000 driver
always disables interrupts
Ingo,
this patch turns off the preemptable BKL when
either PREEMPT_VOLUNTARY or PREEMPT_NONE is selected.
Signed-off-by: Sven-Thorsten Dietrich <[EMAIL PROTECTED]>
Index: linux-2.6.10-vaio/lib/Kconfig.RT
===
--- linux-2.6.10-vaio.
On Thu, Feb 17, 2005 at 05:01:39AM -0800, Frank Rowand wrote:
> Ingo Molnar wrote:
> > * Frank Rowand <[EMAIL PROTECTED]> wrote:
> > - could you submit the drivers/net/ibm_emac/ibm_emac_core.c patch
> > upstream as well?
>
> Yes, I will do that.
This one is already mainline, was posted a week o
Ingo Molnar wrote:
* Frank Rowand <[EMAIL PROTECTED]> wrote:
I have attached a patch to add realtime support for PowerPC (32 bit
only). [...]
two comments:
- why is us_to_tb needed? It just seems to add alot of unnecessary
clutter to the patch, while it's not used anywhere.
Sorry, the usage of
* Frank Rowand <[EMAIL PROTECTED]> wrote:
> I have attached a patch to add realtime support for PowerPC (32 bit
> only). [...]
two comments:
- why is us_to_tb needed? It just seems to add alot of unnecessary
clutter to the patch, while it's not used anywhere.
- could you submit the drivers/n
mingo/realtime-preempt/realtime-preempt-2.6.11-rc4-V0.7.39-02
This patch has been tested on the IBM PPC 405GP eval board only.
You might notice that this board is not an SMP board. A few small
changes were required to build an SMP kernel, even though only one cpu
is actually active. I can sup
Hi !
Attached patch incorporates real-time preempt support for MIPS. This patch
applies over
Ingo's real-time preempt patch:
http://people.redhat.com/mingo/realtime-preempt/realtime-preempt-2.6.11-rc2-V0.7.37-01
This patch has been tested on the Broadcom Sibyte (UP and SMP) and the
On Mon, 2005-01-24 at 20:47 -0800, John Gilbert wrote:
> Xv isn't supported. DRI isn't supported.
> ATI (and NVIDIA) should be all over the hard-realtime kernel, as this
> has the potential of making video and games frame accurate (never
> missing frames, no page tears).
> The documentation from
Hello all,
Here are two patches that are needed to get this working. It's not
perfect, but quake3 runs, bzflag runs, noof runs, and that's a start.
So here's the recipe...
Linux-2.6.10 source
the linux-2.6.11-rc2 patch
the realtime-preempt-2.6.11-rc2-V0.7.36-03 patch
the fglrx
81 matches
Mail list logo
