* 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
* 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 would be
* 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!!)
best would
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,
* 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
> >
* 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
* 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 right
* 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
somewhere.
And
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.6
> 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
> 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
> > 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
* 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
* 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
* 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. 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-be?
* 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 the
* 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
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 enough to
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
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 repeatably get
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
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
26 matches
Mail list logo
