fxp0: device timeout | SCB already complete.

[Doug Ambrisko]

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.