2003-07-28 17:02:59

by Pavel Rabel

[permalink] [raw]
Subject: OOPS 2.6.0-test2, modprobe i810fb

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


--
Pavel


Attachments:
(No filename) (77.00 B)
oops.txt (2.89 kB)
Download all attachments

2003-07-29 02:20:51

by S. Anderson

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

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.

2003-07-29 03:26:35

by Andrew Morton

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

"S. Anderson" <[email protected]> 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;
+
/*------------------------------------------------------------*/

/**************************************************************

_

2003-07-29 05:18:18

by S. Anderson

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

On Mon, Jul 28, 2003 at 08:26:00PM -0700, Andrew Morton wrote:
> "S. Anderson" <[email protected]> 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

2003-07-29 05:32:58

by Andrew Morton

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

"S. Anderson" <[email protected]> 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);

_

2003-07-29 05:59:34

by Andrew Morton

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

"S. Anderson" <[email protected]> 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?

2003-07-29 07:24:31

by S. Anderson

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

On Mon, Jul 28, 2003 at 10:59:14PM -0700, Andrew Morton wrote:
> "S. Anderson" <[email protected]> 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.

2003-07-29 07:55:20

by Andrew Morton

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

"S. Anderson" <[email protected]> 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.

2003-07-29 08:18:45

by S. Anderson

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

On Tue, Jul 29, 2003 at 12:54:56AM -0700, Andrew Morton wrote:
> "S. Anderson" <[email protected]> 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

2003-07-29 09:36:52

by Pavel Rabel

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

Applied the patch, no OOPSing now, thanks.

Pavel

On Mon, Jul 28, 2003 at 08:26:00PM -0700, Andrew Morton wrote:
> "S. Anderson" <[email protected]> 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.

2003-07-29 12:09:38

by Alan

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

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 ?

2003-07-29 20:12:07

by Andrew Morton

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

Alan Cox <[email protected]> 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.

2003-07-29 23:05:58

by S. Anderson

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

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

2003-07-30 03:04:45

by Bill Davidsen

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

On Mon, 28 Jul 2003, Andrew Morton wrote:

> "S. Anderson" <[email protected]> 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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-07-30 20:57:20

by Michael Driscoll

[permalink] [raw]
Subject: Re: OOPS 2.6.0-test2, modprobe i810fb

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, [email protected]
"A noble spirit embiggens the smallest man" -- J. Springfield