bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-hurd] Ethernet problem actually in hp.c (was Re: Ethernet card dete


From: Prabhu Ramachandran
Subject: [Bug-hurd] Ethernet problem actually in hp.c (was Re: Ethernet card detection bug in wd_probe)
Date: Mon, 18 Sep 2000 21:17:09 +0530 (IST)

hi,

>>>>> "Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

    Marcus> Yes! When you made sure it is the wd_probe, you can check
    Marcus> where in linux/src/drivers/net/Space.c it exactly
    Marcus> hangs. This requires inserting unique printk's at
    Marcus> strategical places, until you have the exact line.  There
    Marcus> are little changes between wd.c in gnumach and linux 2.4,
    Marcus> so I am a bit suspicious. If you found out by the above
    Marcus> procedure that it is not wd_probe.c, but some other probe,
    Marcus> you can find the relevant file in net/ and insert the
    Marcus> printks there.

        Ok.  I now know that it hangs in the hp.c driver
i.e. CONFIG_HPLAN.  I put printk's in hp.c and here is what happens

hp.c: hp_probe

        inside the for loop 
        i = 0, ioaddr = 768
        Then, hp_probe1 is called.

Here is my edited hp_probe1 with the printk's.

---
int hp_probe1(struct device *dev, int ioaddr)
{
        int i, board_id, wordmode;
        const char *name;
        static unsigned version_printed = 0;
        printk ("hp.c: Inside hp_probe1 ");

        /* Check for the HP physical address, 08 00 09 xx xx xx. */
        /* This really isn't good enough: we may pick up HP LANCE boards
           also!  Avoid the lance 0x5757 signature. */
        if (inb(ioaddr) != 0x08
                || inb(ioaddr+1) != 0x00
                || inb(ioaddr+2) != 0x09
                || inb(ioaddr+14) == 0x57)
                return ENODEV;

        printk ("line: 125\n");
        
---
It hangs after printing 
        hp.c: Inside hp_probe1
It does not hit the printl ("line:125.\n")

So the inbs are causing problems?  I have no idea of what inb is or
where it is.

What next?      

    Marcus> Kernel debugging is a bit boring, sorry.

        Well, the biggest pain is the rebooting.  Will vmware be
useful?  Or is there any alternative.  You said plex86 doesnt work.  

I have a general question.  Why not have a debug kernel with a zillion
printk's that are all inside a #ifdef DEBUG?  This way anyone could
help with kernel debugging?  Atleast one can add printk's at the start
and end of each function call.  This way one knows which function is
causing the problem.  I admit that you'd generate a huge number of
messages.  But this would be done only once in a while.  Also, one
could compile the module in question with -DDEBUG and then make the
kernel with everything else without it.  This makes debugging far
easier, adds just 2 lines to each function, and makes life easier.
This could be especially useful when an OS is under active
development.  What do you folks think? 

prabhu


reply via email to

[Prev in Thread] Current Thread [Next in Thread]