D-LINK DFE-530-TX
Which ethernet module works with this card? 2.2.17 kernel -- Mike A. Harris - Linux advocate - Open source advocate This message is copyright 2000, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- #[Mike A. Harris bash tip #3 - how to disable core dumps] # Put the following at the bottom of your ~/.bash_profile ulimit -c 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Wed, 6 Dec 2000, Mike A. Harris wrote: > Which ethernet module works with this card? 2.2.17 kernel Should be the rtl8139 driver. Regards, Jim > -- > Mike A. Harris - Linux advocate - Open source advocate > This message is copyright 2000, all rights reserved. > Views expressed are my own, not necessarily shared by my employer. > -- -- James Bourne, Web Systems Administrator Mount Royal College, Calgary, AB, CA www.mtroyal.ab.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, James Bourne wrote: > On Wed, 6 Dec 2000, Mike A. Harris wrote: > > > Which ethernet module works with this card? 2.2.17 kernel > > Should be the rtl8139 driver. AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. Mike, if you have problems, search list archives: a few people (including me) reported problems under load. I've never solved them. > > Regards, > Jim > > > -- > > Mike A. Harris - Linux advocate - Open source advocate > > This message is copyright 2000, all rights reserved. > > Views expressed are my own, not necessarily shared by my employer. > > -- > > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
> > Should be the rtl8139 driver. > > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. > Mike, if you have problems, search list archives: a few people (including > me) reported problems under load. I've never solved them. 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be way better (but not perfect) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, Alan Cox wrote: > > > Should be the rtl8139 driver. > > > > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. > > Mike, if you have problems, search list archives: a few people (including > > me) reported problems under load. I've never solved them. > > 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his > own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be > way better (but not perfect) Yes, still running 2.2.17 though. The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess replaces the 538 as that is no longer listed on the Dlink site) is an rtl8139 chip. Jim > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > -- James Bourne, Web Systems Administrator Mount Royal College, Calgary, AB, CA www.mtroyal.ab.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, Alan Cox wrote: > > > Should be the rtl8139 driver. > > > > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. > > Mike, if you have problems, search list archives: a few people (including > > me) reported problems under load. I've never solved them. > > 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his > own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be > way better (but not perfect) > Ehm, does it drive the DFE-530TX, which, I believe, it's a via-rhine? I had problems with the 530. I've been told that the 538 (rtl8139) works under the same load (NFS server on a small LAN, and a 5-ports D-Link Switch), even with the old driver. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, James Bourne wrote: > On Thu, 7 Dec 2000, Alan Cox wrote: > > > > > Should be the rtl8139 driver. > > > > > > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. > > > Mike, if you have problems, search list archives: a few people (including > > > me) reported problems under load. I've never solved them. > > > > 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his > > own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be > > way better (but not perfect) > > Yes, still running 2.2.17 though. > > The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess > replaces the 538 as that is no longer listed on the Dlink site) is an > rtl8139 chip. You mean that D-Link made a card named DFE530TX VIA based and one named DFE530TX+ rtl based? Isn't it a bit confusing? B-) > > Jim .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, Marco Colombo wrote: > On Thu, 7 Dec 2000, James Bourne wrote: > > > The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess > > replaces the 538 as that is no longer listed on the Dlink site) is an > > rtl8139 chip. > > You mean that D-Link made a card named DFE530TX VIA based and one named > DFE530TX+ rtl based? Isn't it a bit confusing? B-) Ya, 530TX is a 10/100 nic Davicom chipset (sorry, not viacom *slap*) http://www.dlink.com/products/adapters/dfe530tx/ 530TX+ is 10/100 with WOL and rtl8139 chipset http://www.dlink.com/products/adapters/dfe530txplus/ Jim > > > > > Jim > > .TM. > -- James Bourne, Web Systems Administrator Mount Royal College, Calgary, AB, CA www.mtroyal.ab.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
It uses the via-rhine driver on my system On Thu, 7 Dec 2000, James Bourne wrote: > On Wed, 6 Dec 2000, Mike A. Harris wrote: > > > Which ethernet module works with this card? 2.2.17 kernel > > Should be the rtl8139 driver. > > Regards, > Jim > > > -- > > Mike A. Harris - Linux advocate - Open source advocate > > This message is copyright 2000, all rights reserved. > > Views expressed are my own, not necessarily shared by my employer. > > -- > > -- Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Wed, Dec 06, 2000 at 07:44:02PM -0500, Mike A. Harris wrote: > Which ethernet module works with this card? 2.2.17 kernel > If the PCI device ID is 3065 then it's via-rhine, but not supported by the driver in the kernel. Get updated via-rhine from Donald Becker's site http://www.scyld.com/network. Even the DFE-530-TX driver for NT downloaded from D-Link's site doesn't know about this chip yet ... though changing the device ID in the .INF file seemed to make it work ... shrug. HTH P. -- ++ |Peter Horton| ++ |http://www.colonel-panic.com| | http://www.berserk.demon.co.uk | | Linux 2.4.0-test11 | ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
Peter Horton wrote: > > On Wed, Dec 06, 2000 at 07:44:02PM -0500, Mike A. Harris wrote: > > Which ethernet module works with this card? 2.2.17 kernel > > > > If the PCI device ID is 3065 then it's via-rhine, but not supported by the > driver in the kernel. Get updated via-rhine from Donald Becker's site > http://www.scyld.com/network. 2.4.x-test has some fixes for via-rhine which don't appear to have made it into the Becker driver yet... Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
Hi Linux, On Fri, Dec 08, 2000 at 09:56:15AM -0500, Jeff Garzik wrote: > Peter Horton wrote: > > If the PCI device ID is 3065 then it's via-rhine, but not supported > > by the driver in the kernel. Get updated via-rhine from Donald > > Becker's site http://www.scyld.com/network. > 2.4.x-test has some fixes for via-rhine which don't appear to have made > it into the Becker driver yet... Is either of these likely to make it into the stock 2.2 via-rhine? Simon. -- Just another wannabie | "I get mail; therefore I am." | Just another fool --+ - Dilbert+--- This message was brought to you the letter L and the number 31. htag.pl 0.0.17 -- http://www.earth.li/projectpurple/progs/htag.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
> > > Becker's site http://www.scyld.com/network. > > 2.4.x-test has some fixes for via-rhine which don't appear to have made > > it into the Becker driver yet... > > Is either of these likely to make it into the stock 2.2 via-rhine? If someone ports them over for an earlyish 2.2.19pre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
Simon Huggins wrote: > On Fri, Dec 08, 2000 at 09:56:15AM -0500, Jeff Garzik wrote: > > Peter Horton wrote: > > > If the PCI device ID is 3065 then it's via-rhine, but not supported > > > by the driver in the kernel. Get updated via-rhine from Donald > > > Becker's site http://www.scyld.com/network. > > 2.4.x-test has some fixes for via-rhine which don't appear to have made > > it into the Becker driver yet... > > Is either of these likely to make it into the stock 2.2 via-rhine? Becker never replies to patches and changes I send him, so who knows. Ask Becker... Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX [patch]
On Wed, 13 Dec 2000, Alan Cox wrote: > > > > Becker's site http://www.scyld.com/network. > > > 2.4.x-test has some fixes for via-rhine which don't appear to have made > > > it into the Becker driver yet... > > > > Is either of these likely to make it into the stock 2.2 via-rhine? > > If someone ports them over for an earlyish 2.2.19pre Your wish ... Below a patch that updates the 2.2 via-rhine driver from Becker's 1.08b, except for the pci probing that is unchanged, compatibility macros and dead code that are not needed in 2.2 removed (removing ifdef CARDBUS is from 1.08b) and "clear_tally_counters" from 2.4. It would be nice if people using 2.2 and one of these cards could test this too. Patch includes: + new VT6102 pci id & supporting non-aligned data buffers for that chip + completely untested (by me, that is) big<->little endian stuff + free allocated memory on driver unload + no more writel to 0x7c. + 2 16bit values accessed as one 32bit (why? not sure, pci optimization?) + change transmit ring size and some other more or less minor changes/cleanups. This is mostly a copy&paste operation. If you'd rather get a smaller change for just supporting the VT6102 that is easy to do. However, this is very similar to the 2.4 driver (locking is a major diff) so I hope it is ok. Also, if I don't include most of the 1.08b driver I'm not sure what version name to give it ... :) /Urban diff -ur -X exclude linux-2.2.18-orig/drivers/net/via-rhine.c linux/drivers/net/via-rhine.c --- linux-2.2.18-orig/drivers/net/via-rhine.c Wed Dec 13 21:27:37 2000 +++ linux/drivers/net/via-rhine.c Fri Dec 15 00:03:59 2000 @@ -1,35 +1,44 @@ /* via-rhine.c: A Linux Ethernet device driver for VIA Rhine family chips. */ /* - Written 1998-1999 by Donald Becker. + Written 1998-2000 by Donald Becker. - This software may be used and distributed according to the terms - of the GNU Public License (GPL), incorporated herein by reference. - Drivers derived from this code also fall under the GPL and must retain - this authorship and copyright notice. + This software may be used and distributed according to the terms of + the GNU General Public License (GPL), incorporated herein by reference. + Drivers based on or derived from this code fall under the GPL and must + retain the authorship, copyright and license notice. This file is not + a complete program and may only be used when the entire operating + system is licensed under the GPL. This driver is designed for the VIA VT86c100A Rhine-II PCI Fast Ethernet controller. It also works with the older 3043 Rhine-I chip. - The author may be reached as [EMAIL PROTECTED], or - Donald Becker - 312 Severn Ave. #W302 + The author may be reached as [EMAIL PROTECTED], or C/O + Scyld Computing Corporation + 410 Severn Ave., Suite 210 Annapolis MD 21403 Support and updates available at - http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html + http://www.scyld.com/network/via-rhine.html + + + Linux kernel version history: + + LK1.0.0: + - Urban Widmark: merges from Beckers 1.08b version and 2.4.0 (VT6102) */ -static const char *versionA = -"via-rhine.c:v1.01 2/27/99 Written by Donald Becker\n"; -static const char *versionB = -" http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html\n"; +/* These identify the driver base version and may not be removed. */ +static const char version1[] = +"via-rhine.c:v1.08b-LK1.0.0 12/14/2000 Written by Donald Becker\n"; +static const char version2[] = +" http://www.scyld.com/network/via-rhine.html\n"; -/* A few user-configurable values. These may be modified when a driver - module is loaded.*/ +/* The user-configurable values. + These may be modified when a driver module is loaded.*/ static int debug = 1; /* 1 normal messages, 0 quiet .. 7 verbose. */ static int max_interrupt_work = 20; -static int min_pci_latency = 64; +static int min_pci_latency = 32; /* Set the copy breakpoint for the copy-only-tiny-frames scheme. Setting to > 1518 effectively disables this feature. */ @@ -55,7 +64,8 @@ Making the Tx ring too large decreases the effectiveness of channel bonding and packet priority. There are no ill effects from too-large receive rings. */ -#define TX_RING_SIZE 8 +#define TX_RING_SIZE 16 +#define TX_QUEUE_LEN 10 /* Limit ring entries actually used. */ #define RX_RING_SIZE 16 /* Operational parameters that usually are not changed. */ @@ -64,9 +74,15 @@ #define PKT_BUF_SZ 1536/* Size of each temporary Rx buffer.*/ + +#if !defined(__OPTIMIZE__) +#warning You must compile this file with the correct options! +#warning See the last lines of the source file. +#error You must compile this driver with "-O". +#endif + #include #include -#include #include
d-link dfe-530 tx (bug-report)
hi! When I download big files with a win-client from my linux-server with samba 2.07 and kernel 2.4.1 (just downloaded to test the new driver) after a random time there is a connection-error! ..when I just download a few megabytes there is no problem. /var/log/messages on the linux-server with the d-link dfe-530 tx: [THIS IS THE ERROR-MESSAGE!] Feb 1 17:25:56 Nethost kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 1 17:25:56 Nethost kernel: eth0: Transmit timed out, status , PHY status 782d, resetting... after booting everthing is fine (..until the big smb-transfer): /var/log/messages (good): via-rhine.c:v1.08b-LK1.1.6 8/9/2000 Written by Donald Becker http://www.scyld.com/network/via-rhine.html PCI: Assigned IRQ 9 for device 00:0a.0 PCI: Setting latency timer of device 00:0a.0 to 64 eth0: VIA VT6102 Rhine-II at 0xe000, 00:50:ba:68:59:9c, IRQ 9. eth0: MII PHY found at address 8, status 0x7829 advertising 01e1 Link 0081. I hope you can fix this problem. bye. additional informations: lspci -vvv: 00:0a.0 Ethernet controller: VIA Technologies, Inc.: Unknown device 3065 (rev 42 ) Subsystem: D-Link System Inc: Unknown device 1401 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Step ping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot +,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- cat /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 4 model name : Pentium MMX stepping: 3 cpu MHz : 192.107 fdiv_bug: no hlt_bug : no f00f_bug: yes coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 mmx bogomips: 383.38 cat /proc/ioports: -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0280-029f : eth1 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 e000-e0ff : VIA Technologies, Inc. Ethernet Controller e000-e0ff : eth0 e800-e80f : Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] e800-e807 : ide0 e808-e80f : ide1 cat /proc/interrupts: CPU0 0: 59686 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 4: 21 XT-PIC serial 9: 3276 XT-PIC eth0 10: 93 XT-PIC eth1 11: 11704 XT-PIC HiSax 14: 9771 XT-PIC ide0 15: 13 XT-PIC ide1 NMI: 0 ERR: 0 cat /proc/modules: smc-ultra 4784 1 (autoclean) via-rhine 9616 1 (autoclean) hisax 140176 4 isdn 89904 5 [hisax] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
>/var/log/messages on the linux-server with the d-link dfe-530 tx: >[THIS IS THE ERROR-MESSAGE!] >Feb 1 17:25:56 Nethost kernel: NETDEV WATCHDOG: eth0: transmit timed out >Feb 1 17:25:56 Nethost kernel: eth0: Transmit timed out, status , >PHY status 782d, resetting... > >after booting everthing is fine (..until the big smb-transfer): >/var/log/messages (good): > >via-rhine.c:v1.08b-LK1.1.6 8/9/2000 Written by Donald Becker > http://www.scyld.com/network/via-rhine.html >PCI: Assigned IRQ 9 for device 00:0a.0 >PCI: Setting latency timer of device 00:0a.0 to 64 >eth0: VIA VT6102 Rhine-II at 0xe000, 00:50:ba:68:59:9c, IRQ 9. >eth0: MII PHY found at address 8, status 0x7829 advertising 01e1 Link 0081. This sounds every much like it's related to the problems we're having with the card not initialising on reboot from Windows. What's the bets we're looking at a new revision of the chip which VIA haven't (publically) released documentation for yet? I'd say they're pretty high... -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
Hi, >This sounds every much like it's related to the problems we're having with >the card not initialising on reboot from Windows. > >What's the bets we're looking at a new revision of the chip which VIA >haven't (publically) released documentation for yet? I'd say they're >pretty high... I had the same problem yesterday. I don't have any Windows crap in my network, the affected machine hasn't rebooted in a week, and my card is not new. There may be another problem. via-rhine.c:v1.08b-LK1.1.6 8/9/2000 Written by Donald Becker http://www.scyld.com/network/via-rhine.html PCI: Found IRQ 10 for device 00:0a.0 eth0: VIA VT3043 Rhine at 0xd800, 00:40:05:a4:3d:84, IRQ 10. eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link . Kernel 2.4.1-pre9. I loaded the module like this: insmod via-rhine options=28 00:0a.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine 10/100] (rev 06) Subsystem: Elecom Co Ltd: Unknown device 1420 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] I wonder about the subsystem: Unknown device. It's the first time I see this (lspci 2.1.8). BTW why do I have to "strings /sbin/lspci" to find out its version? Regards, hjb -- Pro-Linux - Germany's largest volunteer Linux support site http://www.pro-linux.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
> This sounds every much like it's related to the problems we're having with > the card not initialising on reboot from Windows. It's not the same problem. Here the card initializes just fine. And it works for a while. The "transmit timed out" message is simply saying that we told the card to send something but it hasn't generated an interrupt or anything allowing the driver to know the packet was actually sent. > What's the bets we're looking at a new revision of the chip which VIA > haven't (publically) released documentation for yet? I'd say they're > pretty high... Oh, that's known already. They haven't released any info on the older "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a preliminary version. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
Urban Widmark wrote: > > The "transmit timed out" message is simply saying that we told the card to > send something but it hasn't generated an interrupt or anything allowing > the driver to know the packet was actually sent. > check via_rhine_tx_timeout(): the function is basically empty. > > Oh, that's known already. They haven't released any info on the older > "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a > preliminary version. > Where can I find that file? I'll try to implement tx_timeout() -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
On Sun, 4 Feb 2001, Manfred Spraul wrote: > > Oh, that's known already. They haven't released any info on the older > > "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a > > preliminary version. > > > Where can I find that file? > I'll try to implement tx_timeout() http://www.via.com.tw/pdf/productinfo/vt86c100a.pdf /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
Urban Widmark wrote:
>
> On Sun, 4 Feb 2001, Manfred Spraul wrote:
>
> > > Oh, that's known already. They haven't released any info on the older
> > > "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a
> > > preliminary version.
> > >
> > Where can I find that file?
> > I'll try to implement tx_timeout()
>
> http://www.via.com.tw/pdf/productinfo/vt86c100a.pdf
>
Ok, I've attached a patch that performs an unconditional reset in
tx_timeout().
I don't have the hardware, could you test it?
I also found newer via documentation on via's ftp site:
ftp.via.com.tw/public/lan/Products/NIC/VT86C100A, from Sept 98
--
Manfred
--- 2.4/drivers/net/via-rhine.c Sat Feb 3 14:02:54 2001
+++ build-2.4/drivers/net/via-rhine.c Sun Feb 4 15:58:38 2001
@@ -380,6 +380,7 @@
CmdNoTxPoll=0x0800, CmdReset=0x8000,
};
+#define MAX_MII_CNT4
struct netdev_private {
/* Descriptor rings */
struct rx_desc *rx_ring;
@@ -421,7 +422,8 @@
/* MII transceiver section. */
u16 advertising;/* NWay media
advertisement */
- unsigned char phys[2]; /* MII device addresses. */
+ unsigned char phys[MAX_MII_CNT];/* MII device
+addresses. */
+ unsigned int mii_cnt; /* number of MIIs found, but only the
+first one is used */
u16 mii_status; /* last read MII
status */
};
@@ -431,7 +433,6 @@
static void via_rhine_check_duplex(struct net_device *dev);
static void via_rhine_timer(unsigned long data);
static void via_rhine_tx_timeout(struct net_device *dev);
-static void via_rhine_init_ring(struct net_device *dev);
static int via_rhine_start_tx(struct sk_buff *skb, struct net_device *dev);
static void via_rhine_interrupt(int irq, void *dev_instance, struct pt_regs *regs);
static void via_rhine_tx(struct net_device *dev);
@@ -451,14 +452,11 @@
struct netdev_private *np;
int i, option;
int chip_id = (int) ent->driver_data;
- int irq = pdev->irq;
static int card_idx = -1;
static int did_version = 0;
long ioaddr;
int io_size;
int pci_flags;
- void *ring;
- dma_addr_t ring_dma;
/* print version once and once only */
if (! did_version++) {
@@ -471,6 +469,10 @@
io_size = via_rhine_chip_info[chip_id].io_size;
pci_flags = via_rhine_chip_info[chip_id].pci_flags;
+ if (pci_enable_device (pdev))
+ goto err_out;
+
+
/* this should always be supported */
if (!pci_dma_supported(pdev, 0x)) {
printk(KERN_ERR "32-bit PCI DMA addresses not supported by the
card!?\n");
@@ -484,20 +486,7 @@
goto err_out;
}
- /* allocate pci dma space for rx and tx descriptor rings */
- ring = pci_alloc_consistent(pdev,
- RX_RING_SIZE * sizeof(struct rx_desc) +
- TX_RING_SIZE * sizeof(struct tx_desc),
- &ring_dma);
- if (!ring) {
- printk(KERN_ERR "Could not allocate DMA memory.\n");
- goto err_out;
- }
-
ioaddr = pci_resource_start (pdev, pci_flags & PCI_ADDR0 ? 0 : 1);
-
- if (pci_enable_device (pdev))
- goto err_out_free_dma;
if (pci_flags & PCI_USES_MASTER)
pci_set_master (pdev);
@@ -506,7 +495,7 @@
if (dev == NULL) {
printk (KERN_ERR "init_ethernet failed for card #%d\n",
card_idx);
- goto err_out_free_dma;
+ goto err_out;
}
SET_MODULE_OWNER(dev);
@@ -545,23 +534,18 @@
dev->dev_addr[i] = readb(ioaddr + StationAddr + i);
for (i = 0; i < 5; i++)
printk("%2.2x:", dev->dev_addr[i]);
- printk("%2.2x, IRQ %d.\n", dev->dev_addr[i], irq);
+ printk("%2.2x, IRQ %d.\n", dev->dev_addr[i], pdev->irq);
/* Reset the chip to erase previous misconfiguration. */
writew(CmdReset, ioaddr + ChipCmd);
dev->base_addr = ioaddr;
- dev->irq = irq;
np = dev->priv;
spin_lock_init (&np->lock);
np->chip_id = chip_id;
np->drv_flags = via_rhine_chip_info[chip_id].drv_flags;
np->pdev = pdev;
- np->rx_ring = ring;
- np->tx_ring = ring + RX_RING_SIZE * sizeof(struct rx_desc);
- np->rx_ring_dma = ring_dma;
- np->tx_ring_dma = ring_dma + RX_RING_SIZE * sizeof(struct rx_desc);
if (dev->mem_start)
option = dev->mem_start;
@@ -593,7 +577,7 @@
if (np->drv_flags & CanHaveMII) {
int phy, phy_idx = 0;
np->phys[0] = 1;/* Standard for this chip. */
- for (phy = 1; phy < 32 && phy_idx < 4; phy++) {
+
Re: d-link dfe-530 tx (bug-report)
On 4 Feb 2001, at 23:31, Urban Widmark wrote: > On Sun, 4 Feb 2001, Manfred wrote: > > > Ok, I've attached a patch that performs an unconditional reset in > > tx_timeout(). > > > > I don't have the hardware, could you test it? > > The changed startup code doesn't break anything for me. > > > I also found newer via documentation on via's ftp site: > > ftp.via.com.tw/public/lan/Products/NIC/VT86C100A, from Sept 98 > > You've done even better than that: > ftp.via.com.tw/public/lan/Products/NIC/VT6102 > :) > > > For those of you with vt6102s that don't like being rebooted from > win98 I have modified Manfred's patch to try and really reset the card > at startup. > > CmdReset is not instant, it may need a delay. There is also a "force > software reset" operation that sounds good, I assume that one also > could use a delay so I gave it 6ms. > > This will probably not fix things, but it would be nice if you could > test it as well as Manfred's variant. (I know it's painful to reboot > into win98 all the time :) > > You shouldn't have to reboot between testing each of the patches > (assumes via-rhine.o as a module). Just make sure the module is > unloaded and reloaded. So a single win98 trip would allow testing both > of them. > > The via-diag.c program has a bug when looking at vt6102's. They have > 256 bytes of registers, not just 128. The attached patch fixes this > (no need to use the -Ii switches). Checking the output again when the > card is working and not working could give some clue. There are some > power save states in the higher registers that look suspicious. > > 0x96 contains "PHY address at suspend well" > 0x94-0x95 contains "MII address at suspend well" > (at suspend well == in power save mode?) > > Finally, MII PHYs can be reset by setting bit15 in MII register 0. > During the search for the PHY it could try resetting each address. > > /Urban > Right, i patched the via-diag and its showing more regs. I applyed Manfred's patch but that changed nothing. Then I applyed your patch and still changed nothing as you suspected. But there are regs that are different. Not working:- via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400. Station address 00:00:00:00:00:00. Tx disabled, Rx disabled, half-duplex (0x0004). Receive mode is 0x6c: Normal unicast and hashed multicast. Transmit mode is 0x21: Normal transmit, 256 byte threshold. VIA VT3065 Rhine-II chip registers at 0xd400 0x000: 216c 0004 07c62000 07c62120 0x020: 0400 0600 07c61010 07c62010 0600 07c61810 07c62020 0x040: c000 00e0824e 07c80402 07c62120 feff 0x060: 0006131f 8100 0880 0247 0x080: 03012000 0680 0x0A0: 0x0C0: 0x0E0: No interrupt sources are pending (). Access to the EEPROM has been disabled (0x80). Direct reading or writing is not possible. EEPROM contents (Assumed from chip registers): 0x100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x110: 00 00 00 00 00 00 00 00 06 00 00 00 47 02 73 73 ***WARNING***: No MII transceivers found! Working:- via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400. Station address 00:50:ba:6e:d8:55. Tx disabled, Rx disabled, half-duplex (0x0004). Receive mode is 0x6c: Normal unicast and hashed multicast. Transmit mode is 0x21: Normal transmit, 256 byte threshold. VIA VT3065 Rhine-II chip registers at 0xd400 0x000: 6eba5000 216c55d8 0004 8000 07c620e0 07c62180 0x020: 0400 0600 07c85010 07c620f0 0600 07c85810 07c62000 0x040: 00e08000 07c62190 fefd 0x060: 00061108 9f00 0880 0247 0x080: 00012000 0680 0008 0x0A0: 0101 0101 0x0C0: 0x0E0: No interrupt sources are pending (). Access to the EEPROM has been disabled (0x80). Direct reading or writing is not possible. EEPROM contents (Assumed from chip registers): 0x100: 00 50 ba 6e d8 55 00 00 00 00 00 00 00 00 00 00 0x110: 00 00 00 00 00 00 00 00 06 00 00 00 47 02 73 73 MII PHY found at address 8, status 0x782d. MII PHY #8 transceiver registers: 3000 782d 0016
Re: d-link dfe-530 tx (bug-report)
Thomas Stewart wrote: > > > > > CmdReset is not instant, it may need a delay. There is also a "force > > software reset" operation that sounds good, I assume that one also > > could use a delay so I gave it 6ms. > > 6 ms is quite long: I added a reset into tx_timeout, and that function should not take more than 1 ms or so. Did you find something about the delay in the documentation? Is it possible to poll for reset completion? I know that the winbond-840 chipset resets in 4 pci cycles - perhaps the via-rhine is also fast? > > I applyed Manfred's patch but that changed nothing. > That's expected, my patch fixes another bug. The NIC now recover from "Tx timeout" messages. ksa confirmed that, but there is still a delay of a few seconds. I'll try to fix that. > Then I applyed your patch and still changed nothing as you suspected. > But there are regs that are different. > Did you run via-diag before or after loading the via-rhine module? -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
On Mon, 5 Feb 2001, Manfred Spraul wrote: > 6 ms is quite long: > I added a reset into tx_timeout, and that function should not take more > than 1 ms or so. > Did you find something about the delay in the documentation? Is it > possible to poll for reset completion? I don't know how long. For testing I figured it might be nice with a long delay, and I was hoping 6ms is long enough. If it changes anything, then you can start working on getting it right. :) There is a flag that may indicate reset complete (that's why the while loop is there). It is supposed to do that for normal "CmdReset" so maybe it does the same for "forced reset". I have no idea if it does. But the reset doesn't seem to change much anyway. The MII PHY (miffy?) is not responding but there are a few registers to play with there. One clear difference is the PHY address, 8 vs 31 (and 31 has some special meaning for some other register). The new register dumps needs to be examined for any vt6102 specifics that are disabled. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
On 5 Feb 2001, at 9:38, Manfred Spraul wrote: > That's expected, my patch fixes another bug. > The NIC now recover from "Tx timeout" messages. ksa confirmed that, > but there is still a delay of a few seconds. I'll try to fix that. > > > Then I applyed your patch and still changed nothing as you > > suspected. But there are regs that are different. > > > Did you run via-diag before or after loading the via-rhine module? I compiled it into the kernel, I ran via-diag when it was working and when it was not working. regards tom - This message is ROT-13 encoded twice for extra security Thomas Stewart - [EMAIL PROTECTED] This should contain no attachments - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
Thomas Stewart wrote: > > Right, i patched the via-diag and its showing more regs. > > I applyed Manfred's patch but that changed nothing. > Then I applyed your patch and still changed nothing as you suspected. > But there are regs that are different. > Several regs are just the wakeup frames, but some look suspicious. Could you try Urban's patch, but add writeb(0x00, ioaddr + 0x83); writel(0x0101, ioaddr + 0xa0); writel(0x0101, ioaddr + 0xa4) writew(0x, ioaddr + 0x72); writeb(0x08, ioaddr + 0x96); > just before + writeb(0x40, ioaddr + 0x81);/* Force software reset */ (around line 540) -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
hi! ..I installed Manfred's patch and the d-link-card was now able to reset after the tx-timeout-error. that means that the card was again reachable after the error. but the smb-transfer-connection-error still appeared. then I set "static int debug = 2;" in the patched via-rhine.c to get more debug-informations but from then on the card worked without errors!? I tested this several times and produced a lot of network traffic - but there was no more error-message! ..but I will do some more tests to get sure. ;-) bye. -- Kristofmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
On 5 Feb 2001, at 11:58, Manfred Spraul wrote: > Thomas Stewart wrote: > Several regs are just the wakeup frames, but some look suspicious. > > Could you try Urban's patch, but add > > > writeb(0x00, ioaddr + 0x83); > writel(0x0101, ioaddr + 0xa0); > writel(0x0101, ioaddr + 0xa4) > writew(0x, ioaddr + 0x72); > writeb(0x08, ioaddr + 0x96); > > > > just before > + writeb(0x40, ioaddr + 0x81);/* Force software reset */ > (around line 540) Right, I tryed that, mac address still reported as 00:00:00:00:00:00 on boot. I also turned on a bios option to try to reset pnp things. Also now I cant get the card to do the dhcpcd stuff now, oh why didn't I just buy an ne2000 :) regards tom - This message is ROT-13 encoded twice for extra security Thomas Stewart - [EMAIL PROTECTED] This should contain no attachments - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: d-link dfe-530 tx (bug-report)
I just installed Urban's most recent patch, and I still get much the same problems when I reboot from Windows. The main difference appears to be that there's a few seconds' pause during the via-rhine driver initialisation (presumably while it tries to find PHY devices), and there aren't quite so many "transmit timed out" messages in the system log after booting. They do still appear though, and the network is not accessible. This happens when I reboot from Windows, and when I subsequently soft-power the machine and turn it back on. If also happens if I soft-power the machine from Windows and switch on straight into Linux. In short, the card still needs a hard power-off for Linux to get it working after Windows. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
