Bug 9699 - radio-sf16fmr2 probably buggy - system inconsistent after probe
Summary: radio-sf16fmr2 probably buggy - system inconsistent after probe
Status: CLOSED CODE_FIX
Alias: None
Product: v4l-dvb
Classification: Unclassified
Component: radio (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Mauro Carvalho Chehab
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-05 15:08 UTC by Roland Kletzing
Modified: 2008-01-12 03:20 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.24-rc6
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Deattaches pnp, if request_region fails (683 bytes, text/x-patch)
2008-01-07 04:47 UTC, Mauro Carvalho Chehab
Details
Fix to issue 9699 (468 bytes, patch)
2008-01-09 01:36 UTC, Douglas Schilling Landgraf
Details | Diff

Description Roland Kletzing 2008-01-05 15:08:43 UTC
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

or:
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:~ # modprobe esp
<system freeze>


dmesg after cat /proc/ioports:
fmr2: port 0x384 already in use
BUG: unable to handle kernel paging request at virtual address e09e467a
printing eip: c01d6c8e *pde = 1f41b067 *pte = 00000000
Oops: 0000 [#1] SMP
Modules linked in: videodev v4l2_common v4l1_compat compat_ioctl32 edd iptable_filter ip_tables ip6table_filter ip6_tables x_tables ipv6 af_packet microcode firmware_class fuse loop dm_mod ide_cd cdrom pata_acpi ata_piix ahci ata_generic libata container piix pcnet32 thermal generic shpchp mii ac intel_agp parport_pc pci_hotplug processor ide_core i2c_piix4 parport rtc_cmos agpgart power_supply button rtc_core i2c_core rtc_lib sg ext3 jbd mbcache sd_mod ehci_hcd mptspi mptscsih mptbase uhci_hcd scsi_transport_spi scsi_mod usbcore

Pid: 2551, comm: cat Not tainted (2.6.24-rc6-vanilla+suseconfig #11)
EIP: 0060:[<c01d6c8e>] EFLAGS: 00010297 CPU: 0
EIP is at strnlen+0x6/0x18
EAX: e09e467a EBX: e09e467a ECX: e09e467a EDX: fffffffe
ESI: dec4f15e EDI: dee89f10 EBP: ffffffff ESP: dee89e88
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process cat (pid: 2551, ti=dee88000 task=dea14e70 task.ti=dee88000)
Stack: c01d63d6 00000000 00000000 00000010 00000004 ffffffff 00000001 00000eae
       dec4f152 00000010 dec50000 00000000 ffffffff c03233cb dec4f152 de82ac80
       de82ac80 00000400 c018a6b2 dee89ef0 dee89ef0 00000000 c0368774 c012ab4c
Call Trace:
 [<c01d63d6>] vsnprintf+0x29c/0x469
 [<c018a6b2>] seq_printf+0x2e/0x4b
 [<c012ab4c>] r_show+0x7f/0x88
 [<c018ac63>] seq_read+0x1a1/0x27e
 [<c018aac2>] seq_read+0x0/0x27e
 [<c01a1125>] proc_reg_read+0x5e/0x71
 [<c01a10c7>] proc_reg_read+0x0/0x71
 [<c017557a>] vfs_read+0x9f/0x127
 [<c017596f>] sys_read+0x41/0x67
 [<c0104f52>] sysenter_past_esp+0x6b/0xa9
 =======================
Code: c9 74 0c f2 ae 74 05 bf 01 00 00 00 4f 89 fa 5f 89 d0 c3 85 c9 57 89 c7 89 d0 74 05 f2 ae 75 01 4f 89 f8 5f c3 89 c1 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 c3 90 90 90 57 83 c9
EIP: [<c01d6c8e>] strnlen+0x6/0x18 SS:ESP 0068:dee89e88
---[ end trace 598964de8ea8972c ]---
Comment 1 Anonymous Emailer 2008-01-05 19:25:43 UTC
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;
 	}
_
Comment 2 Roland Kletzing 2008-01-06 08:30:37 UTC
> 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;
>  }
> _
> 
Comment 3 Mauro Carvalho Chehab 2008-01-07 04:47:46 UTC
Created attachment 14325 [details]
Deattaches pnp, if request_region fails

Please try the enclosed patch. It should fix the issue.
Comment 4 Roland Kletzing 2008-01-08 14:41:17 UTC
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-
Comment 5 Mauro Carvalho Chehab 2008-01-09 00:38:08 UTC
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.
Comment 6 Douglas Schilling Landgraf 2008-01-09 01:36:21 UTC
Created attachment 14377 [details]
Fix to issue 9699
Comment 7 Douglas Schilling Landgraf 2008-01-09 01:44:35 UTC
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
Comment 8 Roland Kletzing 2008-01-10 14:55:22 UTC
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
Comment 9 Roland Kletzing 2008-01-10 15:34:16 UTC
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
Comment 10 Douglas Schilling Landgraf 2008-01-11 04:57:14 UTC
(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
Comment 11 Roland Kletzing 2008-01-12 03:20:04 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.