I recently got a local (Australian, NetComm) NIC that uses a 8139D.
The standard 8139too seems to work with it but I wonder if I can
get something more out of a driver that has extra support.
The vendor supplies a driver in
http://www.netcomm.com.au/one/support/drivers/NP1100_4.exe
which contains
np11004.c
This is a modified rtl8139.c, based on a reasonably old version
1.11 7/14/2000
The latest rtl8139.c I found is
1.20 6/21/2002
2.4 does not anymore contain the rtl8139.c driver, but has moved
to the 8139too.c
Rather than use a vendor driver, is there support for this chip
in a current (2.4) driver?
Anyone knows the difference between the 8139C and 8139D?
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
Eyal Lebedinsky wrote:
> I recently got a local (Australian, NetComm) NIC that uses a 8139D.
> The standard 8139too seems to work with it but I wonder if I can
> get something more out of a driver that has extra support.
[...]
> Anyone knows the difference between the 8139C and 8139D?
At the driver level, there should not be appreciable differences between
the two chips. 8139C+ is the super-cool tulip-like chip from RealTek
with all the speed and features. 8139D is just a small incremental
revision of the chip. It does add a few features, but none that would
affect performance or stability (positively or negatively).
RealTek's 8139C+, and it's GigE cousin 8169 are really nice. I hope
RealTek finds a lot of customers for these chips, because so far they
are both solid, fast, and feature-full.
Regards,
Jeff
On Mon, Nov 18, 2002 at 01:30:18PM -0500, Jeff Garzik wrote:
> Eyal Lebedinsky wrote:
>
> >I recently got a local (Australian, NetComm) NIC that uses a 8139D.
> >The standard 8139too seems to work with it but I wonder if I can
^^^^^^^^^^^^^^^^
> >get something more out of a driver that has extra support.
>
> [...]
>
> >Anyone knows the difference between the 8139C and 8139D?
>
>
>
> At the driver level, there should not be appreciable differences between
> the two chips. 8139C+ is the super-cool tulip-like chip from RealTek
> with all the speed and features. 8139D is just a small incremental
> revision of the chip. It does add a few features, but none that would
> affect performance or stability (positively or negatively).
>
> RealTek's 8139C+, and it's GigE cousin 8169 are really nice. I hope
> RealTek finds a lot of customers for these chips, because so far they
> are both solid, fast, and feature-full.
>
Do we have to assume that Eyal Lebedinsky should use 8139cp driver
instead of 8139too ?
Cheers,
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
Ducrot Bruno wrote:
> Do we have to assume that Eyal Lebedinsky should use 8139cp driver
> instead of 8139too ?
If it is definitely 8139D chip, then no. That is a continuation of the
"old 8139" line of chips.
But, we cannot know for sure until we see an lspci output :)
On Mon, 18 Nov 2002, Jeff Garzik wrote:
> If it is definitely 8139D chip, then no. That is a continuation of the
> "old 8139" line of chips.
>
> But, we cannot know for sure until we see an lspci output :)
Want me to put this 8139D here into a machine and do an lspci for you?
Mike
Mike Dresser wrote:
> On Mon, 18 Nov 2002, Jeff Garzik wrote:
>
>
> >If it is definitely 8139D chip, then no. That is a continuation of the
> >"old 8139" line of chips.
> >
> >But, we cannot know for sure until we see an lspci output :)
>
>
> Want me to put this 8139D here into a machine and do an lspci for you?
Sure... I'm pretty sure of what I will see, but it cannot hurt :)
Jeff
On Mon, 18 Nov 2002, Jeff Garzik wrote:
> Given the output you just provided, 8139too is indeed the only driver
> that will work for you.
>
> WRT pci-skeleton.c I think that is a red herring for you... 8139cp
> support is available from 8139cp.c. But given the lspci output, it will
> not work for you...
>
> thanks!
>
> Jeff
I guess 2.4.20 should get the proper pci_id added into 8139too.c then, if
these cards are just starting to come out.
I left the D card in my workstation for now, I'll see how it handles the
nightly backup tonight, and if you want me to test things for 8139cp
What IS pci-skeleton then?
Mike
On Mon, 18 Nov 2002, Jeff Garzik wrote:
> this is a toughie... basically that is an invalid PCI ID that should
> not occur. the "00ec" should really be "10ec", but it sounds like there
> is a missing bit in the EEPROM where your card's PCI ID is stored.
I'll try another card, and get back to you, just in case it's a
partially fubar card.
> A better patch would add
>
> { 0x00ec, 0x8139, 0xa0a0, 0x0027, ... }
True true, until Aopen plays games with PCI ID's again :)
Never said i was a programmer :) More of a hacker in the traditional
sense. Nano is my hammer, all .c code is nails.
> > I left the D card in my workstation for now, I'll see how it handles the
> > nightly backup tonight, and if you want me to test things for 8139cp
>
> cool. no need to test 8139cp, it won't even load with your card, since
> it is not an 8139C+ chip.
Ok. I take it the C+ has functions that weren't carried over to D?
> > What IS pci-skeleton then?
> Example driver that other developers may base drivers off of...
Or feed to the Penguin. Hey, you said red herring :D
Mike
Mike Dresser wrote:
> On Mon, 18 Nov 2002, Jeff Garzik wrote:
>
>
> >Given the output you just provided, 8139too is indeed the only driver
> >that will work for you.
> >
> >WRT pci-skeleton.c I think that is a red herring for you... 8139cp
> >support is available from 8139cp.c. But given the lspci output, it will
> >not work for you...
> >
> >thanks!
> >
> > Jeff
>
>
> I guess 2.4.20 should get the proper pci_id added into 8139too.c then, if
> these cards are just starting to come out.
this is a toughie... basically that is an invalid PCI ID that should
not occur. the "00ec" should really be "10ec", but it sounds like there
is a missing bit in the EEPROM where your card's PCI ID is stored.
A better patch would add
{ 0x00ec, 0x8139, 0xa0a0, 0x0027, ... }
because otherwise you wind up with a potential [low] chance of picking
up boards with that same PCI device id 0x8139.
> I left the D card in my workstation for now, I'll see how it handles the
> nightly backup tonight, and if you want me to test things for 8139cp
cool. no need to test 8139cp, it won't even load with your card, since
it is not an 8139C+ chip.
> What IS pci-skeleton then?
Example driver that other developers may base drivers off of...
Jeff
grrr, Mozilla cannot seem to quote your message properly. anyway...
Given the output you just provided, 8139too is indeed the only driver
that will work for you.
WRT pci-skeleton.c I think that is a red herring for you... 8139cp
support is available from 8139cp.c. But given the lspci output, it will
not work for you...
thanks!
Jeff
On Mon, 18 Nov 2002, Jeff Garzik wrote:
> > Want me to put this 8139D here into a machine and do an lspci for you?
>
> Sure... I'm pretty sure of what I will see, but it cannot hurt :)
>
> Jeff
>
Ok, I put the 8139D card in, did not work with either the 8139too or
8139cp driver.
Here is the lspci -vvvvvvvvvvv output(i'm lazy)
00:0d.0 Ethernet controller: Unknown device 00ec:8139 (rev 10)
Subsystem: AOPEN Inc.: Unknown device 0027
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+
Latency: 32 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 8000 [size=256]
Region 1: Memory at d9000000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
I went into drivers/net/8139too.c and added a line
{0x00ec, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
to the pci_id table with the 00ec:8139 address, and now the card works
with 8139too.
I assume the same fix in pci-skeleton.c would fix it for 8139cp, correct?
I am using the card right now, and seems to be working, although picked up
as a C
eth0: RealTek RTL8139 Fast Ethernet at 0xd0800000, 00:40:f4:64:bd:34, IRQ 10
eth0: Identified 8139 chip type 'RTL-8139C'
I'll modify pci-sketelon.c the same way, and see if 8139cp works.
Mike
Mike Dresser wrote:
> On Mon, 18 Nov 2002, Jeff Garzik wrote:
>
>
> >this is a toughie... basically that is an invalid PCI ID that should
> >not occur. the "00ec" should really be "10ec", but it sounds like there
> >is a missing bit in the EEPROM where your card's PCI ID is stored.
>
>
> I'll try another card, and get back to you, just in case it's a
> partially fubar card.
FWIW I have seen tons of 8139s that work fine but have invalid PCI
IDs... the price of being a US$0.50 chip I guess :)
So I doubt it's a fubar card...
> >A better patch would add
> >
> > { 0x00ec, 0x8139, 0xa0a0, 0x0027, ... }
>
>
> True true, until Aopen plays games with PCI ID's again :)
exactly... :/
> Never said i was a programmer :) More of a hacker in the traditional
> sense. Nano is my hammer, all .c code is nails.
hehe
>
>
> >>I left the D card in my workstation for now, I'll see how it handles the
> >>nightly backup tonight, and if you want me to test things for 8139cp
> >
> >cool. no need to test 8139cp, it won't even load with your card, since
> >it is not an 8139C+ chip.
>
>
> Ok. I take it the C+ has functions that weren't carried over to D?
8139C+ is, in CVS lingo, a branch. 8139D has -none- of the 8139C+
functions...
> >>What IS pci-skeleton then?
> >
> >Example driver that other developers may base drivers off of...
>
> Or feed to the Penguin. Hey, you said red herring :D
hehe :)
Jeff
On Mon, 18 Nov 2002, Jeff Garzik wrote:
> Mike Dresser wrote:
>
> > I'll try another card, and get back to you, just in case it's a
> > partially fubar card.
>
> FWIW I have seen tons of 8139s that work fine but have invalid PCI
> IDs... the price of being a US$0.50 chip I guess :)
>
> So I doubt it's a fubar card...
Just tried another 8139D card, same make, and it shows up as a 10ec:8139
instead of the 00ec. Bad bit, indeed.
So I've got a card that has a wrong PCI id, I wonder what Windows would do
if i installed it there. I wonder if I have more of these to test. Found
another one. I'll test THIS one too :)
> 8139C+ is, in CVS lingo, a branch. 8139D has -none- of the 8139C+
> functions...
Thanks :) How about a note in the C+ things that D isn't higher than C+
then.
Mike
On Mon, 18 Nov 2002, Jeff Garzik wrote:
> this is a toughie... basically that is an invalid PCI ID that should
> not occur. the "00ec" should really be "10ec", but it sounds like there
> is a missing bit in the EEPROM where your card's PCI ID is stored.
Took the card out, tried another, 10ec:8139 as expected.
Put the old card back in, didn't come up in BIOS or lspci. Pulled the
card out, put it back in, comes up as 10ec:8139.
I suspect there's something flaky about this card :D
So yeah, ignore all the pci_id stuff, this card is just fubar :)
Man, I'd hate to be someone in charge of hardware under linux, there's so
much flaky stuff.
Mike
On Mon, Nov 18, 2002 at 05:57:34PM -0500, Mike Dresser wrote:
>
> Took the card out, tried another, 10ec:8139 as expected.
>
> Put the old card back in, didn't come up in BIOS or lspci. Pulled the
> card out, put it back in, comes up as 10ec:8139.
>
> I suspect there's something flaky about this card :D
In the past, I've seen similar problems caused by a not-completely
seated PCI card. If the problem goes away when you take the card out
and put it back, I would suspect poor seating rather than a bad card.
> So yeah, ignore all the pci_id stuff, this card is just fubar :)
Don't toss it out just yet. :)
-VAL
On Mon, Nov 18, 2002 at 05:24:15PM -0500, Jeff Garzik wrote:
> this is a toughie... basically that is an invalid PCI ID that should
> not occur. the "00ec" should really be "10ec", but it sounds like there
> is a missing bit in the EEPROM where your card's PCI ID is stored.
I had this happen to me last week on a brand new box (never had
anything put into its PCI slots before), Pulled it out, gave the
card contacts a wipe over (even though they didn't *look* dirty)
plugged it back in, and it worked perfectly.
Odd thing was, I googled for the PCI ID that showed up, and all
it turned up was a Don Becker posting suggesting dirty contacts.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs