I just started testing the cPCI hotplug driver I'm working on against
2.4.19 after upgrading the kernel in SOMA's in-house distribution,
and I'm now getting the attached oops code when trying to access the
pcihpfs (e.g. with ls) after mounting it. I backed out the couple of
changes I made last night that might have been remotely connected
(added hardware_test and get_power_status hotplug ops in my driver),
and I'm still getting it in the same place, so it looks like maybe a
VFS change somewhere in 2.4.19 broke pcihpfs. Any ideas?
Thanks,
Scott
ksymoops 2.4.4 on i686 2.4.19. Options used
-v vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/ (specified)
-m /boot/System.map (default)
Unable to handle kernel NULL pointer dereference at virtual address 00000024
c013d0d2
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c013d0d2>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: cf341488 ebx: cf341460 ecx: 0805a495 edx: 00000018
esi: 00000020 edi: c13eaf60 ebp: cfe19f54 esp: cfe19f44
ds: 0018 es: 0018 ss: 0018
Process ls (pid: 372, stackpage=cfe19000)
Stack: cfdd8b80 cfdd8bfc cfdd8be8 cf341488 cfe19f74 c013ce80 c13eaf60 cfe19fac
c013d3d0 fffffff7 00000000 00000003 cfe19fbc c013d571 c13eaf60 c013d3d0
cfe19fac cfe18000 00000000 00000003 c13eaf60 cffacc78 cfe19fbc c0122ecc
Call Trace: [<c013ce80>] [<c013d3d0>] [<c013d571>] [<c013d3d0>] [<c0122ecc>]
[<c010890b>]
Code: 8b 46 04 8b 16 89 42 04 89 10 8b 43 28 89 70 04 89 06 8b 55
>>EIP; c013d0d2 <dcache_readdir+a2/134> <=====
Trace; c013ce80 <vfs_readdir+60/80>
Trace; c013d3d0 <filldir64+0/154>
Trace; c013d571 <sys_getdents64+4d/100>
Trace; c013d3d0 <filldir64+0/154>
Trace; c0122ecc <sys_brk+c0/ec>
Trace; c010890b <system_call+33/38>
Code; c013d0d2 <dcache_readdir+a2/134>
00000000 <_EIP>:
Code; c013d0d2 <dcache_readdir+a2/134> <=====
0: 8b 46 04 mov 0x4(%esi),%eax <=====
Code; c013d0d5 <dcache_readdir+a5/134>
3: 8b 16 mov (%esi),%edx
Code; c013d0d7 <dcache_readdir+a7/134>
5: 89 42 04 mov %eax,0x4(%edx)
Code; c013d0da <dcache_readdir+aa/134>
8: 89 10 mov %edx,(%eax)
Code; c013d0dc <dcache_readdir+ac/134>
a: 8b 43 28 mov 0x28(%ebx),%eax
Code; c013d0df <dcache_readdir+af/134>
d: 89 70 04 mov %esi,0x4(%eax)
Code; c013d0e2 <dcache_readdir+b2/134>
10: 89 06 mov %eax,(%esi)
Code; c013d0e4 <dcache_readdir+b4/134>
12: 8b 55 00 mov 0x0(%ebp),%edx
--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]
On Fri, Aug 09, 2002 at 04:18:02PM -0400, Scott Murray wrote:
> I just started testing the cPCI hotplug driver I'm working on against
> 2.4.19 after upgrading the kernel in SOMA's in-house distribution,
> and I'm now getting the attached oops code when trying to access the
> pcihpfs (e.g. with ls) after mounting it. I backed out the couple of
> changes I made last night that might have been remotely connected
> (added hardware_test and get_power_status hotplug ops in my driver),
> and I'm still getting it in the same place, so it looks like maybe a
> VFS change somewhere in 2.4.19 broke pcihpfs. Any ideas?
Hm, I just verified this on one of my machines, but a different one
(ia64 box) works just fine. I'll dig and try to find the problem later
on today. As a side note, someone who based their code off of pcihpfs
also has the same problem, so I think it's some vfs change that I didn't
catch.
thanks,
greg k-h
On Fri, Aug 09, 2002 at 04:18:02PM -0400, Scott Murray wrote:
> I just started testing the cPCI hotplug driver I'm working on against
> 2.4.19 after upgrading the kernel in SOMA's in-house distribution,
> and I'm now getting the attached oops code when trying to access the
> pcihpfs (e.g. with ls) after mounting it. I backed out the couple of
> changes I made last night that might have been remotely connected
> (added hardware_test and get_power_status hotplug ops in my driver),
> and I'm still getting it in the same place, so it looks like maybe a
> VFS change somewhere in 2.4.19 broke pcihpfs. Any ideas?
Ah, looks like a change with readdir.c in 2.4.19-pre2 caused this
problem. Please try the attached patch, it fixes the problem for me.
Thanks to Dan Stekloff for helping in finding this fix.
thanks,
greg k-h
diff -Nru a/drivers/hotplug/pci_hotplug_core.c b/drivers/hotplug/pci_hotplug_core.c
--- a/drivers/hotplug/pci_hotplug_core.c Tue Aug 13 12:57:16 2002
+++ b/drivers/hotplug/pci_hotplug_core.c Tue Aug 13 12:57:16 2002
@@ -76,7 +76,6 @@
};
static struct super_operations pcihpfs_ops;
-static struct file_operations pcihpfs_dir_operations;
static struct file_operations default_file_operations;
static struct inode_operations pcihpfs_dir_inode_operations;
static struct vfsmount *pcihpfs_mount; /* one of the mounts of our fs for reference counting */
@@ -122,7 +121,7 @@
break;
case S_IFDIR:
inode->i_op = &pcihpfs_dir_inode_operations;
- inode->i_fop = &pcihpfs_dir_operations;
+ inode->i_fop = &dcache_dir_ops;
break;
}
}
@@ -234,11 +233,6 @@
return 0;
}
-
-static struct file_operations pcihpfs_dir_operations = {
- read: generic_read_dir,
- readdir: dcache_readdir,
-};
static struct file_operations default_file_operations = {
read: default_read_file,
On Tue, 13 Aug 2002, Greg KH wrote:
> On Fri, Aug 09, 2002 at 04:18:02PM -0400, Scott Murray wrote:
> > I just started testing the cPCI hotplug driver I'm working on against
> > 2.4.19 after upgrading the kernel in SOMA's in-house distribution,
> > and I'm now getting the attached oops code when trying to access the
> > pcihpfs (e.g. with ls) after mounting it. I backed out the couple of
> > changes I made last night that might have been remotely connected
> > (added hardware_test and get_power_status hotplug ops in my driver),
> > and I'm still getting it in the same place, so it looks like maybe a
> > VFS change somewhere in 2.4.19 broke pcihpfs. Any ideas?
>
> Ah, looks like a change with readdir.c in 2.4.19-pre2 caused this
> problem. Please try the attached patch, it fixes the problem for me.
I've finally gotten around to trying this out after coming back from
vacation, and have verified that it fixes the problem for me.
> Thanks to Dan Stekloff for helping in finding this fix.
Ditto, I wan't enjoying the prospect of trying to debug this myself.
Scott
--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]