insmod segfault in pci_find_subsys()

insmod segfault in pci_find_subsys()

[Toralf Lund]

Hi.

I'm having some major issues with a custom module I'm hacking on 
(actually maintained by someone else, but I've done odd bits of 
development.) I simply get a segfault at module install time, and the 
problem seems to occur while the module is scanning the PCI bus. The 
error log from one instance is included below. The actual error message 
varies - I have seen at least 3 different variants:

   1. Unable to handle kernel paging request
   2. Unable to handle kernel NULL pointer dereference
   3. general protection fault

As far as I can tell, the problem always occurs at the same point, 
however - or at list in the same function, namely pci_find_subsys(). 
Actually, I have a very simple module based on the original one, which 
I'm using to reproduce the problem - this is the "itifg8tst" mentioned 
in the log. Source code is included below. Try to build as module 
"itifg8tst.ko", then do "insmod itifg8tst.ko" and see what happens.

This originally happened on a Red Hat Linux EL system with Linux 2.6.9, 
but I've later reproduced it with 2.6.11.4 from kernel.org. I've seen it 
on two hosts with completely different hardware setup. "lspci" output 
from one of them is also included.

Am I seeing an issue with the PCI functions here, or is it just that I 
fail to spot an obvious mistake in the module itself?

- Toralf

------------------------------------------------------------------------

Mar 18 09:17:49 localhost kernel: itifg Scanning all devices...
Mar 18 09:17:49 localhost kernel: general protection fault: 0000 [#1]
Mar 18 09:17:49 localhost kernel: Modules linked in: itifg8tst video button battery ac uhci_hcd ehci_hcd snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc tg3 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata sd_mod scsi_mod
Mar 18 09:17:49 localhost kernel: CPU:    0
Mar 18 09:17:49 localhost kernel: EIP:    0060:[<c021481a>]    Not tainted VLI
Mar 18 09:17:49 localhost kernel: EFLAGS: 00010286   (2.6.11.4-0.EL.toralf2) 
Mar 18 09:17:49 localhost kernel: EIP is at pci_find_subsys+0xaa/0x280
Mar 18 09:17:49 localhost kernel: eax: 00000000   ebx: ffffffff   ecx: ffffffff   edx: 00000000
Mar 18 09:17:49 localhost kernel: esi: 000000ac   edi: 00000021   ebp: 00000000   esp: c23c1f30
Mar 18 09:17:49 localhost kernel: ds: 007b   es: 007b   ss: 0068
Mar 18 09:17:49 localhost kernel: Process insmod (pid: 2235, threadinfo=c23c0000 task=f7cc39f0)
Mar 18 09:17:49 localhost kernel: Stack: c03ae458 65636976 2e2e2e73 f7ef1000 00000000 00000000 ffffffff ffffffff 
Mar 18 09:17:49 localhost kernel:        ffffffff 00000000 00000021 c23c0000 c0214a2a ffffffff ffffffff ffffffff 
Mar 18 09:17:49 localhost kernel:        000006e9 47c12378 f892c053 ffffffff ffffffff 00000000 0804a018 f88f1580 
Mar 18 09:17:49 localhost kernel: Call Trace:
Mar 18 09:17:49 localhost kernel:  [<c0214a2a>] pci_find_device+0x3a/0x50
Mar 18 09:17:49 localhost kernel:  [<f892c053>] iti_os_attach+0x53/0x60 [itifg8tst]
Mar 18 09:17:49 localhost kernel:  [<c0144a42>] sys_init_module+0x1f2/0x330
Mar 18 09:17:49 localhost kernel:  [<c01799c8>] filp_close+0x48/0x90
Mar 18 09:17:49 localhost kernel:  [<c010397d>] sysenter_past_esp+0x52/0x75
Mar 18 09:17:49 localhost kernel: Code: 00 00 be ac 00 00 00 a3 00 56 3e c0 b8 50 34 3a c0 a3 0c 56 3e c0 a1 e8 52 3e c0 89 35 10 56 3e c0 89 44 24 0c 31 c0 85 db 74 02 <8b> 03 89 44 24 08 89 5c 24 04 c7 04 24 7c e4 3a c0 e8 40 cf f0 


------------------------------------------------------------------------

% /sbin/lspci
00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#1 (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#2 (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02)00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) SATA Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV18GL [Quadro4 380 XGL] (rev a2)
05:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5782 Gigabit Ethernet (rev 03)


------------------------------------------------------------------------


#include <linux/version.h>	/* LINUX_VERSION_CODE */

#include <linux/pci.h>		/* pci specific stuff */

#ifdef MODULE
#include <linux/module.h>	/* init_/cleanup_ module */


MODULE_DESCRIPTION("CorecoImaging device driver test");
MODULE_AUTHOR("Matthias Stein");
#if LINUX_VERSION_CODE >= 0x02040a /* 2.4.10 */
MODULE_LICENSE("GPL");
#endif


#define ITI_LOG_STRING "itifg "

int
iti_printi (const char *fmt, ...)
{
  int retval;
  char string[80] = KERN_INFO ITI_LOG_STRING;
  long a, b, c, d;
  va_list argptr;

  strcat (string, fmt);
  va_start (argptr, fmt);
  a = va_arg (argptr, long);
  b = va_arg (argptr, long);
  c = va_arg (argptr, long);
  d = va_arg (argptr, long);
  retval = printk (string, 'I', a, b, c, d);
  va_end (argptr);
  
  return retval;
}

static int __exit
iti_os_detach (void)
{  
  return 0;
}

static __init int
iti_os_attach (void)
{
  struct pci_dev *the_dev;
  
  iti_printi("Scanning all devices...\n");
  
  the_dev=NULL;
  while((the_dev=pci_find_device(PCI_ANY_ID, PCI_ANY_ID, the_dev))) {
    iti_printi("Slot %s: Device %04hx:%04hx\n",
	       the_dev->slot_name, the_dev->vendor, the_dev->device);
  }
  
  
  return 0;
}
#endif /* MODULE */

module_init(iti_os_attach);
module_exit(iti_os_detach);

Re: insmod segfault in pci_find_subsys()

[Greg KH]

On Fri, Mar 18, 2005 at 10:12:05AM +0100, Toralf Lund wrote:
> Am I seeing an issue with the PCI functions here, or is it just that I 
> fail to spot an obvious mistake in the module itself?

I think it's a problem in your code.  I built and ran the following
example module just fine (based on your example, which wasn't the
smallest or cleanest...), with no oops.  Does this code work for you?

Oh, and the pci_find* functions are depreciated, do not use them, they
are going away in the near future.  Please use the pci_get* functions
instead.

thanks,

greg k-h

-----------------
#include <linux/pci.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");

	
static void __exit exit(void)
{  
}

static __init int init(void)
{
	struct pci_dev *dev;
 
	printk(KERN_DEBUG "Scanning all devices...\n");
 
	dev = NULL;
	while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev))) {
		printk(KERN_DEBUG "Device %04hx:%04hx\n",
			dev->vendor, dev->device);
	}
	return 0;
}

module_init(init);
module_exit(exit);

Re: insmod segfault in pci_find_subsys()

[Toralf Lund]

Greg KH wrote:

>On Fri, Mar 18, 2005 at 10:12:05AM +0100, Toralf Lund wrote:
>  
>
>>Am I seeing an issue with the PCI functions here, or is it just that I 
>>fail to spot an obvious mistake in the module itself?
>>    
>>
>
>I think it's a problem in your code.  I built and ran the following
>example module just fine (based on your example, which wasn't the
>smallest or cleanest...), with no oops.  Does this code work for you?
>  
>
I'm not able to test that right now (not on the right system), but did 
you try the exact code I submitted? It would be *very* helpful if 
someone could verify that it leads to a crash, before I go any further.

I also have this feeling that an arbitrary change to the code might make 
the module work without really resolving the problem.

>Oh, and the pci_find* functions are depreciated, do not use them, they
>are going away in the near future.  Please use the pci_get* functions
>instead.
>  
>
I think pci_find* are used because the code is supposed to be compatible 
with Linux 2.4 as well. Or did pci_get* exist there, too?

Like I said, most of the code was actually written by someone else...

- T

Re: insmod segfault in pci_find_subsys()

[Toralf Lund]

Greg KH wrote:

>On Fri, Mar 18, 2005 at 10:12:05AM +0100, Toralf Lund wrote:
>  
>
>>Am I seeing an issue with the PCI functions here, or is it just that I 
>>fail to spot an obvious mistake in the module itself?
>>    
>>
>
>I think it's a problem in your code.  I built and ran the following
>example module just fine (based on your example, which wasn't the
>smallest or cleanest...), with no oops.  Does this code work for you?
>  
>
OK, I've finally been able to test this, and no, it does not work. 
insmod segfaults and the system log says

kernel: Unable to handle kernel paging request at virtual address 533e3762



>Oh, and the pci_find* functions are depreciated, do not use them, they
>are going away in the near future.  Please use the pci_get* functions
>instead.
>
>thanks,
>
>greg k-h
>
>-----------------
>#include <linux/pci.h>
>#include <linux/module.h>
>
>MODULE_LICENSE("GPL");
>
>	
>static void __exit exit(void)
>{  
>}
>
>static __init int init(void)
>{
>	struct pci_dev *dev;
> 
>	printk(KERN_DEBUG "Scanning all devices...\n");
> 
>	dev = NULL;
>	while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev))) {
>		printk(KERN_DEBUG "Device %04hx:%04hx\n",
>			dev->vendor, dev->device);
>	}
>	return 0;
>}
>
>module_init(init);
>module_exit(exit);
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>

Re: insmod segfault in pci_find_subsys()

[Greg KH]

On Tue, Mar 29, 2005 at 04:15:37PM +0200, Toralf Lund wrote:
> Greg KH wrote:
> 
> >On Fri, Mar 18, 2005 at 10:12:05AM +0100, Toralf Lund wrote:
> > 
> >
> >>Am I seeing an issue with the PCI functions here, or is it just that I 
> >>fail to spot an obvious mistake in the module itself?
> >>   
> >>
> >
> >I think it's a problem in your code.  I built and ran the following
> >example module just fine (based on your example, which wasn't the
> >smallest or cleanest...), with no oops.  Does this code work for you?
> > 
> >
> OK, I've finally been able to test this, and no, it does not work. 
> insmod segfaults and the system log says
> 
> kernel: Unable to handle kernel paging request at virtual address 533e3762

Then I think you have a broken build system or makefile or gcc.  It
works fine here.

thanks,

greg k-h

Re: insmod segfault in pci_find_subsys()

[Toralf Lund]

Greg KH wrote:

>On Tue, Mar 29, 2005 at 04:15:37PM +0200, Toralf Lund wrote:
>  
>
>>Greg KH wrote:
>>
>>    
>>
>>>On Fri, Mar 18, 2005 at 10:12:05AM +0100, Toralf Lund wrote:
>>>
>>>
>>>      
>>>
>>>>Am I seeing an issue with the PCI functions here, or is it just that I 
>>>>fail to spot an obvious mistake in the module itself?
>>>>  
>>>>
>>>>        
>>>>
>>>I think it's a problem in your code.  I built and ran the following
>>>example module just fine (based on your example, which wasn't the
>>>smallest or cleanest...), with no oops.  Does this code work for you?
>>>
>>>
>>>      
>>>
>>OK, I've finally been able to test this, and no, it does not work. 
>>insmod segfaults and the system log says
>>
>>kernel: Unable to handle kernel paging request at virtual address 533e3762
>>    
>>
>
>Then I think you have a broken build system or makefile or gcc.  It
>works fine here.
>  
>
Yes. You are right. I actually mentioned this on a different thread: I 
eventually found out that the kernel was compiled with -mregparam=3, and 
the module was not. This option seems to have been added to the default 
config and/or Red Hat's build setup sometime before the current kernel 
release, but after the start of the 2.6 series...

- Toralf

Re: insmod segfault in pci_find_subsys()

[Arjan van de Ven]

> Yes. You are right. I actually mentioned this on a different thread: I 
> eventually found out that the kernel was compiled with -mregparam=3, and 
> the module was not. This option seems to have been added to the default 
> config and/or Red Hat's build setup sometime before the current kernel 
> release, but after the start of the 2.6 series...

that means your makefile indeed is utterly bust. A correct makefile for
an external module correctly and automatically inherits all the CFLAGs
used by the kernel.

Care to point to a full URL of your module so that we can help you by
sending patches?

Re: insmod segfault in pci_find_subsys()

[Toralf Lund]

Arjan van de Ven wrote:

>>Yes. You are right. I actually mentioned this on a different thread: I 
>>eventually found out that the kernel was compiled with -mregparam=3, and 
>>the module was not. This option seems to have been added to the default 
>>config and/or Red Hat's build setup sometime before the current kernel 
>>release, but after the start of the 2.6 series...
>>    
>>
>
>that means your makefile indeed is utterly bust. A correct makefile for
>an external module correctly and automatically inherits all the CFLAGs
>used by the kernel.
>  
>
Yes. As I've (also) already said elsewhere, I knew that, really. The 
current build setup fails to do this partly for historical reasons, 
partly because the driver also supports different OSes. (And is still 
expected to build correctly with Linux 2.4, not just 2.6.)

>Care to point to a full URL of your module so that we can help you by
>sending patches?
>
Official (info page) URL is http://itifg.sourceforge.net/

The most recent source is probably 
ftp://ftp.gom.com/pub/ITI-FG/itifg-8.2.1-11.tar.gz.


>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>

Re: insmod segfault in pci_find_subsys()

[Sam Ravnborg]

On Wed, Apr 13, 2005 at 01:49:10PM +0200, Toralf Lund wrote:
> > 
> >
> Yes. As I've (also) already said elsewhere, I knew that, really. The 
> current build setup fails to do this partly for historical reasons, 
> partly because the driver also supports different OSes. (And is still 
> expected to build correctly with Linux 2.4, not just 2.6.)

Following trick works with both 2.4 and 2.6:

makefile:
all:
	$(MAKE) -C Kernel_src_path SUBDIRS=$(PWD) modules

Makefile:

obj-m := mymodule.o

It obtains CFLAGS as expected etc.
People seems to do their best to avoid such a simple setup :-(

	Sam

Re: insmod segfault in pci_find_subsys()

[Toralf Lund]

Sam Ravnborg wrote:

>On Wed, Apr 13, 2005 at 01:49:10PM +0200, Toralf Lund wrote:
>  
>
>>>      
>>>
>>Yes. As I've (also) already said elsewhere, I knew that, really. The 
>>current build setup fails to do this partly for historical reasons, 
>>partly because the driver also supports different OSes. (And is still 
>>expected to build correctly with Linux 2.4, not just 2.6.)
>>    
>>
>
>  
>
Hmmm. Seems like my original reply to this message got lost...

>Following trick works with both 2.4 and 2.6:
>
>makefile:
>all:
>	$(MAKE) -C Kernel_src_path SUBDIRS=$(PWD) modules
>
>Makefile:
>
>obj-m := mymodule.o
>
>It obtains CFLAGS as expected etc.
>People seems to do their best to avoid such a simple setup :-(
>  
>
What? Write a simple makefile that a normal human being may actually 
understand? Not autogenerate something utterly unreadable from something 
that's autogenerated from something that's ... ???

It's not *quite* that simple with the module I'm talking about, though, 
as the source code is split into several files. Which is a Good Thing, IMO.

Also, I was unsure if this would work with Linux 2.4 (but I was going to 
test it)...

>	Sam
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>