LinuxLists.cc - MPlayer broken under 2.6.15-rc7-rt1?

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Saturday 31 December 2005 18:29, Bradley Reed wrote:
> I have tried MPlayer versions 1.0pre6, 1.0pre7, and cvs from today and
> they all work fine under 2.6.14 and 2.6.14-rt21/22.
>
> I booted into 2.6.15-rc7-rt1 and the same MPlayer binaries segfault on
> every video I try and play. Yes, I have nvidia modules loaded, so won't
> get much help, but thought someone might like to know.
>
> xine plays the videos fine.
>
> BTW, other than MPLayer problems, everything else works great.
>
> Brad

Try mplayer -nortc? If that work's it'll confirm the problem is with opening
the rtc device.

--
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

2005-12-31 18:59:40

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sat, 31 Dec 2005 18:47:48 +0000
Alistair John Strachan <[email protected]> wrote:

> Try mplayer -nortc? If that work's it'll confirm the problem is with
> opening the rtc device.
>

It works fine with the -nortc option. I wonder why it can't open it? It
exists and the perms look pretty wide open.

breed@galactus:~[1024]$ ls -l /dev/rtc
lrwxrwxrwx 1 root root 8 2005-12-31 19:37:09 /dev/rtc -> misc/rtc
breed@galactus:~[1025]$ ls -l /dev/misc/rtc
crw-rw-rw- 1 root root 10, 135 2005-12-31 19:36:03 /dev/misc/rtc

Thanks,
Brad

2005-12-31 19:14:15

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Saturday 31 December 2005 18:59, Bradley Reed wrote:
> On Sat, 31 Dec 2005 18:47:48 +0000
>
> Alistair John Strachan <[email protected]> wrote:
> > Try mplayer -nortc? If that work's it'll confirm the problem is with
> > opening the rtc device.
>
> It works fine with the -nortc option. I wonder why it can't open it? It
> exists and the perms look pretty wide open.

That's a question for one of the hr-timer guys, but it's 2006 in just under
five hours here, so it might take a while for somebody to get back to you :-)

--
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

2005-12-31 19:51:51

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sat, 2005-12-31 at 20:29 +0200, Bradley Reed wrote:
> I have tried MPlayer versions 1.0pre6, 1.0pre7, and cvs from today and
> they all work fine under 2.6.14 and 2.6.14-rt21/22.
>
> I booted into 2.6.15-rc7-rt1 and the same MPlayer binaries segfault on
> every video I try and play. Yes, I have nvidia modules loaded, so won't
> get much help, but thought someone might like to know.
>
> xine plays the videos fine.
>
> BTW, other than MPLayer problems, everything else works great.
>
> Brad
>
> dmesg shows:
> ------------[ cut here ]------------
> kernel BUG at include/linux/timer.h:83!

Hey guys (Ingo, Thomas and John), second person with the rtc bug.

Bradley and Jan, try the below patch and see if it doesn't deadlock the
system. I'm not sure why they pulled out the mod_timer add_timer and
del_timer from the rtc_lock, but there might be a call back to it.

-- Steve

Index: linux-2.6.15-rc7-rt1/drivers/char/rtc.c
===================================================================
--- linux-2.6.15-rc7-rt1.orig/drivers/char/rtc.c 2005-12-28 14:02:48.000000000 -0500
+++ linux-2.6.15-rc7-rt1/drivers/char/rtc.c 2005-12-31 14:41:58.000000000 -0500
@@ -384,7 +384,6 @@
}

#ifdef RTC_IRQ
-
/*
* A very tiny interrupt handler. It runs with SA_INTERRUPT set,
* but there is possibility of conflicting with the set_rtc_mmss()
@@ -397,8 +396,6 @@

irqreturn_t rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
- int mod;
-
/*
* Can be an alarm interrupt, update complete interrupt,
* or a periodic interrupt. We store the status in the
@@ -420,13 +417,10 @@
rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);
}

- mod = 0;
if (rtc_status & RTC_TIMER_ON)
- mod = 1;
+ mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);

spin_unlock (&rtc_lock);
- if (mod)
- mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);

/* Now do the rest of the actions */
spin_lock(&rtc_task_lock);
@@ -588,24 +582,18 @@
case RTC_PIE_OFF: /* Mask periodic int. enab. bit */
{
unsigned long flags; /* can be called from isr via rtc_control() */
- int del = 0;
-
spin_lock_irqsave (&rtc_lock, flags);
mask_rtc_irq_bit_locked(RTC_PIE);
if (rtc_status & RTC_TIMER_ON) {
rtc_status &= ~RTC_TIMER_ON;
- del = 1;
+ del_timer(&rtc_irq_timer);
}
spin_unlock_irqrestore (&rtc_lock, flags);
- if (del)
- del_timer(&rtc_irq_timer);
return 0;
}
case RTC_PIE_ON: /* Allow periodic ints */
{
unsigned long flags; /* can be called from isr via rtc_control() */
- int add = 0;
-
/*
* We don't really want Joe User enabling more
* than 64Hz of interrupts on a multi-user machine.
@@ -617,13 +605,11 @@
spin_lock_irqsave (&rtc_lock, flags);
if (!(rtc_status & RTC_TIMER_ON)) {
rtc_irq_timer.expires = jiffies + HZ/rtc_freq + 2*HZ/100;
+ add_timer(&rtc_irq_timer);
rtc_status |= RTC_TIMER_ON;
- add = 1;
}
set_rtc_irq_bit_locked(RTC_PIE);
spin_unlock_irqrestore (&rtc_lock, flags);
- if (add)
- add_timer(&rtc_irq_timer);
return 0;
}
case RTC_UIE_OFF: /* Mask ints from RTC updates. */
@@ -914,7 +900,6 @@
{
#ifdef RTC_IRQ
unsigned char tmp;
- int del;

if (rtc_has_irq == 0)
goto no_irq;
@@ -933,14 +918,11 @@
CMOS_WRITE(tmp, RTC_CONTROL);
CMOS_READ(RTC_INTR_FLAGS);
}
- del = 0;
if (rtc_status & RTC_TIMER_ON) {
rtc_status &= ~RTC_TIMER_ON;
- del = 1;
+ del_timer(&rtc_irq_timer);
}
spin_unlock_irq(&rtc_lock);
- if (del)
- del_timer(&rtc_irq_timer);

if (file->f_flags & FASYNC) {
rtc_fasync (-1, file, 0);
@@ -1017,7 +999,6 @@
return -EIO;
#else
unsigned char tmp;
- int del;

spin_lock_irq(&rtc_lock);
spin_lock(&rtc_task_lock);
@@ -1037,15 +1018,12 @@
CMOS_WRITE(tmp, RTC_CONTROL);
CMOS_READ(RTC_INTR_FLAGS);
}
- del = 0;
if (rtc_status & RTC_TIMER_ON) {
rtc_status &= ~RTC_TIMER_ON;
- del = 1;
+ del_timer(&rtc_irq_timer);
}
rtc_status &= ~RTC_IS_OPEN;
spin_unlock(&rtc_task_lock);
- if (del)
- del_timer(&rtc_irq_timer);
spin_unlock_irq(&rtc_lock);
return 0;
#endif
@@ -1307,7 +1285,6 @@
static void rtc_dropped_irq(unsigned long data)
{
unsigned long freq;
- int mod;

spin_lock_irq (&rtc_lock);

@@ -1317,9 +1294,8 @@
}

/* Just in case someone disabled the timer from behind our back... */
- mod = 0;
if (rtc_status & RTC_TIMER_ON)
- mod = 1;
+ mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);

rtc_irq_data += ((rtc_freq/HZ)<<8);
rtc_irq_data &= ~0xff;
@@ -1328,8 +1304,6 @@
freq = rtc_freq;

spin_unlock_irq(&rtc_lock);
- if (mod)
- mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);

printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);

2005-12-31 20:08:06

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

Steve,

Perhaps I'm doing something wrong, but it doesn't seem to apply cleanly
here:

patching file drivers/char/rtc.c
Hunk #1 succeeded at 384 with fuzz 2.
Hunk #2 FAILED at 396.
Hunk #3 FAILED at 417.
Hunk #4 FAILED at 582.
Hunk #5 FAILED at 605.
Hunk #6 FAILED at 900.
Hunk #7 FAILED at 918.
Hunk #8 FAILED at 999.
Hunk #9 FAILED at 1018.
Hunk #10 FAILED at 1285.
Hunk #11 FAILED at 1294.
Hunk #12 FAILED at 1304.
11 out of 12 hunks FAILED -- saving rejects to file drivers/char/rtc.c.rej

Brad

On Sat, 31 Dec 2005 14:51:36 -0500
Steven Rostedt <[email protected]> wrote:

> Hey guys (Ingo, Thomas and John), second person with the rtc bug.
>
> Bradley and Jan, try the below patch and see if it doesn't deadlock
> the system. I'm not sure why they pulled out the mod_timer add_timer
> and del_timer from the rtc_lock, but there might be a call back to it.
>
> -- Steve
>
> Index: linux-2.6.15-rc7-rt1/drivers/char/rtc.c
> ===================================================================
> --- linux-2.6.15-rc7-rt1.orig/drivers/char/rtc.c 2005-12-28

2005-12-31 20:34:11

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sat, 2005-12-31 at 22:07 +0200, Bradley Reed wrote:
> Steve,
>
> Perhaps I'm doing something wrong, but it doesn't seem to apply cleanly
> here:

Make sure you're in the directory of 2.6.15-rc7-rt1 (head Makefile and
see if you see:)

----
$ head Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 15
EXTRAVERSION =-rc7-rt1
NAME=Sliding Snow Leopard

# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
# More info can be located in ./README
# Comments in this file are targeted only to the developer, do not
----

Then in that same directory try:

patch -p1 --dry-run < my-rtc-patchfile

See if it works, and if it does try it again without the --dry-run
option. I just tried applying it to a clean 2.6.15-rc7-rt1 and it
worked.

-- Steve

2005-12-31 20:58:54

by Jan Engelhardt

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

>Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

I seriously demand that this be changed into "RTC broekn under..."! :)

>> BTW, other than MPLayer problems, everything else works great.

BTW2, 2.6.15 has an option in ALSA to use RTC as timing source
(CONFIG_SND_RTCTIMER). I do not have it activated ATM, nor do I use it (as
said, I used "-ao null" for mplayer), but would use of alsa with this rtc
timesourcing also crash?

>Bradley and Jan, try the below patch and see if it doesn't deadlock the
>system. I'm not sure why they pulled out the mod_timer add_timer and
>del_timer from the rtc_lock, but there might be a call back to it.

Well, it did not deadlock my system. Interesting! It displayed "BUG", as
posted multiple times here. Otherwise, it just oopsed. That is, I could
continue using the system, with the exception, of course, /dev/rtc. Opening
rtc however did not lock a process trying to do so, but instead (as
designed in the code) returns -EBUSY.

>
>Index: linux-2.6.15-rc7-rt1/drivers/char/rtc.c

This patch fixes the rtc BUG for me.

Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

2005-12-31 22:47:06

[permalink] [raw]

Subject: RTC broken under 2.6.15-rc7-rt1 (was: Re: MPlayer broken under 2.6.15-rc7-rt1?)

On Sat, 2005-12-31 at 21:58 +0100, Jan Engelhardt wrote:
> >Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?
>
> I seriously demand that this be changed into "RTC broekn under..."! :)

Done ;)

[...]

> >
> >Index: linux-2.6.15-rc7-rt1/drivers/char/rtc.c
>
> This patch fixes the rtc BUG for me.

Yeah, attached is a program that does what mplayer does. I run it from
the command line like this:

# for i in `seq 10000`; do ./rtc_ioctl ; done

And with the patch it runs perfectly fine. Without it, it segfaults
several times.

-- Steve

Attachments:

rtc_ioctl.c (473.00 B)

2005-12-31 23:22:49

[permalink] [raw]

Subject: Re: RTC broken under 2.6.15-rc7-rt1 (was: Re: MPlayer broken under 2.6.15-rc7-rt1?)

On Sat, 31 Dec 2005 17:46:55 -0500
Steven Rostedt <[email protected]> wrote:

> On Sat, 2005-12-31 at 21:58 +0100, Jan Engelhardt wrote:
> > >Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?
> >
> > I seriously demand that this be changed into "RTC broekn
> > under..."! :)
>
> Done ;)
>
> [...]
>
> > >
> > >Index: linux-2.6.15-rc7-rt1/drivers/char/rtc.c
> >
> > This patch fixes the rtc BUG for me.
>

And me too. I had inadvertently cut off a bit at the very top of your
patch, when I re-cut and pasted, it applied fine.

Shouldn't patch kernels this close to new years. (Which was an hour and
a half ago here...)

> Yeah, attached is a program that does what mplayer does. I run it
> from the command line like this:
>
> # for i in `seq 10000`; do ./rtc_ioctl ; done
>
> And with the patch it runs perfectly fine. Without it, it segfaults
> several times.

Without it, it segfaults 100% here:

root@galactus:~[1002]# for i in `seq 10`; do ./rtc_ioctl; done
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault

Brad

2006-01-01 00:04:39

[permalink] [raw]

Subject: Re: RTC broken under 2.6.15-rc7-rt1 (was: Re: MPlayer broken under 2.6.15-rc7-rt1?)

On Sun, 1 Jan 2006, Bradley Reed wrote:

> Shouldn't patch kernels this close to new years. (Which was an hour and
> a half ago here...)
>

Happy New Year! I've got 5 hours to go.

-- Steve

2006-01-01 09:14:25

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

2006-01-01 09:51:26

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sun, 01 Jan 2006 10:14:21 +0100
Arjan van de Ven <[email protected]> wrote:

> On Sat, 2005-12-31 at 20:29 +0200, Bradley Reed wrote:
> > I have tried MPlayer versions 1.0pre6, 1.0pre7, and cvs from today
> > and they all work fine under 2.6.14 and 2.6.14-rt21/22.
> >
> > I booted into 2.6.15-rc7-rt1 and the same MPlayer binaries segfault
> > on every video I try and play. Yes, I have nvidia modules loaded,
> > so won't get much help, but thought someone might like to know.
>
>
> you know, you could have done a little bit more effort and reproduced
> this without the binary crud... it's not that hard you know and it
> shows that you actually care about the problem enough that you want
> to make it worthwhile for people to look into it.
>

And you could have saved the time and effort of replying, as you had
nothing useful to say. Why do you expect kernel users (non-developers)
to jump through hoops and cripple their systems in order to provide bug
reports? Exactly how could I have tested MPLayer realistically without
Xv support? It isn't that easy to swap video cards in a laptop.

I noticed that after trying a new kernel a user space tool, which
worked fine under earlier kernels, was no longer working. Linus himself
said that this is worth pointing out. I did so.

Yes, I was very fortunate in that someone else with a non-tainted
kernel noticed a similar bug with /dev/rtc, and even more fortunate
that Steven Rostedt provided a patch that worked for both of us. As I
had said in my original post I was not expecting that, but thought the
bug was worth reporting.

DO YOU REALLY PREFER USERS NOT REPORT BUGS?

Brad

2006-01-01 11:26:21

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

>
> DO YOU REALLY PREFER USERS NOT REPORT BUGS?

It is better to not have any reports than to have "bad" bugreports (bad
in the sense that they are caused by external kernel components), that
much is obvious, since such reports cost a lot of time from the
developers, time that could better be spent on "real" bugs. Often you
can deal with 3 real bugs in the time it takes to find out that a
bugreport is really a "bad" one (because you end up looking for things
that aren't there compared to things that are there and usually are
found quicker).

So the question is, are all tainted bugreports bad bugreports. The
answer again is simple, "no, not all". However, many are. So where to
draw the line?
A rather good line is "is it reproducable without the external
components"; if it is, then it's clearly a non-bad report (and the
non-tainted reproducer means the developer even has a chance to try it
during debugging). If it's not, there is a pretty high chance that it's
a "bad" report; this from my experience of being on the receiving end of
a distros bugreporting system for a long time. If the reported can't or
can't be bothered to reproduce it, the developer spending time on it is
generally a waste of time.

What you have here is a bit of a gray area; you're using one of the
maybe-illegal binary modules that has a really long history of
introducing bugs that, just from the oops, may appear unrelated to this
module, and you can't reproduce it without. Just not because the bug
won't happen, but because you state that the application that triggers
it won't run without it. In this case, someone else apparently reported
the same issue but without external influences, so it looks like a real
bug. But we only know that because someone else saw it, not because of
your report...

So getting back to your question:
I would say that I think it's generally better that bugs that cannot be
reproduced on an untainted kernel are not reported on lkml, but reported
to the vendor of the tainting module instead, simply because it's very
likely that it'll waste precious debug time. (debugging isn't the most
favorite task developers do, having it be a waste of time only makes it
more so)

2006-01-01 11:50:39

by Adrian Bunk

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sun, Jan 01, 2006 at 11:51:21AM +0200, Bradley Reed wrote:
> On Sun, 01 Jan 2006 10:14:21 +0100
> Arjan van de Ven <[email protected]> wrote:
>
> > On Sat, 2005-12-31 at 20:29 +0200, Bradley Reed wrote:
> > > I have tried MPlayer versions 1.0pre6, 1.0pre7, and cvs from today
> > > and they all work fine under 2.6.14 and 2.6.14-rt21/22.
> > >
> > > I booted into 2.6.15-rc7-rt1 and the same MPlayer binaries segfault
> > > on every video I try and play. Yes, I have nvidia modules loaded,
> > > so won't get much help, but thought someone might like to know.
> >
> >
> > you know, you could have done a little bit more effort and reproduced
> > this without the binary crud... it's not that hard you know and it
> > shows that you actually care about the problem enough that you want
> > to make it worthwhile for people to look into it.
> >
>
> And you could have saved the time and effort of replying, as you had
> nothing useful to say. Why do you expect kernel users (non-developers)
> to jump through hoops and cripple their systems in order to provide bug
> reports? Exactly how could I have tested MPLayer realistically without
> Xv support? It isn't that easy to swap video cards in a laptop.
>...

MPlayer has more than enough output drivers including some that work
without the nvidia module.

If your problem was an RTC one, it might have even trigger using the
AAlib output driver.

> DO YOU REALLY PREFER USERS NOT REPORT BUGS?

There are _many_ new bug reports every day and too few developers with
too few spare time to go through all of them.

A binary-only module can do _anything_ even at module load time, and
_noone_ except people with access to the source code can debug such
problems.

Many developers know how it feels if after spending hours on debugging a
problem someone reported it turned out "oh, it goes away if I remove the
nvidia/vmware/... module".

It usually takes two parties to get a bug found:

A developer willing to look into it and a user willing to provide any
assistance for the developer.

The latter might include 10 reboots with different kernel patches
applied, and compared to that it's not a big issue to boot in these
cases without binary-only modules ever loaded. Your system might be
crippled, but only for the time you are helping the developer to
identify your problem.

> Brad

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-01-01 12:12:10

by Jerome Lacoste

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On 1/1/06, Arjan van de Ven <[email protected]> wrote:
>
> >
> > DO YOU REALLY PREFER USERS NOT REPORT BUGS?

[...]

> So getting back to your question:
> I would say that I think it's generally better that bugs that cannot be
> reproduced on an untainted kernel are not reported on lkml, but reported
> to the vendor of the tainting module instead, simply because it's very
> likely that it'll waste precious debug time.

Although I like the idea of making the vendors of binary modules
really aware of the costs they introduce with regard to debug issues
on tainted system, if I was them, the first thing I would say is
"contact the vendor of the part of the system that changed", i.e. the
kernel.

J

2006-01-01 12:25:57

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

> Although I like the idea of making the vendors of binary modules
> really aware of the costs they introduce with regard to debug issues
> on tainted system, if I was them, the first thing I would say is
> "contact the vendor of the part of the system that changed", i.e. the
> kernel.

the good ones don't, and investigate. The bad ones... do you really want
their code in your kernel??

2006-01-01 13:16:16

by Adrian Bunk

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sun, Jan 01, 2006 at 02:54:02PM +0200, Bradley Reed wrote:
> On Sun, 1 Jan 2006 12:50:38 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > MPlayer has more than enough output drivers including some that work
> > without the nvidia module.
> >
> > If your problem was an RTC one, it might have even trigger using the
> > AAlib output driver.
>
> True, I can reproduce this kernel bug by running mplayer with AAlib
> output without nvidia's module loaded. I never run mplayer under usual
> use with the aalib library and never thought to test with it. If I had
> been asked to try that, I would have.
>
> Yes, I understand that GPL fanatics like Arjan refuse to look at bugs
> from tainted kernels, regardless of whether the tainted kernel module
> is at fault. That is his right. So be it.
>...

It's not about the GPL, it's simply a matter of fact that noone can
debug a kernel if any binary-onluy module was ever loaded.

There have been too many problems in the past where after hours of
debugging it turned out that it wasn't reproducible without the nvidia
module.

> Reporting all kernel bugs SOLELY to the source of a binary kernel
> module (NVidia in my case) is rather pointless as the only thing that
> changed in my system is the kernel. Their logical conclusion is the bug
> is in the part of the system that changed, i.e. the kernel. In this
> case it was a kernel bug as Mr. Rostedt's patch showed.
>...

A kernel module can do _anything it wants_ in the whole kernel.

If the nvidia module did something in a strange and completely
unsupported way or if the nvidia module contained a bug that only
wasn't triggered before a bug might not be in the changed kernel.

In your case the bug was in the kernel, but who can debug such bugs?

We don't have the sources for the nvidia module.
The nvidia developers have the source of the kernel.

Guess who has the source of everything involved and can therefore
debug the problem...

> Brad

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-01-01 13:25:10

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sun, Jan 01, 2006 at 02:54:02PM +0200, Bradley Reed wrote:
> > On Sun, 1 Jan 2006 12:50:38 +0100
> > Adrian Bunk <[email protected]> wrote:
> >
> > > MPlayer has more than enough output drivers including some that work
> > > without the nvidia module.
> > >
> > > If your problem was an RTC one, it might have even trigger using the
> > > AAlib output driver.
> >
> > True, I can reproduce this kernel bug by running mplayer with AAlib
> > output without nvidia's module loaded. I never run mplayer under usual
> > use with the aalib library and never thought to test with it. If I had
> > been asked to try that, I would have.
> >
> Yes, I understand that GPL fanatics like Arjan refuse to look at bugs
> from tainted kernels, regardless of whether the tainted kernel module
> is at fault. That is his right. So be it.
> ...

I wonder what made you describe me as a fanatic based on my posting? My
posting was not about license at all, it was about the non-debugability
and the wasting of time (compared to spending time on bugs where the
developer does have a chance). Maybe you're one of those nvidia fanatics
who wants to demand that all kernel developers spent all their time on
your toy without you having to pay anything, even if it's not a useful
way for these people to spend their time in general.
(see how easy it is to name someone a fanatic? :)

2006-01-01 13:28:53

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sun, 2006-01-01 at 13:12 +0100, jerome lacoste wrote:
> On 1/1/06, Arjan van de Ven <[email protected]> wrote:
> >
> > >
> > > DO YOU REALLY PREFER USERS NOT REPORT BUGS?
>
> [...]
>
> > So getting back to your question:
> > I would say that I think it's generally better that bugs that cannot be
> > reproduced on an untainted kernel are not reported on lkml, but reported
> > to the vendor of the tainting module instead, simply because it's very
> > likely that it'll waste precious debug time.
>
> Although I like the idea of making the vendors of binary modules
> really aware of the costs they introduce with regard to debug issues
> on tainted system, if I was them, the first thing I would say is
> "contact the vendor of the part of the system that changed", i.e. the
> kernel.

btw you do have a point; should nvidia care if someone patches their
kernel with the -rt patchkit, something which changes many rules inside
the kernel. I'm actually surprised such binary modules work *at all*
given how many of the rules have changed. (For source-compiled modules
it's a bit less of a surprise since the api changes get compiled
through, eg most of the cases the API stayed the same the ABI didn't ,
for binary ones.. that only works if you're lucky I guess. Even for
source modules several needed changes (just look at the -rt patchkit) ).

To some degree, if you use binary modules and experimental patches, you
are on your own; the module vendor is unlikely to care, but so are most
of the developers of the patchkits.. (after all.. there is a good reason
-rt has different rules, that is the whole POINT of the -rt patches,
different rules to achieve the goal of extremely low latencies)

2006-01-01 13:41:28

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sun, 2006-01-01 at 11:51 +0200, Bradley Reed wrote:

> And you could have saved the time and effort of replying, as you had
> nothing useful to say. Why do you expect kernel users (non-developers)
> to jump through hoops and cripple their systems in order to provide bug
> reports? Exactly how could I have tested MPLayer realistically without
> Xv support? It isn't that easy to swap video cards in a laptop.

Hi Bradley,

I never even noticed that it was a tainted kernel. But you did have a
same problem as someone without it. I too have two machines with NVidia
cards that are not very useful without the binary drivers. Thus the next
two machines I bought (a server, and a laptop) I made damn well that it
didn't have a NVidia card in them (I used to be a devoted NVidia
consumer, now I'm a frustrated one).

The reason that I will no long run test kernels with NVidia is that that
module has caused more bugs than I could stand. __Especially__ with the
-rt patch. I'm very surprised that you actually have the nvidia module
working with that patch, since it does things that the nvidia module
doesn't even know about. I gave up trying to modify the nvidia stuff to
work with the -rt patch almost a year ago. Too much black magic going
on in the binary part.

>
> I noticed that after trying a new kernel a user space tool, which
> worked fine under earlier kernels, was no longer working. Linus himself
> said that this is worth pointing out. I did so.

I agree that it is good to point it out, even if it was just a
coincidence that you had the same problem with someone that didn't have
a tainted kernel. It did help me to know exactly where the bug was.
But don't be surprised if someone tells you to try it without the
tainting module before they look any further. If you say you can't,
then they very well might just ignore your post.

>
> Yes, I was very fortunate in that someone else with a non-tainted
> kernel noticed a similar bug with /dev/rtc, and even more fortunate
> that Steven Rostedt provided a patch that worked for both of us. As I
> had said in my original post I was not expecting that, but thought the
> bug was worth reporting.
>
> DO YOU REALLY PREFER USERS NOT REPORT BUGS?

I say 'no', I don't want users to _not_ report bugs. Even if it
increases the noise out there. It's up to the developer to decide if
they want to look further, or just tell the user "sorry, I can't waste
my time if there's a chance that the problem is in code I can't see".

Cheers,

-- Steve

2006-01-01 14:31:01

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sunday 01 January 2006 09:14, Arjan van de Ven wrote:
> On Sat, 2005-12-31 at 20:29 +0200, Bradley Reed wrote:
> > I have tried MPlayer versions 1.0pre6, 1.0pre7, and cvs from today and
> > they all work fine under 2.6.14 and 2.6.14-rt21/22.
> >
> > I booted into 2.6.15-rc7-rt1 and the same MPlayer binaries segfault on
> > every video I try and play. Yes, I have nvidia modules loaded, so won't
> > get much help, but thought someone might like to know.
>
> you know, you could have done a little bit more effort and reproduced
> this without the binary crud... it's not that hard you know and it shows
> that you actually care about the problem enough that you want to make it
> worthwhile for people to look into it.

REPORTING-BUGS should probably be fixed to make the points you repeatedly have
to make. I agree 100% that people should not be reporting easily reproducible
bugs with proprietary drivers loaded; what's a reboot to them?

Let's add something to REPORTING-BUGS about tainted kernels and/or proprietary
drivers. A quick grep of this file from 2.6.15-rc6 gives me no hits for
"proprietary", "tainted" or "binary".

--
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

2006-01-01 14:21:24

by Alexander E. Patrakov

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

Arjan van de Ven wrote:

> What you have here is a bit of a gray area; you're using one of the
> maybe-illegal binary modules that has a really long history of
> introducing bugs that, just from the oops, may appear unrelated to this
> module, and you can't reproduce it without. Just not because the bug
> won't happen, but because you state that the application that triggers
> it won't run without it.

Wrong. The "nv" driver supports xvideo, and does this better than the
official "nvidia" driver. When I had a GeForce 2 MX 200 (now this card
is dead), my computer was was fast enough to play DVDs with
deinterlacing with the "nv" driver, but not with "nvidia". Probably due
to improper MTRR setup done by the "nvidia" driver.

So the original reporter was actually just lazy or misinformed about the
capabilities of the "nv" driver.

--
Alexander E. Patrakov
Don't mail to [email protected]: the server is off until 2006-01-11
Use my GMail or linuxfromscratch address instead

2006-01-01 15:21:17

by Jan Engelhardt

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

>> you know, you could have done a little bit more effort and reproduced
>> this without the binary crud... it's not that hard you know and it
>> shows that you actually care about the problem enough that you want
>> to make it worthwhile for people to look into it.
>
>And you could have saved the time and effort of replying, as you had
>nothing useful to say. Why do you expect kernel users (non-developers)
>to jump through hoops and cripple their systems in order to provide bug
>reports? Exactly how could I have tested MPLayer realistically without
>Xv support? It isn't that easy to swap video cards in a laptop.

Well, -vo is teh option with which you can choose anything, down to aa.

>Yes, I was very fortunate in that someone else with a non-tainted
>kernel noticed a similar bug with /dev/rtc, and even more fortunate

Oh did not notice *I* actually ran a tainted one *too* :p
but not touching X (despite having loaded a prop module) at all is
sometimes enough to "untaint" a bug report ;)

Jan Engelhardt
--

2006-01-01 15:24:43

by Jan Engelhardt

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

>>Yes, I was very fortunate in that someone else with a non-tainted
>>kernel noticed a similar bug with /dev/rtc, and even more fortunate
>
>Oh did not notice *I* actually ran a tainted one *too* :p

Forget that ^ what I said; the testing box does not even have an nvidia one...

2006-01-01 17:49:38

by Prakash Punnoor

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

Am Sonntag Januar 1 2006 15:21 schrieb Alexander E. Patrakov:
> Arjan van de Ven wrote:
> > What you have here is a bit of a gray area; you're using one of the
> > maybe-illegal binary modules that has a really long history of
> > introducing bugs that, just from the oops, may appear unrelated to this
> > module, and you can't reproduce it without. Just not because the bug
> > won't happen, but because you state that the application that triggers
> > it won't run without it.
>
> Wrong. The "nv" driver supports xvideo, and does this better than the
> official "nvidia" driver. When I had a GeForce 2 MX 200 (now this card
> is dead), my computer was was fast enough to play DVDs with
> deinterlacing with the "nv" driver, but not with "nvidia". Probably due
> to improper MTRR setup done by the "nvidia" driver.

It depends on what you call "better". If you want to watch HD resolution
videos w/o stutters, you need the Nvidia one, as the nv one just wastes CPU
cycles.

--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V

Attachments:

(No filename) (1.03 kB)
(No filename) (189.00 B)
Download all attachments

2006-01-01 18:57:20

by Lee Revell

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

On Sun, 2006-01-01 at 14:31 +0000, Alistair John Strachan wrote:
> On Sunday 01 January 2006 09:14, Arjan van de Ven wrote:
> > On Sat, 2005-12-31 at 20:29 +0200, Bradley Reed wrote:
> > > I have tried MPlayer versions 1.0pre6, 1.0pre7, and cvs from today and
> > > they all work fine under 2.6.14 and 2.6.14-rt21/22.
> > >
> > > I booted into 2.6.15-rc7-rt1 and the same MPlayer binaries segfault on
> > > every video I try and play. Yes, I have nvidia modules loaded, so won't
> > > get much help, but thought someone might like to know.
> >
> > you know, you could have done a little bit more effort and reproduced
> > this without the binary crud... it's not that hard you know and it shows
> > that you actually care about the problem enough that you want to make it
> > worthwhile for people to look into it.
>
> REPORTING-BUGS should probably be fixed to make the points you repeatedly have
> to make. I agree 100% that people should not be reporting easily reproducible
> bugs with proprietary drivers loaded; what's a reboot to them?
>
> Let's add something to REPORTING-BUGS about tainted kernels and/or proprietary
> drivers. A quick grep of this file from 2.6.15-rc6 gives me no hits for
> "proprietary", "tainted" or "binary".
>

Heh, wow, that's a serious omission. It would explain why so many users
post tainted bug reports then act like we're fanatics for telling them
not to do that ;-)

Lee

2006-01-01 21:33:51

by Keith Owens

[permalink] [raw]

Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?

Lee Revell (on Sun, 01 Jan 2006 13:57:14 -0500) wrote:
>On Sun, 2006-01-01 at 14:31 +0000, Alistair John Strachan wrote:
>> On Sunday 01 January 2006 09:14, Arjan van de Ven wrote:
>> > On Sat, 2005-12-31 at 20:29 +0200, Bradley Reed wrote:
>> > > I have tried MPlayer versions 1.0pre6, 1.0pre7, and cvs from today and
>> > > they all work fine under 2.6.14 and 2.6.14-rt21/22.
>> > >
>> > > I booted into 2.6.15-rc7-rt1 and the same MPlayer binaries segfault on
>> > > every video I try and play. Yes, I have nvidia modules loaded, so won't
>> > > get much help, but thought someone might like to know.
>> >
>> > you know, you could have done a little bit more effort and reproduced
>> > this without the binary crud... it's not that hard you know and it shows
>> > that you actually care about the problem enough that you want to make it
>> > worthwhile for people to look into it.
>>
>> REPORTING-BUGS should probably be fixed to make the points you repeatedly have
>> to make. I agree 100% that people should not be reporting easily reproducible
>> bugs with proprietary drivers loaded; what's a reboot to them?
>>
>> Let's add something to REPORTING-BUGS about tainted kernels and/or proprietary
>> drivers. A quick grep of this file from 2.6.15-rc6 gives me no hits for
>> "proprietary", "tainted" or "binary".
>>
>
>Heh, wow, that's a serious omission. It would explain why so many users
>post tainted bug reports then act like we're fanatics for telling them
>not to do that ;-)

Historically this was covered in the kernel FAQ, see
http://www.kernel.org/pub/linux/docs/lkml/#s1-18.

2006-01-01 22:57:44