20 Sep
2006
20 Sep
'06
1:55 p.m.
Hi,
I'm having problems booting realtime kernels on two different machines.
One is an IBM Thinkpad X21 with a 700MHz P3, the other one is a desktop
machine with an AMD Duron, also at 700MHz.
Apart from the fact that both machines are about the same age, they don't
seem to have much in common. However, both fail to boot at the same
point.
On both machines, the last messages of the kernel of are along the lines
of:
PCI: Found IRQ 10 for device 0000:00:08.0
PCI: Sharing IRQ 10 with 0000:00:0b.0
PCI: Sharing IRQ 10 with 0000:01:00.0
PCI: Found IRQ 5 for device 0000:00:08.1
NET: Registered protocol family 2
Then it just stops. I've tried many different kernel versions (2.6.17-rt8,
2.6.17-rt5, even as far back as 2.6.13-rt14), to no avail. I also tried
turning ACPI and APIC on/off, which didn't help either. Now I'm at a
loss... The same kernels boot just fine on a more recent machine.
What else can I try, or how do I find out where exactly (and why) it
hangs? Is anyone successfully running a realtime kernel on a similarly old
machine?
Thanks,
Dominic
20 Sep
20 Sep
2:06 p.m.
Apart from the fact that both machines are about the
same age, they don't
seem to have much in common. However, both fail to boot at the same
point.
NET: Registered protocol family 2
Then it just stops. I've tried many different kernel versions (2.6.17-rt8,
2.6.17-rt5, even as far back as 2.6.13-rt14), to no avail. I also tried
turning ACPI and APIC on/off, which didn't help either. Now I'm at a
loss... The same kernels boot just fine on a more recent machine.
What else can I try, or how do I find out where exactly (and why) it
hangs?
you can try adding kernel arguments like: noapic, nolapic, noacpi, irqpoll (not all at
once)
you can try changing the kernel config. irq polling styles (at-apic vs acpi is it?) cpu
types (i386 vs Athlon), scheduler types (cfq vs this vs that)
if you find out how to debug a frozen kernel (ie, doesnt even get a chance to print a
backtrace) let us know. ive been tryin out ingo's kernel every 6 month or so for the
past couple of years on a few differet amd64 rigs using the above techniques. so far it
always blackscreens/reboots right after grub, freezes during boot, or freezes anywhere
from 3 to 20 minutes after booting regardless of load. i dont want to say the above
techniques are a total waste of time, as they do tend to change when it freezes from eg,
right after grub, to later on, etc. so theyre doing something..
Is anyone successfully running a realtime kernel on a similarly old
machine?
Thanks,
Dominic
2:19 p.m.
On Wed, 2006-09-20 at 16:11 +0000, carmen wrote:
if you find out how to debug a frozen kernel (ie,
doesnt even get a
chance to print a backtrace) let us know. ive been tryin out ingo's
kernel every 6 month or so for the past couple of years on a few
differet amd64 rigs using the above techniques. so far it always
blackscreens/reboots right after grub, freezes during boot, or freezes
anywhere from 3 to 20 minutes after booting regardless of load. i dont
want to say the above techniques are a total waste of time, as they do
tend to change when it freezes from eg, right after grub, to later on,
etc. so theyre doing something..
Works perfectly here for months on a dual core AMD64. Probably a
bad .config. Try disabling all kernel debugging options.
Lee
4:18 p.m.
On Wed, 2006-09-20 at 16:11 +0000, carmen wrote:
if you find out how to debug a frozen kernel (ie,
doesnt even get a chance to print a backtrace) let us know. ive been tryin out ingo's
kernel every 6 month or so for the past couple of years on a few differet amd64 rigs using
the above techniques. so far it always blackscreens/reboots right after grub, freezes
during boot, or freezes anywhere from 3 to 20 minutes after booting regardless of load. i
dont want to say the above techniques are a total waste of time, as they do tend to change
when it freezes from eg, right after grub, to later on, etc. so theyre doing something..
same here with 2.6.17-rt8 and a dual opteron system. removing kernel/RT
debugging improves things, but not so much that the system will run for
long. its a bit sad.
4:47 p.m.
On Wed, 2006-09-20 at 14:17 -0400, Paul Davis wrote:
On Wed, 2006-09-20 at 16:11 +0000, carmen wrote:
2.6.18-rt2 is out now, it's worth a try.
I'd be interested to see if the problem can be reproduced with
the .config I posted. Neither I nor the 64studio guys nor any of their
users can reproduce these problems at all.
Lee
if you find out how to debug a frozen kernel (ie,
doesnt even get a chance to print a backtrace) let us know. ive been tryin out ingo's
kernel every 6 month or so for the past couple of years on a few differet amd64 rigs using
the above techniques. so far it always blackscreens/reboots right after grub, freezes
during boot, or freezes anywhere from 3 to 20 minutes after booting regardless of load. i
dont want to say the above techniques are a total waste of time, as they do tend to change
when it freezes from eg, right after grub, to later on, etc. so theyre doing something..
same here with 2.6.17-rt8 and a dual opteron system. removing kernel/RT
debugging improves things, but not so much that the system will run for
long. its a bit sad.
5:12 p.m.
2.6.18-rt2 is out now, it's worth a try.
I'd be interested to see if the problem can be reproduced with
the .config I posted. Neither I nor the 64studio guys nor any of their
users can reproduce these problems at all.
is said .config in the list archives? interested in trying it out..
Lee
5:18 p.m.
On Wed, 2006-09-20 at 19:18 +0000, carmen wrote:
Oh, right, it was queued for being over the size limit. I mailed it to
you off list.
Lee
2.6.18-rt2 is
out now, it's worth a try.
I'd be interested to see if the problem can be reproduced with
the .config I posted. Neither I nor the 64studio guys nor any of their
users can reproduce these problems at all.
is said .config in the list archives? interested in trying it out.. 
5:43 p.m.
On 9/20/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
2.6.18-rt2 is out now, it's worth a try.
I'd be interested to see if the problem can be reproduced with
the .config I posted. Neither I nor the 64studio guys nor any of their
users can reproduce these problems at all.
Lee
2.6.18-rt2 doesn't boot on my AMD64 machine.
2.6.17-rt5 is fine. 2.6.17-rt8 is unreliable booting for me.
I'd suggesting giving Ingo a few days to work through the initial
reports before anyone do *too* much work with the 2.6.18-rt stuff.
Just my thoughts.
Cheers,
Mark
5:52 p.m.
On Wed, 2006-09-20 at 12:43 -0700, Mark Knecht wrote:
On 9/20/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
On the bright side, 2.8.18-rt* is the first -rt patch since 2.6.13 or so
to be *smaller* than the previous one, due to many -rt only features
going into mainline for 2.6.18. Hopefully this trend will continue...
Lee
2.6.18-rt2 is out now, it's worth a try.
I'd be interested to see if the problem can be reproduced with
the .config I posted. Neither I nor the 64studio guys nor any of their
users can reproduce these problems at all.
Lee
2.6.18-rt2 doesn't boot on my AMD64 machine.
2.6.17-rt5 is fine. 2.6.17-rt8 is unreliable booting for me.
I'd suggesting giving Ingo a few days to work through the initial
reports before anyone do *too* much work with the 2.6.18-rt stuff.
Just my thoughts.
6:54 p.m.
On 9/20/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Wed, 2006-09-20 at 12:43 -0700, Mark Knecht wrote:
Yeah, one can only hope!
I'm now writing you from my first booting 2.6.18-rt3 on AMD64. Still
many issues. Traces showing up in dmesg. For some reason all the
modules got built into the kernel. It seems that the make oldconfig
process failed me, but still:
mark@lightning ~ $ uname -a
Linux lightning 2.6.18-rt3 #1 SMP PREEMPT Wed Sep 20 13:14:06 PDT 2006
x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
mark@lightning ~ $
It's a start!
- Mark
On 9/20/06, Lee Revell
<rlrevell(a)joe-job.com> wrote:
On the bright side, 2.8.18-rt* is the first -rt patch since 2.6.13 or so
to be *smaller* than the previous one, due to many -rt only features
going into mainline for 2.6.18. Hopefully this trend will continue...
2.6.18-rt2 is out now, it's worth a try.
I'd be interested to see if the problem can be reproduced with
the .config I posted. Neither I nor the 64studio guys nor any of their
users can reproduce these problems at all.
Lee
2.6.18-rt2 doesn't boot on my AMD64 machine.
2.6.17-rt5 is fine. 2.6.17-rt8 is unreliable booting for me.
I'd suggesting giving Ingo a few days to work through the initial
reports before anyone do *too* much work with the 2.6.18-rt stuff.
Just my thoughts.
10:21 p.m.
On 9/20/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Wed, 2006-09-20 at 13:42 -0700, Mark Knecht wrote:
Lee,
They were sent to the LKML where they should be sent. No reason to
post them here in my mind.
Mark
Traces showing up in dmesg.
It would be useful to see them...
Lee 
23 Sep
23 Sep
2:23 p.m.
On Wed, 2006-09-20 at 15:54 -0400, Lee Revell wrote:
On Wed, 2006-09-20 at 12:43 -0700, Mark Knecht wrote:
I don't know if you've seen this or not, but that is definitely the
plan:
http://www.internetnews.com/dev-news/article.php/3627831
Dana
On 9/20/06, Lee Revell
<rlrevell(a)joe-job.com> wrote:
On the bright side, 2.8.18-rt* is the first -rt patch since 2.6.13 or so
to be *smaller* than the previous one, due to many -rt only features
going into mainline for 2.6.18. Hopefully this trend will continue...
Lee
2.6.18-rt2 is out now, it's worth a try.
I'd be interested to see if the problem can be reproduced with
the .config I posted. Neither I nor the 64studio guys nor any of their
users can reproduce these problems at all.
Lee
2.6.18-rt2 doesn't boot on my AMD64 machine.
2.6.17-rt5 is fine. 2.6.17-rt8 is unreliable booting for me.
I'd suggesting giving Ingo a few days to work through the initial
reports before anyone do *too* much work with the 2.6.18-rt stuff.
Just my thoughts.
20 Sep
20 Sep
4:34 p.m.
On Wednesday, 20. September 2006 18:11, carmen wrote:
you can try adding kernel arguments like: noapic,
nolapic, noacpi,
irqpoll (not all at once)
Well, most of my efforts so far revolved around these kernel arguments,
but none of them makes any difference (except for acpi=off, whithout
which the thinkpad hangs even earlier).
you can try changing the kernel config. irq polling
styles (at-apic vs
acpi is it?) cpu types (i386 vs Athlon), scheduler types (cfq vs this
vs that)
All this doesn't seem to help either, unfortunately :/
One more thing I've noticed: It doesn't matter if the kernel is actually
compiled with realtime preemption enabled. Just patching a vanilla kernel
and then configuring it for "Low-Latency Desktop" will produce a kernel
that does not boot...
Dominic
21 Sep
21 Sep
6:28 p.m.
On Wednesday, 20. September 2006 17:52, I wrote:
PCI: Found IRQ 10 for device 0000:00:08.0
PCI: Sharing IRQ 10 with 0000:00:0b.0
PCI: Sharing IRQ 10 with 0000:01:00.0
PCI: Found IRQ 5 for device 0000:00:08.1
NET: Registered protocol family 2
Then it just stops. I've tried many different kernel versions
(2.6.17-rt8, 2.6.17-rt5, even as far back as 2.6.13-rt14), to no avail.
I also tried turning ACPI and APIC on/off, which didn't help either.
Now I'm at a loss... The same kernels boot just fine on a more recent
machine.
I've finally found a kernel that works on both machines: 2.6.18-rt3! It's
far from stable, but at least it boots, unlike all the previous versions
I've tried. Now I can only hope that the remaining issues will be resolved
in future versions of 2.6.18-rt...
6:32 p.m.
On Thu, 2006-09-21 at 22:24 +0200, Dominic Sacré wrote:
On Wednesday, 20. September 2006 17:52, I wrote:
What's wrong with it? People keep making these vague statements that
the -rt kernel is unstable, but I haven't seen any details.
Lee
PCI: Found IRQ 10 for device 0000:00:08.0
PCI: Sharing IRQ 10 with 0000:00:0b.0
PCI: Sharing IRQ 10 with 0000:01:00.0
PCI: Found IRQ 5 for device 0000:00:08.1
NET: Registered protocol family 2
Then it just stops. I've tried many different kernel versions
(2.6.17-rt8, 2.6.17-rt5, even as far back as 2.6.13-rt14), to no avail.
I also tried turning ACPI and APIC on/off, which didn't help either.
Now I'm at a loss... The same kernels boot just fine on a more recent
machine.
I've finally found a kernel that works on both machines: 2.6.18-rt3! It's
far from stable, but at least it boots, unlike all the previous versions
I've tried. Now I can only hope that the remaining issues will be resolved
in future versions of 2.6.18-rt...
7:13 p.m.
On Thursday, 21. September 2006 22:33, Lee Revell wrote:
What's wrong with it? People keep making these
vague statements that
the -rt kernel is unstable, but I haven't seen any details.
I'm not saying -rt is unstable per se, I've been running realtime kernels
on my main desktop machine for more than a year, with little problems.
However, 2.6.18-rt3 is not working very well so far. For one thing, the
e100 network driver seems to be broken (it compiles and loads, but it's
not functional). Also, dmesg is full of call traces.
I'm sure things will improve in future versions, and in the meantime I'll
try to gather some more info/call traces and report it.
Dominic
8:03 p.m.
On Thu, 2006-09-21 at 23:07 +0200, Dominic Sacré wrote:
On Thursday, 21. September 2006 22:33, Lee Revell
wrote:
What's wrong with it? People keep making
these vague statements that
the -rt kernel is unstable, but I haven't seen any details.
I'm not saying -rt is unstable per se, I've been running realtime kernels
on my main desktop machine for more than a year, with little problems.
However, 2.6.18-rt3 is not working very well so far. For one thing, the
e100 network driver seems to be broken (it compiles and loads, but it's
not functional). Also, dmesg is full of call traces.
I'm sure things will improve in future versions, and in the meantime I'll
try to gather some more info/call traces and report it.
They won't improve in future versions if you don't report the bugs.
Please don't assume that every bug you hit is already known.
Lee
10:01 p.m.
On 9/21/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
<SNIP>
What's wrong with it? People keep making these vague statements that
the -rt kernel is unstable, but I haven't seen any details.
Lee
While I don't think this is the venue to report this stuff since you
asked, and since you are a person who helps fix things:
) I had these messages in dmesg (already sent to LKML)
EXT3-fs: mounted filesystem with ordered data mode.
Adding 2008084k swap on /dev/sda10. Priority:-1 extents:1 across:2008084k
eth0: no IPv6 routers present
BUG: time warp detected!
prev > now, 1014d39b1fe7c3e8 > 1014d39b063d8631:
= 430587319 delta, on CPU#0
Call Trace:
[<ffffffff8020b15c>] dump_stack+0x12/0x17
[<ffffffff8023ba68>] getnstimeofday+0x131/0x13c
[<ffffffff80247bfa>] ktime_get_ts+0x1a/0x4e
[<ffffffff8022ffac>] copy_process+0x449/0x159c
[<ffffffff802312e7>] do_fork+0xd0/0x1d4
[<ffffffff80209c7b>] ptregscall_common+0x67/0xac
DWARF2 unwinder stuck at ptregscall_common+0x67/0xac
Leftover inexact backtrace:
---------------------------
| preempt count: 00000000 ]
| 0-level deep critical section nesting:
----------------------------------------
2) (Not sent to LKML) Using 2.6.18-rt3 the machine hard crashes when
exiting from Gnome back to the gdm login screen. The machine is down
hard and would not even respond to ssh login attempts. I was using the
ati-driver-8.28.8 driver which is most likely the culprit. I was not
motivated enough though to muck around with my xorg.config files to
try the kernel's radeon driver. I hope to look at that this weekend.
If the radeon driver crashes I will send that info on to the LKML.
(And I suppose here since you want to see it!) ;-)
I am currently back to running 2.6.17-rt5.
Cheers,
Mark
22 Sep
22 Sep
1:43 a.m.
On Thu, 2006-09-21 at 17:01 -0700, Mark Knecht wrote:
I was using the
ati-driver-8.28.8 driver which is most likely the culprit.
The LKML guys won't help you if you're using binary drivers; make sure
you were using the open source driver if you post bug reports.
Lee
2:45 a.m.
On 9/21/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Thu, 2006-09-21 at 17:01 -0700, Mark Knecht wrote:
Lee,
Candidly it's not the least bit important to me at all if they want
to help or not. If I run into a problem, and it's clearly a kernel
problem, then I report it. I understand that there have been many
issues with the ati-drivers in the past. that's always the way it is
with the ATI stuff. I hate it, but I cannot change it.
I don't and won't be running this kernel any time soon. Ingo put it
out there and *he* asked people to test it. He doesn't get to pick how
we test it and in fact he doesn't place any restrictions on how we
test it. If he doesn't want to work on a bug that's reported then
that's completely his business. Not a problem for me. He picks what he
works on. I pick what I report.
I'm not gonna run 2.6.18-rtX for months I'm sure.
None the less, you asked for a report here so hopefully I've given
you what you wanted.
Cheers,
Mark
I was using the
ati-driver-8.28.8 driver which is most likely the culprit.
The LKML guys won't help you if you're using binary drivers; make sure
you were using the open source driver if you post bug reports.
Lee 
7:52 a.m.
On Friday 22 September 2006 06:45, Mark Knecht wrote:
Candidly it's not the least bit important to me
at all if they want
to help or not. If I run into a problem, and it's clearly a kernel
problem, then I report it. I understand that there have been many
issues with the ati-drivers in the past. that's always the way it is
with the ATI stuff. I hate it, but I cannot change it.
I don't and won't be running this kernel any time soon. Ingo put it
out there and *he* asked people to test it. He doesn't get to pick how
we test it and in fact he doesn't place any restrictions on how we
test it. If he doesn't want to work on a bug that's reported then
that's completely his business. Not a problem for me. He picks what he
works on. I pick what I report.
I'm not gonna run 2.6.18-rtX for months I'm sure.
None the less, you asked for a report here so hopefully I've given
you what you wanted.
Well, if you use a closed source driver, there's no way for Ingo to fix it.
Period. That's why noone will look at it. The place to report kernel troubles
to, when using closed source drivers, is the provider of these kernel
drivers. In this case ATI.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
11:43 a.m.
On 9/22/06, Florian Schmidt <mista.tapas(a)gmx.net> wrote:
<SNIP>
Well, if you use a closed source driver, there's
no way for Ingo to fix it.
Period. That's why noone will look at it. The place to report kernel troubles
to, when using closed source drivers, is the provider of these kernel
drivers. In this case ATI.
Regards,
Flo
Flo,
Please read the thread.
This conversation is just silly and a waste of time. Just because
an ATI driver is on the machine doesn't mean you don't report a
problem with the with the kernel to Ingo. What about when I boot the
machine, the kernel has a problem at boot time and I'm not even in X?
What about when the ATI driver isn't being loaded and the machine is
in text mode? What about when I *do* have the ATI driver loaded and
the problem is clearly kernel related? This conversation is just silly
and a waste of time.
As I stated earlier, I do not report problems to Ingo that are ATI
driver related. I did not report this specific problem (machine
crashed when exiting X) to him since it was possibly ATI related. I
reported other problems. Please read the thread.
- Mark
12:08 p.m.
On Fri, 2006-09-22 at 06:43 -0700, Mark Knecht wrote:
This conversation is just silly and a waste of time.
Just because
an ATI driver is on the machine doesn't mean you don't report a
problem with the with the kernel to Ingo.
Yes, it does, if it's a binary only driver. Drivers are part of the
kernel and if a closed source driver has been loaded the kernel cannot
be debugged.
This isn't my opinion, it's consensus on LKML. Bug reports from tainted
kernels will be ignored.
Lee
1:38 p.m.
On Friday 22 September 2006 15:43, Mark Knecht wrote:
On 9/22/06, Florian Schmidt
<mista.tapas(a)gmx.net> wrote:
<SNIP>
No, it's not. There's an important point to be made.
Well, if you use a closed source driver,
there's no way for Ingo to fix
it. Period. That's why noone will look at it. The place to report kernel
troubles to, when using closed source drivers, is the provider of these
kernel drivers. In this case ATI.
Regards,
Flo
This conversation is just silly and a waste of time. Just because
an ATI driver is on the machine doesn't mean you don't report a
problem with the with the kernel to Ingo.
It exactly does mean that, because he will ignore the bug report for good
reasons.
What about when I boot the
machine, the kernel has a problem at boot time and I'm not even in X?
What about when the ATI driver isn't being loaded and the machine is
in text mode? What about when I *do* have the ATI driver loaded and
the problem is clearly kernel related? This conversation is just silly
and a waste of time.
Well, if the ATI driver isn't loaded and the kernel shows a bug, then report
it.
As I stated earlier, I do not report problems to
Ingo that are ATI
driver related. I did not report this specific problem (machine
crashed when exiting X) to him since it was possibly ATI related. I
reported other problems. Please read the thread.
The problem with closed source drivers is:
There's no process seperation between different parts of the kernel. Any part
of the kernel can write memory anywhere else in the kernel. If i wanted to, i
could write a kernel module that simply overwrites the whole kernel in RAM
with 0's.
If you have a closed source kernel module it could be a bad one. It could do
something really bad and there could be bugs showing up that _look_ like they
are caused by some other part of the kernel, but really they are produced by
the closed source driver. As there's no way to find out, as the driver is
closed source, it is a simple manner of efficiency to simply rule this out,
by simply not caring about bug reports with closed source drivers loaded.
So, if you think the kernel has a problem, run your setup without the closed
source driver. If the problem can be reproduced -> Great, you found a bug
that can be fixed. If it cannot be reproduced -> too bad, it seems your
closed source driver might be faulty -> report to the closed source driver
author.
I hope this clears the issue up a bit..
Regards,
Flo
P.S.: using closed source drivers with -rt kernels is asking for trouble
anyways, as the -rt model relies on rewriting parts of the kernel (by
altering macros, inline functions, etc.). The closed source binary driver
cannot be altered in the same way. Thus it is highly probable, that bad
things might happen if running a closed source driver.
--
Palimm Palimm!
http://tapas.affenbande.org
2:29 p.m.
On 9/22/06, Florian Schmidt <mista.tapas(a)gmx.net> wrote:
<SNIP>
So, if you think the kernel has a problem, run your setup without the closed
source driver. If the problem can be reproduced -> Great, you found a bug
that can be fixed. If it cannot be reproduced -> too bad, it seems your
closed source driver might be faulty -> report to the closed source driver
author.
I hope this clears the issue up a bit..
Regards,
Flo
OK. To make you guys happy I rebuilt 2.6.18-rt3 with radeon and DRI
support turned on. The kernel did not boot. It hung immediately saying
it couldn't find the hard drive.
That's the only change I made.
Interesting....
NOTE: I'm no programmer. I understand your description above, but I
also understand the description of others who say since the interface
portion that goes between the kernel and the binary portion compiles
OK then it's OK to use the ATI Driver. Clearly there are differing
opinions out there and no reason for stupid simpleton me to know who's
right and who's wrong. Please excuse my technical ignorance. Note
however that there is *no* debate that there are Open Source zealots
all over these lists who revel in telling people they are simply
*wrong* for using closed source drivers no matter what the reason.
Again, there is no way for me to know where anyone comes down on that
subject unless they make their person views known.
NOTE 2: Back on 2.6.17-rt5 (since it does boot) I see
**significantly** less CPU usage with the Open Source Radeon driver
than with the ATI driver. (9% vs. 90%) After rebuilding my AMD64
machine with gcc-4.1.1 the CPU usage in MythTV went through the roof.
I had wondered if it had anything to do with the ATI driver and was
thinking about trying the radeon driver this weekend. It's done now
and nice to have it lower again with the radeon driver. I also see
lower frame rate from the close source driver but I can live with
that.
- Mark
2:47 p.m.
On Fri, 2006-09-22 at 09:29 -0700, Mark Knecht wrote:
Note
however that there is *no* debate that there are Open Source zealots
all over these lists who revel in telling people they are simply
*wrong* for using closed source drivers no matter what the reason.
Again, there is no way for me to know where anyone comes down on that
subject unless they make their person views known.
Understood. I for one am coming from a 100% technical POV and dislike
zealotry and people who make free software a political/religious issue.
The point is not whether the ATI driver is likely to work, or whether
you should be using it - it's only that for the specific purpose of
kernel debugging, closed source drivers cannot be present for purely
technical reasons.
Lee
2:55 p.m.
On 9/22/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Fri, 2006-09-22 at 09:29 -0700, Mark Knecht wrote:
Understood. Thanks. If the radeon driver continues to work then I'd be
happy to use it. Currently I have no errors but I do have warnings
about DRM support for Radeon 9500 and higher. Probably not a big deal
for me.
Now, if I Can find some time I'll try to report 2.6.18-rt3 not booting.
- Mark
Note
however that there is *no* debate that there are Open Source zealots
all over these lists who revel in telling people they are simply
*wrong* for using closed source drivers no matter what the reason.
Again, there is no way for me to know where anyone comes down on that
subject unless they make their person views known.
Understood. I for one am coming from a 100% technical POV and dislike
zealotry and people who make free software a political/religious issue.
The point is not whether the ATI driver is likely to work, or whether
you should be using it - it's only that for the specific purpose of
kernel debugging, closed source drivers cannot be present for purely
technical reasons.
Lee
2:50 p.m.
On Fri, 2006-09-22 at 09:29 -0700, Mark Knecht wrote:
OK. To make you guys happy I rebuilt 2.6.18-rt3 with
radeon and DRI
support turned on. The kernel did not boot. It hung immediately saying
it couldn't find the hard drive.
Is it an SMP kernel? If so, do you have better results with SMP
disabled?
Lee
2:58 p.m.
On 9/22/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Fri, 2006-09-22 at 09:29 -0700, Mark Knecht wrote:
It is not an SMP kernel and the ONLY change I made was to enable the
radeon driver and DRI. Since DRI isn't working for my ATI chipset I
will try turning that off and rebuilding again.
The message was the one you get when the kernel cannot find the
drives, generally because you forgot to build in ext3 support..
Something like drive not found - VFS not syncing.
- Mark
OK. To make you guys happy I rebuilt 2.6.18-rt3
with radeon and DRI
support turned on. The kernel did not boot. It hung immediately saying
it couldn't find the hard drive.
Is it an SMP kernel? If so, do you have better results with SMP
disabled?
Lee 
1:43 p.m.
On Thu, Sep 21, 2006 at 04:33:51PM -0400, Lee Revell wrote:
What's wrong with it? People keep making these
vague statements that
the -rt kernel is unstable, but I haven't seen any details.
When I tried 2.6.17-rt2 on a machine with a heavy load (uptime would
report from 2.7 to over 3.0, top would show one process consistantly
using about 70% of the CPU power) the machine would lock up without
printing out a single warning, trace, or giving any evidence about what
it was that locked up. There was nothing printed to the serial console
that I could go on. So, any complaints I could make about it would be
vague. I could describe the system load, but it would probably be
atypical for most linux audio people. Further, I had also patched the
kernel with a non-official bigphysarea patch.
--
Joshua D. Boyd
jdboyd(a)jdboyd.net
http://www.jdboyd.net/
http://www.joshuaboyd.org/
25 Sep
25 Sep
3:17 p.m.
On Fri, Sep 22, 2006 at 11:53:20AM -0400, Lee Revell wrote:
On Fri, 2006-09-22 at 11:27 -0400, Joshua Boyd wrote:
No crashes so far. If I add the bigphysarea patch but don't run the
video application, I also don't seem to get any crashes either. It
isn't feasible to run the video application without bigphys area
though.
This is at work. I'm using a AJA Oem HS video card (like their Xena XS
card for Windows) using driver's supplied by AJA, along with the source
code. So, not as bad as ATI or Nvidia, but still not great. However,
there is no similar product supported by any sort of open source
drivers.
--
Joshua D. Boyd
jdboyd(a)jdboyd.net
http://www.jdboyd.net/
http://www.joshuaboyd.org/
Further, I had also patched the
kernel with a non-official bigphysarea patch.
What happens if you don't do that? 
23 Sep
23 Sep
6:41 a.m.
On Wednesday 20 September 2006 16:52, Dominic Sacré was like:
Is anyone successfully running a realtime kernel on a
similarly old
machine?
Yes. Various kernels from 2.4 to current using both realtime-lsm and patched
PAM successfully.
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
We are the people We've been waiting for.
6662
days inactive
6667
days old
linux-audio-user@lists.linuxaudio.org
33 comments
9 participants
participants (9)
-
carmen -
Dana Olson -
Dominic Sacré -
Florian Schmidt -
Joshua Boyd -
Lee Revell -
Mark Knecht -
Paul Davis -
tim hall