Date: Mon, 9 Jun 2003 17:00:08 -0700 (PDT) From: Doug Ambrisko <ambrisko@ambrisko.com> To: Palle Girgensohn <girgen@pingpong.net> Cc: freebsd-net@freebsd.org Subject: Re: fxp0: device timeout | SCB already complete. Message-ID: <200306100000.h5A008Ae055437@www.ambrisko.com> In-Reply-To: <176830000.1054647441@palle.girgensohn.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Palle Girgensohn writes:
| Hi!
|
| When I run network backups, one of our FreeBSD machines (backup client) get
| NIC timeouts and warnings from the scsi driver:
|
| Jun 3 14:50:12 melon /kernel: fxp0: device timeout
| Jun 3 14:50:36 melon /kernel: fxp0: device timeout
| Jun 3 14:51:03 melon /kernel: fxp0: device timeout
| Jun 3 14:51:38 melon /kernel: fxp0: device timeout
| Jun 3 14:52:41 melon /kernel: ahc0: Timedout SCB already complete.
| Interrupts may not be functioning.
| Jun 3 14:53:12 melon /kernel: fxp0: device timeout
|
| Both machines are on a hubbed 100 Mbit/s half duplex network. Looking at
| the traffic with netstat -d 1, I see that as soon as the traffic increases,
| there is a timeout and traffic stops, after with the net is reachable
| again. This goes on and on. It only happens when there is much traffic on
| both NIC and SCSI, it seems (alas when running backups...)
|
| Since there was a second NIC, it tried connecting it to the server using
| that NIC through a switch, on a private network, but then the machine
| nearly crashed, or at least came to a grinding halt. It seems, as soon as I
| pulled the ethernet cable it came back. This happened without any backup
| running...
|
| To me, this sounds like some odd interrupt problem? It is a PCI machine
| with an Intel ?x440 (if memory serves me right) and dual CPUs 400 Mhz,
| running freebsd-4.7p2.
|
| Any ideas where to look, how to debug or what to do?
Try this:
diff -c -r1.1.1.2 -r1.3
*** if_fxp.c 28 May 2003 23:39:32 -0000 1.1.1.2
--- if_fxp.c 5 Jun 2003 02:10:23 -0000 1.3
***************
*** 574,579 ****
--- 579,610 ----
}
}
+ if (i == 0x1039 || i == 0x103A) {
+ fxp_read_eeprom(sc, &data, 13, 1);
+ if ((data & 0x0f) == 4) {
+ u_int16_t cksum;
+ int i;
+
+ device_printf(dev,
+ "Fix Tyan bug in EEPROM\n");
+ data = (data & 0xf0) + 0xf;
+ fxp_write_eeprom(sc, &data, 13, 1);
+ device_printf(dev, "New EEPROM ID: 0x%x\n", data);
+ cksum = 0;
+ for (i = 0; i < (1 << sc->eeprom_size) - 1; i++) {
+ fxp_read_eeprom(sc, &data, i, 1);
+ cksum += data;
+ }
+ i = (1 << sc->eeprom_size) - 1;
+ cksum = 0xBABA - cksum;
+ fxp_read_eeprom(sc, &data, i, 1);
+ fxp_write_eeprom(sc, &cksum, i, 1);
+ device_printf(dev,
+ "EEPROM checksum @ 0x%x: 0x%x -> 0x%x\n",
+ i, data, cksum);
+ }
+ }
+
/*
* If we are not a 82557 chip, we can enable extended features.
*/
For kicks. We had to do this on our motherboard. Don't know why. Couldn't
get an answer. I figured this out via a binary search of a good eeprom
contents and bad.
Note you have to boot the kernel twice or power off.
Your mileage may vary. Your machine could blow up etc. This is on a
Tyan 2099GNN board.
Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306100000.h5A008Ae055437>