*** Bug 115528 has been marked as a duplicate of this bug. ***

On FC1, the driver was not recognized either but there was a prompt
where I could manually select the sk98lin driver.

But if a not so knowing user installs Fedora and has this network card
, how are they supposed to know this, isn't this what the automated
setup it for?

One of these two should be closed as a duplicate bug 115512

*** Bug 115512 has been marked as a duplicate of this bug. ***

Adding my output from the duplicated bug

Abit KV8-MAX3 with a integrated 3Com 3C940

lspci -vv
0000:00:0e.0 Ethernet controller: 3Com Corporation 3c940 1000Base?
(rev 12)
        Subsystem: ABIT Computer Corp.: Unknown device 1406
        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 (5750ns min, 7750ns max), cache line size 08
        Interrupt: pin A routed to IRQ 5
        Region 0: Memory at eb004000 (32-bit, non-prefetchable)
        Region 1: I/O ports at b800 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable+ DSel=7 DScale=1 PME-
        Capabilities: [50] Vital Product Data

I just noticed that this was filed against setup.  I believe it should
be filed against anaconda (the installer).  Setup has nothing to do
with this problem.

BTW, the 3C940 works fine after the system is installed and it is
configured.

The problem is twofold:

1. The 3C940 is not recognized as needing the sk98lin driver.

2. Anaconda has lost the capability to manually select a driver for a NIC.

I am adding Jeremy Katz as a CC since he is currently handling at
least first cut on anaconda problems.

Jeff/Dave: why doesn't the sk98lin driver have ID tables?

OK, looks like there may be two problems here ...

1. sk98lin should have table to handle 3c940 (or at least that is how
I interpret Bills comment).

2. Regardless, the Manual slect is notworking.  I just checked
anaconda and the code is still there in loader2/loader.c ... it just
is not getting executed.

Bill: 

See the macro at line 82 of drivers/net/sk98lin/h/skdrv2nd.h

Yes, this is horrible horrible code.

As a quick fix, I've added the ID to this massive chunk of code.
Long term, I've also added "convert this driver to use PCI API" to my
todo list.

It should be in the next kernel build.

If you can figure a way to test this before test2, I can give it a try.

Fixing the driver do not explain why the manual selection prompt did
not work.

I think using the sk98lin driver is a mistake:

the sk98lin driver was made for the SysKonnect chipset, which is
indeed used by the 3Com 3c940/3c2000 gigabit ethernet.

the problem is, that the 3Com 3c940/3c2000 have some differences,
and 3Com has released its own drivers for Linux, based on the
existing sk98lin. Their own drivers include some changes because
the sk98lin driver will drop packets at high speed if used with
the 3c940/3c2000.

The 3Com driver can be downloaded here (in source form):
ftp://ftp.asus.com.tw/pub/ASUS/lan/3com/3c940/046_Linux.zip

The problem is that the driver is made for 2.4 kernels only,
and won't compile under the 2.6.1 that comes with FC2.

I think the best solution is to include the modified version
of the sk98lin by 3Com into the distribution, and not use
the original sk98lin driver.

Also, please take a look at this thread:

http://www.ussg.iu.edu/hypermail/linux/kernel/0306.2/1556.html

The driver on Asus web site is broken (and has very strange behavior),
the driver in the kernel works just fine (100%). I started this bug
becuase the automated set was not setting it up. But I do it manually
, make the modprobe.conf entry and everything works fine. 

Also to add, Suse 9.0 detects my card and places sk98lin as the driver
for it. So to keep this bug on track. There is nothing wrong with the
sk98lin driver in the kernel. The only thing wrong is that Fedora
needs anacond to detect it.

Are you using the sk98lin driver at 1gigabit speeds? because
thats when you'll start having problems, dropped packets.

I haven't had any problems with the 3c2000 driver on the Asus
website, i'm using the latest version (046_Linux.zip).

I've been using this driver since Redhat9 and now with Fedora Core 1.

When you say the driver is broken, what do you mean? Also what do
you mean by "strange behavior"?

If you can be specific, then i can try to reproduce the problem.

OK, not related to this bug (just so everyone knows)...

No, actually I only use it at 100. The drivers on Asuses site had a
really really strange behavior. For some reason it would not allow you
to go to certain web sites (google.com is one of them ... nothing no
ping either, no nothing), no matter what program you where using. But
it would let you go to others. I had found doing some googling that it
wasn't just me , others were seeing the same thing. It was really
really odd, I was looking at ip ranges and everything to see what was
going on. But around the (I think) 2.4.21 or 22 kernel the an updated
sk98lin was add and it worked with my card and that problem went away.
I've had no problems since. 

I think if you are having problems at gigabit speeds or see the need
of using a different driver (you should try out the sk98lin in 2.6
first) then probably you should open a new bugzilla ticket.

The problem with gigabit speeds is related to the sk98lin driver,
the 3c2000 driver was the solution to the problem. Unless the
latest sk98lin solves the problem.

I just tested the sk98lin driver that comes with FC2 test, and it
seemed to work fine at 100mbit. Havent tested at 1gbit yet.

We agree on one thing, Fedora should be able to recognize the
3c2000/3c940 chipset on boot and load a driver.

I dont really care if the driver is the 3Com 3c2000 or the sk98lin,
as long as it works.

OK, I took a look at the code in the current FC1 2.4 kernel, the FC2
2.6 kernel, and the stuff pointed to above form ASUS.  These are all
related with the ASUS code being the oldest and, naturally, the 2.6
code being most recently updated.

As Dave Jones pointed out in a previous comment, the 3Com pciid
10b7:1700 is coded in the driver (horrible code or not).  Furthermore,
the driver appears to work (mostly) ... at least it has for me.  There
may be issues with it working at 1000Mbps but that should be true with
all versions of this driver since they are basically the same. 
Therefore, I would consider that the 2.6 kernels version to be the
most "up to date" and any non-working aspects should be worked against
that version.

The problems related to in this report and a related one --
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115609 -- are
concerned with the anaconda installer handling things correctly.

Thank you for taking the time to work this out.

An association should then be made to match the
2.6 kernel driver with those ids.

btw, the /usr/share/hwdata/ database which holds
pci and usb ids, includes the 10b7:1700.

There appear to be three problems:

1. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115609

is a report asking for automatic recognition of NICs supported by the
sk98lin driver.

2. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115667

is a report for the lack of the ability to manually select a driver or
to use a driver disk.

3.  There may be problems with the 1000Mbps support ... I can't speak
to that and it should be opened as a new problem.

I suggest that this report be closed since it seems to be covering
multiple problems and that the above reports be used.

Dimitris -- you are correct that the /usr/share/hwdata/pci.ids
database has the 3C940 id (and a lot of SysKonnect ones too). 
However, for whatever reason, anaconda has its own version of the
pci.ids file which is not "as current".

There should be some consideration given to a single database but
there may be reasons why this is not practical.

erm, anaconda shouldn't use its own file, the hwdata package
was made just for that reason. I think its a dependency by all the
hardware related applications. For example, lspci will use the
strings found in the hwdata database, as well as the printer gui.

anaconda does use the information from hwdata (and supplements that
with information from the pcimap files from the kernel)

Then why not detect and load the correct driver? Is the problem
on the kernel side? I dont know much about the kernel unfortunately,
so i can't comment, but i'm sure there must be a file somewhere
which matches kernel modules with hardware devices.

Yes, why doesn't it load sk98lin?

And if it does not recognize the proper driver, why doesn't it prompt
for manual selection like FC1 did?

My comments on them being missing are based on what is in the anaconda
src.rpm.  I am likely misunderstanding how things work.

anaconda bug possibly related to bug #115682 and bug #115505

anaconda ignores nforce NIC during install even though;

# /sbin/lspci -v

0000:00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
Controller (rev a1)
        Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer: Unknown
device 0531
        Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 5
        Memory at e2086000 (32-bit, non-prefetchable)
        I/O ports at c400 [size=8]
        Capabilities: [44] Power Management version 2

# /sbin/lspci -nv

0000:00:04.0 Class 0200: 10de:0066 (rev a1)
        Subsystem: 1297:0531
        Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 5
        Memory at e2086000 (32-bit, non-prefetchable)
        I/O ports at c400 [size=8]
        Capabilities: [44] Power Management version 2

# grep '10de.*0066' /lib/modules/2.6.2-1.79/modules.pcimap
forcedeth            0x000010de 0x00000066 0xffffffff 0xffffffff
0x00000000 0x00000000 0x0

# egrep '10de|0066' /usr/share/hwdata/pci.ids
10de  nVidia Corporation
                10de 0020  Riva TNT
                10de 0005  RIVA TNT2 Pro
                10de 000f  Compaq NVIDIA TNT2 Pro
                10de 001e  M64 AGP4x
        0066  nForce2 Ethernet Controller

*** Bug 115609 has been marked as a duplicate of this bug. ***

pcitable whacked in for now, will be in 0.109-1.