2.6.15-rc7-rt1

2.6.15-rc7-rt1

[Ingo Molnar]

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

Re: 2.6.15-rc7-rt1

[K.R. Foley]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
   kr

Re: 2.6.15-rc7-rt1

[Ingo Molnar]

* K.R. Foley <kr@cybsft.com> 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

Re: 2.6.15-rc7-rt1

[Jan Engelhardt]

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
-- 

Re: 2.6.15-rc7-rt1

[Steven Rostedt]

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

Re: 2.6.15-rc7-rt1

[Steven Rostedt]

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

Re: 2.6.15-rc7-rt1

[Mark Knecht]

On 12/31/05, Steven Rostedt <rostedt@goodmis.org> 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 majordomo@vger.kernel.org
> 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>

Re: 2.6.15-rc7-rt1

[Jan Engelhardt]

>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
-- 

Re: 2.6.15-rc7-rt1

[Steven Rostedt]

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);

Re: 2.6.15-rc7-rt1

[Steven Rostedt]

FYI,

Ingo has been paying attention to this thread :)

2.6.15-rc7-rt2 is out and contains this patch.

-- Steve

Re: 2.6.15-rc7-rt1

[Mark Knecht]

On 1/2/06, Steven Rostedt <rostedt@goodmis.org> 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

Re: 2.6.15-rc7-rt1

[Lee Revell]

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

Re: 2.6.15-rc7-rt1

[Mark Knecht]

On 1/5/06, Lee Revell <rlrevell@joe-job.com> 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

Re: 2.6.15-rc7-rt1

[Mark Knecht]

On 1/5/06, Mark Knecht <markknecht@gmail.com> wrote:
> On 1/5/06, Lee Revell <rlrevell@joe-job.com> 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

Re: 2.6.15-rc7-rt1

[Lee Revell]

On Thu, 2006-01-05 at 16:43 -0800, Mark Knecht wrote:
> On 1/5/06, Mark Knecht <markknecht@gmail.com> wrote:
> > On 1/5/06, Lee Revell <rlrevell@joe-job.com> 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

Re: 2.6.15-rc7-rt1

[Mark Knecht]

On 1/5/06, Lee Revell <rlrevell@joe-job.com> wrote:
> On Thu, 2006-01-05 at 16:43 -0800, Mark Knecht wrote:
> > On 1/5/06, Mark Knecht <markknecht@gmail.com> wrote:
> > > On 1/5/06, Lee Revell <rlrevell@joe-job.com> 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