Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3

[Ingo Molnar]

* Dominik Karall <dominik.karall@xxxxxxx> wrote:

> > The trace looks like mplayer reading from a FAT filesystem.  Can you
> > reproduce the problem if you do whatever you were doing with mplayer
> > again?
> 
> i could reproduce it now, but only once. it appeared when i started an
> avi movie from my fat32 partition. mplayer stopped at buffering 2% and
> does not play the movie. i tried to start mplayer again and reproduce
> it, but the bug does not appear again. mplayer only stopped at 2%
> buffering and does nothing more. it seems like the file couldn't be
> read clearly now from the fat32 partition, as it does not work with
> xine and others too. here is the bug i get now:

did you retry after rebooting the box? Such bugs can easily depend on IO
patterns (and code sequences) that only happen the first time the file
is accessed in such way (inode init, delays due to IO, etc.). So what
would be nice to try (if you havent tried it already) is to:

 - reboot the box into this same kernel and retry - do you get the oops?

 - if you can reproduce the oops this way in a more or less reliable way
   then please try the same with 2.6.9-rc4-mm1 too.

it _looks_ like a bug not related to the RT patch but a connection
cannot be ruled out: the mutex based kernel changes locking for fatfs
too, and could trigger hidden or hard-to-trigger bugs in an easier way.

In the locking sense the RT kernel can be considered equivalent to an
SMP box with an infinite number of CPUs, even on a uniprocessor. It
tests SMP locking in way nothing else does.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/