MPlayer broken under 2.6.15-rc7-rt1?

MPlayer broken under 2.6.15-rc7-rt1?

[Bradley Reed]

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!
invalid operand: 0000 [#5]
PREEMPT 
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device snd_pcm_oss snd_mixer_o ss intel_agp snd_intel8x0
snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc nvidia
agpgart b44 orinoco_cs orinoco hermes CPU:    0
EIP:    0060:[<c031491c>]    Tainted: P      VLI
EFLAGS: 00010286   (2.6.15-rc7-rt1) 
EIP is at rtc_do_ioctl+0xa13/0xa44
eax: 00000021   ebx: cf16e000   ecx: de8e8000   edx: cf16e000
esi: 00000246   edi: 00000001   ebp: 00007005   esp: cf16fe7c
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process mplayer (pid: 4067, threadinfo=cf16e000 task=df315380
stack_left=7752 worst_left=-1) Stack: c047704e c047dff9 00000053
00000000 00000000 00000246 dffb4e00 c0500380 00000087 00000000 c030809a
de91e330 cb5f1b80 00000000 00000246 dffb4e00 dffb4e00 00000000 c0307fc3
c016ed76 de91e330 cb5f1b80 cf16ff38 00000003 Call Trace:
 [<c030809a>] misc_open+0xd7/0x2ee (44)
 [<c0307fc3>] misc_open+0x0/0x2ee (32)
 [<c016ed76>] chrdev_open+0xf6/0x1c8 (4)
 [<c016ec80>] chrdev_open+0x0/0x1c8 (32)
 [<c0164380>] __dentry_open+0xc3/0x259 (4)
 [<c0164656>] nameidata_to_filp+0x37/0x4f (28)
 [<c016456a>] filp_open+0x54/0x60 (28)
 [<c0178983>] do_ioctl+0x6f/0xa9 (40)
 [<c0178b54>] vfs_ioctl+0x65/0x1e1 (36)
 [<c01732ac>] putname+0x2b/0x37 (20)
 [<c0178d15>] sys_ioctl+0x45/0x6c (16)
 [<c0103171>] syscall_call+0x7/0xb (36)
Code: 73 14 00 e9 bb fd ff ff e8 d0 73 14 00 eb ae c7 44 24 08 53 00 00
00 c7 44 24 04 f9 df 47 c0 c7 04 24 4e 70 47 c0 e8 25 7d e0 ff <0f> 0b
53 00 f9 df 47 c0 e9 a1 fd ff ff fb 83 6b 14 01 8b 43 08 

====
strace mplayer ends with:

munmap(0xb6cd8000, 790528)              = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE)  = 3
ioctl(3, RTC_IRQP_SET, 0x400)           = 0
ioctl(3, RTC_PIE_ON <unfinished ...>
+++ killed by SIGSEGV +++

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Alistair John Strachan]

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.

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Bradley Reed]

On Sat, 31 Dec 2005 18:47:48 +0000
Alistair John Strachan <s0348365@sms.ed.ac.uk> 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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Alistair John Strachan]

On Saturday 31 December 2005 18:59, Bradley Reed wrote:
> On Sat, 31 Dec 2005 18:47:48 +0000
>
> Alistair John Strachan <s0348365@sms.ed.ac.uk> 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.

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Steven Rostedt]

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);
 

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Bradley Reed]

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 <rostedt@goodmis.org> 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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Steven Rostedt]

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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Jan Engelhardt]

>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/

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

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

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


[-- Attachment #2: rtc_ioctl.c --]
[-- Type: text/x-csrc, Size: 473 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>

#include <linux/rtc.h>

#define RTC "/dev/rtc"

int main(int argc, char **argv)
{
	int fd;
	unsigned long data;

	if ((fd = open(RTC, O_RDONLY)) < 0) {
		perror(RTC);
		exit(0);
	}
	
	ioctl(fd, RTC_IRQP_SET, 1024);
	ioctl(fd, RTC_PIE_ON, 0);

	read(fd, &data, sizeof(data));
	printf("%08lx\n",data);

	close (fd);
	exit(0);
}

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

[Bradley Reed]

On Sat, 31 Dec 2005 17:46:55 -0500
Steven Rostedt <rostedt@goodmis.org> 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

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

[Steven Rostedt]

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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Arjan van de Ven]

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.

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Bradley Reed]

On Sun, 01 Jan 2006 10:14:21 +0100
Arjan van de Ven <arjan@infradead.org> 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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Arjan van de Ven]

> 
> 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)

Re: MPlayer broken under 2.6.15-rc7-rt1?

[jerome lacoste]

On 1/1/06, Arjan van de Ven <arjan@infradead.org> 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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Arjan van de Ven]

> 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??

[OT] Re: MPlayer broken under 2.6.15-rc7-rt1?

[jerome lacoste]

On 1/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
>
> > 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??

I should have emphasized the "system that changed" part over the
"contact the vendor" one.

I believe most of us have to deal with time as a limited constraint.
And the issue investigation heuristic that considers that an issue
most likely results from the latest change in your configuration gives
a good result most of the time. Software, hardware, we all do it.

So maybe it's a bad vendor practise to *redirect* people somewhere
else, but it's I think a good engineering practise to work by
*isolating changes*. Kernel people work by isolating binary from
non-binary code. Vendor probably work by isolating unknown
configurations from preferred known working configurations. Everyone
just tries to do what best suit their development environment and
constraints.

Cheers,

Jerome

(and Happy Linux Year 2006)

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Arjan van de Ven]

On Sun, 2006-01-01 at 13:12 +0100, jerome lacoste wrote:
> On 1/1/06, Arjan van de Ven <arjan@infradead.org> 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)

Re: MPlayer broken under 2.6.15-rc7-rt1?

[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.

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

-- 
Alexander E. Patrakov
Don't mail to patrakov@ums.usu.ru: the server is off until 2006-01-11
Use my GMail or linuxfromscratch address instead

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Adrian Bunk]

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 <arjan@infradead.org> 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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Adrian Bunk]

On Sun, Jan 01, 2006 at 02:54:02PM +0200, Bradley Reed wrote:
> On Sun, 1 Jan 2006 12:50:38 +0100
> Adrian Bunk <bunk@stusta.de> 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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Arjan van de Ven]

On Sun, Jan 01, 2006 at 02:54:02PM +0200, Bradley Reed wrote:
> > On Sun, 1 Jan 2006 12:50:38 +0100
> > Adrian Bunk <bunk@stusta.de> 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? :)

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Steven Rostedt]

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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Jan Engelhardt]

>> 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
-- 

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Jan Engelhardt]

>>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...

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Alistair John Strachan]

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.

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Lee Revell]

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

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Keith Owens]

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.

Re: MPlayer broken under 2.6.15-rc7-rt1?

[Alistair John Strachan]

On Sunday 01 January 2006 21:33, Keith Owens wrote:
> 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.

I can see no reason why it shouldn't also be in the kernel. The issue is not 
even a political one, it is a matter of debugging practicality.

-- 
Cheers,
Alistair.

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