PCI card Netgear FA311 v2
Francesco Bochicchio
I recently purchased an ethernet PCI card Netgear FA311 v2, but cannot
make it work on my box, which has Debian 5.0 on it, with kernel 2.6.26.
Tried also with a Live Ubuntu CD, with the same results (nothing).
Here is what I get if I do lspci -v :
00:14.0 Class 4200: Realtek Semiconductor Co., Ltd. Device c139 (rev 10)
Subsystem: Netgear Device b31d
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at 1000 [size=256]
Memory at 60000000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
No module is loaded automatically. Following various hints on the net I
tried first with natsemi (which is supposed to support v1 of this card )
and then with 8139too/8139cp, which are supposed to support v2. The
modules load without error, but they not create any new ethX interface,
probably because they failed to recognize the card.
Anybody knows if it is possible make this card work with linux ?
Ciao
-----
FB
Moe Trin
<4ad9c96d$0$1113$4faf...@reader2.news.tin.it>, Francesco Bochicchio wrote:
>I recently purchased an ethernet PCI card Netgear FA311 v2, but cannot
>make it work on my box, which has Debian 5.0 on it, with kernel 2.6.26.
>Tried also with a Live Ubuntu CD, with the same results (nothing).
>
>Here is what I get if I do lspci -v :
>
> 00:14.0 Class 4200: Realtek Semiconductor Co., Ltd. Device c139 (rev 10)
> Subsystem: Netgear Device b31d
> Flags: bus master, medium devsel, latency 32, IRQ 10
> I/O ports at 1000 [size=256]
> Memory at 60000000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
Hmmm.... what do you see in /var/log/messages at boot time relating to
this card? The two device numbers don't look correct.
# List of PCI ID's
#
# Version: 2009.09.18
# Date: 2009-09-18 03:15:01
#
# Maintained by Martin Mares <m...@ucw.cz> and other volunteers from the
# PCI ID Project at http://pciids.sf.net/.
10ec Realtek Semiconductor Co., Ltd.
8139 RTL-8139/8139C/8139C+
1385 f31d FA311 v2
c139 = 1100 0001 0011 1001
8139 = 1000 0001 0011 1001
b31d = 1011 0011 0001 1101
f31d = 1111 0011 0001 1101
^
|
Notice that the same bit is swapped ('0' verses '1'). If you manually
load the 8139 module, and manually try to /sbin/ifconfig the card, what
do you see for a MAC (HwAddr) address?
[compton ~]$ etherwhois REALTEK
00-E0-4C (hex) REALTEK SEMICONDUCTOR CORP.
00E04C (base 16) REALTEK SEMICONDUCTOR CORP.
1F, NO. 11, INDUSTRY E. RD. IX
SCIENCE-BASED INDUSTRIAL PARK
HSINCHU 300
TAIWAN, REPUBLIC OF CHINA
[compton ~]$
I'd expect a MAC address of 00:e0:4c:XX:XX:XX or similar.
Old guy
Francesco Bochicchio
> On 17 Oct 2009, in the Usenet newsgroup comp.os.linux.hardware, in
> article <4ad9c96d$0$1113$4faf...@reader2.news.tin.it>, Francesco
> Bochicchio wrote:
>
>>I recently purchased an ethernet PCI card Netgear FA311 v2, but cannot
>>make it work on my box, which has Debian 5.0 on it, with kernel 2.6.26.
>>Tried also with a Live Ubuntu CD, with the same results (nothing).
>>
>>Here is what I get if I do lspci -v :
>>
>> 00:14.0 Class 4200: Realtek Semiconductor Co., Ltd. Device c139 (rev
>> 10)
>> Subsystem: Netgear Device b31d
>> Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports
>> at 1000 [size=256]
>> Memory at 60000000 (32-bit, non-prefetchable) [size=256]
>> Capabilities: [50] Power Management version 2
>
> Hmmm.... what do you see in /var/log/messages at boot time relating to
> this card? The two device numbers don't look correct.
>
Actually, I forgot to mention this:
[ 0.131248] PCI: Cannot allocate resource region 0 of device
0000:00:14.0
I got the same message for a bunch of other addresses, too
Elsewere, someone suggested my to disable Bios plug An Play.
Did not try this yet. My box has an EPIA board inside, so not sure if the
BIOS is the same of standard PC.
> # List of PCI ID's
> #
> # Version: 2009.09.18
> # Date: 2009-09-18 03:15:01
> #
> # Maintained by Martin Mares <m...@ucw.cz> and other volunteers
> from the # PCI ID Project at http://pciids.sf.net/.
>
> 10ec Realtek Semiconductor Co., Ltd.
>
> 8139 RTL-8139/8139C/8139C+
>
> 1385 f31d FA311 v2
>
> c139 = 1100 0001 0011 1001
> 8139 = 1000 0001 0011 1001
>
> b31d = 1011 0011 0001 1101
> f31d = 1111 0011 0001 1101
>
> ^
> |
> Notice that the same bit is swapped ('0' verses '1').
This is interesting ....
If you manually
> load the 8139 module, and manually try to /sbin/ifconfig the card, what
> do you see for a MAC (HwAddr) address?
>
> [compton ~]$ etherwhois REALTEK
> 00-E0-4C (hex) REALTEK SEMICONDUCTOR CORP. 00E04C
> (base 16) REALTEK SEMICONDUCTOR CORP.
> 1F, NO. 11, INDUSTRY E. RD. IX
> SCIENCE-BASED INDUSTRIAL PARK
> HSINCHU 300
> TAIWAN, REPUBLIC OF CHINA
> [compton ~]$
>
> I'd expect a MAC address of 00:e0:4c:XX:XX:XX or similar.
>
Actually, I can't ifconfig because the module does not create any
/dev/eth? for me to ifconfig.
> Old guy
Ciao
-----
FB
Francesco Bochicchio
> I got the same message for a bunch of other addresses, too Elsewere,
> someone suggested my to disable Bios plug An Play. Did not try this yet.
> My box has an EPIA board inside, so not sure if the BIOS is the same of
> standard PC.
>
>
Update: checked the BIOS settings and disabled Bios PnP : no change.
notbob
> Update: checked the BIOS settings and disabled Bios PnP : no change.
I recall the upgrade from FA310 cards was a real fiasco, the 311/312
cards so fraught with bugs and bad mojo, linux users avoided them like
the plague. I went out and bought up a half dozen FA310 cards before
they disappeared off the shelf, which I still use happily, today. I
can't say if the 311/312 prob was ever resolved, but good luck.
nb
Pascal Hambourg
Moe Trin a ï¿œcrit :
>>
>> Here is what I get if I do lspci -v :
>>
>> 00:14.0 Class 4200: Realtek Semiconductor Co., Ltd. Device c139 (rev 10)
>> Subsystem: Netgear Device b31d
[...]
> 10ec Realtek Semiconductor Co., Ltd.
>
> 8139 RTL-8139/8139C/8139C+
>
> 1385 f31d FA311 v2
>
> c139 = 1100 0001 0011 1001
> 8139 = 1000 0001 0011 1001
>
> b31d = 1011 0011 0001 1101
> f31d = 1111 0011 0001 1101
>
> ^
> |
> Notice that the same bit is swapped ('0' verses '1').
Same with the class ID 4200 which should read 0200 (ethernet controller).
4200 = 0100 0010 ...
0200 = 0000 0010 ...
^
Looks like there is a hardware error somewhere on that bit line of the
PCI bus. Did you physically check the card for visible defects and try
it in a different PCI slot ?
Francesco Bochicchio
> Hello,
>
> Moe Trin a écrit :
The box has only a PCI slot. It used to have a TV tuner card that worked
fine, although I did not used it in the summer months. maybe I did
something wrong when I plugged the network card... I will check that.
Thanks for the suggestion
Ciao
-----
FB
Pascal Hambourg
> Il Wed, 21 Oct 2009 12:10:54 +0200, Pascal Hambourg ha scritto:
>>
>> Looks like there is a hardware error somewhere on that bit line of the
>> PCI bus.
Thinking twice, the error could also lie in the configuration EEPROM
chip which contains these data on the network card.
>> Did you physically check the card for visible defects and try
>> it in a different PCI slot ?
>
> The box has only a PCI slot. It used to have a TV tuner card that worked
> fine, although I did not used it in the summer months. maybe I did
> something wrong when I plugged the network card... I will check that.
You can also check the network card on another motherboard. If the same
happens, then the card is faulty.
Francesco Bochicchio
> Francesco Bochicchio a écrit :
>> Il Wed, 21 Oct 2009 12:10:54 +0200, Pascal Hambourg ha scritto:
>>>
>>> Looks like there is a hardware error somewhere on that bit line of the
>>> PCI bus.
>
>
>>> Did you physically check the card for visible defects and try it in a
>>> different PCI slot ?
>>
>> The box has only a PCI slot. It used to have a TV tuner card that
>> worked fine, although I did not used it in the summer months. maybe I
>> did something wrong when I plugged the network card... I will check
>> that.
>
> You can also check the network card on another motherboard. If the same
> happens, then the card is faulty.
Oh well, it was just a loose contact, after all. I tried the dumb trick
of unplugging and plugging again the card, and now it works :-)
This is what I get now with lspci -v
00:14.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Netgear Device f31d
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at e000 [size=256]
Memory at de003000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Kernel driver in use: 8139too
Kernel modules: 8139cp, 8139too
and, most importantly, the card works.
Previously, I ruled out the loose contact idea because I expected it
would have garbled all lspci output ( does not come from card EPROM?),
not just the Ids. Also, I already tried the unplug/replug think, but
looks like I made the same mistake twice. The card is not an exact fit
for the EPIA case, so it was a bit loose, I guess.
Anyway, thanks again.
Ciao
-----
FB
Moe Trin
<4ae0943d$0$1111$4faf...@reader2.news.tin.it>, Francesco Bochicchio wrote:
>Oh well, it was just a loose contact, after all. I tried the dumb
>trick of unplugging and plugging again the card, and now it works :-)
It's not a "dumb trick" when it works. ;-)
>This is what I get now with lspci -v
>
>00:14.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>RTL-8139/8139C/8139C+ (rev 10)
> Subsystem: Netgear Device f31d
> Flags: bus master, medium devsel, latency 32, IRQ 10
> I/O ports at e000 [size=256]
> Memory at de003000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
> Kernel driver in use: 8139too
> Kernel modules: 8139cp, 8139too
compared to your original post
] 00:14.0 Class 4200: Realtek Semiconductor Co., Ltd. Device c139 (rev 10)
] Subsystem: Netgear Device b31d
] Flags: bus master, medium devsel, latency 32, IRQ 10
] I/O ports at 1000 [size=256]
] Memory at 60000000 (32-bit, non-prefetchable) [size=256]
] Capabilities: [50] Power Management version 2
>Previously, I ruled out the loose contact idea because I expected it
>would have garbled all lspci output ( does not come from card EPROM?),
All of the data does NOT come from EPROM. The command takes data
from the card, and looks that up in several internal lists - some are
part of the driver module, some are part of the kernel, and so on.
Looking at the first line above, the 'Class' entry being 4200 rather
than '0200' as Pascal noted - this prevented lspci from looking in the
right part of the table, and prevented the kernel from determining
this was an Ethernet card that wanted a 8139too driver. It was able
to determine Realtek, but is that an Ethernet card, an audio system
controller, a modem, wireless LAN device (all of which are built by
Realtek) or what?
>Also, I already tried the unplug/replug think, but looks like I made
>the same mistake twice. The card is not an exact fit for the EPIA
>case, so it was a bit loose, I guess.
Perhaps. If the card is loose, I'd expect a lot more problems
rather than a single pin not making reliable contact.
Old guy