i have released the 2.6.15-rc7-rt1 tree, which can be downloaded from
the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release mainly includes fixes from Steven Rostedt, for various
problems with -rc5-rt4 - while i'm over in mutex-land ;)
Please re-report any bugs that remain.
to build a 2.6.15-rc7-rt1 tree, the following patches should be applied:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.15-rc7.bz2
http://redhat.com/~mingo/realtime-preempt/patch-2.6.15-rc7-rt1
Ingo
Ingo Molnar wrote:
> i have released the 2.6.15-rc7-rt1 tree, which can be downloaded from
> the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this release mainly includes fixes from Steven Rostedt, for various
> problems with -rc5-rt4 - while i'm over in mutex-land ;)
>
> Please re-report any bugs that remain.
This one got all of the outstanding issues that I had run into thus far
with previous patches. Compiled and booted on the old dual 933.
>
> to build a 2.6.15-rc7-rt1 tree, the following patches should be applied:
>
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2
> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.15-rc7.bz2
> http://redhat.com/~mingo/realtime-preempt/patch-2.6.15-rc7-rt1
>
> Ingo
> -
> 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://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
kr
* K.R. Foley <[email protected]> wrote:
> Ingo Molnar wrote:
> > i have released the 2.6.15-rc7-rt1 tree, which can be downloaded from
> > the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
> > this release mainly includes fixes from Steven Rostedt, for various
> > problems with -rc5-rt4 - while i'm over in mutex-land ;)
> >
> > Please re-report any bugs that remain.
>
> This one got all of the outstanding issues that I had run into thus far
^---fixed
> with previous patches. Compiled and booted on the old dual 933.
(just to clarify it to others)
Ingo
Hi,
>i have released the 2.6.15-rc7-rt1 tree, which can be downloaded from
>the usual place:
>[...]
>Please re-report any bugs that remain.
>
This happened upon starting mplayer for the first time:
BUG at include/linux/timer.h:83!
------------[ cut here ]------------
kernel BUG at include/linux/timer.h:83!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: thermal processor fan button battery ac af_packet pcmcia
firmware_class yenta_socket rsrc_nonstatic pcmcia_core rtc psmouse 8139too mii
crc32
CPU: 0
EIP: 0060:[<df111b02>] Not tainted VLI
EFLAGS: 00010286 (2.6.15-rc7-rt1)
EIP is at rtc_do_ioctl+0x8a2/0x8e0 [rtc]
eax: 00000024 ebx: df1125f4 ecx: ddd8e000 edx: 00000000
esi: 00000053 edi: c038e070 ebp: dbafbf54 esp: dbafbed4
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process mplayer (pid: 1728, threadinfo=dbafa000 task=de7a1100 stack_left=7840
worst_left=-1)
Stack: df11260a df1125f4 00000053 00000000 dded230c dbafbef8 da98a080 dded230c
c0167640 00200246 c015d42a de6e7620 dd9c6264 00000000 dc7a0b2c da98a080
dbafbf3c dd4d9000 dbafbf30 c015d6c5 da98a080 00000000 00008000 dbafbf88
Call Trace:
[<c0104036>] show_stack+0xa6/0xe0 (32)
[<c01041fe>] show_registers+0x16e/0x220 (56)
[<c010443d>] die+0xdd/0x170 (56)
[<c010454e>] do_trap+0x7e/0xe0 (28)
[<c0104837>] do_invalid_op+0x97/0xb0 (180)
[<c0103cc3>] error_code+0x4f/0x54 (188)
[<df111b4f>] rtc_ioctl+0xf/0x20 [rtc] (8)
[<c0170e68>] do_ioctl+0x78/0x90 (28)
[<c0171017>] vfs_ioctl+0x57/0x1f0 (32)
[<c01711e9>] sys_ioctl+0x39/0x60 (28)
[<c01031b5>] syscall_call+0x7/0xb (-8116)
Code: 00 e9 30 ff ff ff e8 fe d7 19 e1 eb 8c be 53 00 00 00 bb f4 25 11 df 89
74 24 08 89 5c 24 04 c7 04 24 0a 26 11 df e8 de 9c 00 e1 <0f> 0b 53 00 f4 25 11
df e9 73 ff ff ff e8 cc d7 19 e1 e9 63 f9
Segmentation fault
This looks like it's due to some timer - mplayer opens /dev/rtc if you want
to know. A second invocation of mplayer went fine, I guess due to
/dev/rtc still having a refcount of >0 and therefore not able to be opened
again.
AFA-IIRC this did not happen with (my own portage of) 2.6.15-rc5-rt4 into
2.6.15-rc7 (on the very day that rc7 was released).
If you need config.gz/.config or other info, please let me know.
I also notice that mplayer uses approximately a lot more CPU, as shown in
top when CONFIG_HIGH_RES_TIMERS=y. That is, without highres timers, mplayer
uses less than 1%, with hrt it's somewhere between 10% and 18%.
I practically just ran the decoding routine:
`mplayer -ao null sometrack.ogg`.
Jan Engelhardt
--
On Sat, 2005-12-31 at 18:15 +0100, Jan Engelhardt wrote:
> Hi,
>
>
> >i have released the 2.6.15-rc7-rt1 tree, which can be downloaded from
> >the usual place:
> >[...]
> >Please re-report any bugs that remain.
> >
> This happened upon starting mplayer for the first time:
> BUG at include/linux/timer.h:83!
> ------------[ cut here ]------------
> kernel BUG at include/linux/timer.h:83!
> invalid operand: 0000 [#1]
[...]
> [<df111b4f>] rtc_ioctl+0xf/0x20 [rtc] (8)
Hmm, which rtc_ioctl?
> [<c0170e68>] do_ioctl+0x78/0x90 (28)
> [<c0171017>] vfs_ioctl+0x57/0x1f0 (32)
> [<c01711e9>] sys_ioctl+0x39/0x60 (28)
> [<c01031b5>] syscall_call+0x7/0xb (-8116)
> Code: 00 e9 30 ff ff ff e8 fe d7 19 e1 eb 8c be 53 00 00 00 bb f4 25 11 df 89
> 74 24 08 89 5c 24 04 c7 04 24 0a 26 11 df e8 de 9c 00 e1 <0f> 0b 53 00 f4 25 11
> df e9 73 ff ff ff e8 cc d7 19 e1 e9 63 f9
> Segmentation fault
>
> This looks like it's due to some timer - mplayer opens /dev/rtc if you want
> to know. A second invocation of mplayer went fine, I guess due to
> /dev/rtc still having a refcount of >0 and therefore not able to be opened
> again.
>
> AFA-IIRC this did not happen with (my own portage of) 2.6.15-rc5-rt4 into
> 2.6.15-rc7 (on the very day that rc7 was released).
> If you need config.gz/.config or other info, please let me know.
Yeah, could you send it. If anything, just so I know which rtc_ioctl is
used.
>
>
> I also notice that mplayer uses approximately a lot more CPU, as shown in
> top when CONFIG_HIGH_RES_TIMERS=y. That is, without highres timers, mplayer
> uses less than 1%, with hrt it's somewhere between 10% and 18%.
> I practically just ran the decoding routine:
> `mplayer -ao null sometrack.ogg`.
I'll give this a try too. This isn't an x86_64 box is it?
Thanks,
-- Steve
On Sat, 2005-12-31 at 12:45 -0500, Steven Rostedt wrote:
> [...]
> > [<df111b4f>] rtc_ioctl+0xf/0x20 [rtc] (8)
>
> Hmm, which rtc_ioctl?
Never mind, I figured out that this is the generic rtc. (late night
last night -pre-New-Years-, so I'm not thinking all that well today).
>
> > [<c0170e68>] do_ioctl+0x78/0x90 (28)
> > [<c0171017>] vfs_ioctl+0x57/0x1f0 (32)
> > [<c01711e9>] sys_ioctl+0x39/0x60 (28)
> > [<c01031b5>] syscall_call+0x7/0xb (-8116)
> > Code: 00 e9 30 ff ff ff e8 fe d7 19 e1 eb 8c be 53 00 00 00 bb f4 25 11 df 89
> > 74 24 08 89 5c 24 04 c7 04 24 0a 26 11 df e8 de 9c 00 e1 <0f> 0b 53 00 f4 25 11
> > df e9 73 ff ff ff e8 cc d7 19 e1 e9 63 f9
> > Segmentation fault
> >
> > This looks like it's due to some timer - mplayer opens /dev/rtc if you want
> > to know. A second invocation of mplayer went fine, I guess due to
> > /dev/rtc still having a refcount of >0 and therefore not able to be opened
> > again.
> >
> > AFA-IIRC this did not happen with (my own portage of) 2.6.15-rc5-rt4 into
> > 2.6.15-rc7 (on the very day that rc7 was released).
> > If you need config.gz/.config or other info, please let me know.
>
> Yeah, could you send it. If anything, just so I know which rtc_ioctl is
> used.
Don't bother.
>
> >
> >
> > I also notice that mplayer uses approximately a lot more CPU, as shown in
> > top when CONFIG_HIGH_RES_TIMERS=y. That is, without highres timers, mplayer
> > uses less than 1%, with hrt it's somewhere between 10% and 18%.
> > I practically just ran the decoding routine:
> > `mplayer -ao null sometrack.ogg`.
I haven't gotten around to the CPU usage part (maybe Thomas has time for
that).
But, is the BUG easily reproducible? I believe I found the race.
In drivers/char/rtc.c: searching for rtc_irq_timer
The places that rtc_irq_timer is used:
rtc_interrupt:
mod = 0;
// below the add timer can change the rtc_status and then call mod_timer
// which can activate it.
if (rtc_status & RTC_TIMER_ON)
mod = 1;
spin_unlock (&rtc_lock);
if (mod)
mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
rtc_do_ioctl:
case RTC_PIE_OFF: /* Mask periodic int. enab. bit */
{
unsigned long flags; /* can be called from isr via rtc_control() */
int del = 0;
spin_lock_irqsave (&rtc_lock, flags);
mask_rtc_irq_bit_locked(RTC_PIE);
if (rtc_status & RTC_TIMER_ON) {
rtc_status &= ~RTC_TIMER_ON;
del = 1;
}
spin_unlock_irqrestore (&rtc_lock, flags);
// if we are preempted here, we can also go and add the timer before
// we delete it.
if (del)
del_timer(&rtc_irq_timer);
return 0;
}
case RTC_PIE_ON: /* Allow periodic ints */
{
unsigned long flags; /* can be called from isr via rtc_control() */
int add = 0;
/*
* We don't really want Joe User enabling more
* than 64Hz of interrupts on a multi-user machine.
*/
if (!kernel && (rtc_freq > rtc_max_user_freq) &&
(!capable(CAP_SYS_RESOURCE)))
return -EACCES;
spin_lock_irqsave (&rtc_lock, flags);
if (!(rtc_status & RTC_TIMER_ON)) {
rtc_irq_timer.expires = jiffies + HZ/rtc_freq + 2*HZ/100;
rtc_status |= RTC_TIMER_ON;
add = 1;
}
set_rtc_irq_bit_locked(RTC_PIE);
spin_unlock_irqrestore (&rtc_lock, flags);
// there's no protection between the above setting of rtc_status
// and this add_timer
if (add)
add_timer(&rtc_irq_timer);
return 0;
}
So you took the bug in include/linux/timer.h:83
81:static inline void add_timer(struct timer_list *timer)
82:{
83: BUG_ON(timer_pending(timer));
84: __mod_timer(timer, timer->expires);
85:}
You can very well have a timer pending when calling add.
Looking at the vanilla kernel rtc.c, all these are protected by the
rtc_lock. So this was changed by -rt.
So Ingo, Thomas or John, is it OK to put that back or what?
-- Steve
On 12/31/05, Steven Rostedt <[email protected]> wrote:
> On Sat, 2005-12-31 at 12:45 -0500, Steven Rostedt wrote:
>
> > [...]
> > > [<df111b4f>] rtc_ioctl+0xf/0x20 [rtc] (8)
> >
> > Hmm, which rtc_ioctl?
>
> Never mind, I figured out that this is the generic rtc. (late night
> last night -pre-New-Years-, so I'm not thinking all that well today).
>
> >
> > > [<c0170e68>] do_ioctl+0x78/0x90 (28)
> > > [<c0171017>] vfs_ioctl+0x57/0x1f0 (32)
> > > [<c01711e9>] sys_ioctl+0x39/0x60 (28)
> > > [<c01031b5>] syscall_call+0x7/0xb (-8116)
> > > Code: 00 e9 30 ff ff ff e8 fe d7 19 e1 eb 8c be 53 00 00 00 bb f4 25 11 df 89
> > > 74 24 08 89 5c 24 04 c7 04 24 0a 26 11 df e8 de 9c 00 e1 <0f> 0b 53 00 f4 25 11
> > > df e9 73 ff ff ff e8 cc d7 19 e1 e9 63 f9
> > > Segmentation fault
> > >
> > > This looks like it's due to some timer - mplayer opens /dev/rtc if you want
> > > to know. A second invocation of mplayer went fine, I guess due to
> > > /dev/rtc still having a refcount of >0 and therefore not able to be opened
> > > again.
> > >
> > > AFA-IIRC this did not happen with (my own portage of) 2.6.15-rc5-rt4 into
> > > 2.6.15-rc7 (on the very day that rc7 was released).
> > > If you need config.gz/.config or other info, please let me know.
> >
> > Yeah, could you send it. If anything, just so I know which rtc_ioctl is
> > used.
>
> Don't bother.
>
> >
> > >
> > >
> > > I also notice that mplayer uses approximately a lot more CPU, as shown in
> > > top when CONFIG_HIGH_RES_TIMERS=y. That is, without highres timers, mplayer
> > > uses less than 1%, with hrt it's somewhere between 10% and 18%.
> > > I practically just ran the decoding routine:
> > > `mplayer -ao null sometrack.ogg`.
>
> I haven't gotten around to the CPU usage part (maybe Thomas has time for
> that).
>
<SNIP>
>
>
> You can very well have a timer pending when calling add.
>
> Looking at the vanilla kernel rtc.c, all these are protected by the
> rtc_lock. So this was changed by -rt.
>
> So Ingo, Thomas or John, is it OK to put that back or what?
>
> -- Steve
>
>
> -
> 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://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi all,
Happy New Year.
Is this the same problem Steven? It happened when running MythTV
for the first time. Rerunning MythTV did not cause a second problem
and the program then ran fine.
- Mark
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at include/linux/timer.h:83
invalid operand: 0000 [1] PREEMPT
CPU 0
Modules linked in: snd_seq_midi snd_pcm_oss snd_mixer_oss snd_seq_oss
snd_seq_mi di_event snd_seq realtime sbp2 ohci1394 ieee1394 snd_hdsp
snd_rawmidi snd_seq_de vice snd_hwdep snd_intel8x0 snd_ac97_codec
snd_ac97_bus snd_pcm snd_timer snd sn d_page_alloc radeon drm
Pid: 8553, comm: mythfrontend Not tainted 2.6.15-rc7-rt1 #1
RIP: 0010:[<ffffffff802ae2fa>] <ffffffff802ae2fa>{rtc_do_ioctl+730}
RSP: 0018:ffff81000adb9e08 EFLAGS: 00210282
RAX: 0000000000000000 RBX: 0000000000200202 RCX: ffff81001f9217c0
RDX: 0000000000000000 RSI: ffff81000a6d5030 RDI: ffff81001f9217c0
RBP: 0000000000000001 R08: ffff81000adb8000 R09: 0000000000000001
R10: 00002aaaaaac0660 R11: 0000000000200246 R12: 00000000fffffff3
R13: 0000000000007005 R14: 0000000000000013 R15: 00002aaaab3d3850
FS: 0000000043005960(0063) GS:ffffffff80573800(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaac987620 CR3: 00000000063a9000 CR4: 00000000000006e0
Process mythfrontend (pid: 8553, threadinfo ffff81000adb8000, task
ffff81000a6d5 030)
Stack: ffff81001e986bc8 0000000000200246 0000000000200202 0000000000200246
ffff81001ffa13c0 ffffffff80181331 0000000000008000 0000000000008000
ffff81000adc56c0 ffff81001e986bc8
Call Trace:<ffffffff80181331>{chrdev_open+449} <ffffffff80181170>{chrdev_open+0}
<ffffffff801771fc>{__dentry_open+332} <ffffffff804051da>{lock_kernel+42}
<ffffffff8018b4e4>{do_ioctl+116} <ffffffff8018b7c2>{vfs_ioctl+690}
<ffffffff8018b85a>{sys_ioctl+106} <ffffffff8010dba6>{system_call+126}
Code: 0f 0b 68 9d 5f 42 80 c2 53 00 48 8b 35 25 54 2a 00 48 c7 c7
RIP <ffffffff802ae2fa>{rtc_do_ioctl+730} RSP <ffff81000adb9e08>
>Hi all,
> Happy New Year.
>
> Is this the same problem Steven? It happened when running MythTV
>for the first time. Rerunning MythTV did not cause a second problem
>and the program then ran fine.
Try in userspace:
strace -e open mythtv 2>&1 | grep /dev/rtc
should probably enlighten you a little more. I'd be very surprised if it
was not rtc now..
Jan Engelhardt
--
On Sun, 1 Jan 2006, Mark Knecht wrote:
>
> Hi all,
> Happy New Year.
>
> Is this the same problem Steven? It happened when running MythTV
> for the first time. Rerunning MythTV did not cause a second problem
> and the program then ran fine.
>
> - Mark
>
> ----------- [cut here ] --------- [please bite here ] ---------
> Kernel BUG at include/linux/timer.h:83
Looking at the above...
> invalid operand: 0000 [1] PREEMPT
> CPU 0
...
>
> Code: 0f 0b 68 9d 5f 42 80 c2 53 00 48 8b 35 25 54 2a 00 48 c7 c7
> RIP <ffffffff802ae2fa>{rtc_do_ioctl+730} RSP <ffff81000adb9e08>
>
And that rtc_do_ioctl, I would say "Yes".
Try out this patch and see if it fixes the problem. I'm reposting it just
so you don't need to go back and look for it.
-- Steve
Index: linux-2.6.15-rc7-rt1/drivers/char/rtc.c
===================================================================
--- linux-2.6.15-rc7-rt1.orig/drivers/char/rtc.c 2005-12-28 14:02:48.000000000 -0500
+++ linux-2.6.15-rc7-rt1/drivers/char/rtc.c 2005-12-31 14:41:58.000000000 -0500
@@ -384,7 +384,6 @@
}
#ifdef RTC_IRQ
-
/*
* A very tiny interrupt handler. It runs with SA_INTERRUPT set,
* but there is possibility of conflicting with the set_rtc_mmss()
@@ -397,8 +396,6 @@
irqreturn_t rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
- int mod;
-
/*
* Can be an alarm interrupt, update complete interrupt,
* or a periodic interrupt. We store the status in the
@@ -420,13 +417,10 @@
rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);
}
- mod = 0;
if (rtc_status & RTC_TIMER_ON)
- mod = 1;
+ mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
spin_unlock (&rtc_lock);
- if (mod)
- mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
/* Now do the rest of the actions */
spin_lock(&rtc_task_lock);
@@ -588,24 +582,18 @@
case RTC_PIE_OFF: /* Mask periodic int. enab. bit */
{
unsigned long flags; /* can be called from isr via rtc_control() */
- int del = 0;
-
spin_lock_irqsave (&rtc_lock, flags);
mask_rtc_irq_bit_locked(RTC_PIE);
if (rtc_status & RTC_TIMER_ON) {
rtc_status &= ~RTC_TIMER_ON;
- del = 1;
+ del_timer(&rtc_irq_timer);
}
spin_unlock_irqrestore (&rtc_lock, flags);
- if (del)
- del_timer(&rtc_irq_timer);
return 0;
}
case RTC_PIE_ON: /* Allow periodic ints */
{
unsigned long flags; /* can be called from isr via rtc_control() */
- int add = 0;
-
/*
* We don't really want Joe User enabling more
* than 64Hz of interrupts on a multi-user machine.
@@ -617,13 +605,11 @@
spin_lock_irqsave (&rtc_lock, flags);
if (!(rtc_status & RTC_TIMER_ON)) {
rtc_irq_timer.expires = jiffies + HZ/rtc_freq + 2*HZ/100;
+ add_timer(&rtc_irq_timer);
rtc_status |= RTC_TIMER_ON;
- add = 1;
}
set_rtc_irq_bit_locked(RTC_PIE);
spin_unlock_irqrestore (&rtc_lock, flags);
- if (add)
- add_timer(&rtc_irq_timer);
return 0;
}
case RTC_UIE_OFF: /* Mask ints from RTC updates. */
@@ -914,7 +900,6 @@
{
#ifdef RTC_IRQ
unsigned char tmp;
- int del;
if (rtc_has_irq == 0)
goto no_irq;
@@ -933,14 +918,11 @@
CMOS_WRITE(tmp, RTC_CONTROL);
CMOS_READ(RTC_INTR_FLAGS);
}
- del = 0;
if (rtc_status & RTC_TIMER_ON) {
rtc_status &= ~RTC_TIMER_ON;
- del = 1;
+ del_timer(&rtc_irq_timer);
}
spin_unlock_irq(&rtc_lock);
- if (del)
- del_timer(&rtc_irq_timer);
if (file->f_flags & FASYNC) {
rtc_fasync (-1, file, 0);
@@ -1017,7 +999,6 @@
return -EIO;
#else
unsigned char tmp;
- int del;
spin_lock_irq(&rtc_lock);
spin_lock(&rtc_task_lock);
@@ -1037,15 +1018,12 @@
CMOS_WRITE(tmp, RTC_CONTROL);
CMOS_READ(RTC_INTR_FLAGS);
}
- del = 0;
if (rtc_status & RTC_TIMER_ON) {
rtc_status &= ~RTC_TIMER_ON;
- del = 1;
+ del_timer(&rtc_irq_timer);
}
rtc_status &= ~RTC_IS_OPEN;
spin_unlock(&rtc_task_lock);
- if (del)
- del_timer(&rtc_irq_timer);
spin_unlock_irq(&rtc_lock);
return 0;
#endif
@@ -1307,7 +1285,6 @@
static void rtc_dropped_irq(unsigned long data)
{
unsigned long freq;
- int mod;
spin_lock_irq (&rtc_lock);
@@ -1317,9 +1294,8 @@
}
/* Just in case someone disabled the timer from behind our back... */
- mod = 0;
if (rtc_status & RTC_TIMER_ON)
- mod = 1;
+ mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
rtc_irq_data += ((rtc_freq/HZ)<<8);
rtc_irq_data &= ~0xff;
@@ -1328,8 +1304,6 @@
freq = rtc_freq;
spin_unlock_irq(&rtc_lock);
- if (mod)
- mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
FYI,
Ingo has been paying attention to this thread :)
2.6.15-rc7-rt2 is out and contains this patch.
-- Steve
On 1/2/06, Steven Rostedt <[email protected]> wrote:
> FYI,
>
> Ingo has been paying attention to this thread :)
>
> 2.6.15-rc7-rt2 is out and contains this patch.
>
> -- Steve
Hi all,
Sorry for the delay. We had a 3 day power failure here in Northern
California and I'm just getting back in the swing of things starting
yesterday.
I have installed 2.6.15-rt2 and I no longer see the error
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at include/linux/timer.h:83
invalid operand: 0000 [1] PREEMPT
CPU 0
in my dmesg file. Thanks for fixing that.
I expect that I am probably still getting a low level of xruns. I
hope one day we can make that work a bit better. In the mean time no
problems with mplayer or MythTV so far.
Cheers,
Mark
On Thu, 2006-01-05 at 11:33 -0800, Mark Knecht wrote:
> I expect that I am probably still getting a low level of xruns. I
> hope one day we can make that work a bit better.
Were you ever able to get latency tracing to work on your box?
Lee
On 1/5/06, Lee Revell <[email protected]> wrote:
> On Thu, 2006-01-05 at 11:33 -0800, Mark Knecht wrote:
> > I expect that I am probably still getting a low level of xruns. I
> > hope one day we can make that work a bit better.
>
> Were you ever able to get latency tracing to work on your box?
>
> Lee
Not yet, due to the power failure and being off line. I'll give it a
shot this evening.
Does anyone with an AMD64 platform have this working?
Thanks,
Mark
On 1/5/06, Mark Knecht <[email protected]> wrote:
> On 1/5/06, Lee Revell <[email protected]> wrote:
> > On Thu, 2006-01-05 at 11:33 -0800, Mark Knecht wrote:
> > > I expect that I am probably still getting a low level of xruns. I
> > > hope one day we can make that work a bit better.
> >
> > Were you ever able to get latency tracing to work on your box?
> >
> > Lee
>
> Not yet, due to the power failure and being off line. I'll give it a
> shot this evening.
>
> Does anyone with an AMD64 platform have this working?
>
> Thanks,
> Mark
>
Hi Lee,
OK, I rebuilt the new kernel (2.6.15-rt2) with latency tracing
enabled. I still get xruns when running Jack and Aqualung. The tracing
doesn't show anything new although I do have the IRQ off tracing
turned on and don't see the long timer delays that Iused to see.
What the following shows is that I have a 14uS delay before
mounting my 1394 audio drive. I mount the drive which goes normally. I
then started Aqualung and am just playing some audio from the 1394
drive. I also start MythTV and am streaming a TV show. Along the way I
get another 14uS delay which is fine. However in the process of doing
that I get a 2.9mS xrun but I see nothing in the latency tracing info.
I can send along the config file if that would help.
<SNIP>
16:20:45.814 Patchbay deactivated.
16:20:45.891 Statistics reset.
16:20:45.952 MIDI connection graph change.
16:20:46.112 MIDI connection change.
16:20:47.701 JACK is starting...
16:20:47.701 /usr/bin/jackd -R -P80 -p512 -dalsa -dhw:1 -r44100 -p64 -n2
16:20:47.713 JACK was started with PID=7942 (0x1f06).
jackd 0.100.5
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 44100
creating alsa driver ... hw:1|hw:1|64|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 44100Hz, period = 64 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
16:20:49.730 Server configuration saved to "/home/mark/.jackdrc".
16:20:49.731 Statistics reset.
16:20:49.893 Client activated.
16:20:49.895 Audio connection change.
16:20:49.898 Audio connection graph change.
16:21:41.419 Audio connection graph change.
16:21:41.550 Audio connection change.
16:21:43.684 Audio connection graph change.
subgraph starting at qjackctl-7941 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
16:30:47.171 XRUN callback (1).
16:30:47.171 XRUN callback (2).
**** alsa_pcm: xrun of at least 1.422 msecs
**** alsa_pcm: xrun of at least 2.896 msecs
subgraph starting at qjackctl-7941 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
16:34:40.068 XRUN callback (3).
**** alsa_pcm: xrun of at least 1.196 msecs
**** alsa_pcm: xrun of at least 2.906 msecs
16:34:40.628 XRUN callback (1 skipped).
<SNIP>
( X-7771 |#0): new 14 us maximum-latency critical section.
=> started at timestamp 165360021: <__schedule+0xb8/0x596>
=> ended at timestamp 165360035: <thread_return+0xb5/0x11a>
Call Trace:<ffffffff8014d79f>{check_critical_timing+479}
<ffffffff803c79e0>{unix_poll+ 0}
<ffffffff8014db78>{sub_preempt_count_ti+88}
<ffffffff80403c0c>{thread_return+70 }
<ffffffff80403c7b>{thread_return+181} <ffffffff80403de5>{schedule+261}
<ffffffff804048ed>{schedule_timeout+141}
<ffffffff8013b2e0>{process_timeout+0}
<ffffffff8018d237>{do_select+967} <ffffffff8018cd80>{__pollwait+0}
<ffffffff8018d57d>{sys_select+749} <ffffffff8010dc86>{system_call+126}
=> dump-end timestamp 165360140
ieee1394: Error parsing configrom for node 0-00:1023
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
ieee1394: Node added: ID:BUS[0-00:1023] GUID[0050c504e0006463]
scsi4 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
Vendor: Maxtor 6 Model: Y160P0 Rev: YAR4
Type: Direct-Access-RBC ANSI SCSI revision: 04
SCSI device sdb: 320173056 512-byte hdwr sectors (163929 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
SCSI device sdb: 320173056 512-byte hdwr sectors (163929 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
sdb: sdb1 sdb2 sdb3
sd 4:0:0:0: Attached scsi disk sdb
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
kjournald starting. Commit interval 5 seconds
EXT3 FS on sdb1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
( X-7771 |#0): new 14 us maximum-latency critical section.
=> started at timestamp 900866152: <__schedule+0xb8/0x596>
=> ended at timestamp 900866166: <thread_return+0xb5/0x11a>
Call Trace:<ffffffff8014d79f>{check_critical_timing+479}
<ffffffff8014db78>{sub_preemp t_count_ti+88}
<ffffffff80403c0c>{thread_return+70}
<ffffffff80403c7b>{thread_return+181}
<ffffffff80403de5>{schedule+261} <ffffffff804048ed>{schedule_timeout+141}
<ffffffff8013b2e0>{process_timeout+0} <ffffffff8018d237>{do_select+967}
<ffffffff8018cd80>{__pollwait+0} <ffffffff8018d57d>{sys_select+749}
<ffffffff8010dab2>{sys_rt_sigreturn+578}
<ffffffff8010dc86>{system_call+126}
=> dump-end timestamp 900866281
lightning ~ #
Thanks,
Mark
On Thu, 2006-01-05 at 16:43 -0800, Mark Knecht wrote:
> On 1/5/06, Mark Knecht <[email protected]> wrote:
> > On 1/5/06, Lee Revell <[email protected]> wrote:
> > > On Thu, 2006-01-05 at 11:33 -0800, Mark Knecht wrote:
> > > > I expect that I am probably still getting a low level of xruns. I
> > > > hope one day we can make that work a bit better.
> > >
> > > Were you ever able to get latency tracing to work on your box?
> > >
> > > Lee
> >
> > Not yet, due to the power failure and being off line. I'll give it a
> > shot this evening.
> >
> > Does anyone with an AMD64 platform have this working?
> >
> > Thanks,
> > Mark
> >
>
> Hi Lee,
> OK, I rebuilt the new kernel (2.6.15-rt2) with latency tracing
> enabled. I still get xruns when running Jack and Aqualung. The tracing
> doesn't show anything new although I do have the IRQ off tracing
> turned on and don't see the long timer delays that Iused to see.
>
> What the following shows is that I have a 14uS delay before
Yeah 14 usec is nothing, I think we've established that this isn't a
kernel problem. We should take it to the JACK list.
Lee
On 1/5/06, Lee Revell <[email protected]> wrote:
> On Thu, 2006-01-05 at 16:43 -0800, Mark Knecht wrote:
> > On 1/5/06, Mark Knecht <[email protected]> wrote:
> > > On 1/5/06, Lee Revell <[email protected]> wrote:
> > > > On Thu, 2006-01-05 at 11:33 -0800, Mark Knecht wrote:
> > > > > I expect that I am probably still getting a low level of xruns. I
> > > > > hope one day we can make that work a bit better.
> > > >
> > > > Were you ever able to get latency tracing to work on your box?
> > > >
> > > > Lee
> > >
> > > Not yet, due to the power failure and being off line. I'll give it a
> > > shot this evening.
> > >
> > > Does anyone with an AMD64 platform have this working?
> > >
> > > Thanks,
> > > Mark
> > >
> >
> > Hi Lee,
> > OK, I rebuilt the new kernel (2.6.15-rt2) with latency tracing
> > enabled. I still get xruns when running Jack and Aqualung. The tracing
> > doesn't show anything new although I do have the IRQ off tracing
> > turned on and don't see the long timer delays that Iused to see.
> >
> > What the following shows is that I have a 14uS delay before
>
> Yeah 14 usec is nothing, I think we've established that this isn't a
> kernel problem. We should take it to the JACK list.
>
> Lee
Will do.
Thanks,
Mark