hi,
I have a D-Link DFE-530TX Rev A, PCI ethernet card, but it refuses
to work.
I have looked at http://www.scyld.com/network/index.html#pci
which sugests using the via-rhine driver.
I did this and compiled it into the kernel. It detects it at boot (via-
rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the
hardware address (mac address?) is 00-00-00-00-00-00.
The card is not a DF-530TX or a DFE-530TX+ AFAIK.
http://www.d-link.com don't do linux drivers or say anything about linux.
The card works perfect with d-link drivers in win98 and w2k.
Whats the differance between via-rhine in 2.2.18 and 2.4.1?
Can any one help?
Thanks for reading
tom
(can u cc replys to me)
Some more info:-
pci device 00:0a.0
io=0xD400
irq=9
linux-2.4.1
glibc-2.2.1
gcc-2.95.3
ps I have tryed to exaust all prosabilitys before posting here, and I
am sorry if this is stupid, its my first post to linux-kernel!
>I have a D-Link DFE-530TX Rev A, PCI ethernet card, but it refuses
>to work.
>
>I have looked at http://www.scyld.com/network/index.html#pci
>which sugests using the via-rhine driver.
>
>I did this and compiled it into the kernel. It detects it at boot (via-
>rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the
>hardware address (mac address?) is 00-00-00-00-00-00.
I have an identical card, which usually works - except when I've rebooted
from Windows, when it shows the above symptoms. After using Windows, I
have to power the machine off, including turning off the "standby power"
switch on the PSU, then turn it back on and boot straight into Linux. Very
occasionally it also loses "identity" and requires a similar reset, even
when running Linux.
I'm using kernel 2.4.1 on that machine too, which is a Duron 700MHz on an
Abit KT7 (KT133 chipset).
--------------------------------------------------------------
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-----
> >I did this and compiled it into the kernel. It detects it at boot (via-
> >rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the
> >hardware address (mac address?) is 00-00-00-00-00-00.
This is a good example of what is missed by not copying the exact message.
For example, mine says:
eth0: VIA VT3043 Rhine at 0xd400, 00:50:ba:a4:15:86, IRQ 19.
eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link 0000.
Does it say "VIA VT6102 Rhine-II" for both of you?
If not, could you do an 'lspci -n'?
My VT3043 survives win98, but it may be a new feature in the newer chip.
It may be a bios setting or something ...
> I have an identical card, which usually works - except when I've rebooted
> from Windows, when it shows the above symptoms. After using Windows, I
> have to power the machine off, including turning off the "standby power"
> switch on the PSU, then turn it back on and boot straight into Linux. Very
> occasionally it also loses "identity" and requires a similar reset, even
> when running Linux.
Yes, the card is in some (for the linux driver) unknown state. Powering
off completely resets it. Something that could help someone find out what
is going on is running these two commands, both when the card is working
and when it is not.
via-diag -aaeemm
lspci -vvvxxx -d 1106:3065
via-diag is available from http://www.scyld.com/diag/index.html
(1106:3065 is the pci id, if lspci -n gives you a different number you use
that of course.)
/Urban
Linux version 2.4.1 (root@diamond) (gcc version 2.95.3 20010125 (prerelease)) #1 Fri Feb 2 13:33:07 GMT 2001
BIOS-provided physical RAM map:
BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
BIOS-e820: 0000000000000400 @ 000000000009fc00 (reserved)
BIOS-e820: 0000000000004000 @ 00000000000dc000 (reserved)
BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
BIOS-e820: 0000000007ef0000 @ 0000000000100000 (usable)
BIOS-e820: 0000000000008000 @ 0000000007ff0000 (ACPI data)
BIOS-e820: 0000000000008000 @ 0000000007ff8000 (ACPI NVS)
BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone(1): 28656 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux ro root=305
Initializing CPU#0
Detected 798.095 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1592.52 BogoMIPS
Memory: 126436k/131008k available (1119k kernel code, 4184k reserved, 469k data, 204k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 0387f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0387f9ff 00000000 00000000 00000000
CPU serial number disabled.
CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU: Common caps: 0383f9ff 00000000 00000000 00000000
CPU: Intel Pentium III (Coppermine) stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfdb01, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
DMI 2.3 present.
29 structures occupying 980 bytes.
DMI table at 0x000F0600.
BIOS Vendor: American Megatrends Inc.
BIOS Version: 62710
BIOS Release: 09/15/2000
System Vendor: American Megatrends Inc..
Product Name: VIA694X/686A.
Version 00000000.
Serial Number 00000000.
Board Vendor: Gigabyte Technology Co., Ltd.
Board Name: 6VXC7-4X.
Board Version: 1.0.
Asset Tag: 00000000.
IA-32 Microcode Update Driver: v1.08 <[email protected]>
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq=<none or set by other means> dma=<none or set by other means>
parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
parport0: cpp_daisy: aa5500ff(98)
parport0: assign_addrs: aa5500ff(98)
parport0: Printer, HEWLETT-PACKARD DESKJET
parport_pc: Via 686A parallel port: io=0x378, irq=7
pty: 256 Unix98 ptys configured
lp0: using parport0 (interrupt-driven).
block: queued sectors max/low 83965kB/27988kB, 256 slots per queue
loop: enabling 8 loop devices
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD307AA-00BAA0, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: Pioneer DVD-ROM ATAPIModel DVD-115 0111, ATAPI CD/DVD-ROM drive
hdd: CD-W54E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 60074784 sectors (30758 MB) w/2048KiB Cache, CHS=3739/255/63, UDMA(66)
hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 1280kB Cache, DMA
Partition check:
hda: hda1 hda2 < hda5 hda6 hda7 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
Non-volatile memory driver v1.1
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 9 for device 00:0a.0
eth0: VIA VT6102 Rhine-II at 0xd400, 00:00:00:00:00:00, IRQ 9.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 94M
agpgart: Detected Via Apollo Pro chipset
agpgart: AGP aperture is 128M @ 0xe0000000
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
Creative EMU10K1 PCI Audio Driver, version 0.7, 13:34:34 Feb 2 2001
PCI: Found IRQ 10 for device 00:0b.0
PCI: The same IRQ used for device 00:07.2
emu10k1: EMU10K1 rev 7 model 0x8026 found, IO at 0xd000-0xd01f, IRQ 10
usb.c: registered new driver hub
PCI: Found IRQ 10 for device 00:07.2
PCI: The same IRQ used for device 00:0b.0
uhci.c: USB UHCI at I/O 0xd800, IRQ 10
uhci.c: detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver usbscanner
scanner.c: USB Scanner support registered.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
ip_tables: (c)2000 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux IPX 0.43 for NET4.0
IPX Portions Copyright (c) 1995 Caldera, Inc.
IPX Portions Copyright (c) 2000 Conectiva, Inc.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 204k freed
uhci.c: root-hub INT complete: port1: 49b port2: 48a data: 6
hub.c: USB new device connect on bus1/1, assigned device number 2
usb.c: USB device 2 (vend/prod 0x3f0/0x405) is not claimed by any active driver.
uhci.c: root-hub INT complete: port1: 495 port2: 488 data: 4
Adding Swap: 136512k swap-space (priority -1)
On Sat, 3 Feb 2001 [email protected] wrote:
> VIA VT3065 Rhine-II chip registers at 0xd400
> 0x000: 00000000 00000000 00000804 00000000 00000000
> 00000000 00000000 00000000
> 0x020: 00000400 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> 0x040: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 feffffff
> 0x060: 00000000 00000000 00000000 0e09131f 00008100
> 08000080 02470000 00000000
> No interrupt sources are pending (0000).
> 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 09 0e 00 00 47 02 73 73
> ***WARNING***: No MII transceivers found!
This is intresting. Your card reports that it is stopped while the other
report show normal values on most things. Does this change if you try and
send something (like a ping)?
Common to both reports is that the transceivers don't respond.
The functioning card reports a PHY ID of 0016 f880, wonder which chip that
is ... ?
The attached patch for the via-daig program plays with a few registers.
Run it as 'via-diag -aaeemm -I' then do a 'ifconfig eth0 down; ifconfig
eth0 up' and see if anything happens.
If this doesn't work you may want to play "guess the register". A fun
game for all ages, made more fun by using obfuscated english. There is a
datasheet here for a chip similar to the ones you have.
http://www.via.com.tw/pdf/productinfo/vt86c100a.pdf
/Urban
>The attached patch for the via-daig program plays with a few registers.
>
>Run it as 'via-diag -aaeemm -I' then do a 'ifconfig eth0 down; ifconfig
>eth0 up' and see if anything happens.
OK, after a little trouble applying the patch, here's what I found:
Starting with the card in working condition, I tried "via-diag -aaeemm -I"
and there was no change in functionality. Running the ifconfig toggle also
had no overall effect. Then I tried "via-diag -aaeemm -i" (running a
pinger in another console) and noted that the pinger stopped working when
the command was run. However, running "via-diag -aaeemm -I" did not change
that situation. The ifconfig toggle did correctly restart operation.
Examining the system log after the above showed that at some point during
the sequence the kernel emitted a series of "transmit timed out" log-entry
pairs as shown in my last mail. Also, I noticed that while running -i the
receive status was listed as "unicast/hashed multicast" and while running
-I the receive status was "unknown/invalid".
Do you want me to try this again, after first setting the card into
non-working condition?
--------------------------------------------------------------
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-----
On Sat, 3 Feb 2001, Jonathan Morton wrote:
> Do you want me to try this again, after first setting the card into
> non-working condition?
Yes, the idea was to start from non-working, test -I and then ifconfig
down/up. Getting the working card to work is a much simpler problem :)
/Urban
On 3 Feb 2001, at 14:02, Urban Widmark wrote:
> This is intresting. Your card reports that it is stopped while the
> other report show normal values on most things. Does this change if
> you try and send something (like a ping)? Common to both reports is
> that the transceivers don't respond.
>
> The functioning card reports a PHY ID of 0016 f880, wonder which chip
> that is ... ?
>
>
> The attached patch for the via-daig program plays with a few
> registers.
>
> Run it as 'via-diag -aaeemm -I' then do a 'ifconfig eth0 down;
> ifconfig eth0 up' and see if anything happens.
>
> If this doesn't work you may want to play "guess the register". A fun
> game for all ages, made more fun by using obfuscated english. There is
> a datasheet here for a chip similar to the ones you have.
> http://www.via.com.tw/pdf/productinfo/vt86c100a.pdf
Ye, sounds like a fun game ;-)
See bottom for via-diag outputs.
It looks as thought your I switchs do not fix the prob. There is still
no Station address (00:00:00:00:00:00). The next thing I did was
look at the working output again:-
VIA VT3065 Rhine-II chip registers at 0xd400
0x000: 6eba5000 206c55d8 00000c5a 4eff0000 80000000
00000000 01264010 01264190
0x020: 80000400 00000600 079ae810 01264020 80000000
00000600 079ad010 01264030
0x040: 00000000 00e08000 00000000 012641a0 00000000
00000000 013c013c feffffff
0x060: 00000000 00000000 00000000 00061108 782d8100
08000080 02470000 00000000
<SNIP>
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
I noticed that the mac address was stored in the registers and
eprom. I guess it would not be as easy as just writing the mac
back in the blank eprom and registers?
Is there a reset 'thing' for thses chips, that sets them back to
factory tests (like switching them off)?
So.....How do I go about playing this game?
tom
freshboot of linux, no eth0 confg done, via-diag -aaeemm
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: 00000000 216c0000 00000004 00000000 00000000
00000000 01264000 01264120
0x020: 00000400 00000600 01362010 01264010 00000000
00000600 01362810 01264020
0x040: c0000000 00e0824e 07c49402 01264120 00000000
00000000 00000000 feffffff
0x060: 00000000 00000000 00000000 0006131f 00008100
08000080 02470000 00000000
No interrupt sources are pending (0000).
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!
ifconfig eth0 up, via-diag -aaeemm -I
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 enabled, Rx enabled, half-duplex (0x081a).
Receive mode is 0x6c: Normal unicast and hashed multicast.
Transmit mode is 0x20: Normal transmit, 256 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
0x000: 00000000 206c0000 0000081a 4eff0000 00000000
00000000 01264000 01264100
0x020: 00000400 00000000 00000000 00000000 00000000
00000000 00000000 00000000
0x040: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 feffffff
0x060: 00000000 00000000 00000000 0e091308 00008100
08000080 02470000 00000000
No interrupt sources are pending (0000).
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 09 0e 00 00 47 02 73 73
***WARNING***: No MII transceivers found!
ifconifig eth0 down, ifconfig eth0 up, via-diag -aaeemm
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 enabled, Rx enabled, half-duplex (0x081a).
Receive mode is 0x6c: Normal unicast and hashed multicast.
Transmit mode is 0x20: Normal transmit, 256 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
0x000: 00000000 206c0000 0000081a 4eff0000 00000000
00000000 01264000 01264100
0x020: 00000400 00000000 00000000 00000000 00000000
00000000 00000000 00000000
0x040: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 feffffff
0x060: 00000000 00000000 00000000 00061301 00008100
08000080 02470000 00000000
No interrupt sources are pending (0000).
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!
On Sat, 3 Feb 2001 [email protected] wrote:
> I noticed that the mac address was stored in the registers and
> eprom. I guess it would not be as easy as just writing the mac
> back in the blank eprom and registers?
What my changed via-diag tries to do is to tell the chip to reload things
from the eeprom (note that the diag program doesn't actually list the
eeprom contents).
You can always try writing all the registers with "good" values.
> Is there a reset 'thing' for thses chips, that sets them back to
> factory tests (like switching them off)?
[snip]
> So.....How do I go about playing this game?
You find the reset "thing". Maybe there is better documentation somewhere.
Maybe your bios allows you to reset something on reboots.
The pdf document has a few things that you can play with, SRST, INIT,
STRT.
/Urban
>You can always try writing all the registers with "good" values.
No good - nothing actually changes except 16 bits at 0x6C, and that doesn't
change to anything useful.
>> Is there a reset 'thing' for thses chips, that sets them back to
>> factory tests (like switching them off)?
>[snip]
>> So.....How do I go about playing this game?
>
>You find the reset "thing". Maybe there is better documentation somewhere.
>Maybe your bios allows you to reset something on reboots.
>
>The pdf document has a few things that you can play with, SRST, INIT,
>STRT.
Already played with those, to no avail.
I think the PDF is talking about a different revision of the chip to ours -
I'm seeing some bits set which are marked "reserved" in the PDF, and some
reserved bits are clear.
--------------------------------------------------------------
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-----