Re: via-rhine driver: wicked 2005 problem
On Mon, Mar 26, 2001 at 11:51:02AM -0500, Jeff Garzik wrote: > > If the problem is still not solved, could you download via-diag.c and > libmii.c from ftp://www.scyld.com/pub/diag/ Compile instructions are > at the bottom of via-diag.c. I'm interested in seeing two via-diag > register snapshots, one from a cold boot (where it is working), and one > from a warm boot. > > ./via-diag -maaavvveef > via-diag-cold.txt > and > ./via-diag -maaavvveef > via-diag-warm.txt > then >diff -u v*cold.txt v*warm.txt | send mail... > > And to see if the PCI configuration registers change between warm boot > and cold boot, run lspci from pciutils: > > lspci -vvvxxx > lspci-cold.txt > and > lspci -vvvxxx > lspci-warm.txt > then > diff -u l*cold.txt l*warm.txt | send mail... I still have the boot problem, these are the diffs you asked for. I hope they are useful. (using 2.4.3-pre8) I had to include the driver in the kernel, and could not load it as module, I don't know why. == [root@twisted /root]# modprobe via-rhine /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: unresolved symbol alloc_etherdev /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: unresolved symbol unregister_netdev /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: unresolved symbol register_netdev /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: insmod /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o failed /lib/modules/2.4.3-pre8/kernel/drivers/net/via-rhine.o: insmod via-rhine failed == --- lspci-cold.txt Thu Mar 29 04:10:49 2001 +++ lspci-warm.txt Thu Mar 29 04:08:04 2001 @@ -65,7 +65,7 @@ 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 00 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 -40: 08 01 00 00 00 80 60 e6 05 01 84 00 00 00 f0 f3 +40: 08 01 00 00 00 80 60 ee 05 01 84 00 00 00 f0 f3 50: 00 00 04 00 00 a0 0b f0 00 06 ff 08 50 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 05 1e 00 02 00 00 f0 40 00 00 00 00 @@ -115,7 +115,7 @@ 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00 40: 20 84 5c 00 ba 70 00 00 01 40 00 00 d8 10 00 00 -50: 00 fe ff 88 50 04 00 00 00 ff ff 00 00 00 00 00 +50: 00 ff ff 88 50 04 00 00 00 ff ff 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 00 02 00 00 00 00 00 70: 01 60 00 00 01 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --- via-diag-cold.txt Thu Mar 29 04:10:31 2001 +++ via-diag-warm.txt Thu Mar 29 04:07:26 2001 @@ -1,24 +1,19 @@ 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 0xec00. - Station address 00:50:ba:1e:91:1b. + Station address 00:00:00:00:00:00. Tx disabled, Rx disabled, half-duplex (0x0804). Receive mode is 0x00: Unknown/invalid. Transmit mode is 0x00: Normal transmit, 128 byte threshold. VIA VT3065 Rhine-II chip registers at 0xec00 - 0x000: 1eba5000 1b91 0804 + 0x000: 0804 0x020: 0400 0x040: ffd7dffa - 0x060: 0e091108 9f00 0880 0247 + 0x060: 0e09131f 8100 0880 0247 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 1e 91 1b 00 00 00 00 00 00 00 00 00 00 +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 - mdio_read(0xec00, 0, 1).. mdio_read(0xec00, 1, 1).. mdio_read(0xec00, 2, 1).. mdio_read(0xec00, 3, 1).. mdio_read(0xec00, 4, 1).. mdio_read(0xec00, 5, 1).. mdio_read(0xec00, 6, 1).. mdio_read(0xec00, 7, 1).. mdio_read(0xec00, 8, 1).. MII PHY found at address 8, status 0x782d. - mdio_read(0xec00, 9, 1).. mdio_read(0xec00, 10, 1).. mdio_read(0xec00, 11, 1).. mdio_read(0xec00, 12, 1).. mdio_read(0xec00, 13, 1).. mdio_read(0xec00, 14, 1).. mdio_read(0xec00, 15, 1).. mdio_read(0xec00, 16, 1).. mdio_read(0xec00, 17, 1).. mdio_read(0xec00, 18, 1).. mdio_read(0xec00, 19, 1).. mdio_read(0xec00, 20, 1).. mdio_read(0xec00, 21, 1).. mdio_read(0xec00, 22, 1).. mdio_read(0xec00, 23, 1).. mdio_read(0xec00, 24, 1).. mdio_read(0xec00, 25, 1).. mdio_read(0xec00, 26, 1).. mdio_read(0xec00, 27, 1).. mdio_read(0xec00, 28, 1).. mdio_read(0xec00, 29, 1).. mdio_read(0xec00, 30, 1).. mdio_read(0xec00, 31, 1).. MII PHY #8 transceiver registers: mdio_read(0xec00, 8, 0).. - 3000 mdio_read(0xec00, 8, 1).. 782d mdio_read(0xec00, 8, 2).. 0016 mdio_read(0xec00, 8, 3
Re: via-rhine driver: wicked 2005 problem
wing tung Leung wrote: > It doesn't solve the (less urgent) problem of not being able the use the > NIC after a warm boot in M$ Windows. As I said, pulling the power cord from > the ATX power supply and reinserting it, makes it go away. Would it be possible for you to re-run your tests against kernel 2.4.3-pre8? (ftp://ftp.us.kernel.org/pub/linux/kernel/testing/) This is the "official" latest version of the via-rhine driver, and it includes Manfred's patch, as well as a pci_enable_device movement might solve your problem. If the problem is still not solved, could you download via-diag.c and libmii.c from ftp://www.scyld.com/pub/diag/ Compile instructions are at the bottom of via-diag.c. I'm interested in seeing two via-diag register snapshots, one from a cold boot (where it is working), and one from a warm boot. ./via-diag -maaavvveef > via-diag-cold.txt and ./via-diag -maaavvveef > via-diag-warm.txt then diff -u v*cold.txt v*warm.txt | send mail... And to see if the PCI configuration registers change between warm boot and cold boot, run lspci from pciutils: lspci -vvvxxx > lspci-cold.txt and lspci -vvvxxx > lspci-warm.txt then diff -u l*cold.txt l*warm.txt | send mail... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: via-rhine driver: wicked 2005 problem
On Mon, Mar 26, 2001 at 09:08:46AM +0200, Manfred Spraul wrote: > > [Kernel 2.4.2, > > the -ac kernels contain a patch that automatically resets the nic if it > dies. I've attached my old patch, it applies to 2.4.2. Your patch works fine for resetting the NIC. There are some a one or two log messages coming up, but the transfer continues after a small delay. It doesn't solve the (less urgent) problem of not being able the use the NIC after a warm boot in M$ Windows. As I said, pulling the power cord from the ATX power supply and reinserting it, makes it go away. > > I tried the diagnostic utilities from Donald Becker at Scyld.com, > > but I don't know what I should be looking for. The text output > > seems ok to me. > > > Could you post the output? > And a few more lines from your kernel log. It's rather much to post the the mailing list, I think, so I've put it online at [http://win-www.uia.ac.be/u/s965817/via-rhine.report/]. If you prefer otherwise, just tell me. I can always send a tarball of the logs. Some explanation of the logs: report: script for creating the device status dumps hang/: about the "timed out" problem receiving much data 242/: using the default module from 2.4.2 release before/: device status before the lock, while NIC works well after/:device status after the lock, during timeout messages 242patch/: using the patched version before/: device status before the timeout or wicked messages after/:device status afterwards (NIC keeps working fine) windoze:/ about the warm-boot-after-windoze problem winboot/: device info booting after warm boot (problem case) coldboot/: device info booting after total cold boot (no problem) Thanks a lot for the patch. Tung - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: via-rhine driver: wicked 2005 problem
> [Kernel 2.4.2,
the -ac kernels contain a patch that automatically resets the nic if it
dies. I've attached my old patch, it applies to 2.4.2.
>
> I tried the diagnostic utilities from Donald Becker at Scyld.com,
> but I don't know what I should be looking for. The text output
> seems ok to me.
>
Could you post the output?
And a few more lines from your kernel log.
--
Manfred
--- 2.4/drivers/net/via-rhine.c Mon Feb 5 16:44:59 2001
+++ build-2.4/drivers/net/via-rhine.c Mon Feb 5 19:46:23 2001
@@ -55,6 +55,9 @@
LK1.1.6:
- Urban Widmark: merges from Beckers 1.08b version (VT6102 + mdio)
set netif_running_on/off on startup, del_timer_sync
+
+ LK1.1.7:
+ - Manfred Spraul: added reset into tx_timeout
*/
@@ -121,13 +124,14 @@
#include
#include
#include
+#include
#include /* Processor type for cache alignment. */
#include
#include
/* These identify the driver base version and may not be removed. */
static char version1[] __devinitdata =
-"via-rhine.c:v1.08b-LK1.1.6 8/9/2000 Written by Donald Becker\n";
+"via-rhine.c:v1.08b-LK1.1.7 8/9/2000 Written by Donald Becker\n";
static char version2[] __devinitdata =
" http://www.scyld.com/network/via-rhine.html\n";
@@ -380,6 +384,7 @@
CmdNoTxPoll=0x0800, CmdReset=0x8000,
};
+#define MAX_MII_CNT4
struct netdev_private {
/* Descriptor rings */
struct rx_desc *rx_ring;
@@ -421,7 +426,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 +437,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);
@@ -443,6 +448,25 @@
static int via_rhine_close(struct net_device *dev);
static inline void clear_tally_counters(long ioaddr);
+static void wait_for_reset(struct net_device *dev)
+{
+ long ioaddr = dev->base_addr;
+ int i;
+
+ i = 0;
+ do {
+ udelay(5);
+ i++;
+ if(i > 2000) {
+ printk(KERN_ERR "%s: reset did not complete in 10 ms.\n",
+ dev->name);
+ break;
+ }
+ } while(readw(ioaddr + ChipCmd) & CmdReset);
+ if (debug > 1)
+ printk(KERN_INFO "%s: reset finished after %d microseconds.\n",
+ dev->name, 5*i);
+}
static int __devinit via_rhine_init_one (struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -451,14 +475,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 +492,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 +509,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 +518,7 @@
if (dev == NULL) {
p
via-rhine driver: wicked 2005 problem
Hello, [Kernel 2.4.2, gcc-2.9.3 (same problem with egcs-2.91.66), binutils-2.9.5.0.22-6] [AMD Thunderbird, ABIT KT7A, no overclocking, D-Link DFE-530TX, 3Com 10Mbit hub, ATI Radeon AGP video, Matrox Mystique PCI video.] When I download a big sized a few MB from the LAN using FTP, the hub collision LED burns a lot, and after a few downloads the connection suddenly hangs and syslog dumps: Mar 25 16:44:03 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 25 16:44:03 localhost kernel: eth0: Transmit timed out, status , PHY status 782d, resetting... I just need the restart the device using "/etc/rc.d/init.d/network restart" and the connection is back. I just need to start a heavy download to initiate the problem, uploading seems to work fine. If I increase the debug level to 7, the logs contains: Mar 25 16:44:01 localhost kernel: eth0: Transmit error, Tx status 8100. Mar 25 16:44:01 localhost kernel: eth0: Something Wicked happened! 2009. Mar 25 16:44:01 localhost kernel: eth0: exiting interrupt, status=0x. Mar 25 16:44:01 localhost kernel: eth0: Interrupt, status 0001. Mar 25 16:44:01 localhost kernel: In via_rhine_rx(), entry 5 status 05ee8f00. Mar 25 16:44:01 localhost kernel: via_rhine_rx() status is 05ee8f00. Mar 25 16:44:01 localhost kernel: eth0: exiting interrupt, status=0x. I tried the diagnostic utilities from Donald Becker at Scyld.com, but I don't know what I should be looking for. The text output seems ok to me. I also tried to move the network card into other PCI slots, even tried to throw out the AGP and PCI video card, but with no succes. This is an extract from /proc/pci, and I don't think see any IRQ conflict there. Bus 0, device 11, function 0: Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 67). IRQ 15. Master Capable. Latency=32. Min Gnt=3.Max Lat=8. I/O at 0xec00 [0xecff]. Non-prefetchable 32 bit memory at 0xde00 [0xdeff]. Last fact: when using M$ Windows, I get comparable FTP speeds, without the locking. The subjective collision rate is about the same. I also have the problem to need a cold boot after having used Windows, the network card completely refuses to send or/and receive before pulling the power cord. The via-rhine module *does* recognize the card correctly, but just is not able to use it. I know this kind of issues have come up in the past, but I haven't found any real solution in the archives. Please redirect me to it if it does exist. Regards, Tung - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
