[Bug-hurd] Re: Ethernet problem actually in hp.c (was Re: Ethernet card detection bug in wd_probe)

[Marcus Brinkmann]

On Mon, Sep 18, 2000 at 09:17:09PM +0530, Prabhu Ramachandran wrote:
> hp.c: hp_probe
> 
>       inside the for loop 
>       i = 0, ioaddr = 768
>       Then, hp_probe1 is called.

That's the first probe (768 == 0x300).

> 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?

Yes, one of them. Do you have some strange device at 0x300, which could be
sensitive to this probe and lock the system? My knowledge about the PC bus
architecture is pretty much non-existent, but exactly the same code is used
in linux, and so I would assume that you'd get the same problem there (with
a linux kernel that has the hp lan driver installed). But maybe some prior
initialization makes a difference.

> I have no idea of what inb is or
> where it is.

inb reads a byte from the given address. So, the code checks if at ioaddr
(0x300) are the bytes 08 00 09 and a while later not 0x57. Otherwise it
returns immediately.

> What next?    

Unless you tell me that it is a very special hardware problem on your system
only, I will probably disable the HP Lan driver in the next gnumach, just to be 
on
the safe side. I don't think it is one of the common cards (tell me if I am
wrong), and people who need the driver can compile their own kernel. We
don't have a better concept to handle conflicting driver support currently.
 
But it is a bit strange that gnumach hangs there. hp.c is not the only place
where inb(0x0300) is done. Just look at ne.c:

/* A zero-terminated list of I/O addresses to be probed. */
static unsigned int netcard_portlist[] =
{ 0x300, 0x280, 0x320, 0x340, 0x360, 0};

int ne_probe(struct device *dev)
...
    /* Last resort. The semi-risky ISA auto-probe. */
    for (i = 0; netcard_portlist[i]; i++) {
        int ioaddr = netcard_portlist[i];
        if (check_region(ioaddr, NE_IO_EXTENT))
            continue;
        if (ne_probe1(dev, ioaddr) == 0)
            return 0;
    }


static int ne_probe1(struct device *dev, int ioaddr)
{
    int i;
    unsigned char SA_prom[32];
    int wordlength = 2;
    const char *name = NULL;
    int start_page, stop_page;
    int neX000, ctron, bad_card;
    int reg0 = inb_p(ioaddr);
    ^^^^^^^^^^^^^^^^^^^^^^^^^

inb_p is inb with slower i/o ("pausing").

Maybe "cat /proc/ioports" under linux sheds a light on this.

> I have a general question.  Why not have a debug kernel with a zillion
> printk's that are all inside a #ifdef DEBUG?

That's a bit inflexible, but worse, it is overkill. Usually we have a quite
good idea on where the problem is, and can make an informed guess.
OTOH, the better way to debug such problems is over the serial line or so.
Some of us can do that, I think. But only if we see the problem of course :)

Thanks,
Marcus
     

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de,     marcus@gnu.org    PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       brinkmd@debian.org