Question: DFE-650 not always Linux-compatible? 

Forum: PCMCIA Network Adapter Issues
Date: 2000, Feb 25
From: Anthony Jameson AJameson

Subject: DFE-650 not always Linux-compatible? Reply-to: Anthony Jameson <jameson@cs.uni-sb.de> BCC: jameson@sol.cs.uni-sb.de --text follows this line-- Hi, The D-Link DFE-650TX is well known as a Linux-compatible Fast Ethernet card. For example, two such cards have been found to work fine on my Toshiba Satellite 4090XCDT running S.u.S.e. Linux 6.0 But just a few days ago I bought a third such card for myself, and it's been nothing but trouble, even as its supposedly identical twins continue to work fine. It's recognized by the card manager, and the pcnet_cs driver is duly loaded. But it's impossible to connect to the network: I always get the error message "No route to host". In /var/log/messages, there's always a message like this: Feb 24 22:14:40 helena kernel: eth0: Tx timed out, cable problem? TSR=0x42, ISR=0x0, t=1000. Followng the advice in the PCMCIA how-to, I've tried juggling the IRQs and the ports, but the result is always the same. And this is not a unique experience: I've corresponded with a Linux expert in northern Germany who spent days combating exactly the same problem with his new DFE-650TX card, before giving up and returning the card to the dealer. So it looks as if D-Link may have made some change in their card that renders it Linux-incompatible (though they still claim Linux-compatibility for the card on the packaging and on their web site). Anthony Jameson Here's some debugging information: Kernel version: 2.0.36 cardctl version 3.0.6 Output of "cardctl ident": Socket 0: no product info available Socket 1: product info: "D-Link", "DFE-650", "Fast Ethernet", "Rev. D1" manfid: 0x0149, 0x0230 function: 6 (network) Output of "cardctl status": Socket 0: no card Socket 1: 5V 16-bit card present Function 0: Typical sequence in /var/log/messages, starting with a system reboot: Feb 24 22:13:51 helena syslogd 1.3-3: restart. Feb 24 22:13:52 helena kernel: klogd 1.3-3, log source = /proc/kmsg started. Feb 24 22:13:52 helena kernel: Inspecting /boot/System.map Feb 24 22:13:52 helena kernel: Loaded 5086 symbols from /boot/System.map. Feb 24 22:13:52 helena kernel: Symbols match kernel version 2.0.36. Feb 24 22:13:52 helena kernel: Loaded 18 symbols from 6 modules. Feb 24 22:13:52 helena kernel: Linux PCMCIA Card Services 3.0.6 Feb 24 22:13:52 helena kernel: kernel build: 2.0.36 #1 Fri Dec 11 16:26:51 /etc/localtime 1998 Feb 24 22:13:52 helena kernel: options: [pci] [cardbus] Feb 24 22:13:52 helena kernel: Intel PCIC probe: Feb 24 22:13:52 helena kernel: Toshiba ToPIC97 PCI-to-CardBus at bus 0 slot 2, mem 0x68000000, 2 sockets Feb 24 22:13:52 helena kernel: host opts [0]: [slot 0xf0] [ccr 0x10] [cdr 0x86] [rcr 0x02] [no pci irq] [lat 168/176] [bus 20/20] Feb 24 22:13:52 helena kernel: host opts [1]: [slot 0xf0] [ccr 0x11] [cdr 0x86] [rcr 0x02] [no pci irq] [lat 168/176] [bus 21/21] Feb 24 22:13:52 helena kernel: ISA irqs (default) = 3,4,5,7,9,10,11,12 polling interval = 1000 ms Feb 24 22:13:52 helena kernel: cs: IO port probe 0x1000-0x17ff: clean. Feb 24 22:13:52 helena kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 Feb 24 22:13:52 helena kernel: cs: IO port probe 0x0a00-0x0aff: clean. Feb 24 22:13:52 helena kernel: cs: memory probe 0x0d0000-0x0dffff: clean. Feb 24 22:13:52 helena kernel: eth0: NE2000 Compatible: port 0x300, irq 9, hw_addr 00:E0:98:77:94:FD Feb 24 22:13:53 helena ypbind[124]: unable to register (YPBINDPROG, YPBINDVERS, udp). : Connection refused # Is the above relevant here? Feb 24 22:13:54 helena lpd[147]: restarted Feb 24 22:14:18 helena apmd[255]: Version 3.0final (APM BIOS 1.1, Linux driver 1.2) Feb 24 22:14:18 helena apmd[255]: Charge: * * * (94% 2:38) Feb 24 22:14:22 helena su: (to jameson) root on /dev/ttyp2 Feb 24 22:14:32 helena apmd[255]: Now using AC Power Feb 24 22:14:40 helena kernel: eth0: Tx timed out, cable problem? TSR=0x42, ISR=0x0, t=1000. Feb 24 22:15:45 helena kernel: eth0: Tx timed out, cable problem? TSR=0x42, ISR=0x0, t=6500. Feb 24 22:17:45 helena kernel: eth0: Tx timed out, cable problem? TSR=0x42, ISR=0x0, t=12000. /etc/pcmcia/config.opts: (Don't know if there's anything nonstandard here.) # # Local PCMCIA Configuration File # # System resources available for PCMCIA devices # include port 0x100-0x4ff, port 0x1000-0x17ff include memory 0xc0000-0xfffff include memory 0xa0000000-0xa0ffffff, memory 0x60000000-0x60ffffff # # Extra port range for IBM Token Ring # include port 0xa00-0xaff # # Resources we should not use, even if they appear to be available # # First built-in serial port exclude irq 4 # Second built-in serial port exclude irq 3 # First built-in parallel port exclude irq 7

[ Next-in-Thread ]  [ Next Message ] 

Messages Inline: [ 0 ]  [ 1 ] 

Idea: Try This 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

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

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: 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

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: 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

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: 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

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

Agree: NetGear FA410TXC Tool works for D-Link DE-650 Re: Question: DFE-650 not always Linux-compatible? (Anthony Jameson) Date: 2000, Feb 26 From: Ingo Ciechowski inki

I've just found Anthony Jamesons recommendation and his great little tool as postes under #46. in this group. Since I ran into the same problem as Phil Brooke I gave it a try and found that Anthony's enabling code works pretty well for the newer DE-650 cards. Thanks a lot for this input - and I hope it will make it's way into one of the new versions of the pcmcia sources. Ingo

Angry: HELP! *Still* can't get D-Link DFE-650TX going! (Day 5) Re: Agree: NetGear FA410TXC Tool works for D-Link DE-650 (Ingo Ciechowski) Date: 2000, Aug 18 From: Harold Boyer hboyer

Hi. I'm going absolutely crazy. I've read all of this stuff, and I still can't get this D-Link going. It's the endless "found link beat" "lost link beat" crisis in /var/log/messages. Funny thing is, it's not just the D-link, it happened with a 3com 656 modem+adapter card too. Same exact thing. I have a Toshiba Satellite 2250CDT. I'm running RedHat 6.2, with pcmcia-cs 2.2.16-17 beta code (so the fixes aren't in the pcmcia upgrade yet). The same exact thing happened with pcmcia-cs 2.2.16-3, and the whole 2.2.14-x series. Ugh! The card works perfectly at 10M or 100M in Windows 98 and 2000. I've tried PCIC card mode and Cardbus/16-bit in the BIOS. I downloaded a binary for fa_select, but it doesn't run (must not be RedHat), and I downloaded the source for Jochen Friedrich's fix, but I don't know C, and can't get it to compile. If I type "make fa_select" it errors on "inline", and if I take the inline line out, it errors on the next line. I also typed "gcc fa_select" but that obviously didn't help either. What else... I've bounced it from irq 3 to 5 to 9 to 10, and none of those worked. Any ideas? I'm going mad. I don't care if the fix is slow, as long as it works. I've put literally 30+ hours into this, and I've already switched cards, and don't want to order another one. If someone can send me a RedHat binary of fa_select, that might work, and could you please tell me which init script to call it from? Any help would be REALLY appreciated! Please cc: hboyer@minn.net. My /var/log/messages: Aug 17 12:07:36 localhost kernel: Linux PCMCIA Card Services 3.1.8 Aug 17 12:07:36 localhost kernel: kernel build: 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 Aug 17 12:07:36 localhost kernel: options: [pci] [cardbus] [apm] Aug 17 12:07:36 localhost kernel: Intel PCIC probe: Aug 17 12:07:36 localhost kernel: Intel i82365sl B step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 1 socket Aug 17 12:07:36 localhost kernel: host opts [0]: none Aug 17 12:07:36 localhost kernel: ISA irqs (scanned) = 3,4,5,7,10 polling interval = 1000 ms Aug 17 12:07:36 localhost cardmgr[859]: starting, version is 3.1.8 Aug 17 12:07:36 localhost cardmgr[859]: watching 1 sockets Aug 17 12:07:36 localhost kernel: cs: IO port probe 0x1000-0x17ff: clean. Aug 17 12:07:36 localhost kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 Aug 17 12:07:36 localhost kernel: cs: IO port probe 0x0a00-0x0aff: clean. Aug 17 12:07:37 localhost cardmgr[859]: initializing socket 0 Aug 17 12:07:37 localhost kernel: cs: memory probe 0x0d0000-0x0dffff: clean. Aug 17 12:07:37 localhost cardmgr[859]: socket 0: KTI ETHER-C16 Fast ethernet Aug 17 12:07:37 localhost cardmgr[859]: executing: 'insmod /lib/modules/2.2.14-5.0/net/8390.o' Aug 17 12:07:37 localhost cardmgr[859]: executing: 'insmod /lib/modules/2.2.14-5.0/pcmcia/pcnet_cs.o' Aug 17 12:07:37 localhost kernel: eth0: NE2000 Compatible: io 0x300, irq 5, hw_addr 00:50:BA:73:6D:1E Aug 17 12:07:37 localhost cardmgr[859]: executing: './network start eth0' Aug 17 12:07:37 localhost pumpd[891]: starting at (uptime 0 days, 0:02:31) Thu Aug 17 12:07:37 2000 Aug 17 12:07:38 localhost kernel: eth0: found link beat Aug 17 12:07:39 localhost kernel: eth0: lost link beat Aug 17 12:07:41 localhost kernel: eth0: trigger_send() called with the transmitter busy. Aug 17 12:08:07 localhost kernel: eth0: trigger_send() called with the transmitter busy. Aug 17 12:08:07 localhost ifdown: Operation failed. Aug 17 12:08:08 localhost network: Shutting down interface eth0 succeeded Jochen Friedrich's code: #include <sys/types.h> #include <sys/socket.h> #include <sys/ioctl.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; outb(0x08, port); usleep(1); outb(0x0C, port); usleep(1); outb(0x08, port); usleep(1); outb(0x0C, port); outb(0x00, port); 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, led; 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; break; case 1: sub = 0x0100; break; case 2: sub = 0x2000; break; default: sub = 0x2100; break; } ioperm(ifr.ifr_map.base_addr+0x1c, 1, 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); close(skfd); exit(0); }

Re: Angry: HELP! *Still* can't get D-Link DFE-650TX going! (Day 5) Re: Angry: HELP! *Still* can't get D-Link DFE-650TX going! (Day 5) (Harold Boyer) Date: 2000, Aug 21 From: David Hinds <dhinds@pcmcia.sourceforge.org>

> Funny thing is, it's not just the D-link, it happened with a 3com 656 > modem+adapter card too. Same exact thing. I don't get this. The driver for that card doesn't generate any sort of link beat messages, ever, so how can it be the exact same thing? > I downloaded a binary for fa_select, but it doesn't run Binaries are not distribution specific. Does it give you a specific error message? > I downloaded the source for Jochen Friedrich's fix, but I > don't know C, and can't get it to compile. gcc -O -o faselect faselect.c -- Dave

[ Add Message ]  to: "DFE-650 not always Linux-compatible?"

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