* Re: your mail
2004-02-24 13:58 Jim Deas
@ 2004-02-24 14:44 ` Richard B. Johnson
0 siblings, 0 replies; 2+ messages in thread
From: Richard B. Johnson @ 2004-02-24 14:44 UTC (permalink / raw)
To: Jim Deas; +Cc: linux-kernel
On Tue, 24 Feb 2004, Jim Deas wrote:
> Can someone point me in the right direction.
> I am getting a oops on a driver I am porting from 2.4 to 2.6.2 kernel.
> I have expanded the file_operations structures and have a driver that
> loads and inits the hardware but when I call the open function I
> get an oops. The best I can track it is
>
Fix your line-warp!
> EIP 0060:[c0188954]
> chrdev_open +0x104
>
> What is the best debug tool to put this oops information in clear
> sight? It appears to never get to my modules open routine so I am
> at a debugging crossroad. What is the option on a kernel compile
> to get the compile listing so I can see what is at 0x104 in this
> block of code?
>
Nothing is going to help with that EIP with a segment value of
0x60. It looks like some dumb coding error, using a pointer
that disappeared after the module init function. In other
words, it's probably something like:
int __init init_module()
{
struct file_operations fops;
mset(&fops, 0x00, sizeof(fops));
fops.open = open;
fops.release = close;
fops.owner = THIS_MODULE;
register_chrdev(DEV_MAJOR, dev, &fops);
}
So, everything in init_module is GONE. Your program calls open()
and the pointer in the kernel gets dereferenced to junk.
There are kernel debugging tools, however I have found that
the most useful tools are printk() and some discipline.
In the case of code above, don't just change the declaration
of the fops object to static. Instead, move it outside the
function, so it's obviously where it won't go away.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
^ permalink raw reply [flat|nested] 2+ messages in thread