Subject: kern/10622: fxp driver has problem on DMA processing?
To: None <gnats-bugs@gnats.netbsd.org>
From: Takahiro Kambe <taca@sky.yamashina.kyoto.jp>
List: netbsd-bugs
Date: 07/17/2000 18:11:48
>Number:         10622
>Category:       kern
>Synopsis:       fxp driver has problem on DMA processing?
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 17 15:26:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Takahiro Kambe
>Release:        NetBSD 1.5_ALPHA (2000/7/4)
>Organization:
	
>Environment:
	
System: NetBSD candle.kyoto.jepro.co.jp 1.5_ALPHA NetBSD 1.5_ALPHA (KERNEL) #13: Thu Jul 13 21:26:53 JST 2000     taca@candle.kyoto.jepro.co.jp:/usr/src/sys/arch/i386/compile/KERNEL i386


>Description:
	Intel's i82557 base Fast Ethernet Card has a trouble with Tekram
	SCSI card (DC-390 or DC-390U).

	The same problem was discussted on freebsd-hackers mailing list,
	at the following thread.

	http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=502449+505841+/usr/local/www/db/text/1999/freebsd-hackers/19991010.freebsd-hackers

	It crashes at fxp_add_rfabuf(), and the same crash happens on
	FreeBSD 2.2.8 (same code base fxp driver) on the same machine.

(gdb) target kcore netbsd.5.core
panic: pool_get(%s): free list modified: magic=%x; page %p; item addr %p

#0  0x100 in ?? ()
(gdb) where
#0  0x100 in ?? ()
#1  0xc01e5f1b in cpu_reboot ()
#2  0xc0148c45 in panic ()
#3  0xc0147bd8 in _pool_get ()
#4  0xc0108a05 in fxp_add_rfabuf ()
#5  0xc01074ed in fxp_intr ()
#6  0xc0101b80 in Xintr15 ()

>How-To-Repeat:
	It seems to happen the following configuration:

	i82557 base Fast Ethernet Card
	Realtek DC-390 or DC-390U with BIOS enabled
	Intel 440BX based motherboadr?

>Fix:
	One strange thing is disabling DC-390's SCSI BIOS solve the
	problem (but DC-390U can't disable SCSI BIOS).  It seems that
	some PCI configuration change affect to this problem.

	With tsutsui@netbsd.org's advise, I tested as bellow.

	1. Increasing FXP_NRFABUFS defer panic(), but not prevent completly.

	2. Changing i82557's PCI mapping as bellow:
	   This dosen't imporve anything.

--- sys/dev/ic/i82557.c.orig	Wed Jul 12 00:09:14 2000
+++ sys/dev/ic/i82557.c	Wed Jul 12 00:20:11 2000
@@ -998,6 +998,9 @@
 
  do_transmit:
 		if (statack & FXP_SCB_STATACK_RNR) {
+			fxp_scb_wait(sc);
+			CSR_WRITE_1(sc, FXP_CSR_SCB_COMMAND,
+			    FXP_SCB_COMMAND_RU_ABORT);
 			rxmap = M_GETCTX(sc->sc_rxq.ifq_head, bus_dmamap_t);
 			fxp_scb_wait(sc);
 			CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL,

	3. Changing to issue FXP_SCB_COMMAND_RU_ABORT command to i82557
	   when FXP_SCB_STATACK_RNR condition has occured:

	   This fixes the problem even if SCSI BIOS is enabled!
	   The patch attached bellow.


Index: sys/dev/ic/i82557.c
===================================================================
diff -u -r1.1.1.6 -r1.1.1.5.2.2
--- sys/dev/ic/i82557.c	2000/07/05 00:13:52	1.1.1.6
+++ sys/dev/ic/i82557.c	2000/07/17 03:36:31	1.1.1.5.2.2
@@ -998,6 +998,9 @@
 
  do_transmit:
 		if (statack & FXP_SCB_STATACK_RNR) {
+			fxp_scb_wait(sc);
+			CSR_WRITE_1(sc, FXP_CSR_SCB_COMMAND,
+				    FXP_SCB_COMMAND_RU_ABORT);
 			rxmap = M_GETCTX(sc->sc_rxq.ifq_head, bus_dmamap_t);
 			fxp_scb_wait(sc);
 			CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL,

	It seems fix my problem, but I'm not expert about i82557 nor PCI
	configuration.  I wish this problem analyzed by some expert.  :-)


>Release-Note:
>Audit-Trail:
>Unformatted: