Re: insmod segfault in pci_find_subsys()
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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()
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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()
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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()
> 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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()
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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()
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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()
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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()
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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()
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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 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
#include
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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()
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
#include
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
insmod segfault in pci_find_subsys()
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: [#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:[]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: ebx: ecx: edx:
Mar 18 09:17:49 localhost kernel: esi: 00ac edi: 0021 ebp: 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=c23c task=f7cc39f0)
Mar 18 09:17:49 localhost kernel: Stack: c03ae458 65636976 2e2e2e73 f7ef1000
Mar 18 09:17:49 localhost kernel: 0021 c23c c0214a2a
Mar 18 09:17:49 localhost kernel:06e9 47c12378 f892c053 0804a018 f88f1580
Mar 18 09:17:49 localhost kernel: Call Trace:
Mar 18 09:17:49 localhost kernel: [] pci_find_device+0x3a/0x50
Mar 18 09:17:49 localhost kernel: [] iti_os_attach+0x53/0x60 [itifg8tst]
Mar 18 09:17:49 localhost kernel: [] sys_init_module+0x1f2/0x330
Mar 18 09:17:49 localhost kernel: [] filp_close+0x48/0x90
Mar 18 09:17:49 localhost kernel: [] 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_CODE */
#include /* pci specific stuff */
#ifdef MODULE
#include /* 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] =
insmod segfault in pci_find_subsys()
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: [#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: ebx: ecx: edx: Mar 18 09:17:49 localhost kernel: esi: 00ac edi: 0021 ebp: 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=c23c task=f7cc39f0) Mar 18 09:17:49 localhost kernel: Stack: c03ae458 65636976 2e2e2e73 f7ef1000 Mar 18 09:17:49 localhost kernel: 0021 c23c c0214a2a Mar 18 09:17:49 localhost kernel:06e9 47c12378 f892c053 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
Re: insmod segfault in pci_find_subsys()
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);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
