Re: 3c509 Detection problem. Experienced user needs assistance.
George Bonser wrote:
> I have been watching this on the list. One thing I have noticed is that
> Windows likes to set network cards up at irq 10 and some weird address.
> Even if you disabled pnp, the card settings may now be locked where they
> were before you disabled it. Can you, with the DOS config program, hard
> set the card to irq 5 address 0x300?
> If you must set it to another IRQ or address because of conflicts, go
> ahead, then reboot linux. Log in and manually run the insmod command like
> insmod 3c509 io=0x300
> or wherever you set the address. The IRQ should be
> autodetected. you must use the 0x before the address that is zero and an
> If this works, assuming that you have the 3c509 module :) edit your
> /etc/init.d/network script to add that insmod command to the beginning of
> On Tue, 25 Nov 1997, Wintermute wrote:
Been there, done that. Like I said.. this is an advanced problem. I've done some
more experimenting today and so I have some more things to add should anyone still
be watching this thread.
As I stated before the el3 diagnostic program and the 3c5x9 setup utility (written
by Becker) both detect the card correctly at 0x300, IRQ 10. They get everything
right (to the best of my knowledge).
However, no matter if I set the card to any number of other IRQ's/Base IO Addresses,
compile the driver into the kernel (and use the ether= statement at boot), or as a
module and use the io= and irq= statements with insmod, the card will not be
To be clear: I have taken the machine down to it's bare essentials to do this!!! I
have removed everything not necessary to the booting and normal basic operation of
the machine. I removed my sound card, modem, disabled the second channel on my ide
controller, disabled all com ports, I even switched out the card with another from
work (the exact same model), still with no result. By base, I mean BASE. Video
card, IDE controller, Ethernet card. That's it.
Now I did some tinkering with the driver source code, and set the EL3_DEBUG value to
a sizeable one (9) so that I could see exactly what was happening at boot. From
what I can see, there is a section of the driver code that reads in some information
from the EEPROM on the 3c509b (actually it reads from a standard address that I
would suppose holds true for cards of the 3c5x9 family to access EEPROM values) and
tries to determine if the card it found is indeed a 3c509.
If it does not see a data word that equals 0x6b59 (or something like that) it exits
determining that if it didn't see the right value, then the card it found was not a
3c509 and it moves on.
I spent some time today comparing the code inside the el3 diagnostic utility and the
code inside of the 3c509.c driver file. With few exceptions the code is almost
exactly the same between them (I haven't gotten all the way through the file yet).
However, when I run the el3 program it returns a string of 16 data words that match
exactly the values the card should have, and in the first column of the Window 1
output there is the value it's looking for (the 0x6b59 value).
I'm wondering if my particular machine configuration could be throwing the code off
in the driver and when it tries to read from whatever address it's using, it's
pointing to the wrong offset. The values are clearly there in the el3 diagnostic
output, so the driver must be looking in the wrong place for the data, or reading it
I'll spend some more time hacking at the code and see if I can somehow recreate the
exact method of polling the EEPROM of the card that the el3 program has in the
If you're out there Becker, drop me a line so I can bounce some of these ideas off
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .