Bug 9699

Reply-To: akpm@linux-foundation.org

On Sat,  5 Jan 2008 15:08:44 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9699
> 
>            Summary: radio-sf16fmr2 probably buggy - system inconsistent
>                     after probe
>            Product: Other
>            Version: 2.5
>      KernelVersion: 2.6.24-rc6
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Modules
>         AssignedTo: other_modules@kernel-bugs.osdl.org
>         ReportedBy: devzero@web.de
> 
> 
> Most recent kernel where this bug did not occur: not known
> 
> Distribution: OpenSuSE 10.3 with suse kernel & vanilla 2.6.24rc6,  grml
> (live-cd) daily build
> 
> Hardware Environment: running inside VMware Workstation 6.x on FSC Lifebook
> e-series, running native on older FSC Lifebook
> 
> Software Environment: ???
> 
> Problem Description:
> loading radio-sf16fmr2 on a system without that hardware leaves the system in
> an inconsistent state after probe, leading to weird behaviour or even system
> crash
> 
> Steps to reproduce:
> 
> either:
> opensuse103:~ # modprobe radio-sf16fmr2
> FATAL: Error inserting radio_sf16fmr2
> (/lib/modules/2.6.24-rc6/kernel/drivers/media/radio/radio-sf16fmr2.ko):
> Device
> or resource busy
> opensuse103:~ # cat /proc/ioports
> Segmentation fault

This, maybe?

--- a/drivers/media/radio/radio-sf16fmr2.c~a
+++ a/drivers/media/radio/radio-sf16fmr2.c
@@ -476,8 +476,7 @@ static int __init fmr2_init(void)
 		return -EBUSY;
 	}
 
-	if(video_register_device(&fmr2_radio, VFL_TYPE_RADIO, radio_nr)==-1)
-	{
+	if (video_register_device(&fmr2_radio, VFL_TYPE_RADIO, radio_nr) < 0) {
 		release_region(io, 2);
 		return -EINVAL;
 	}
_

> This, maybe?

thanks - but doesn`t seem to make a difference.
cat /proc/ioports still segfaults

----- Original Message ----- 
From: "Andrew Morton" <akpm@linux-foundation.org>
To: <devzero@web.de>
Cc: "bugme-daemon@kernel-bugs.osdl.org" <bugme-daemon@bugzilla.kernel.org>; 
<video4linux-list@redhat.com>
Sent: Sunday, January 06, 2008 4:25 AM
Subject: Re: [Bugme-new] [Bug 9699] New: radio-sf16fmr2 probably buggy - 
system inconsistent after probe


> On Sat,  5 Jan 2008 15:08:44 -0800 (PST) bugme-daemon@bugzilla.kernel.org 
> wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=9699
>>
>>            Summary: radio-sf16fmr2 probably buggy - system inconsistent
>>                     after probe
>>            Product: Other
>>            Version: 2.5
>>      KernelVersion: 2.6.24-rc6
>>           Platform: All
>>         OS/Version: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: normal
>>           Priority: P1
>>          Component: Modules
>>         AssignedTo: other_modules@kernel-bugs.osdl.org
>>         ReportedBy: devzero@web.de
>>
>>
>> Most recent kernel where this bug did not occur: not known
>>
>> Distribution: OpenSuSE 10.3 with suse kernel & vanilla 2.6.24rc6,  grml
>> (live-cd) daily build
>>
>> Hardware Environment: running inside VMware Workstation 6.x on FSC 
>> Lifebook
>> e-series, running native on older FSC Lifebook
>>
>> Software Environment: ???
>>
>> Problem Description:
>> loading radio-sf16fmr2 on a system without that hardware leaves the 
>> system in
>> an inconsistent state after probe, leading to weird behaviour or even 
>> system
>> crash
>>
>> Steps to reproduce:
>>
>> either:
>> opensuse103:~ # modprobe radio-sf16fmr2
>> FATAL: Error inserting radio_sf16fmr2
>> (/lib/modules/2.6.24-rc6/kernel/drivers/media/radio/radio-sf16fmr2.ko): 
>> Device
>> or resource busy
>> opensuse103:~ # cat /proc/ioports
>> Segmentation fault
>
> This, maybe?
>
> --- a/drivers/media/radio/radio-sf16fmr2.c~a
> +++ a/drivers/media/radio/radio-sf16fmr2.c
> @@ -476,8 +476,7 @@ static int __init fmr2_init(void)
>  return -EBUSY;
>  }
>
> - if(video_register_device(&fmr2_radio, VFL_TYPE_RADIO, radio_nr)==-1)
> - {
> + if (video_register_device(&fmr2_radio, VFL_TYPE_RADIO, radio_nr) < 0) {
>  release_region(io, 2);
>  return -EINVAL;
>  }
> _
> 

Created attachment 14325 [details]
Deattaches pnp, if request_region fails

Please try the enclosed patch. It should fix the issue.

yes, confirmed! thanks very much!

just curious - is it worth taking a look at the other modules, too ?
(same goes for  for andrews patch)

regards
roland

radio-aimslab.c-
radio-aimslab.c-        if (!request_region(io, 2, "rtrack"))
radio-aimslab.c-        {
radio-aimslab.c:                printk(KERN_ERR "rtrack: port 0x%x already in use\n", io);
radio-aimslab.c-                return -EBUSY;
radio-aimslab.c-        }
radio-aimslab.c-
--
radio-aztech.c-
radio-aztech.c- if (!request_region(io, 2, "aztech"))
radio-aztech.c- {
radio-aztech.c:         printk(KERN_ERR "aztech: port 0x%x already in use\n", io);
radio-aztech.c-         return -EBUSY;
radio-aztech.c- }
radio-aztech.c-
--
radio-gemtek-pci.c-     card->length = pci_resource_len( pci_dev, 0 );
radio-gemtek-pci.c-
radio-gemtek-pci.c-     if ( request_region( card->iobase, card->length, card_names[pci_id->driver_data] ) == NULL ) {
radio-gemtek-pci.c:             printk( KERN_ERR "gemtek_pci: i/o port already in use\n" );
radio-gemtek-pci.c-             goto err_pci;
radio-gemtek-pci.c-     }
radio-gemtek-pci.c-
--
radio-gemtek.c- gemtek_probe();
radio-gemtek.c- if (io) {
radio-gemtek.c-         if (!request_region(io, 1, "gemtek")) {
radio-gemtek.c:                 printk(KERN_ERR "I/O port 0x%x already in use.\n", io);
radio-gemtek.c-                 return -EBUSY;
radio-gemtek.c-         }
radio-gemtek.c-
--
radio-rtrack2.c-        }
radio-rtrack2.c-        if (!request_region(io, 4, "rtrack2"))
radio-rtrack2.c-        {
radio-rtrack2.c:                printk(KERN_ERR "rtrack2: port 0x%x already in use\n", io);
radio-rtrack2.c-                return -EBUSY;
radio-rtrack2.c-        }
radio-rtrack2.c-
--
radio-terratec.c-       }
radio-terratec.c-       if (!request_region(io, 2, "terratec"))
radio-terratec.c-       {
radio-terratec.c:               printk(KERN_ERR "TerraTec: port 0x%x already in use\n", io);
radio-terratec.c-               return -EBUSY;
radio-terratec.c-       }
radio-terratec.c-
--
radio-trust.c-          return -EINVAL;
radio-trust.c-  }
radio-trust.c-  if(!request_region(io, 2, "Trust FM Radio")) {
radio-trust.c:          printk(KERN_ERR "trust: port 0x%x already in use\n", io);
radio-trust.c-          return -EBUSY;
radio-trust.c-  }
radio-trust.c-  if(video_register_device(&trust_radio, VFL_TYPE_RADIO, radio_nr)==-1)
--
radio-typhoon.c-        mutex_init(&typhoon_unit.lock);
radio-typhoon.c-        io = typhoon_unit.iobase;
radio-typhoon.c-        if (!request_region(io, 8, "typhoon")) {
radio-typhoon.c:                printk(KERN_ERR "radio-typhoon: port 0x%x already in use\n",
radio-typhoon.c-                       typhoon_unit.iobase);
radio-typhoon.c-                return -EBUSY;
radio-typhoon.c-        }
--
radio-zoltrix.c-
radio-zoltrix.c-        zoltrix_radio.priv = &zoltrix_unit;
radio-zoltrix.c-        if (!request_region(io, 2, "zoltrix")) {
radio-zoltrix.c:                printk(KERN_ERR "zoltrix: port 0x%x already in use\n", io);
radio-zoltrix.c-                return -EBUSY;
radio-zoltrix.c-        }
radio-zoltrix.c-

Those radio drivers are really old. We did a recent update on those radio drivers when converting them to V4L2. 

Since they are all based on the same code, it is generally a good idea to review the other drivers when a bug is found on one of them.

Created attachment 14377 [details]
Fix to issue 9699

Hi Roland,

      Could you test the patch above for radio-sf16fmr2 driver ?
I've found the same issue only for this driver.

Cheers,
Douglas Schilling Landgraf

Hi Douglas, 

mhh - that patch doesn`t seem to make a difference - i`m getting both

[ 3411.826812] Linux video capture interface: v2.00
[ 3411.857112] fmr2: port 0x384 already in use

for the patched and unpatched version when modprobing radio-sf16fmr2

module doesn`t stay loaded after that (as expected, as i don`t even own that hardware)

just curious why is it telling that port is in use ?

cat /proc/ioports |grep 03
0376-0376 : 0000:00:07.1
  0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f2-03f5 : floppy
03f6-03f6 : 0000:00:07.1
03f7-03f7 : floppy DIR
03f8-03ff : serial

so, who`s using that port ?

oh, just curious - if i just insmod that module or modprobe that a second time, i`m getting this one:

[ 3502.551385] Linux video capture interface: v2.00
[ 3502.573660] videodev: "SF16FMR2 radio" has no release callback. Please fix your driver for proper sysfs support, see http://lwn.net/Articles/36850/
[ 3502.594689] SF16FMR2 radio card driver at 0x384.

and the module stays loaded afterwards.

regards
roland

mauro, andrew - apparently some things went wrong here.

mauro - your patch was for radio-sf16fmi, but my bugreport was for sf16fmr2

the weird thing is , that i couldn`t reproduce the crash of sf16fmr2 after i patched sf16fmi (and thus the wrong driver) - but i didn`t notice that the patch patched the wrong file.

maybe this is a race condition - so i think i will start from scratch and try again if this crash alway happens, then apply andrews patch and compare again with more concentration. sorry for the trouble

(In reply to comment #8)
> Hi Douglas, 

Hi Roland, thanks for your feedback!
 
> mhh - that patch doesn`t seem to make a difference

Really ? 

Without the above patch I received segmentation fault message like you received. 
Using the above patch it was fixed. 

> for the patched and unpatched version when modprobing radio-sf16fmr2
> 
> module doesn`t stay loaded after that (as expected, as i don`t even own that
> hardware)
> 
> just curious why is it telling that port is in use ?

This is a message when this driver can't request_region.
Probably we need to change this message.

> oh, just curious - if i just insmod that module or modprobe that a second 
> time, i`m getting this one:

Well, as you said the module was loaded and some output message has appeared.

> [ 3502.573660] videodev: "SF16FMR2 radio" has no release callback. Please fix
> your driver for proper sysfs support, see http://lwn.net/Articles/36850/

This is a annoying message, It's in my personal task list ASAP I'll fix it.

> [ 3502.594689] SF16FMR2 radio card driver at 0x384.
> and the module stays loaded afterwards.

Gotta check it!
 
Thanks!

Cheers,
Douglas

hello douglas, 

>Without the above patch I received segmentation fault message like you
>received.  Using the above patch it was fixed. 

yes, you`re right! !request_region is the fix!
i was testing wrong - did some make SUBDIRS=..... modules_install and didn`t notice that the module was placed at /lib/modules/2.6.24-rc6/extra and apparently, i did load the wrong module.