OOPS 2.6.0-test2, modprobe i810fb

OOPS 2.6.0-test2, modprobe i810fb

[Pavel Rabel]

[-- Attachment #1: Type: text/plain, Size: 77 bytes --]

Got this OOPS when trying "modprobe i810fb",
kernel 2.6.0-test2


-- 
Pavel


[-- Attachment #2: oops.txt --]
[-- Type: text/plain, Size: 2960 bytes --]

ksymoops 2.4.8 on i686 2.6.0-test2.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.6.0-test2/ (default)
     -m /boot/System.map-2.6.0-test2 (specified)

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address d00fb018
c018abd9
*pde = 013be067
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c018abd9>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010296
eax: 00008086   ebx: c12c5000   ecx: d00fb018   edx: 00000000
esi: c12c5000   edi: d01372a0   ebp: d01372c8   esp: c2d29f28
ds: 007b   es: 007b   ss: 0068
Stack: ffffffed c018afd7 d00fae58 c12c5000 ffffffed d01372c8 c12c5054 c01b46f0 
       c12c5054 d01372c8 c12c505c c0267be4 d01372c8 c01b47e3 c12c5054 d01372c8 
       c0267b88 c0267b40 00000000 c01b4a2b d01372c8 d01372a0 00000000 d0137340 
Call Trace:
 [<c018afd7>] pci_bus_match+0x23/0xb8
 [<c01b46f0>] bus_match+0x20/0x64
 [<c01b47e3>] driver_attach+0x3f/0x54
 [<c01b4a2b>] bus_add_driver+0x6f/0x8c
 [<c01b4dac>] driver_register+0x34/0x38
 [<c018af44>] pci_register_driver+0x68/0x88
 [<d00fae1e>] init_module+0x3a/0x57 [i810fb]
 [<c0126d11>] sys_init_module+0xe5/0x1bc
 [<c0108993>] syscall_call+0x7/0xb
Code: 83 39 00 75 a2 83 79 08 00 75 9c 83 79 14 00 75 96 31 c0 5b 


>>EIP; c018abd9 <pci_match_device+69/80>   <=====

>>ebx; c12c5000 <_end+fced34/3fd07d34>
>>ecx; d00fb018 <_end+fe04d4c/3fd07d34>
>>esi; c12c5000 <_end+fced34/3fd07d34>
>>edi; d01372a0 <_end+fe40fd4/3fd07d34>
>>ebp; d01372c8 <_end+fe40ffc/3fd07d34>
>>esp; c2d29f28 <_end+2a33c5c/3fd07d34>

Trace; c018afd7 <pci_bus_match+23/b8>
Trace; c01b46f0 <bus_match+20/64>
Trace; c01b47e3 <driver_attach+3f/54>
Trace; c01b4a2b <bus_add_driver+6f/8c>
Trace; c01b4dac <driver_register+34/38>
Trace; c018af44 <pci_register_driver+68/88>
Trace; d00fae1e <_end+fe04b52/3fd07d34>
Trace; c0126d11 <sys_init_module+e5/1bc>
Trace; c0108993 <syscall_call+7/b>

Code;  c018abd9 <pci_match_device+69/80>
00000000 <_EIP>:
Code;  c018abd9 <pci_match_device+69/80>   <=====
   0:   83 39 00                  cmpl   $0x0,(%ecx)   <=====
Code;  c018abdc <pci_match_device+6c/80>
   3:   75 a2                     jne    ffffffa7 <_EIP+0xffffffa7>
Code;  c018abde <pci_match_device+6e/80>
   5:   83 79 08 00               cmpl   $0x0,0x8(%ecx)
Code;  c018abe2 <pci_match_device+72/80>
   9:   75 9c                     jne    ffffffa7 <_EIP+0xffffffa7>
Code;  c018abe4 <pci_match_device+74/80>
   b:   83 79 14 00               cmpl   $0x0,0x14(%ecx)
Code;  c018abe8 <pci_match_device+78/80>
   f:   75 96                     jne    ffffffa7 <_EIP+0xffffffa7>
Code;  c018abea <pci_match_device+7a/80>
  11:   31 c0                     xor    %eax,%eax
Code;  c018abec <pci_match_device+7c/80>
  13:   5b                        pop    %ebx


1 error issued.  Results may not be reliable.

Re: OOPS 2.6.0-test2, modprobe i810fb

[S. Anderson]

On Mon, Jul 28, 2003 at 06:18:07PM +0100, Pavel Rabel wrote:
> Got this OOPS when trying "modprobe i810fb",
> kernel 2.6.0-test2
> 

I am also getting this oops, or somthing very simmillar.

I am new to kernel hacking, but I will try to explain what why I
think this is happening, and then hopefully someone will know how to fix
it :-).

basicly, in pci_bus_match(), when  *ids is assigned pci_drv->id_table
from a driver, (intel-agp, i810_audio and i810fb mabey others) the value
of ids->vendor is located at place where it cant be handled. Then further
up the line, the oops occurs at the pci_match_device() function when it 
tries to access ids->vendor. hopefully that makes sense.

I have added some debugging printks to pci_bus_match():

--- pci-driver.0.c      2003-07-27 15:40:56.000000000 -0600
+++ pci-driver.c        2003-07-28 19:51:47.000000000 -0600
@@ -48,6 +48,7 @@
 const struct pci_device_id *
 pci_match_device(const struct pci_device_id *ids, const struct pci_dev *dev)
 {
+       printk("pci_match_device: &ids->vendor = %p\n", &ids->vendor);
        while (ids->vendor || ids->subvendor || ids->class_mask) {
                if (pci_match_one_device(ids, dev))
                        return ids;
@@ -430,6 +431,12 @@
        if (!ids)
                return 0;
 
+       printk("pci_bus_match: bus=%d, devfn=%d %x %x\n",
+               pci_dev->bus->number, pci_dev->devfn, 
+               pci_dev->vendor,      pci_dev->device);
+       printk(" ^ matching? ^ (%s)  ((( &ids->vendor = %p )))\n", 
+                       pci_drv->name, &ids->vendor);
+
        found_id = pci_match_device(ids, pci_dev);
        if (found_id)
                return 1;

here is the output I get right before the oops + the oops run
through ksymoops

...
Adding 524280k swap on /swapfile.  Priority:-1 extents:209
mtrr: 0xe8000000,0x8000000 overlaps existing 0xe8000000,0x80000
 (pci_bus_add_devices) bus 3 devfn 0  1260 3890
pci_bus_match: bus=3, devfn=0 1260 3890
 ^ matching? ^ (agpgart-intel)  ((( &ids->vendor = c03f8e98 )))
pci_match_device: &ids->vendor = c03f8e98
Unable to handle kernel paging request at virtual address c03f8e98
 printing eip:
c01f7da3
... 

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address c03f8e98
c01f7da3
*pde = 00102027
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c01f7da3>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 0000002a   ebx: c03f8e98   ecx: 00000001   edx: c036f238
esi: c748b004   edi: c748b004   ebp: cf5fde94   esp: cf5fde84
ds: 007b   es: 007b   ss: 0068
Stack: c0327020 c03f8e98 c03a65a0 c03f8e98 cf5fdeb4 c01f84fb c03f8e98 c748b004
       ffffffed c03a65c8 c748b058 c8f12004 cf5fded0 c022b599 c748b058 c03a65c8
       c03a6610 c03a10f4 c748b058 cf5fdeec c022b62a c748b058 c03a65c8 c03a1080
Call Trace:
 [<c01f84fb>] pci_bus_match+0x5f/0x2b0
 [<c022b599>] bus_match+0x21/0x64
 [<c022b62a>] device_attach+0x4e/0x70
 [<c022b7a2>] bus_add_device+0x72/0xb4
 [<c022a0e0>] device_add+0xd0/0x108
 [<c01f4864>] pci_bus_add_devices+0x50/0x300
 [<c026186d>] cb_alloc+0xad/0xc8
 [<c025e802>] socket_insert+0x56/0xa4
 [<c025ea11>] socket_detect_change+0x69/0x70
 [<c025ec07>] pccardd+0x1ef/0x2a0
 [<c025ea18>] pccardd+0x0/0x2a0
 [<c011ae7c>] default_wake_function+0x0/0x20
 [<c011ae7c>] default_wake_function+0x0/0x20
 [<c01070c5>] kernel_thread_helper+0x5/0xc
Code: 83 3b 00 75 a0 83 7b 08 00 75 9a 83 7b 14 00 75 94 31 c0 8d


>>EIP; c01f7da3 <pci_match_device+73/90>   <=====

>>ebx; c03f8e98 <agp_intel_pci_table+0/38>
>>edx; c036f238 <log_wait+18/20>
>>esi; c748b004 <_end+7066900/3fbd98fc>
>>edi; c748b004 <_end+7066900/3fbd98fc>
>>ebp; cf5fde94 <_end+f1d9790/3fbd98fc>
>>esp; cf5fde84 <_end+f1d9780/3fbd98fc>

Trace; c01f84fb <pci_bus_match+5f/2b0>
Trace; c022b599 <bus_match+21/64>
Trace; c022b62a <device_attach+4e/70>
Trace; c022b7a2 <bus_add_device+72/b4>
Trace; c022a0e0 <device_add+d0/108>
Trace; c01f4864 <pci_bus_add_devices+50/300>
Trace; c026186d <cb_alloc+ad/c8>
Trace; c025e802 <socket_insert+56/a4>
Trace; c025ea11 <socket_detect_change+69/70>
Trace; c025ec07 <pccardd+1ef/2a0>
Trace; c025ea18 <pccardd+0/2a0>
Trace; c011ae7c <default_wake_function+0/20>
Trace; c011ae7c <default_wake_function+0/20>
Trace; c01070c5 <kernel_thread_helper+5/c>

Code;  c01f7da3 <pci_match_device+73/90>
00000000 <_EIP>:
Code;  c01f7da3 <pci_match_device+73/90>   <=====
   0:   83 3b 00                  cmpl   $0x0,(%ebx)   <=====
Code;  c01f7da6 <pci_match_device+76/90>
   3:   75 a0                     jne    ffffffa5 <_EIP+0xffffffa5> c01f7d48 <pci_match_device+18/90>
Code;  c01f7da8 <pci_match_device+78/90>
   5:   83 7b 08 00               cmpl   $0x0,0x8(%ebx)
Code;  c01f7dac <pci_match_device+7c/90>
   9:   75 9a                     jne    ffffffa5 <_EIP+0xffffffa5> c01f7d48 <pci_match_device+18/90>
Code;  c01f7dae <pci_match_device+7e/90>
   b:   83 7b 14 00               cmpl   $0x0,0x14(%ebx)
Code;  c01f7db2 <pci_match_device+82/90>
   f:   75 94                     jne    ffffffa5 <_EIP+0xffffffa5> c01f7d48 <pci_match_device+18/90>
Code;  c01f7db4 <pci_match_device+84/90>
  11:   31 c0                     xor    %eax,%eax
Code;  c01f7db6 <pci_match_device+86/90>
  13:   8d 00                     lea    (%eax),%eax


1 warning and 1 error issued.  Results may not be reliable.

Re: OOPS 2.6.0-test2, modprobe i810fb

[Andrew Morton]

"S. Anderson" <sa@xmission.com> wrote:
>
> On Mon, Jul 28, 2003 at 06:18:07PM +0100, Pavel Rabel wrote:
> > Got this OOPS when trying "modprobe i810fb",
> > kernel 2.6.0-test2
> > 
> 
> I am also getting this oops, or somthing very simmillar.

yay!  I finally fixed a bug! (sheesh, bad day).

The device table is not null-terminated so we run off the end during
matching and go oops.

I also moved all the statics out of i810_main.h and into i810_main.c. 
There is not a lot of point putting them in a header file: if any other .c
file includes the header we get multiple private instantiatiations of
all that stuff.



 drivers/video/i810/i810_main.c |   51 +++++++++++++++++++++++++++++++++++++++++
 drivers/video/i810/i810_main.h |   50 ----------------------------------------
 2 files changed, 51 insertions(+), 50 deletions(-)

diff -puN drivers/video/i810/i810_main.h~i810-fix drivers/video/i810/i810_main.h
--- 25/drivers/video/i810/i810_main.h~i810-fix	2003-07-28 20:20:15.000000000 -0700
+++ 25-akpm/drivers/video/i810/i810_main.h	2003-07-28 20:20:15.000000000 -0700
@@ -14,62 +14,12 @@
 #ifndef __I810_MAIN_H__
 #define __I810_MAIN_H__
 
-/* PCI */
-static const char *i810_pci_list[] __initdata = {
-	"Intel(R) 810 Framebuffer Device"                                 ,
-	"Intel(R) 810-DC100 Framebuffer Device"                           ,
-	"Intel(R) 810E Framebuffer Device"                                ,
-	"Intel(R) 815 (Internal Graphics 100Mhz FSB) Framebuffer Device"  ,
-	"Intel(R) 815 (Internal Graphics only) Framebuffer Device"        , 
-	"Intel(R) 815 (Internal Graphics with AGP) Framebuffer Device"  
-};
-
-static struct pci_device_id i810fb_pci_tbl[] __initdata = {
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG1, 
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG3,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1  },
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810E_IG,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 2 },
-	/* mvo: added i815 PCI-ID */  
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_100,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 3 },
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_NOAGP,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 4 },
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_CGC,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 5 }
-};	  
-	             
 static int  __init i810fb_init_pci (struct pci_dev *dev, 
 				       const struct pci_device_id *entry);
 static void __exit i810fb_remove_pci(struct pci_dev *dev);
 static int i810fb_resume(struct pci_dev *dev);
 static int i810fb_suspend(struct pci_dev *dev, u32 state);
 
-static struct pci_driver i810fb_driver = {
-	.name     =	"i810fb",
-	.id_table =	i810fb_pci_tbl,
-	.probe    =	i810fb_init_pci,
-	.remove   =	__exit_p(i810fb_remove_pci),
-	.suspend  =     i810fb_suspend,
-	.resume   =     i810fb_resume,
-};	
-
-static int vram       __initdata = 4;
-static int bpp        __initdata = 8;
-static int mtrr       __initdata = 0;
-static int accel      __initdata = 0;
-static int hsync1     __initdata = 0;
-static int hsync2     __initdata = 0;
-static int vsync1     __initdata = 0;
-static int vsync2     __initdata = 0;
-static int xres       __initdata = 640;
-static int yres       __initdata = 480;
-static int vyres      __initdata = 0;
-static int sync       __initdata = 0;
-static int ext_vga    __initdata = 0;
-static int dcolor     __initdata = 0;
-
 /*
  * voffset - framebuffer offset in MiB from aperture start address.  In order for
  * the driver to work with X, we must try to use memory holes left untouched by X. The 
diff -puN drivers/video/i810/i810_main.c~i810-fix drivers/video/i810/i810_main.c
--- 25/drivers/video/i810/i810_main.c~i810-fix	2003-07-28 20:20:15.000000000 -0700
+++ 25-akpm/drivers/video/i810/i810_main.c	2003-07-28 20:20:15.000000000 -0700
@@ -56,6 +56,57 @@
 #include "i810.h"
 #include "i810_main.h"
 
+/* PCI */
+static const char *i810_pci_list[] __initdata = {
+	"Intel(R) 810 Framebuffer Device"                                 ,
+	"Intel(R) 810-DC100 Framebuffer Device"                           ,
+	"Intel(R) 810E Framebuffer Device"                                ,
+	"Intel(R) 815 (Internal Graphics 100Mhz FSB) Framebuffer Device"  ,
+	"Intel(R) 815 (Internal Graphics only) Framebuffer Device"        ,
+	"Intel(R) 815 (Internal Graphics with AGP) Framebuffer Device"
+};
+
+static struct pci_device_id i810fb_pci_tbl[] __initdata = {
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG1,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG3,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1  },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810E_IG,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 2 },
+	/* mvo: added i815 PCI-ID */
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_100,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 3 },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_NOAGP,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 4 },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_CGC,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 5 },
+	{ 0 },
+};
+
+static struct pci_driver i810fb_driver = {
+	.name     =	"i810fb",
+	.id_table =	i810fb_pci_tbl,
+	.probe    =	i810fb_init_pci,
+	.remove   =	__exit_p(i810fb_remove_pci),
+	.suspend  =     i810fb_suspend,
+	.resume   =     i810fb_resume,
+};
+
+static int vram       __initdata = 4;
+static int bpp        __initdata = 8;
+static int mtrr       __initdata = 0;
+static int accel      __initdata = 0;
+static int hsync1     __initdata = 0;
+static int hsync2     __initdata = 0;
+static int vsync1     __initdata = 0;
+static int vsync2     __initdata = 0;
+static int xres       __initdata = 640;
+static int yres       __initdata = 480;
+static int vyres      __initdata = 0;
+static int sync       __initdata = 0;
+static int ext_vga    __initdata = 0;
+static int dcolor     __initdata = 0;
+
 /*------------------------------------------------------------*/
 
 /**************************************************************

_

Re: OOPS 2.6.0-test2, modprobe i810fb

[S. Anderson]

On Mon, Jul 28, 2003 at 08:26:00PM -0700, Andrew Morton wrote:
> "S. Anderson" <sa@xmission.com> wrote:
> >
> > On Mon, Jul 28, 2003 at 06:18:07PM +0100, Pavel Rabel wrote:
> > > Got this OOPS when trying "modprobe i810fb",
> > > kernel 2.6.0-test2
> > > 
> > 
> > I am also getting this oops, or somthing very simmillar.
> 
> yay!  I finally fixed a bug! (sheesh, bad day).
> 
> The device table is not null-terminated so we run off the end during
> matching and go oops.
> 

Thanks, that fixes the oops Pavel reported!

But I now realize the oops I am getting is different...

It happens only if any of these "i810fb, i810_audio or intel-agp"
are compiled in the kernel or insterted as modules.

i810fb, i810_audio or intel-agp load up fine and seem to all work
properly. I only get the oops when I put a card into my cardbus slot.

this is what i think happens, when I put the card in, it sets off some
functions that will try to get a driver for the card I just inserted.
when it gets to the pci_bus_match function, my cards vendor and device 
numbers are tested against a drivers id_table. when that driver is 
"i810fb, i810_audio or intel-agp" (and i810fb, i810_audio or intel-agp
is allready loaded) the id_table is at an address that cant be handled, 
thus cauing the oops. I am having trouble figuring out why 
pci_drv->id_table isnt valid in this case.

Any ideas?

Thanks,
Shawn Anderson

Re: OOPS 2.6.0-test2, modprobe i810fb

[Andrew Morton]

"S. Anderson" <sa@xmission.com> wrote:
>
> when that driver is 
>  "i810fb, i810_audio or intel-agp" (and i810fb, i810_audio or intel-agp
>  is allready loaded) the id_table is at an address that cant be handled, 
>  thus cauing the oops. I am having trouble figuring out why 
>  pci_drv->id_table isnt valid in this case.

Does this fix?  I'm not sure whether that "{ }" in there will generate
another table entry...


diff -puN drivers/char/agp/intel-agp.c~intel-agp-oops-fix drivers/char/agp/intel-agp.c
--- 25/drivers/char/agp/intel-agp.c~intel-agp-oops-fix	2003-07-28 22:30:30.000000000 -0700
+++ 25-akpm/drivers/char/agp/intel-agp.c	2003-07-28 22:30:53.000000000 -0700
@@ -1426,7 +1426,7 @@ static struct pci_device_id agp_intel_pc
 	.subvendor	= PCI_ANY_ID,
 	.subdevice	= PCI_ANY_ID,
 	},
-	{ }
+	{ 0, },
 };
 
 MODULE_DEVICE_TABLE(pci, agp_intel_pci_table);

_

Re: OOPS 2.6.0-test2, modprobe i810fb

[Bill Davidsen]

On Mon, 28 Jul 2003, Andrew Morton wrote:

> "S. Anderson" <sa@xmission.com> wrote:
> >
> > when that driver is 
> >  "i810fb, i810_audio or intel-agp" (and i810fb, i810_audio or intel-agp
> >  is allready loaded) the id_table is at an address that cant be handled, 
> >  thus cauing the oops. I am having trouble figuring out why 
> >  pci_drv->id_table isnt valid in this case.
> 
> Does this fix?  I'm not sure whether that "{ }" in there will generate
> another table entry...
> 
> 
> diff -puN drivers/char/agp/intel-agp.c~intel-agp-oops-fix drivers/char/agp/intel-agp.c
> --- 25/drivers/char/agp/intel-agp.c~intel-agp-oops-fix	2003-07-28 22:30:30.000000000 -0700
> +++ 25-akpm/drivers/char/agp/intel-agp.c	2003-07-28 22:30:53.000000000 -0700
> @@ -1426,7 +1426,7 @@ static struct pci_device_id agp_intel_pc
>  	.subvendor	= PCI_ANY_ID,
>  	.subdevice	= PCI_ANY_ID,
>  	},
> -	{ }
> +	{ 0, },
>  };
>  
>  MODULE_DEVICE_TABLE(pci, agp_intel_pci_table);
> 
> _

Sure about that last comma? Any compiler version issues?

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: OOPS 2.6.0-test2, modprobe i810fb

[Michael Driscoll]

On Tuesday 29 July 2003 20:56, Bill Davidsen wrote:
> > diff -puN drivers/char/agp/intel-agp.c~intel-agp-oops-fix
> > drivers/char/agp/intel-agp.c ---
> > 25/drivers/char/agp/intel-agp.c~intel-agp-oops-fix	2003-07-28
> > 22:30:30.000000000 -0700 +++
> > 25-akpm/drivers/char/agp/intel-agp.c	2003-07-28 22:30:53.000000000 -0700
> > @@ -1426,7 +1426,7 @@ static struct pci_device_id agp_intel_pc
> >  	.subvendor	= PCI_ANY_ID,
> >  	.subdevice	= PCI_ANY_ID,
> >  	},
> > -	{ }
> > +	{ 0, },
> >  };
> >
> >  MODULE_DEVICE_TABLE(pci, agp_intel_pci_table);
> >
> > _
>
> Sure about that last comma? Any compiler version issues?

It's allowed in K&R2 (and explicitly marked as a feature, see pp.218-219).

I don't have C99 handy but I'm pretty sure it's still legal.

-- 
Michael Driscoll, fenris@ulfheim.net
"A noble spirit embiggens the smallest man" -- J. Springfield

Re: OOPS 2.6.0-test2, modprobe i810fb

[Andrew Morton]

"S. Anderson" <sa@xmission.com> wrote:
>
> Thanks, that fixes the oops Pavel reported!
> 
> But I now realize the oops I am getting is different...
> 
> It happens only if any of these "i810fb, i810_audio or intel-agp"
> are compiled in the kernel or insterted as modules.
> 
> i810fb, i810_audio or intel-agp load up fine and seem to all work
> properly. I only get the oops when I put a card into my cardbus slot.
> 
> this is what i think happens, when I put the card in, it sets off some
> functions that will try to get a driver for the card I just inserted.
> when it gets to the pci_bus_match function, my cards vendor and device 
> numbers are tested against a drivers id_table. when that driver is 
> "i810fb, i810_audio or intel-agp" (and i810fb, i810_audio or intel-agp
> is allready loaded) the id_table is at an address that cant be handled, 
> thus cauing the oops. I am having trouble figuring out why 
> pci_drv->id_table isnt valid in this case.

Everything seems happy here:

vmm:/home/akpm> lsmod
Module                  Size  Used by
i810fb                 31572  0 
cfbcopyarea             4700  1 i810fb
vgastate               10660  1 i810fb
cfbimgblt               4068  1 i810fb
cfbfillrect             4820  1 i810fb
intel_agp              16940  1 
agpgart                32496  1 intel_agp
i810_audio             34208  0 
ac97_codec             18932  1 i810_audio
rtc                    15744  0 

Can you do modprobe-by-hand, see which one causes the oops?

Re: OOPS 2.6.0-test2, modprobe i810fb

[S. Anderson]

On Mon, Jul 28, 2003 at 10:59:14PM -0700, Andrew Morton wrote:
> "S. Anderson" <sa@xmission.com> wrote:
> >
> > Thanks, that fixes the oops Pavel reported!
> > 
> > But I now realize the oops I am getting is different...
> > 
> > It happens only if any of these "i810fb, i810_audio or intel-agp"
> > are compiled in the kernel or insterted as modules.
> > 
> > i810fb, i810_audio or intel-agp load up fine and seem to all work
> > properly. I only get the oops when I put a card into my cardbus slot.
> > 
> > this is what i think happens, when I put the card in, it sets off some
> > functions that will try to get a driver for the card I just inserted.
> > when it gets to the pci_bus_match function, my cards vendor and device 
> > numbers are tested against a drivers id_table. when that driver is 
> > "i810fb, i810_audio or intel-agp" (and i810fb, i810_audio or intel-agp
> > is allready loaded) the id_table is at an address that cant be handled, 
> > thus cauing the oops. I am having trouble figuring out why 
> > pci_drv->id_table isnt valid in this case.
> 
> Everything seems happy here:
> 
> vmm:/home/akpm> lsmod
> Module                  Size  Used by
> i810fb                 31572  0 
> cfbcopyarea             4700  1 i810fb
> vgastate               10660  1 i810fb
> cfbimgblt               4068  1 i810fb
> cfbfillrect             4820  1 i810fb
> intel_agp              16940  1 
> agpgart                32496  1 intel_agp
> i810_audio             34208  0 
> ac97_codec             18932  1 i810_audio
> rtc                    15744  0 
> 
> Can you do modprobe-by-hand, see which one causes the oops?

I will try to explain the problem better.

First of all, I can modprobe all three of these modules with no problems.

the oops only occurs when one of these modules are modprobed
_before_ I insert a card into my cardbus.

With no modules inserted, I can insert my card into the cardbus slot 
with no problems. This is what my log looks like. (with my debugging printk)

Jul 29 00:28:48 localhost kernel:  (pci_bus_add_devices) bus 3 devfn 0  1260 3890
Jul 29 00:28:48 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:28:48 localhost kernel:  ^ matching? ^ (serial)  ((( &ids->vendor = c0397314 )))
Jul 29 00:28:48 localhost kernel: pci_match_device: &ids->vendor = c0397314
Jul 29 00:28:48 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:28:48 localhost kernel:  ^ matching? ^ (eepro100)  ((( &ids->vendor = c0398a60 )))
Jul 29 00:28:48 localhost kernel: pci_match_device: &ids->vendor = c0398a60
Jul 29 00:28:48 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:28:48 localhost kernel:  ^ matching? ^ (PCI IDE)  ((( &ids->vendor = c039a630 )))
Jul 29 00:28:48 localhost kernel: pci_match_device: &ids->vendor = c039a630
Jul 29 00:28:48 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:28:48 localhost kernel:  ^ matching? ^ (yenta_cardbus)  ((( &ids->vendor = c039df98 )))
Jul 29 00:28:48 localhost kernel: pci_match_device: &ids->vendor = c039df98
Jul 29 00:28:48 localhost pci.agent: ... no modules for PCI slot 0000:03:00.0

then I take my card out of its slot and 
then modprobe i810fb (I could modprobe i810_audio or intel-agp or 
all three at the same time)

Jul 29 00:33:48 localhost kernel: pci_bus_match: bus=0, devfn=0 8086 3575
Jul 29 00:33:48 localhost kernel:  ^ matching? ^ (i810fb)  ((( &ids->vendor = d094ee7c )))
Jul 29 00:33:48 localhost kernel: pci_match_device: &ids->vendor = d094ee7c
Jul 29 00:33:48 localhost kernel: pci_bus_match: bus=0, devfn=16 8086 3577
Jul 29 00:33:48 localhost kernel:  ^ matching? ^ (i810fb)  ((( &ids->vendor = d094ee7c )))
Jul 29 00:33:48 localhost kernel: pci_match_device: &ids->vendor = d094ee7c
Jul 29 00:33:48 localhost kernel: pci_bus_match: bus=0, devfn=17 8086 3577
Jul 29 00:33:48 localhost kernel:  ^ matching? ^ (i810fb)  ((( &ids->vendor = d094ee7c )))
Jul 29 00:33:48 localhost kernel: pci_match_device: &ids->vendor = d094ee7c
Jul 29 00:33:48 localhost kernel: pci_bus_match: bus=0, devfn=232 8086 2482
Jul 29 00:33:48 localhost kernel:  ^ matching? ^ (i810fb)  ((( &ids->vendor = d094ee7c )))
Jul 29 00:33:48 localhost kernel: pci_match_device: &ids->vendor = d094ee7c
[..snip..]

then when i insert my card again this is when the oops occurs:

Jul 29 00:40:12 localhost kernel:  (pci_bus_add_devices) bus 3 devfn 0  1260 3890
Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (serial)  ((( &ids->vendor = c0397314 )))
Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = c0397314
Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (eepro100)  ((( &ids->vendor = c0398a60 )))
Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = c0398a60
Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (PCI IDE)  ((( &ids->vendor = c039a630 )))
Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = c039a630
Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (yenta_cardbus)  ((( &ids->vendor = c039df98 )))
Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = c039df98
Jul 29 00:40:12 localhost pci.agent: ... no modules for PCI slot 0000:03:00.0
Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (i810fb)  ((( &ids->vendor = d094ee7c )))
Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = d094ee7c
Jul 29 00:40:12 localhost kernel: Unable to handle kernel paging request at virtual address d094ee7c
Jul 29 00:40:12 localhost kernel:  printing eip:
Jul 29 00:40:12 localhost kernel: c01f7da3
Jul 29 00:40:12 localhost kernel: *pde = 0f913067
Jul 29 00:40:12 localhost kernel: *pte = 00000000
Jul 29 00:40:12 localhost kernel: Oops: 0000 [#1]
Jul 29 00:40:12 localhost kernel: CPU:    0
Jul 29 00:40:12 localhost kernel: EIP:    0060:[quirk_transparent_bridge+15/20]    Not tainted
Jul 29 00:40:12 localhost kernel: EIP:    0060:[<c01f7da3>]    Not tainted
Jul 29 00:40:12 localhost kernel: EFLAGS: 00010286
Jul 29 00:40:12 localhost kernel: EIP is at pci_match_device+0x73/0x90
Jul 29 00:40:12 localhost kernel: eax: 0000002a   ebx: d094ee7c   ecx: 00000001   edx: c035fa38
Jul 29 00:40:12 localhost kernel: esi: c67c4004   edi: c67c4004   ebp: cf619e94   esp: cf619e84
Jul 29 00:40:12 localhost kernel: ds: 007b   es: 007b   ss: 0068
Jul 29 00:40:12 localhost kernel: Process pccardd (pid: 9, threadinfo=cf618000 task=cf636000)
Jul 29 00:40:12 localhost kernel: Stack: c031aa20 d094ee7c d096e800 d094ee7c cf619eb4 c01f84fb d094ee7c c67c4004 
Jul 29 00:40:12 localhost kernel:        ffffffed d096e828 c67c4058 c039e09c cf619ed0 c021f0f9 c67c4058 d096e828 
Jul 29 00:40:12 localhost kernel:        d096e870 c03918f4 c67c4058 cf619eec c021f18a c67c4058 d096e828 c0391880 
Jul 29 00:40:12 localhost kernel: Call Trace:
Jul 29 00:40:12 localhost kernel:  [pci_free_dynids+3/360] pci_bus_match+0x5f/0x2b0
Jul 29 00:40:12 localhost kernel:  [<c01f84fb>] pci_bus_match+0x5f/0x2b0
Jul 29 00:40:12 localhost kernel:  [acpi_tb_verify_table_checksum+113/148] bus_match+0x21/0x64
Jul 29 00:40:12 localhost kernel:  [<c021f0f9>] bus_match+0x21/0x64
Jul 29 00:40:12 localhost kernel:  [acpi_tb_find_table+58/308] device_attach+0x4e/0x70
Jul 29 00:40:12 localhost kernel:  [<c021f18a>] device_attach+0x4e/0x70
Jul 29 00:40:12 localhost kernel:  [acpi_get_firmware_table+126/848] bus_add_device+0x72/0xb4
Jul 29 00:40:12 localhost kernel:  [<c021f302>] bus_add_device+0x72/0xb4
Jul 29 00:40:12 localhost kernel:  [acpi_tb_verify_rsdp+320/344] device_add+0xd0/0x108
Jul 29 00:40:12 localhost kernel:  [<c021dc40>] device_add+0xd0/0x108
Jul 29 00:40:12 localhost kernel:  [pci_bus_write_config_word+100/324] pci_bus_add_devices+0x50/0x300
Jul 29 00:40:12 localhost kernel:  [<c01f4864>] pci_bus_add_devices+0x50/0x300
Jul 29 00:40:12 localhost kernel:  [i830_cleanup_buf_error+121/184] cb_alloc+0xad/0xc8
Jul 29 00:40:12 localhost kernel:  [<c02553cd>] cb_alloc+0xad/0xc8
Jul 29 00:40:12 localhost kernel:  [agp_3_5_isochronous_node_enable+342/1020] socket_insert+0x56/0xa4
Jul 29 00:40:12 localhost kernel:  [<c0252362>] socket_insert+0x56/0xa4
Jul 29 00:40:12 localhost kernel:  [agp_3_5_isochronous_node_enable+869/1020] socket_detect_change+0x69/0x70
Jul 29 00:40:13 localhost kernel:  [<c0252571>] socket_detect_change+0x69/0x70
Jul 29 00:40:13 localhost kernel:  [agp_3_5_enable+167/704] pccardd+0x1ef/0x2a0
Jul 29 00:40:13 localhost kernel:  [<c0252767>] pccardd+0x1ef/0x2a0
Jul 29 00:40:13 localhost kernel:  [agp_3_5_isochronous_node_enable+876/1020] pccardd+0x0/0x2a0
Jul 29 00:40:13 localhost kernel:  [<c0252578>] pccardd+0x0/0x2a0
Jul 29 00:40:13 localhost kernel:  [schedule+404/1156] default_wake_function+0x0/0x20
Jul 29 00:40:13 localhost kernel:  [<c011ae7c>] default_wake_function+0x0/0x20
Jul 29 00:40:13 localhost kernel:  [schedule+404/1156] default_wake_function+0x0/0x20
Jul 29 00:40:13 localhost kernel:  [<c011ae7c>] default_wake_function+0x0/0x20
Jul 29 00:40:13 localhost kernel:  [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc
Jul 29 00:40:13 localhost kernel:  [<c01070c5>] kernel_thread_helper+0x5/0xc
Jul 29 00:40:13 localhost kernel: 
Jul 29 00:40:13 localhost kernel: Code: 83 3b 00 75 a0 83 7b 08 00 75 9a 83 7b 14 00 75 94 31 c0 8d 

I hope this makes sense.

Re: OOPS 2.6.0-test2, modprobe i810fb

[Andrew Morton]

"S. Anderson" <sa@xmission.com> wrote:
>
> Jul 29 00:33:48 localhost kernel: pci_bus_match: bus=0, devfn=232 8086 2482
>  Jul 29 00:33:48 localhost kernel:  ^ matching? ^ (i810fb)  ((( &ids->vendor = d094ee7c )))
>  Jul 29 00:33:48 localhost kernel: pci_match_device: &ids->vendor = d094ee7c
>  [..snip..]
> 
>  then when i insert my card again this is when the oops occurs:
> 
>  Jul 29 00:40:12 localhost kernel:  (pci_bus_add_devices) bus 3 devfn 0  1260 3890
>  Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
>  Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (serial)  ((( &ids->vendor = c0397314 )))
>  Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = c0397314
>  Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
>  Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (eepro100)  ((( &ids->vendor = c0398a60 )))
>  Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = c0398a60
>  Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
>  Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (PCI IDE)  ((( &ids->vendor = c039a630 )))
>  Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = c039a630
>  Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
>  Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (yenta_cardbus)  ((( &ids->vendor = c039df98 )))
>  Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = c039df98
>  Jul 29 00:40:12 localhost pci.agent: ... no modules for PCI slot 0000:03:00.0
>  Jul 29 00:40:12 localhost kernel: pci_bus_match: bus=3, devfn=0 1260 3890
>  Jul 29 00:40:12 localhost kernel:  ^ matching? ^ (i810fb)  ((( &ids->vendor = d094ee7c )))
>  Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = d094ee7c
>  Jul 29 00:40:12 localhost kernel: Unable to handle kernel paging request at virtual address d094ee7c

wtf?  So the memory at d094ee7c (which contains i810fb's pci table) became
unmapped from kernel virtual address space as a result of you inserting
your carbus card.

I am impressed.

Jsut as a crazy test, could you delete /sbin/rmmod and see if it still
happens?  Maybe something is removing the module at an embarrassing time or
something.

Re: OOPS 2.6.0-test2, modprobe i810fb

[S. Anderson]

On Tue, Jul 29, 2003 at 12:54:56AM -0700, Andrew Morton wrote:
> "S. Anderson" <sa@xmission.com> wrote:
> >
> >  Jul 29 00:40:12 localhost kernel: pci_match_device: &ids->vendor = d094ee7c
> >  Jul 29 00:40:12 localhost kernel: Unable to handle kernel paging request at virtual address d094ee7c
> 
> wtf?  So the memory at d094ee7c (which contains i810fb's pci table) became
> unmapped from kernel virtual address space as a result of you inserting
> your carbus card.
> 
> I am impressed.
> 
> Jsut as a crazy test, could you delete /sbin/rmmod and see if it still
> happens?  Maybe something is removing the module at an embarrassing time or
> something.
> 

I moved /sbin/rmmod* out of my path and I still get the oop. :-)

I will try to hack something together to find out if inserting a carbus
card unmaps i810fb's pci table, or if something else is doing it.

thanks,
Shawn Anderson

Re: OOPS 2.6.0-test2, modprobe i810fb

[Alan Cox]

On Maw, 2003-07-29 at 08:54, Andrew Morton wrote:
> wtf?  So the memory at d094ee7c (which contains i810fb's pci table) became
> unmapped from kernel virtual address space as a result of you inserting
> your carbus card.
> 
> I am impressed.

This makes complete sense actually - its marked __initdata. Remove the
__initdata and try again or mark it __devinitdata ?

Re: OOPS 2.6.0-test2, modprobe i810fb

[Andrew Morton]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Maw, 2003-07-29 at 08:54, Andrew Morton wrote:
> > wtf?  So the memory at d094ee7c (which contains i810fb's pci table) became
> > unmapped from kernel virtual address space as a result of you inserting
> > your carbus card.
> > 
> > I am impressed.
> 
> This makes complete sense actually - its marked __initdata. Remove the
> __initdata and try again or mark it __devinitdata ?

hmm, that's a bug if the driver is statically linked, but afaik we're not
dropping the __init sections from modules yet.  Or did that change?

Still.  A grep finds forty-odd instances of "pci_device_id.*__initdata".  I
think I'll go convert them all to __devinitdata.

Re: OOPS 2.6.0-test2, modprobe i810fb

[S. Anderson]

On Tue, Jul 29, 2003 at 01:00:40PM +0100, Alan Cox wrote:
> On Maw, 2003-07-29 at 08:54, Andrew Morton wrote:
> > wtf?  So the memory at d094ee7c (which contains i810fb's pci table) became
> > unmapped from kernel virtual address space as a result of you inserting
> > your carbus card.
> > 
> > I am impressed.
> 
> This makes complete sense actually - its marked __initdata. Remove the
> __initdata and try again or mark it __devinitdata ?
> 

Just to confirm your findings:
Changing __initdata to __devinitdata fixes the oops for me.

Thanks!
sa

Re: OOPS 2.6.0-test2, modprobe i810fb

[Pavel Rabel]

Applied the patch, no OOPSing now, thanks.

Pavel

On Mon, Jul 28, 2003 at 08:26:00PM -0700, Andrew Morton wrote:
> "S. Anderson" <sa@xmission.com> wrote:
> >
> > On Mon, Jul 28, 2003 at 06:18:07PM +0100, Pavel Rabel wrote:
> > > Got this OOPS when trying "modprobe i810fb",
> > > kernel 2.6.0-test2
> > > 
> > 
> > I am also getting this oops, or somthing very simmillar.
> 
> yay!  I finally fixed a bug! (sheesh, bad day).
> 
> The device table is not null-terminated so we run off the end during
> matching and go oops.
> 
> I also moved all the statics out of i810_main.h and into i810_main.c. 
> There is not a lot of point putting them in a header file: if any other .c
> file includes the header we get multiple private instantiatiations of
> all that stuff.