Re: 2.6.14-rc4-rt1 - enable IRQ-off tracing causes kernel to fault at boot

[Mark Knecht <markknecht@gmail.com>]

On 10/14/05, Mark Knecht <markknecht@gmail.com> wrote:
> On 10/13/05, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Mark Knecht <markknecht@gmail.com> wrote:
> >
> > > Ingo & Steve,
> > >    Thank you for your great instructions that even a guitar player
> > > could basically follow. After about an hour of messing around I did
> > > manage to capture the crash. The console file is attached.
> > >
> > > NOTE: The first time I booted the kernel it got to the crash point and
> > > the machine rebooted. The second time it booted I got the trace. Both
> > > boots are in the capture file.
> >
> > thanks, this log is much more informative. No smoking gun though, but it
> > seems something fundamental (probably lowlevel x64 code) has been broken
> > by -rt1.
> >
> > Do the crashes go away if you take the -rc3-rt13 version of
> > arch/x86_64/kernel/entry.S and copy it over into the -rc4-rt1 tree?
> > [this undoes a particular set of CONFIG_CRITICAL_IRQSOFF_TIMING fixes
> > from the x64 code, which i did during -rc3-rt13 => -rc4-rt1]
>
> Indeed it is fixed by doing this. Options are on but the modified
> kernel does boot:

Ingo,
   Good news and strange news:

GOOD NEWS: This problem may or may not be fixed in 2.6.14-rc4-rt5. The
kernel now boots for me with IRQoff tracing enabled, but once again
I'm seeing times that appear to be the timer frequency:

( softirq-timer/0-3    |#0): new 998 us maximum-latency critical section.
 => started at timestamp 403325647: <acpi_processor_idle+0x20/0x379>
 =>   ended at timestamp 403326645: <thread_return+0xb5/0x11a>

Call Trace:<ffffffff8014e58c>{check_critical_timing+492}
<ffffffff8014e9e5>{sub_preempt_count_ti+133}
       <ffffffff803edaec>{thread_return+70}
<ffffffff803edb5b>{thread_return+181}
       <ffffffff803edcc5>{schedule+261} <ffffffff8013723a>{ksoftirqd+138}
       <ffffffff801371b0>{ksoftirqd+0} <ffffffff8014757d>{kthread+205}
       <ffffffff8010e70e>{child_rip+8} <ffffffff801474b0>{kthread+0}
       <ffffffff8010e706>{child_rip+0}
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<ffffffff803ed5b8>] .... __schedule+0xb8/0x5a6
.....[<00000000>] ..   ( <= _stext+0x7feff0e8/0xe8)

 =>   dump-end timestamp 403326728

lightning ~ #

STRANGE NEWS: It now takes between 1-2 minutes for Gnome to log out.

I think possibly something is not exactly right about the timers yet.

- Mark