Hi,
I still get an Oops when mounting an XFS filesystem under 2.6.15-rt1-sr1
(Same happend for 2.6.15-rc7-rt1: http://lkml.org/lkml/2005/12/29/67 )
I can make the Oops go away by changing this config option from
# CONFIG_DEBUG_RT_LOCKING_MODE is not set
to
CONFIG_DEBUG_RT_LOCKING_MODE=y
Full dmesg output and .config can be found here:
http://home.hia.no/~vegardl/rt/
Please CC me as I'm not subscribed to the list.
Thanks,
--
Vegard Lima <[email protected]>
On Thu, 5 Jan 2006, Vegard Lima wrote:
> Hi,
>
> I still get an Oops when mounting an XFS filesystem under 2.6.15-rt1-sr1
> (Same happend for 2.6.15-rc7-rt1: http://lkml.org/lkml/2005/12/29/67 )
>
> I can make the Oops go away by changing this config option from
> # CONFIG_DEBUG_RT_LOCKING_MODE is not set
> to
> CONFIG_DEBUG_RT_LOCKING_MODE=y
>
Hi Vergard,
I just want to make sure I understand the above.
The bug happens when CONFIG_DEBUG_RT_LOCKING_MODE is _not_ set?
And the bug goes away when it _is_ set?
Thanks,
-- Steve
> Full dmesg output and .config can be found here:
> http://home.hia.no/~vegardl/rt/
>
>
to den 05.01.2006 Klokka 08:38 (-0500) skreiv Steven Rostedt:
> On Thu, 5 Jan 2006, Vegard Lima wrote:
> > I still get an Oops when mounting an XFS filesystem under 2.6.15-rt1-sr1
> > (Same happend for 2.6.15-rc7-rt1: http://lkml.org/lkml/2005/12/29/67 )
> >
> > I can make the Oops go away by changing this config option from
> > # CONFIG_DEBUG_RT_LOCKING_MODE is not set
> > to
> > CONFIG_DEBUG_RT_LOCKING_MODE=y
>
> I just want to make sure I understand the above.
>
> The bug happens when CONFIG_DEBUG_RT_LOCKING_MODE is _not_ set?
>
> And the bug goes away when it _is_ set?
Hi Steven,
that is correct.
Thanks,
--
Vegard Lima <[email protected]>
On Thu, 2006-01-05 at 08:38 -0500, Steven Rostedt wrote:
> Hi Vergard,
>
> I just want to make sure I understand the above.
>
> The bug happens when CONFIG_DEBUG_RT_LOCKING_MODE is _not_ set?
>
> And the bug goes away when it _is_ set?
Looks like a race , so maybe a timing issue. Just turn on some debugging
in the code path that slows/speeds things just enough .
Daniel
On Thu, 5 Jan 2006, Daniel Walker wrote:
> On Thu, 2006-01-05 at 08:38 -0500, Steven Rostedt wrote:
>
> > Hi Vergard,
> >
> > I just want to make sure I understand the above.
> >
> > The bug happens when CONFIG_DEBUG_RT_LOCKING_MODE is _not_ set?
> >
> > And the bug goes away when it _is_ set?
>
>
> Looks like a race , so maybe a timing issue. Just turn on some debugging
> in the code path that slows/speeds things just enough .
>
> Daniel
CONFIG_DEBUG_RT_LOCKING_MODE turns spinlock_t into raw_spinlock_t again as
far as I can see. It is probably some spinlock_t which has to be a
raw_spinlock_t for the time being.
Esben
>
> -
> 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-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, 2006-01-05 at 16:19 +0100, Esben Nielsen wrote:
>
> CONFIG_DEBUG_RT_LOCKING_MODE turns spinlock_t into raw_spinlock_t again as
> far as I can see. It is probably some spinlock_t which has to be a
> raw_spinlock_t for the time being.
It looks like it may still be using mutexes in one mode, but they aren't
preemptive . Or that's what it says in the menuconfig help section .
I've never used that option, honestly .
Daniel
to den 05.01.2006 Klokka 16:19 (+0100) skreiv Esben Nielsen:
>
> On Thu, 5 Jan 2006, Daniel Walker wrote:
> >
> > Looks like a race , so maybe a timing issue. Just turn on some debugging
> > in the code path that slows/speeds things just enough .
>
> CONFIG_DEBUG_RT_LOCKING_MODE turns spinlock_t into raw_spinlock_t again as
> far as I can see. It is probably some spinlock_t which has to be a
> raw_spinlock_t for the time being.
Just FYI 2.5.14-rt22 worked fine with
CONFIG_DEBUG_RT_LOCKING_MODE _not_ set.
Thanks,
--
Vegard Lima <[email protected]>
On Thu, 5 Jan 2006, Vegard Lima wrote:
> to den 05.01.2006 Klokka 16:19 (+0100) skreiv Esben Nielsen:
> >
> > On Thu, 5 Jan 2006, Daniel Walker wrote:
> > >
> > > Looks like a race , so maybe a timing issue. Just turn on some debugging
> > > in the code path that slows/speeds things just enough .
> >
> > CONFIG_DEBUG_RT_LOCKING_MODE turns spinlock_t into raw_spinlock_t again as
> > far as I can see. It is probably some spinlock_t which has to be a
> > raw_spinlock_t for the time being.
>
> Just FYI 2.5.14-rt22 worked fine with
> CONFIG_DEBUG_RT_LOCKING_MODE _not_ set.
Unfortunately, *a lot* changed between 2.6.14-rt22 (assuming you had a
typo) and 2.6.15-rt1 so this doesn't narrow it down very much. Have you
tried any of the 2.6.15-rcX-rtX versions?
-- Steve
to den 05.01.2006 Klokka 16:49 (-0500) skreiv Steven Rostedt:
> On Thu, 5 Jan 2006, Vegard Lima wrote:
>
> > to den 05.01.2006 Klokka 16:19 (+0100) skreiv Esben Nielsen:
> > >
> > > On Thu, 5 Jan 2006, Daniel Walker wrote:
> > > >
> > > > Looks like a race , so maybe a timing issue. Just turn on some debugging
> > > > in the code path that slows/speeds things just enough .
> > >
> > > CONFIG_DEBUG_RT_LOCKING_MODE turns spinlock_t into raw_spinlock_t again as
> > > far as I can see. It is probably some spinlock_t which has to be a
> > > raw_spinlock_t for the time being.
> >
> > Just FYI 2.5.14-rt22 worked fine with
> > CONFIG_DEBUG_RT_LOCKING_MODE _not_ set.
>
> Unfortunately, *a lot* changed between 2.6.14-rt22 (assuming you had a
> typo) and 2.6.15-rt1 so this doesn't narrow it down very much. Have you
> tried any of the 2.6.15-rcX-rtX versions?
And unfortunately none of the 2.6.15-rcX-rtX kernels would compile for
me...
(Errors compiling lib/rwsem.c in rc5-rt1 f.ex.)
Thanks,
--
Vegard Lima <[email protected]>
On Thu, 5 Jan 2006, Vegard Lima wrote:
>
> And unfortunately none of the 2.6.15-rcX-rtX kernels would compile for
> me...
> (Errors compiling lib/rwsem.c in rc5-rt1 f.ex.)
>
Oh darn, I forgot about that :-/
-- Steve