Re: Ethernet problem actually in hp.c (was Re: Ethernet card

[Prabhu Ramachandran <prabhu@aero.iitm.ernet.in>]

detection bug in wd_probe)
References: <20000911180537.23194.qmail@web2903.mail.yahoo.com>
        <[🔎] 14782.343.954373.442715@monster.linux.in>
        <39BFE216.4A1EE6F6@SoftHome.net>
        <[🔎] 14785.7917.828800.934182@monster.linux.in>
        <[🔎] 20000914223921.D292@ulysses.dhis.net>
        <[🔎] 14786.65467.798472.93677@monster.linux.in>
        <[🔎] 20000917182203.Q270@ulysses.dhis.net>
        <[🔎] 14790.13650.75815.400508@monster.linux.in>
        <[🔎] 20000919013609.C286@ulysses.dhis.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14791.11646.683001.600699@monster.linux.in>

hi,

>>>>> "Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
    >> inside the for loop i = 0, ioaddr = 768 Then, hp_probe1 is
    >> called.

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

Yes, it is the first probe.

    >> --- It hangs after printing hp.c: Inside hp_probe1 It does not
    >> hit the printl ("line:125.\n")
    >>
    >> So the inbs are causing problems?

    Marcus> Yes, one of them. Do you have some strange device at
    Marcus> 0x300, which could be sensitive to this probe and lock the
    Marcus> system? My knowledge about the PC bus architecture is

Well, my NE2000 device uses that address.

$ dmesg | grep 0x300
NE*000 ethercard probe at 0x300: 00 80 48 9f 13 63
eth0: NE2000 found at 0x300, using IRQ 5.
$
    Marcus> pretty much non-existent, but exactly the same code is
    Marcus> used in linux, and so I would assume that you'd get the
    Marcus> same problem there (with a linux kernel that has the hp
    Marcus> lan driver installed). But maybe some prior initialization
    Marcus> makes a difference.

I wouldnt know.  Under linux I have used only modular devices.
Besides, I usually recompile my kernel with just the necessary
devices...

    Marcus> Unless you tell me that it is a very special hardware
    Marcus> problem on your system only, I will probably disable the
    Marcus> HP Lan driver in the next gnumach, just to be on the safe
    Marcus> side. I don't think it is one of the common cards (tell me
    Marcus> if I am wrong), and people who need the driver can compile
    Marcus> their own kernel. We don't have a better concept to handle
    Marcus> conflicting driver support currently.

Well, instead of doing this you could reorder the way in which the
devices are probed and do a ne_probe before the hp_probe.  This way it
should work fine for all the ne2000 nic users and hopefully will also
work for the hplan folks?  What do you think?


    Marcus> But it is a bit strange that gnumach hangs there. hp.c is
    Marcus> not the only place where inb(0x0300) is done. Just look at

<snip>

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

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

Here is the output with the relevant portions.

02f8-02ff : serial(set)
0300-031f : NE2000
0376-0376 : ide1

    Marcus> better way to debug such problems is over the serial line

Would appreciate if you could explain the process or give us a URL.

thanks,
prabhu

    Marcus> But it is a bit strange that gnumach hangs there. hp.c is
    Marcus> not the only place where inb(0x0300) is done. Just look at

<snip>

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

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

Here is the output with the relevant portions.

02f8-02ff : serial(set)
0300-031f : NE2000
0376-0376 : ide1

    Marcus> better way to debug such problems is over the serial line

Would appreciate if you could explain the process or give us a URL.

thanks,
prabhu