BUG with 2.6.16-rt17

BUG with 2.6.16-rt17

[Florian Schmidt]

Hi,

i found the time to build and boot into 2.6.16-rt17 and i got a BUG:

softirq-hrtmono/9[CPU#0]: BUG in check_monotonic_clock at kernel/time/timeofday.
c:162
 [<b0103ec5>] show_trace+0x25/0x30 (20)
 [<b0103ef3>] dump_stack+0x23/0x30 (20)
 [<b011840b>] __WARN_ON+0x6b/0xb0 (40)
 [<b013ca39>] check_monotonic_clock+0x119/0x130 (52)
 [<b013ddca>] __get_monotonic_clock+0xaa/0xc0 (60)
 [<b013dfe1>] get_monotonic_clock+0x21/0x50 (32)
 [<b011bca8>] it_real_fn+0x58/0xa0 (48)
 [<b0130f34>] run_hrtimer_softirq+0xc4/0x270 (60)
 [<b011de74>] ksoftirqd+0x104/0x1c0 (48)
 [<b012d4cc>] kthread+0xdc/0xe0 (48)
 [<b0100e55>] kernel_thread_helper+0x5/0x10 (268615708)
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<b01183c0>] .... __WARN_ON+0x20/0xb0
.....[<b013ca39>] ..   ( <= check_monotonic_clock+0x119/0x130)

------------------------------
| showing all locks held by: |  (softirq-hrtmono/9 [effd07c0,  98]):
------------------------------


Besides the BUG i also am not able to run jackd with a periodsize of 16
frames reliably (xruns and a pretty big cpu load of around 30%). I
suppose this might be due to the tracing overhead though (as
preempt_max_latency shows a value of 34 and 16 frames at 48khz is in the
0.3ms range). Will rebuild w/o the tracing/debug stuff, to see how it
performs then.

Flo

P.S.: .config available here:

http://affenbande.org/~tapas/2.6.16-rt17-config


-- 
Palimm Palimm!
http://tapas.affenbande.org

Re: BUG with 2.6.16-rt17

[Steven Rostedt]

On Wed, 2006-04-19 at 12:46 +0200, Florian Schmidt wrote:
> Hi,
> 
> i found the time to build and boot into 2.6.16-rt17 and i got a BUG:
> 
> softirq-hrtmono/9[CPU#0]: BUG in check_monotonic_clock at kernel/time/timeofday.
> c:162
>  [<b0103ec5>] show_trace+0x25/0x30 (20)
>  [<b0103ef3>] dump_stack+0x23/0x30 (20)
>  [<b011840b>] __WARN_ON+0x6b/0xb0 (40)
>  [<b013ca39>] check_monotonic_clock+0x119/0x130 (52)
>  [<b013ddca>] __get_monotonic_clock+0xaa/0xc0 (60)
>  [<b013dfe1>] get_monotonic_clock+0x21/0x50 (32)
>  [<b011bca8>] it_real_fn+0x58/0xa0 (48)
>  [<b0130f34>] run_hrtimer_softirq+0xc4/0x270 (60)
>  [<b011de74>] ksoftirqd+0x104/0x1c0 (48)
>  [<b012d4cc>] kthread+0xdc/0xe0 (48)
>  [<b0100e55>] kernel_thread_helper+0x5/0x10 (268615708)
> ---------------------------
> | preempt count: 00000001 ]
> | 1-level deep critical section nesting:
> ----------------------------------------
> .. [<b01183c0>] .... __WARN_ON+0x20/0xb0
> .....[<b013ca39>] ..   ( <= check_monotonic_clock+0x119/0x130)
> 
> ------------------------------
> | showing all locks held by: |  (softirq-hrtmono/9 [effd07c0,  98]):
> ------------------------------
> 

Ingo,

I've been running with John Stultz's patch for a bit (the one with
cycle_wrap_bucket), and it seems to solve the problems I've had with
monotonic_clock going backwards.  Maybe it's time to pull that into -rt.

-- Steve