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

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?

[Mark Knecht]

On 12/31/05, Bradley Reed <bradreed1@gmail.com> 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

Hi,
   Strange results here. I tried mplayer playing both audio only and
then some video recorded with MythTV. No segfault problems with either
one on my end but on the video (Tonight Show) the audio was very
clearly out of sync with the video.

   To check it out further I tried watching the same clip in MythTV
and got a crash:

----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at include/linux/timer.h:83
invalid operand: 0000 [1] PREEMPT
CPU 0
Modules linked in: snd_seq_midi snd_pcm_oss snd_mixer_oss snd_seq_oss
snd_seq_mi di_event snd_seq realtime sbp2 ohci1394 ieee1394 snd_hdsp
snd_rawmidi snd_seq_de vice snd_hwdep snd_intel8x0 snd_ac97_codec
snd_ac97_bus snd_pcm snd_timer snd sn d_page_alloc radeon drm
Pid: 8553, comm: mythfrontend Not tainted 2.6.15-rc7-rt1 #1
RIP: 0010:[<ffffffff802ae2fa>] <ffffffff802ae2fa>{rtc_do_ioctl+730}
RSP: 0018:ffff81000adb9e08  EFLAGS: 00210282
RAX: 0000000000000000 RBX: 0000000000200202 RCX: ffff81001f9217c0
RDX: 0000000000000000 RSI: ffff81000a6d5030 RDI: ffff81001f9217c0
RBP: 0000000000000001 R08: ffff81000adb8000 R09: 0000000000000001
R10: 00002aaaaaac0660 R11: 0000000000200246 R12: 00000000fffffff3
R13: 0000000000007005 R14: 0000000000000013 R15: 00002aaaab3d3850
FS:  0000000043005960(0063) GS:ffffffff80573800(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaac987620 CR3: 00000000063a9000 CR4: 00000000000006e0
Process mythfrontend (pid: 8553, threadinfo ffff81000adb8000, task
ffff81000a6d5 030)
Stack: ffff81001e986bc8 0000000000200246 0000000000200202 0000000000200246
       ffff81001ffa13c0 ffffffff80181331 0000000000008000 0000000000008000
       ffff81000adc56c0 ffff81001e986bc8
Call Trace:<ffffffff80181331>{chrdev_open+449} <ffffffff80181170>{chrdev_open+0}
       <ffffffff801771fc>{__dentry_open+332} <ffffffff804051da>{lock_kernel+42}
       <ffffffff8018b4e4>{do_ioctl+116} <ffffffff8018b7c2>{vfs_ioctl+690}
       <ffffffff8018b85a>{sys_ioctl+106} <ffffffff8010dba6>{system_call+126}


Code: 0f 0b 68 9d 5f 42 80 c2 53 00 48 8b 35 25 54 2a 00 48 c7 c7
RIP <ffffffff802ae2fa>{rtc_do_ioctl+730} RSP <ffff81000adb9e08>

mark@lightning ~ $


* media-video/mplayer
     Available versions:  1.0_pre7-r1
     Installed:           1.0_pre7-r1


mark@lightning ~ $ eix mythtv
* media-tv/mythtv
     Available versions:  0.18.1-r1 ~0.18.1-r2 [M]0.18.2_pre7882
     Installed:           0.18.1-r1

lightning ~ # emerge info
Portage 2.0.53 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2,
2.6.15-rc7-rt1 x86_64)
=================================================================
System uname: 2.6.15-rc7-rt1 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"

   Looks like there is a bit of an issue here.

- Mark

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/

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?

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

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

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?

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

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

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

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

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

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

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