4 Jan
2009
4 Jan
'09
11:21 a.m.
[l-a-u CCed because we've been talking about this problem there
recently, and that's what prodded me to do the bisection to track it
down... fortunately the -rt8 to -rt9 interdiff was pretty small!]
Subject: [PATCH] [RT] tasklets: fix typo in tasklet_hi_action
Fix a typo in tasklet_hi_action -- using the wrong tasklet list when removing
actions.
This appears to be what was causing the ALSA sequencer device not to work in
2.6.26 with the RT patch: the sequencer was flaky in -rt1 to -rt8, and just
hung in -rt9 and later, after tasklets-fix-tasklet_hi_schedule.patch which
fixed the same typo when adding to the list. I guess that's because before -rt9
the actions were going onto the wrong list, whereas after -rt9 they were being
lost entirely once the first one had been performed. It seems happy now,
anyway.
Signed-off-by: Adam Sampson <ats(a)offog.org>
--- linux-2.6.26/kernel/softirq.c_orig 2009-01-04 14:41:06.000000000 +0000
+++ linux-2.6.26/kernel/softirq.c 2009-01-04 14:41:49.000000000 +0000
@@ -657,7 +657,7 @@
local_irq_disable();
list = __get_cpu_var(tasklet_hi_vec).head;
__get_cpu_var(tasklet_hi_vec).head = NULL;
- __get_cpu_var(tasklet_hi_vec).tail = &__get_cpu_var(tasklet_vec).head;
+ __get_cpu_var(tasklet_hi_vec).tail = &__get_cpu_var(tasklet_hi_vec).head;
local_irq_enable();
__tasklet_action(a, list);
--
Adam Sampson <ats(a)offog.org> <http://offog.org/>
4 Jan
4 Jan
12:27 p.m.
On Sun, Jan 4, 2009 at 10:20 AM, Adam Sampson <ats(a)offog.org> wrote:
Subject: [PATCH] [RT] tasklets: fix typo in
tasklet_hi_action
Fix a typo in tasklet_hi_action -- using the wrong tasklet list when removing
actions.
Thank you Adam, change made, kernel rebuilt, seems to be working now.
--
aRDy Music and Rick Dicaire present:
http://www.ardynet.com
http://www.ardynet.com:9000/ardymusic.ogg.m3u
3:29 p.m.
On Sun, Jan 04, 2009 at 11:27:22AM -0500, R Dicaire wrote:
On Sun, Jan 4, 2009 at 10:20 AM, Adam Sampson
<ats(a)offog.org> wrote:
Wait, what?
What Linux Audio problem does this patch fix? Is it the RT lockup problems with alsa_seq?
-ken
Subject: [PATCH] [RT] tasklets: fix typo in
tasklet_hi_action
Fix a typo in tasklet_hi_action -- using the wrong tasklet list when removing
actions.
Thank you Adam, change made, kernel rebuilt, seems to be working now.
3:43 p.m.
Yes it does! This will make some people happy I think :)
Thanks to Adam and also to you guys who insisted on this.
Regards
Frank
--- En date de : Dim 4.1.09, Ken Restivo <ken(a)restivo.org> a écrit :
De: Ken Restivo <ken(a)restivo.org>
Objet: Re: [LAU] [PATCH] [RT] tasklets: fix typo in tasklet_hi_action
À: "R Dicaire" <kritek(a)gmail.com>
Cc: "linux-audio-user" <linux-audio-user(a)lists.linuxaudio.org>
Date: Dimanche 4 Janvier 2009, 20h28
On Sun, Jan 04, 2009 at 11:27:22AM -0500, R Dicaire wrote:
be working now.
Wait, what?
What Linux Audio problem does this patch fix? Is it the RT
lockup problems with alsa_seq?
-ken
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
On Sun, Jan 4, 2009 at 10:20 AM, Adam Sampson
<ats(a)offog.org> wrote:
> Subject: [PATCH] [RT] tasklets: fix typo in
tasklet_hi_action
>
> Fix a typo in tasklet_hi_action -- using the
wrong tasklet list when
removing
actions.
Thank you Adam, change made, kernel rebuilt, seems to
5:49 p.m.
On Sun, Jan 04, 2009 at 11:28:51AM -0800, Ken Restivo wrote:
What Linux Audio problem does this patch fix? Is it
the RT lockup
problems with alsa_seq?
Yup. To be more specific:
I've seen three distinct types of reproducible behaviour from the
kernels I've tested...
Kernels that work:
2.6.24.7-rt25 (latest 2.6.24 RT patch)
2.6.25.8-rt7 (latest 2.6.25 RT patch)
2.6.26.5 (no RT patch)
These kernels work fine on my machine from a MIDI perspective --
although 2.6.24 occasionally locks up while I'm running RT applications,
which is why I was trying 2.6.26 in the first place.
Kernels that are partly broken:
2.6.26-rt1
2.6.26.3-rt3 (others reported this one "OK" on l-a-u)
2.6.26.3-rt7
2.6.26.5-rt8
These kernels behave very oddly for me: the MIDI sequencer can be opened
and closed successfully, but events are only delivered when I'm typing
on my (PS/2) keyboard! (That is, I can play some notes on my MIDI
keyboard, then go and tap the shift key on the PS/2 keyboard and they'll
all appear in aseqdump -- or I can wedge down a key so it autorepeats,
and then play fluidsynth through MIDI more-or-less happily...)
I tried generating interrupts by fiddling with other devices (e.g. a USB
mouse), but only the keyboard seems to have an effect.
Kernels that are completely broken:
2.6.26.5-rt9 (others reported this one broken on l-a-u)
2.6.26.6-rt11
2.6.26.8-rt12
With these kernels, no events are delivered even if I'm typing, and
closing /dev/snd/seq hangs the closing process; it then can't be opened
again by anything else. (This doesn't seem to have any other adverse
effects on the system, and the kernel otherwise seems solid; I ran
-rt11 on my desktop for a month under fairly heavy load after wedging
the sequencer for the first time.)
Running aseqdump under strace doesn't show anything unusual, aside from
the close() call never returning:
3562 write(1, "Waiting for data. Press Ctrl+C to end.\n", 39) = 39
3562 write(1, "Source Event Ch Data\n", 40) = 40
3562 rt_sigaction(SIGINT, {0x8048f24, [INT], SA_RESTART}, {SIG_DFL}, 8)
= 0
3562 rt_sigaction(SIGTERM, {0x8048f24, [TERM], SA_RESTART}, {SIG_DFL},
8) = 0
3562 poll([{fd=3, events=POLLIN|POLLERR|POLLNVAL}], 1, -1) = ?
ERESTART_RESTARTBLOCK (To be restarted)
3562 --- SIGINT (Interrupt) @ 0 (0) ---
3562 sigreturn() = ? (mask now [])
3562 close(3
It then looks like this in ps:
PID S WCHAN CMD
3562 D msleep aseqdump -p 20:0
(The full strace output for working and non-working invocations of
aseqdump is in the log-* files under the link above.)
Right, so the last partly-broken version is -rt8, and the first
completely-broken version is -rt9. Fortunately those are both against
the same upstream kernel (which I tested, and works fine without the RT
patch), and the interdiff between -rt8 and -rt9 is pretty small. One
change immediately stuck out as being interrupt-related:
diff -u linux-2.6.26.5-rt8/kernel/softirq.c linux-2.6.26.5-rt9/kernel/softirq.c
--- linux-2.6.26.5-rt8/kernel/softirq.c 2008-09-09 21:50:36.000000000 -0400
+++ linux-2.6.26.5-rt9/kernel/softirq.c 2008-09-11 11:56:06.000000000 -0400
@@ -536,7 +536,7 @@
unsigned long flags;
local_irq_save(flags);
- __tasklet_common_schedule(t, &__get_cpu_var(tasklet_vec), HI_SOFTIRQ);
+ __tasklet_common_schedule(t, &__get_cpu_var(tasklet_hi_vec), HI_SOFTIRQ);
local_irq_restore(flags);
}
... so I tried -rt9, but with that change reverted, and it behaves
just like -rt8 -- i.e. that's the change that causes the "partly-broken"
behaviour to become "completely broken".
(... and then while trying to figure out what that change did, I spotted
the typo that the patch fixes, and changing that made 2.6.26's MIDI
work like 2.6.24/25 for me.)
--
Adam Sampson <ats(a)offog.org> <http://offog.org/>
9:32 p.m.
On Sun, Jan 04, 2009 at 09:49:54PM +0000, Adam Sampson wrote:
On Sun, Jan 04, 2009 at 11:28:51AM -0800, Ken Restivo
wrote:
Totally freakin' awesome! Fantastic deductive work and troubleshooting.
I've built a 2.6.26.8-rt12 with your patch and will boot into it tonight or tomorrow
morning and try it out!
-ken
What Linux Audio problem does this patch fix? Is
it the RT lockup
problems with alsa_seq?
Yup. To be more specific:
I've seen three distinct types of reproducible behaviour from the
kernels I've tested...
Kernels that work:
2.6.24.7-rt25 (latest 2.6.24 RT patch)
2.6.25.8-rt7 (latest 2.6.25 RT patch)
2.6.26.5 (no RT patch)
These kernels work fine on my machine from a MIDI perspective --
although 2.6.24 occasionally locks up while I'm running RT applications,
which is why I was trying 2.6.26 in the first place.
Kernels that are partly broken:
2.6.26-rt1
2.6.26.3-rt3 (others reported this one "OK" on l-a-u)
2.6.26.3-rt7
2.6.26.5-rt8
These kernels behave very oddly for me: the MIDI sequencer can be opened
and closed successfully, but events are only delivered when I'm typing
on my (PS/2) keyboard! (That is, I can play some notes on my MIDI
keyboard, then go and tap the shift key on the PS/2 keyboard and they'll
all appear in aseqdump -- or I can wedge down a key so it autorepeats,
and then play fluidsynth through MIDI more-or-less happily...)
I tried generating interrupts by fiddling with other devices (e.g. a USB
mouse), but only the keyboard seems to have an effect.
Kernels that are completely broken:
2.6.26.5-rt9 (others reported this one broken on l-a-u)
2.6.26.6-rt11
2.6.26.8-rt12
With these kernels, no events are delivered even if I'm typing, and
closing /dev/snd/seq hangs the closing process; it then can't be opened
again by anything else. (This doesn't seem to have any other adverse
effects on the system, and the kernel otherwise seems solid; I ran
-rt11 on my desktop for a month under fairly heavy load after wedging
the sequencer for the first time.)
Running aseqdump under strace doesn't show anything unusual, aside from
the close() call never returning:
3562 write(1, "Waiting for data. Press Ctrl+C to end.\n", 39) = 39
3562 write(1, "Source Event Ch Data\n", 40) = 40
3562 rt_sigaction(SIGINT, {0x8048f24, [INT], SA_RESTART}, {SIG_DFL}, 8)
= 0
3562 rt_sigaction(SIGTERM, {0x8048f24, [TERM], SA_RESTART}, {SIG_DFL},
8) = 0
3562 poll([{fd=3, events=POLLIN|POLLERR|POLLNVAL}], 1, -1) = ?
ERESTART_RESTARTBLOCK (To be restarted)
3562 --- SIGINT (Interrupt) @ 0 (0) ---
3562 sigreturn() = ? (mask now [])
3562 close(3
It then looks like this in ps:
PID S WCHAN CMD
3562 D msleep aseqdump -p 20:0
(The full strace output for working and non-working invocations of
aseqdump is in the log-* files under the link above.)
Right, so the last partly-broken version is -rt8, and the first
completely-broken version is -rt9. Fortunately those are both against
the same upstream kernel (which I tested, and works fine without the RT
patch), and the interdiff between -rt8 and -rt9 is pretty small. One
change immediately stuck out as being interrupt-related:
diff -u linux-2.6.26.5-rt8/kernel/softirq.c linux-2.6.26.5-rt9/kernel/softirq.c
--- linux-2.6.26.5-rt8/kernel/softirq.c 2008-09-09 21:50:36.000000000 -0400
+++ linux-2.6.26.5-rt9/kernel/softirq.c 2008-09-11 11:56:06.000000000 -0400
@@ -536,7 +536,7 @@
unsigned long flags;
local_irq_save(flags);
- __tasklet_common_schedule(t, &__get_cpu_var(tasklet_vec), HI_SOFTIRQ);
+ __tasklet_common_schedule(t, &__get_cpu_var(tasklet_hi_vec), HI_SOFTIRQ);
local_irq_restore(flags);
}
... so I tried -rt9, but with that change reverted, and it behaves
just like -rt8 -- i.e. that's the change that causes the "partly-broken"
behaviour to become "completely broken".
(... and then while trying to figure out what that change did, I spotted
the typo that the patch fixes, and changing that made 2.6.26's MIDI
work like 2.6.24/25 for me.)
6:11 p.m.
On Sun, 2009-01-04 at 15:20 +0000, Adam Sampson wrote:
[l-a-u CCed because we've been talking about this
problem there
recently, and that's what prodded me to do the bisection to track it
down... fortunately the -rt8 to -rt9 interdiff was pretty small!]
Subject: [PATCH] [RT] tasklets: fix typo in tasklet_hi_action
Fix a typo in tasklet_hi_action -- using the wrong tasklet list when removing
actions.
Thank you thank you thank you! I posted to lkml about this a while back
but no real solution was forthcoming. This is such a piece of good news!
-- Fernando
This appears to be what was causing the ALSA sequencer
device not to work in
2.6.26 with the RT patch: the sequencer was flaky in -rt1 to -rt8, and just
hung in -rt9 and later, after tasklets-fix-tasklet_hi_schedule.patch which
fixed the same typo when adding to the list. I guess that's because before -rt9
the actions were going onto the wrong list, whereas after -rt9 they were being
lost entirely once the first one had been performed. It seems happy now,
anyway.
Signed-off-by: Adam Sampson <ats(a)offog.org>
--- linux-2.6.26/kernel/softirq.c_orig 2009-01-04 14:41:06.000000000 +0000
+++ linux-2.6.26/kernel/softirq.c 2009-01-04 14:41:49.000000000 +0000
@@ -657,7 +657,7 @@
local_irq_disable();
list = __get_cpu_var(tasklet_hi_vec).head;
__get_cpu_var(tasklet_hi_vec).head = NULL;
- __get_cpu_var(tasklet_hi_vec).tail = &__get_cpu_var(tasklet_vec).head;
+ __get_cpu_var(tasklet_hi_vec).tail = &__get_cpu_var(tasklet_hi_vec).head;
local_irq_enable();
__tasklet_action(a, list);
5831
days inactive
5831
days old
linux-audio-user@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Adam Sampson -
Fernando Lopez-Lezcano -
go music -
Ken Restivo -
R Dicaire