Next-in-Thread Next Message

Idea Try This 

Forum: PCMCIA Network Adapter Issues
Re: Question DFE-650 not always Linux-compatible? (Anthony Jameson)
Date: 2000, Feb 25
From: Jochen Friedrich jochen1

Hi Anthony,

please try the program i posted in my last message (NetGear FA410TXC Setup). From looking at the vendor code in the ethernet address, it looks like both cards are from the same vendor (or the NetGear card looks like a re-labled DFE-650).

-- Jochen

Next-in-Thread Next Message

Messages Inline: 0 1

Feedback Hope others can try

Re: Idea Try This (Jochen Friedrich)
Date: 2000, Feb 26
From: Anthony Jameson AJameson

Hi Jochen,

Thanks for the tip, which looks promising.

I'm no longer in a position to try it out, since I
had to exchange my D-Link DFE-650TX for a working
card (incidentally, an AnyCom ECO Ethernet 10/100,
which worked right out of the box).

But the idea should be useful for anyone who is
struggling with one of the newer DFE-650TX
cards. In particular, it suggests that these newer
D-Link cards are not identical to the older
ones. (One of our older ones had a hw_addr of
00:80:C8:42:95:E9; the addresses of your FA410TXC
card and my newer DFE-650TX both start with
00:E0:98:77.)

In addition to the hardware addresses, your error
messages certainly look similar to mine.

            Anthony Jameson

Feedback tried and it works

Re: Feedback Hope others can try (Anthony Jameson)
Date: 2000, Feb 26
From: Ingo Ciechowski inki

just wanted to repeat that Anthony's tool works with the D-Link DFE-650 card.

Ingo

Question Where to add fa_select in the startup process

Re: Feedback tried and it works (Ingo Ciechowski)
Date: 2000, Jul 31
From: Juergen Lindemeyer juergen

Hello,

I had to fiddle some time to get my DFE-650 up and running. Now, after I tried fa_select, unloaded pcnet_cs and restarted it, it workes fine.

But I wonder where I can fiddle it into to PCMCIA-startup-process. I don't know if I can run fa_select before/after pcnet_cs.

Is there any "official" way without messing up all the startup scripts?

Thanks in advance!

/juergen

None There is a better way now

Re: Question Where to add fa_select in the startup process (Juergen Lindemeyer)
Date: 2000, Jul 31
From: David Hinds <dhinds@pcmcia.sourceforge.org>

The "official" way is to use the current PCMCIA driver package, which
fixes the problem inside the pcnet_cs driver, so the fa_select program
is unnecessary.

-- Dave

Ok Success at last ...

Re: None There is a better way now (David Hinds)
Date: 2000, Aug 02
From: Juergen Lindemeyer juergen

After a lot of fiddling around with my SuSE distribution (which is really not so bad, but has the disadvantage, that the startup process is somewhat different than for example RedHat) everything is working well.

The problem really wasn't the driver (as I thought first), but the inconsistencies in the startup process.

Thank you very much Dave!

/juergen

Question bad performance with Jochen's patch and DFE-650

Re: Idea Try This (Jochen Friedrich)
Date: 2000, Feb 26
From: Ingo Ciechowski inki

Although I'm really glad that Jochen's tool works pretty well to enable that D-Link card I had to find out that the card only performs as if it was a 10Mbit card, i.e. 10% of the performance under Windows98.

The LEDs at hub and cardadapter indicate the selected transmission protocol.

Any idea out there what I could do to get it faster?

Ingo

None Performance should be equally bad under Windows

Re: Question bad performance with Jochen's patch and DFE-650 (Ingo Ciechowski)
Date: 2000, Feb 27
From: David Hinds <dhinds@pcmcia.sourceforge.org>

Recheck your Windows performance.  It is impossible to get anything
approaching 100Mbit throughput from this card: it is a 16-bit card,
and the 16-bit PCMCIA bus has a maximum throughput of 1.5-2 MB/sec.

So unless D-Link has found a way to push 100Mbits of data through a
15Mbit pipe, I think your Windows performance numbers were incorrect?

-- Dave

Feedback correct: Windows: 8.28MBit/s - Linux: 0.94MBit/s :-((

Re: None Performance should be equally bad under Windows (David Hinds)
Date: 2000, Feb 27
From: Ingo Ciechowski inki

>Recheck your Windows performance.  It is impossible to get anything
>approaching 100Mbit throughput from this card: it is a 16-bit card,
>and the 16-bit PCMCIA bus has a maximum throughput of 1.5-2 MB/sec.

jou're right, its just a relative difference - but the factor lead me to the idea of 10Mbit vs. 100MBit performance. Here are the numbers I get when copying a lager file with the same 16-bit card:

(a) under Windows98 : 1060kByte/s (about 8.28MBit/s)

(b) unter Linux with Jochen's enabler (independent from the choosen mode and independent of using a 10BaseT oder 100BaseT hub): 120kByte/s (about 0.94MBit/s)

So indeed I'm never in the 100MBit range with that 16bit card, but for some reason I'm at 11% of the windows performance :-((

Ingo

Note Same here

Re: Feedback correct: Windows: 8.28MBit/s - Linux: 0.94MBit/s :-(( (Ingo Ciechowski)
Date: 2000, Feb 27
From: Jochen Friedrich jochen1

Hi Ingo,

i also tried ftp now and found the same performance problems. ifconfig also shows a lot of frame errors (looks like one frame error is reported for each received packet). Interesting fact is that only download is affected (both ftp and http). NFS is also not affected (that's what i mostly use here).

However, even with a flood-ping (ping -f -s 1472), i can't trigger the frame errors i get for ftp...

Additional, i noticed that the card somehow always operates in promicious mode. tcpdump -p still shows all packets on the network. Maybe the selection of speed/mode has to be done before setting up the 8390 chip...

-- Jochen

None Well, that is indeed pretty bad

Re: Feedback correct: Windows: 8.28MBit/s - Linux: 0.94MBit/s :-(( (Ingo Ciechowski)
Date: 2000, Feb 28
From: David Hinds <dhinds@pcmcia.sourceforge.org>

Performance of 120 kb/s is pretty bad.  With the older version of this
card, I get 1000-1100 kb/s on 100baseT.  So yes, there is something
wrong here.  I'm not really sure how to go about debugging it without
maybe information from the vendor about what is really different about
these new cards.

-- Dave

Feedback just called DLink ;-)

Re: None Well, that is indeed pretty bad (David Hinds)
Date: 2000, Aug 02
From: hvx

Hi! I just called DLink Germany a few days ago and told them about the newer cards not being as linux compatible as the older ones are. Today I got mail from them, they send me 2 DLink DFE-660 cards to try them out.

The Node IDs are: 0080C8 8DA027 and 0050BA 745550

Ones of them is new, the other one is very old. (The sticker still says 16-bit, even though it IS 32-bit).

But with both of them I only get about 200kb/s. I dont know if I just got 2 cards which dont work well with linux or if I misconfigurated something. Is there anything I can try to figure it out ?

I tried Jochenīs tool as well, but it quit with a "segmentation faul". TIA Markus

None Re: Feedback: just called DLink ;-)

Re: Feedback just called DLink ;-)
Date: 2000, Aug 02
From: David Hinds <dhinds@pcmcia.sourceforge.org>

The discussion of Jochen's tool, etc, is about different versions of
the 16-bit D-Link DFE-650TX cards.  The issue was also fixed, and both
old and new DFE-650 cards work fine with the current Linux drivers.
Jochen's tool is no longer needed, as far as I know.

This has nothing to do with CardBus DFE-660TX cards.  If there is an
issue with these cards, then it is completely unrelated.

-- Dave

News New version

Re: Feedback correct: Windows: 8.28MBit/s - Linux: 0.94MBit/s :-(( (Ingo Ciechowski)
Date: 2000, Mar 01
From: Jochen Friedrich jochen1

Hi Ingo,

i think i found what was causing this. Apparently, the collision detection uses a different register for its setup.
This one attempts to set up the collision detection as well. However, i only tested 10 MBit/s Half duplex this time.

Cheers,
Jochen

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/io.h>
#include <net/if.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

inline unsigned char
inb (unsigned short port)
{
  unsigned char _v;

  __asm__ __volatile__ ("inb %w1,%0":"=a" (_v):"Nd" (port));
  return _v;
}

inline void
outb (unsigned char value, unsigned short port)
{
  __asm__ __volatile__ ("outb %b0,%w1"::"a" (value), "Nd" (port));
}

static int sockets_open(void)
{
    int sock;
    if ((sock = socket(AF_INET, SOCK_DGRAM, 0)) != -1)
	return sock;
    else if ((sock = socket(AF_IPX, SOCK_DGRAM, 0)) != -1)
	return sock;
    else if ((sock = socket(AF_AX25, SOCK_DGRAM, 0)) != -1)
	return sock;
    else
	return socket(AF_APPLETALK, SOCK_DGRAM, 0);
}
void write_bit(int port, int bit)
{
    outb((bit << 6) + 0x20, port);
    usleep(1);
    outb((bit << 6) + 0xa0, port);
    usleep(1);
    outb((bit << 6) + 0x20, port);
}
int read_bit(int port)
{
    int i;
    outb(0,    port);
    usleep(1);
    outb(0x80, port);
    usleep(1);
    i = inb(port);
    outb(0,    port);
    return (i & 0x10) >> 4;
}
void reset(int port)
{
    outb(0x08, port);
    usleep(1);
    outb(0x0C, port);
    usleep(1);
    outb(0x08, port);
    usleep(1);
    outb(0x0C, port);
    outb(0x00, port);
}
int reada(int port, int adr)
{
    int i,j;

    for (i=0; i<0x20; i++)
      write_bit(port, 1);

    write_bit(port, 0);
    write_bit(port, 1);
    write_bit(port, 1);
    write_bit(port, 0);

    write_bit(port, 0);
    write_bit(port, 0);
    write_bit(port, 0);
    write_bit(port, 0);
    write_bit(port, 0);

    write_bit(port, (adr & 0x10) >> 4);
    write_bit(port, (adr & 0x08) >> 3);
    write_bit(port, (adr & 0x04) >> 2);
    write_bit(port, (adr & 0x02) >> 1);
    write_bit(port, (adr & 0x01) >> 0);

    j = read_bit(port);
    if (j == 1)
      j = read_bit(port);
    for (i=0; i<16; i++) {
      j = (j << 1) + read_bit(port);
    }
    write_bit(port, 1);
    return j;
}
int writea(int port, int adr, int val)
{
    int i,j;

    for (i=0; i<0x20; i++)
      write_bit(port, 1);

    write_bit(port, 0);
    write_bit(port, 1);
    write_bit(port, 0);
    write_bit(port, 1);

    write_bit(port, 0);
    write_bit(port, 0);
    write_bit(port, 0);
    write_bit(port, 0);
    write_bit(port, 0);

    write_bit(port, (adr & 0x10) >> 4);
    write_bit(port, (adr & 0x08) >> 3);
    write_bit(port, (adr & 0x04) >> 2);
    write_bit(port, (adr & 0x02) >> 1);
    write_bit(port, (adr & 0x01) >> 0);

    write_bit(port, 1);
    write_bit(port, 0);

    write_bit(port, (val & 0x8000) >> 15);
    write_bit(port, (val & 0x4000) >> 14);
    write_bit(port, (val & 0x2000) >> 13);
    write_bit(port, (val & 0x1000) >> 12);
    write_bit(port, (val & 0x0800) >> 11);
    write_bit(port, (val & 0x0400) >> 10);
    write_bit(port, (val & 0x0200) >> 9);
    write_bit(port, (val & 0x0100) >> 8);
    write_bit(port, (val & 0x0080) >> 7);
    write_bit(port, (val & 0x0040) >> 6);
    write_bit(port, (val & 0x0020) >> 5);
    write_bit(port, (val & 0x0010) >> 4);
    write_bit(port, (val & 0x0008) >> 3);
    write_bit(port, (val & 0x0004) >> 2);
    write_bit(port, (val & 0x0002) >> 1);
    write_bit(port, (val & 0x0001) >> 0);

    write_bit(port, 1);
    return 0;
}
void main(int argc, char **argv)
{
    int skfd, i, sub, filter;
    struct ifreq ifr;

    skfd = sockets_open();
    if (skfd == -1) {
	perror("socket");
	exit(1);
    }
    strcpy(ifr.ifr_name, argv[1]);
    if (ioctl(skfd, SIOCGIFMAP, &ifr) < 0) {
        perror("ioctl");
        exit(1);
    }
    i = atoi(argv[2]);
    switch(i) {
      case 0:
        sub = 0x0000;
	filter = 0;
	break;
      case 1:
        sub = 0x0100;
	filter = 4;
	break;
      case 2:
        sub = 0x2000;
	filter = 0;
	break;
      default:
        sub = 0x2100;
	filter = 4;
	break;
    }
    ioperm(ifr.ifr_map.base_addr+0x1c, 2, 1);
    reset(ifr.ifr_map.base_addr+0x1c);
    writea(ifr.ifr_map.base_addr+0x1c, 0, 0x8000);
    writea(ifr.ifr_map.base_addr+0x1c, 0, sub);
    outb(filter, ifr.ifr_map.base_addr+0x1d);
    close(skfd);
    exit(0);
}

Note Performance

Re: News New version (Jochen Friedrich)
Date: 2000, Mar 07
From: Bernd Mathiszik BerndM

with the new version of Jochen's tool (independent from the choosen mode and independent of using a 10BaseT oder 100BaseT hub) my performance is about 450kByte/s.

Feedback can't try it any more :-(

Re: Feedback correct: Windows: 8.28MBit/s - Linux: 0.94MBit/s :-(( (Ingo Ciechowski)
Date: 2000, Mar 01
From: Ingo Ciechowski inki

Hi Jochen,

thanks a lot for that new version. Dealing with all those pc-cards during the last days I meanwhile unfortunately already sent the DFE-650 back to the distributor - still looking for some way to get a carbus card to work with my system due to the promising increase in performance.

Therefore I can't test your new tool any more, sorry :-(( Hope, someone else will have a chance to do that.

Ingo

Try This


Add Message to: "Try This"

Members Subscribe Admin Mode Show Frames Help for HyperNews at pcmcia-cs.sourceforge.net 1.10