linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* (no subject)
@ 2004-02-24 13:58 Jim Deas
  2004-02-24 14:44 ` your mail Richard B. Johnson
  0 siblings, 1 reply; 2+ messages in thread
From: Jim Deas @ 2004-02-24 13:58 UTC (permalink / raw)
  To: linux-kernel

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 

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?



^ permalink raw reply	[flat|nested] 2+ messages in thread

* 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

end of thread, other threads:[~2004-02-24 14:42 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-24 13:58 Jim Deas
2004-02-24 14:44 ` your mail Richard B. Johnson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).