detection bug in wd_probe)
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid
Message-ID: <[EMAIL PROTECTED]>
hi,
>>>>> "Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> 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
