Bug 2776 - (net dmfe) Davicom 9102AF only works in 10 Mbps
(net dmfe) Davicom 9102AF only works in 10 Mbps
Status: REJECTED INSUFFICIENT_DATA
Product: Drivers
Classification: Unclassified
Component: Network
i386 Linux
: P2 normal
Assigned To: Grant Grundler
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-26 13:03 UTC by Jean Francois Martinez
Modified: 2008-04-04 16:31 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.5
Tree: Mainline
Regression: ---


Attachments

Description Jean Francois Martinez 2004-05-26 13:03:35 UTC
Distribution: Mandrake 9.2, Fedora Core 2
Hardware Environment: Tried on a K6 and on PIII both with VIA chipset
Software Environment:
Problem Description:
I have a Davicom 9102AF who doesn't work on 100 Mbps.  More exactly by
using ethereal on another box I see the packets it is transmitting but
it seems unable to get the replies.  If I configure the card in 10 Mbps
then it works fine.

This bug is also present in 2.4 kernels

Steps to reproduce:
1) Insert card
2) Configure.  My conf is correct, works with a card of a differnt model
3) Try to ping another box
Comment 1 Grant Grundler 2007-08-30 10:48:18 UTC
This looks like a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=5839 but for driver/net/tulip/dmfe.c instead of uli526x.c.

jmf, if we prepare a patch, can you still test it?

I believe this code sequence is b0rken ni dmfe.c:
    597         /* Reset DM910x MAC controller */
    598         outl(DM910X_RESET, ioaddr + DCR0);      /* RESET MAC */
    599         udelay(100);
    600         outl(db->cr0_data, ioaddr + DCR0);
    601         udelay(5);
    602 
    603         /* Phy addr : DM910(A)2/DM9132/9801, phy address = 1 */
    604         db->phy_addr = 1;
    605 
    606         /* Parser SROM and media mode */
    607         dmfe_parse_srom(db);
    608         db->media_mode = dmfe_media_mode;
    609 
    610         /* RESET Phyxcer Chip by GPR port bit 7 */
    611         outl(0x180, ioaddr + DCR12);            /* Let bit 7 output port         */
    612         if (db->chip_id == PCI_DM9009_ID) {
    613                 outl(0x80, ioaddr + DCR12);     /* Issue RESET signal */
    614                 mdelay(300);                    /* Delay 300 ms */
    615         } 
    616         outl(0x0, ioaddr + DCR12);      /* Clear RESET signal */

I expect there needs to be a polling loop after line 616 (where RESET is cleared)...there might need to be a "udelay(50)" before clearing the RESET signal as well.

thanks,
grant
Comment 2 Grant Grundler 2007-09-02 18:33:14 UTC
This driver definitely needs more love.

Davicom has a newer rev of their own driver available:
    http://www.davicom.com.tw/big5/download/Driver/dm9102a/dmfe_1.43.tar.gz

while the linux kernel version is based on 1.36.

And 1.43 looks suspect since it just comments out the Phy reset code.
No reset, no delays, no polling. But it might have other cleanups (e.g. dmfe_set_phyxcer() function was added).
Comment 3 Jean Francois Martinez 2007-09-14 10:29:55 UTC
Yes I can test it: I still have the card.
Comment 4 Grant Grundler 2007-09-14 23:49:04 UTC
(In reply to comment #3)
> Yes I can test it: I still have the card.

Awesome! Thanks!
I've posted a patch which is an immediate pull of my current tree:
    http://iou.parisc-linux.org/~grundler/diff/diff-2.6.23-rc3-dmfe_phy-01

That has more cleanups as well...but the hunk that should fix the problem is "-606,13 +754,21" in dmfe_init_dm9().  The rest is code clean ups. I can submit just the relevant part and add the cleanups later if this works for you.

thanks again!
grant
Comment 5 Grant Grundler 2007-12-14 21:56:20 UTC
ping!

Do you need a kernel to test?
If so, mail me the .config file you need and I can build the x86 kernel for it.

Note You need to log in before you can comment on or make changes to this bug.