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