Re: looking for help tracing oops -- resolved
Thanks for all the tips, guys. I managed to get the problem to occur on a vanilla kernel with just the proprietary module loaded. Contacted the vendor, they got me to try out a new driver, problem appears to be fixed. Looks like the module wasn't properly tracking refcounts, so it was being unloaded when there were still dangling references. Oops. Thanks, Chris - 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: looking for help tracing oops -- resolved
Thanks for all the tips, guys. I managed to get the problem to occur on a vanilla kernel with just the proprietary module loaded. Contacted the vendor, they got me to try out a new driver, problem appears to be fixed. Looks like the module wasn't properly tracking refcounts, so it was being unloaded when there were still dangling references. Oops. Thanks, Chris - 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: looking for help tracing oops
On Fri, 2 Sep 2005, Christopher Friesen wrote: > > I'm debugging a problem. Unfortunately, I have a module loaded that taints > the kernel. > > Now that that's out of the way, if anyone is still willing to help, the oops > is below, along with the disassembly of filp_close(). One thing I don't > understand--the function makes calls to other functions including printk(), > but I don't see those calls listed in the disassembly. I like to use `objdump -d -r` this is mostly handy for modules since the external references aren't resolved yet. - 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: looking for help tracing oops
In-Reply-To: <[EMAIL PROTECTED]>
On Fri, 02 Sep 2005 at 22:25:40 -0600, Christopher Friesen wrote:
> One thing I
> don't understand--the function makes calls to other functions including
> printk(), but I don't see those calls listed in the disassembly.
Calls to external functions whose address is not known at compile time
look like this (using 'objdump -d' on my 2.6.10 kernel:)
19fd: e8 fc ff ff ff call 19fe
e8 is call relative with 32-bit displacement from start of next instruction.
The displacement points right back at itself (fffc == -4)
> EIP is at filp_close+0x64/0xa0
Here:
> 0x1ac4 :mov0x2c(%eax),%edx <
> 0x1ac7 :test %edx,%edx
> 0x1ac9 :je 0x1a93
eax is f88ad500 and your illegal access was at f88ad52c
Looks like filp->fops points to unallocated memory and it dies while
trying to access filp->fops->flush here:
if (filp->f_op && filp->f_op->flush) {
__
Chuck
-
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: looking for help tracing oops
Christopher Friesen napsal(a): [snip] EIP is at filp_close+0x64/0xa0 [snip] 0x1a9a : call 0x1a9b 0x1a9f : mov%edi,0x4(%esp,1) 0x1aa3 : mov%ebx,(%esp,1) [snip] End of assembler dump. It seems, that this is disassemble output of something else. The function pointer doesn't match. -- Jiri Slaby www.fi.muni.cz/~xslaby ~\-/~ [EMAIL PROTECTED] ~\-/~ 241B347EC88228DE51EE A49C4A73A25004CB2A10 - 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: looking for help tracing oops
Christopher Friesen napsal(a): [snip] EIP is at filp_close+0x64/0xa0 [snip] 0x1a9a filp_close+58: call 0x1a9b filp_close+59 0x1a9f filp_close+63: mov%edi,0x4(%esp,1) 0x1aa3 filp_close+67: mov%ebx,(%esp,1) [snip] End of assembler dump. It seems, that this is disassemble output of something else. The function pointer doesn't match. -- Jiri Slaby www.fi.muni.cz/~xslaby ~\-/~ [EMAIL PROTECTED] ~\-/~ 241B347EC88228DE51EE A49C4A73A25004CB2A10 - 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: looking for help tracing oops
In-Reply-To: [EMAIL PROTECTED]
On Fri, 02 Sep 2005 at 22:25:40 -0600, Christopher Friesen wrote:
One thing I
don't understand--the function makes calls to other functions including
printk(), but I don't see those calls listed in the disassembly.
Calls to external functions whose address is not known at compile time
look like this (using 'objdump -d' on my 2.6.10 kernel:)
19fd: e8 fc ff ff ff call 19fe filp_close+0x4e
e8 is call relative with 32-bit displacement from start of next instruction.
The displacement points right back at itself (fffc == -4)
EIP is at filp_close+0x64/0xa0
Here:
0x1ac4 filp_close+100:mov0x2c(%eax),%edx
0x1ac7 filp_close+103:test %edx,%edx
0x1ac9 filp_close+105:je 0x1a93 filp_close+51
eax is f88ad500 and your illegal access was at f88ad52c
Looks like filp-fops points to unallocated memory and it dies while
trying to access filp-fops-flush here:
if (filp-f_op filp-f_op-flush) {
__
Chuck
-
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: looking for help tracing oops
On Fri, 2 Sep 2005, Christopher Friesen wrote: I'm debugging a problem. Unfortunately, I have a module loaded that taints the kernel. Now that that's out of the way, if anyone is still willing to help, the oops is below, along with the disassembly of filp_close(). One thing I don't understand--the function makes calls to other functions including printk(), but I don't see those calls listed in the disassembly. I like to use `objdump -d -r` this is mostly handy for modules since the external references aren't resolved yet. - 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/
