On 12/9/10 7:17 AM, blacknred wrote: > >> which is NOT a rhel 5.0 kernel, and it says x86_64. >> But the addresses are all 32 bits? > > My apologies there, somehow it all got jumbled up, pasting it again: > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 00000098 > printing eip: > *pde = 2c621001 > Oops: 0000 [#1] > SMP > CPU: 2 > EIP: 0060:[<c0619da1>] Tainted: GF VLI > EFLAGS: 00010282 (2.6.18-164.11.1.el5PAE #1) > EIP is at do_page_fault+0x205/0x607 > eax: ec6de000 ebx: 00000000 ecx: ec6de074 edx: 0000000d > esi: 00014005 edi: ec6de0a4 ebp: 00000014 esp: ec6de054 > ds: 007b es: 007b ss: 0068 > Process bm (pid: 2910, ti=ec6dd000 task=ec6e3550 task.ti=ec6dd000) > Stack: 00000000 00000000 ec6de0a4 00000014 00000098 f7180000 00000001 > 00000000 > ec6de0a4 c0639439 00000000 0000000e 0000000b 00000000 00000000 > 00000000 > 00014005 c0619b9c 00000014 c0405a89 00000000 ec6de0f8 0000000d > 00014005 ok, same task.ti and esp though, so same massive stack overflow. Is this really RHEL, or CentOS? RHEL doesn't ship xfs for i386, and using the xfs-kmod is a very unsupported/unmaintained solution. If it is "real RHEL" you could try requesting actual i386 support, but these stack issues are one of the reasons it's unlikely. CentOS would do well to ship the same xfs code as is in the x86_64 kernel and drop the kmod-xfs altogether. Some stack issues have been resolved since then, but probably not as much as we see here. I also am suspicious of whatever "moddw_ioctl" is in mod_dw; I assume that's the proprietary kernel module. It may have a really bad stack footprint, although the callchain below looks bad enough. What does: # objdump -d /path/to/mod_dw.ko | grep -A30 "<moddw_ioctl>:" | grep sub say? -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
