Please test...

verified that this card is not found during autoprobe, and doesn't respond to
tulip or old_tulip drivers in beta3 ...

it also doesn't respond to autoprobe, tulip or old_tulip in 6.1, 6.2 ...

% lspci ; lspci -n
00:0b.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11)
00:0b.0 Class 0200: 1317:0985 (rev
11)

Looks like it needs the .92 version of the Tulip driver and we provide .91.

ftp://ftp.scyld.com/pub/network/tulip.c

  Adding johnsonm to the cc: list so maybe we can get this included.

verified this is still unresolved in post-RC1 tree (qa0819.0) ...

(ie the card still does NOT respond to tulip or old_tulip drivers in tree)

Regarding tulip drivers.. please also note that the current driver and Don's
latest 0.92 driver is flawed w/ forced full duplex operation under certain
conditions/cards.

An example of these is D-Link DFE-570TX, a cheap (250$) quad
ethernet.  Works fine now with tweaked drivers (below).

This was flawed even with the latest Don Becker release (0.92) from Apr 2000.
It has to be patches ad follows (or the driver in
ftp://ftp.scyld.com/pub/network/test/ used)

-------------------
The correction is around line 863.
Note that it fixes two problems.  The code must *clear* the bits first!

        /* Enable autonegotiation: some boards default to off. */
        mdio_write(dev, phy, 0, mii_reg0 |
                   (tp->full_duplex ? 0x1100 : 0x1000) |
                   (media_cap[tp->default_port]&MediaIs100 ? 0x2000:0));
___
        /* Configure the xcvr: some boards default to autonegotiation off. */
        mdio_write(dev, phy, 0, (mii_reg0 & ~0x3100) |
                   (tp->full_duplex ? 0x0100 : 0x0000) |
                   ((media_cap[tp->default_port] & MediaIs100)
                    ? 0x2000 : 0x1000));
-------------------

This was given by Don Becker.  This was discussed on linux-net on about
19th Jul.

This also breaks with the NetGear FA311

The NetGear FA311 isnt relevant to this . That isnt a tulip card but a for the
moment unsupported natsemi device

To make a change this significant to such a commonly-used driver,
the change would have had to have been made before a public beta
where a relatively large group of people would test it, or in a
stable kernel release from Alan (again, a large group of people
would test it).  There are a lot of variants on the tulip chip
out there, and to change any tulip driver significantly without
time for lots of testing would likely cause too many problems --
as evidenced by pekkas's note that Donald's driver from 4 months
ago is known not to be sufficiently stable (and fixing one bug
wouldn't be enough to make us confident in the change).

Therefore, I'm regretfully deferring this.  :-(

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

Please try RC2 on this card.