* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Great, thanks ... I'm not sure which of the 2 patches fixed things,
> > but I now got the following trace. I've not really analyzed this,
> > but it definitely looks like tun_init() is doing something fishy...
> > ("149776 us maximum-latency"!!)
>
* Roland Dreier <[EMAIL PROTECTED]> wrote:
> Great, thanks ... I'm not sure which of the 2 patches fixed things,
> but I now got the following trace. I've not really analyzed this, but
> it definitely looks like tun_init() is doing something fishy...
> ("149776 us maximum-latency"!!)
best wo
Great, thanks ... I'm not sure which of the 2 patches fixed things,
but I now got the following trace. I've not really analyzed this, but
it definitely looks like tun_init() is doing something
fishy... ("149776 us maximum-latency"!!)
- R.
[ 272.392694] tun: Universal TUN/TAP device driver, 1.
* Roland Dreier <[EMAIL PROTECTED]> wrote:
> > I finally got curious enough to want to debug why starting kvm with
> > tun/tap networking produces a bunch of
> >
> > rtc: lost some interrupts at 1024Hz.
> >
> > messages. So I'm assuming it's a ~millisecond irqs-off section
> > somew
* Roland Dreier <[EMAIL PROTECTED]> wrote:
> Any suggestion of where to look? My /proc/latency_trace stays
> stubbornly empty -- are there any sysctls I need to change from their
> default to get latency tracing? I'm a complete noob when it comes to
> the -rt patch, so I'm not sure what the
> I finally got curious enough to want to debug why starting kvm with
> tun/tap networking produces a bunch of
>
> rtc: lost some interrupts at 1024Hz.
>
> messages. So I'm assuming it's a ~millisecond irqs-off section
> somewhere.
And after everything, it's a heisenbug -- I repeatab
> the 64-bit kernel indeed hangs. Does the patch below fix it for you?
Yes, that boots and seems to work fine.
Thanks.
-
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-
> > I'm trying to use 2.6.21-rc4-rt1 to track down who's keeping
> > interrupts off for too long. [...]
> btw., is this something you know for sure (if yes, how do you know?) -
> or is it that you would like to double-check the irqs-off times of
> v2.6.21-to-be?
I finally got curious enou
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm - on 32-bit, CRITICAL_IRQSOFF_TIMING+FUNCTION_TRACING works fine
> for me. I'll try the 64-bit kernel too.
the 64-bit kernel indeed hangs. Does the patch below fix it for you?
Ingo
Index: linux/kernel/timer.c
==
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > OK, another data point. The config below boots and works with
> > 2.6.21-rc4-rt1, but enabling CONFIG_CRITICAL_IRQSOFF_TIMING causes the
> > early boot hang.
>
> ah, i havent tried that option in quite some time, so bitrot is pretty
> likely. Does
* Roland Dreier <[EMAIL PROTECTED]> wrote:
> I'm trying to use 2.6.21-rc4-rt1 to track down who's keeping
> interrupts off for too long. [...]
btw., is this something you know for sure (if yes, how do you know?) -
or is it that you would like to double-check the irqs-off times of
v2.6.21-to-b
* Roland Dreier <[EMAIL PROTECTED]> wrote:
> OK, another data point. The config below boots and works with
> 2.6.21-rc4-rt1, but enabling CONFIG_CRITICAL_IRQSOFF_TIMING causes the
> early boot hang.
>
> Any idea?
ah, i havent tried that option in quite some time, so bitrot is pretty
likely.
OK, another data point. The config below boots and works with
2.6.21-rc4-rt1, but enabling CONFIG_CRITICAL_IRQSOFF_TIMING causes the
early boot hang.
Any idea?
Thanks,
Roland
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc4-rt1
# Sat Mar 24 22:06:44 2007
13 matches
Mail list logo
