17 Oct
2005
17 Oct
'05
7:38 a.m.
Hi to the list,
I'm running the 2.6.14-rc4 kernel with realtime-preemption (rt1) patch
on a debian testing/unstable.
I was trying to create a simple sessione with lash, lash_synth and
patchage but qjackctl died suddenly. In syslog I've found the "stack
trace" of the kernel due to a bug, something that begins with:
localhost kernel: BUG: Unable to handle kernel paging request at
virtual address 00100100
and then continues for more or less 100 lines of additional
informations. Looking in syslog I've found also another 2 o 3
_different_ bugs: they are all audio related.
Are those syslog information useful for debugging? How and where should
I report them?
Now I will try If I can reproduce the bug with the vanilla 2.6.13 kernel
and/or with the 2.6.14-rc3-rt2 that I've previously compiled.
Best Regards,
~ Antonio
17 Oct
17 Oct
8:58 a.m.
On 10/17/05, Antonio <debian(a)fastwebnet.it> wrote:
Hi to the list,
I'm running the 2.6.14-rc4 kernel with realtime-preemption (rt1) patch
on a debian testing/unstable.
I was trying to create a simple sessione with lash, lash_synth and
patchage but qjackctl died suddenly. In syslog I've found the "stack
trace" of the kernel due to a bug, something that begins with:
localhost kernel: BUG: Unable to handle kernel paging request at
virtual address 00100100
and then continues for more or less 100 lines of additional
informations. Looking in syslog I've found also another 2 o 3
_different_ bugs: they are all audio related.
Are those syslog information useful for debugging? How and where should
I report them?
Now I will try If I can reproduce the bug with the vanilla 2.6.13 kernel
and/or with the 2.6.14-rc3-rt2 that I've previously compiled.
QjackCtl is running fine here on 2.6.14-rc4-rt6 on AMD64. I'd suggest
that you update to the very latest stuff that Ingo has released, try
again, and then report any problems on LKML. They will require that
you do that if you want any real support anyway...
You might also try rebuilding Jack against that kernel just to be sure.
Cheers,
Mark
10:58 a.m.
On Mon, 2005-10-17 at 03:58 -0700, Mark Knecht wrote:
[cut]
QjackCtl is running fine here on 2.6.14-rc4-rt6 on
AMD64. I'd suggest
that you update to the very latest stuff that Ingo has released, try
again, and then report any problems on LKML. They will require that
you do that if you want any real support anyway...
Ok... I had not noted the new version. In the mean time I've tried with
the vanilla 2.6.13.2 kernel and I don't have any bug with it.
You might also try rebuilding Jack against that kernel
just to be sure.
By now I'm using jack 0.100 from unstable. Will see with the latest rt
patch.
Cheers,
Mark
Best Regards,
~ Antonio
12:18 p.m.
Antonio,
There is a fix this morning in -rt7 that has something to do with
QJackCtl. While I wasn't seeing the problem possibly you are?
Anyway, watch Ingo's page for releases of interest.
Cheers,
Mark
On 10/17/05, Antonio <debian(a)fastwebnet.it> wrote:
On Mon, 2005-10-17 at 03:58 -0700, Mark Knecht wrote:
[cut]
QjackCtl is running fine here on 2.6.14-rc4-rt6
on AMD64. I'd suggest
that you update to the very latest stuff that Ingo has released, try
again, and then report any problems on LKML. They will require that
you do that if you want any real support anyway...
Ok... I had not noted the new version. In the mean time I've tried with
the vanilla 2.6.13.2 kernel and I don't have any bug with it.
You might also try rebuilding Jack against that
kernel just to be sure.
By now I'm using jack 0.100 from unstable. Will see with the latest rt
patch.
Cheers,
Mark
Best Regards,
~ Antonio
12:09 p.m.
Mark Knecht <markknecht(a)gmail.com> writes:
You might also try rebuilding Jack against that kernel
just to be
sure.
This should not be necessary, under any circumstances;). This is my
understanding.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
12:41 p.m.
Hi Mark,
On Mon, 2005-10-17 at 03:58 -0700, Mark Knecht wrote:
[cut]
QjackCtl is running fine here on 2.6.14-rc4-rt6 on
AMD64. I'd suggest
that you update to the very latest stuff that Ingo has released, try
again, and then report any problems on LKML. They will require that
you do that if you want any real support anyway...
I've just tried 2.6.14-rc4-rt6 and the system freezes in the last steps
of booting (tried two times). The freeze doen't leave any trace on
syslog.
I'll wait the next rt release (rt7) to see if the problem remains.
Besta Regards,
~ Antonio
1:33 p.m.
On 10/17/05, Antonio <debian(a)fastwebnet.it> wrote:
Hi Mark,
On Mon, 2005-10-17 at 03:58 -0700, Mark Knecht wrote:
[cut]
In my experience waiting for -rt7 will almost certianly not fix a
problem like this.
Specifically, where did it hand? What's on the screen? Does
/var/log/messages hold the last boot log on your machine? If so there
may be some clues there.
Probably you need to change the kernel config slightly to get beyond this.
- Mark
QjackCtl is running fine here on 2.6.14-rc4-rt6
on AMD64. I'd suggest
that you update to the very latest stuff that Ingo has released, try
again, and then report any problems on LKML. They will require that
you do that if you want any real support anyway...
I've just tried 2.6.14-rc4-rt6 and the system freezes in the last steps
of booting (tried two times). The freeze doen't leave any trace on
syslog.
I'll wait the next rt release (rt7) to see if the problem remains.
18 Oct
18 Oct
9:07 a.m.
On Mon, 2005-10-17 at 08:33 -0700, Mark Knecht wrote:
[cut]
It hangs on the last 2 or 3 services (few seconds before the login).
I've checked /var/log/messages, but the freeze doesn't leave any trace.
There's no error... the log simply stops when the system hangs. And the
log seem very similar to the 2.6.14-rc4-rt1 one which boots correctly
although sometime gives me some errors.
I'll wait
the next rt release (rt7) to see if the problem remains.
In my experience waiting for -rt7 will almost certianly not fix a
problem like this.
Specifically, where did it hand? What's on the screen? Does
/var/log/messages hold the last boot log on your machine? If so there
may be some clues there. Probably you need to change the kernel config slightly
to get beyond this.
Well, I simply make an oldconfig upon a well functioning 2.6.14-rc4
vanilla kernel. I've read each new voice and I've ended up answering
always no (except for the "Complete Preemption" choice).
This morning I've tried the rt8 patch and I can't even compile the
kernel! This is the error:
CC kernel/ktimers.o
kernel/ktimers.c: In function 'check_ktimer_signal':
kernel/ktimers.c:1209: warning: passing argument 1 of
'unlock_ktimer_base' from incompatible pointer type
kernel/ktimers.c:1225: error: 'struct ktimer_base' has no member named
'getoffset'
make[2]: *** [kernel/ktimers.o] Error 1
Maybe today there will be some others releases.
- Mark
Cheers,
~ Antonio
20 Oct
20 Oct
6:39 a.m.
On Tue, 2005-10-18 at 13:07 +0200, Antonio wrote:
[cut]
This morning I've tried the rt8 patch and I
can't even compile the
kernel! This is the error:
[cut]
Maybe today there will be some others releases.
In fact. I've just installed the rt9 patch and works again like a charm.
Thanks to all had given me suggestions.
Best Regards,
~ Antonio
10:55 a.m.
On 10/19/05, Antonio <debian(a)fastwebnet.it> wrote:
On Tue, 2005-10-18 at 13:07 +0200, Antonio wrote:
[cut]
Humm...I missed that one. It looks like I've done
-rt1
-rt3
-rt5
-rt7
-rt11
Something about prime numbers I suppose. ;-)
Cheers,
Mark
This morning I've tried the rt8 patch and I
can't even compile the
kernel! This is the error:
[cut]
Maybe today there will be some others releases.
In fact. I've just installed the rt9 patch and works again like a charm.
Thanks to all had given me suggestions.
11:53 a.m.
On Thu, 2005-10-20 at 05:55 -0700, Mark Knecht wrote:
[cut]
I'm going to compile rt13 right now. I don't do in time to reproduce a
bug that Ingo has jet release 2 o 3 newer patch, and so I have to
recompile again. In this way I can't never report a bug that hit me :-/.
For the record I can trigger again a bug with rt9, using lash+om
+patchage+whysynth.
In fact.
I've just installed the rt9 patch and works again like a charm.
Thanks to all had given me suggestions.
Humm...I missed that one. It looks like I've done
-rt1
-rt3
-rt5
-rt7
-rt11 Something about prime numbers I suppose. ;-)
Hopefully I will be more luky with the rt13 patch, afterall it's a prime
number ;-).
Cheers,
Mark
1:36 p.m.
On Thursday 20 October 2005 13:54, Antonio wrote:
On Thu, 2005-10-20 at 05:55 -0700, Mark Knecht wrote:
[cut]
I'm going to compile rt13 right now. I don't do in time to reproduce a
bug that Ingo has jet release 2 o 3 newer patch, and so I have to
recompile again. In this way I can't never report a bug that hit me :-/.
For the record I can trigger again a bug with rt9, using lash+om
+patchage+whysynth.
Hi. What exactly is "patchage" for? I've got Whysynth on FC2, and now after
a
struggle on FC3. I am also trying to install Smack, which needs om as a dep,
and saw patchage on the download list on om's site. Nigel.
In fact.
I've just installed the rt9 patch and works again like a
charm.
Thanks to all had given me suggestions.
Humm...I missed that one. It looks like I've done
-rt1
-rt3
-rt5
-rt7
-rt11 Something about prime numbers I suppose. ;-)
Hopefully I will be more luky with the rt13 patch, afterall it's a prime
number ;-).
> Cheers,
> Mark
2 p.m.
On Thu, 2005-10-20 at 10:41 +0000, Nigel Henry wrote:
[cut]
Hi. What exactly is "patchage" for? I've
got Whysynth on FC2, and now after a
struggle on FC3. I am also trying to install Smack, which needs om as a dep,
and saw patchage on the download list on om's site. Nigel.
Patchage is a graphical patch bay to make jack and midi connections. It
support session management through lash and this is the main reason I
find it very interesting.
http://www.nongnu.org/om-synth/patchage.html
By now I wasn't able to use it in a productive way in conjunction with
lash because launching whysynth through jack-dssi-host I don't see the
midi input, while loading whysynth in om and saving the session cause a
kernel bug on session load.
But I'm confident that that these issue will be fixed quite soon.
Cheers,
~ Antonio
2:59 p.m.
On Thursday 20 October 2005 16:00, Antonio wrote:
On Thu, 2005-10-20 at 10:41 +0000, Nigel Henry wrote:
[cut]
Hi Antonio. Thanks for that. It seems similar to the way I use qjackctl's midi
connections, but with a lot more options. I havn't used LASH, but have
bookmarked both it and patchage for further investigation. Do hope you get
you're problem fixed soon. Nigel.
Hi. What exactly is "patchage" for?
I've got Whysynth on FC2, and now
after a struggle on FC3. I am also trying to install Smack, which needs
om as a dep, and saw patchage on the download list on om's site. Nigel.
Patchage is a graphical patch bay to make jack and midi connections. It
support session management through lash and this is the main reason I
find it very interesting.
http://www.nongnu.org/om-synth/patchage.html
By now I wasn't able to use it in a productive way in conjunction with
lash because launching whysynth through jack-dssi-host I don't see the
midi input, while loading whysynth in om and saving the session cause a
kernel bug on session load.
But I'm confident that that these issue will be fixed quite soon.
Cheers,
~ Antonio 
17 Oct
17 Oct
1:16 p.m.
On Mon, 2005-10-17 at 03:58 -0700, Mark Knecht wrote:
You might also try rebuilding Jack against that kernel
just to be
sure.
You don't have to rebuild JACK or any userspace app when changing
kernels.
You do have to rebuild JACK clients like ardour if you rebuild JACK with
different options.
Lee
7033
days inactive
7036
days old
linux-audio-user@lists.linuxaudio.org
14 comments
5 participants
participants (5)
-
Antonio -
Esben Stien -
Lee Revell -
Mark Knecht -
Nigel Henry