From owner-freebsd-bugs@FreeBSD.ORG Sat Jul 3 09:20:24 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C82C416A4CE for ; Sat, 3 Jul 2004 09:20:24 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD47143D5E for ; Sat, 3 Jul 2004 09:20:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i639KOU3022405 for ; Sat, 3 Jul 2004 09:20:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i639KOH9022404; Sat, 3 Jul 2004 09:20:24 GMT (envelope-from gnats) Resent-Date: Sat, 3 Jul 2004 09:20:24 GMT Resent-Message-Id: <200407030920.i639KOH9022404@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Michael Kukat Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9182116A4CF for ; Sat, 3 Jul 2004 09:14:18 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72BE043D6B for ; Sat, 3 Jul 2004 09:14:18 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i639EHBp089792 for ; Sat, 3 Jul 2004 09:14:17 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.11/8.12.11/Submit) id i639EHFj089791; Sat, 3 Jul 2004 09:14:17 GMT (envelope-from nobody) Message-Id: <200407030914.i639EHFj089791@www.freebsd.org> Date: Sat, 3 Jul 2004 09:14:17 GMT From: Michael Kukat To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: kern/68623: sf(4) (Adaptec StarFire) multiple problems on alpha and maybe other platforms X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2004 09:20:24 -0000 >Number: 68623 >Category: kern >Synopsis: sf(4) (Adaptec StarFire) multiple problems on alpha and maybe other platforms >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jul 03 09:20:24 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Michael Kukat >Release: 4.9 alpha >Organization: >Environment: FreeBSD calchas.unixiron.org 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Mon Jun 21 20:15:15 CEST 2004 root@:/usr/src/sys/compile/PC164 alpha >Description: On FreeBSD/alpha, sf(4) causes kernel panics dur to machine checks. The reason is unaligned access mainly. Some Alphas don't show this problem (like the AlphaStation 200), others absolutely don't like those access faults (like the PC164). Another reason is the firmware not assigning I/O space to the chips behind the bridge on multiport cards (ANA-62044 here). The driver tries to assign I/O and reaches useless space in memory when reading the MAC address. Another problem is the statistics showing kind of difference to the moon in inches or so. >How-To-Repeat: Just boot FreeBSD-4.9 GENERIC kernel with an ANA-62044 (or other StarFire-based card) on a PC164 >Fix: diff -Naru sys.orig/pci/if_sf.c sys/pci/if_sf.c --- sys.orig/pci/if_sf.c Sun Dec 16 16:46:07 2001 +++ sys/pci/if_sf.c Sat Jul 3 08:24:26 2004 @@ -114,7 +114,12 @@ #include #include +/* don't use I/O space on alpha. memory mapped I/O performs better (and also * + * works behind bridges, like those found on multiport cards. mkukat 20040703 */ + +#ifndef __alpha__ #define SF_USEIOSPACE +#endif #include @@ -1178,7 +1183,7 @@ /* Empty stats counter registers. */ for (i = 0; i < sizeof(struct sf_stats)/sizeof(u_int32_t); i++) csr_write_4(sc, SF_STATS_BASE + - (i + sizeof(u_int32_t)), 0); + (i * sizeof(u_int32_t)), 0); /* Init our MAC address */ csr_write_4(sc, SF_PAR0, *(u_int32_t *)(&sc->arpcom.ac_enaddr[0])); @@ -1473,11 +1478,11 @@ ptr = (u_int32_t *)&stats; for (i = 0; i < sizeof(stats)/sizeof(u_int32_t); i++) ptr[i] = csr_read_4(sc, SF_STATS_BASE + - (i + sizeof(u_int32_t))); + (i * sizeof(u_int32_t))); for (i = 0; i < sizeof(stats)/sizeof(u_int32_t); i++) csr_write_4(sc, SF_STATS_BASE + - (i + sizeof(u_int32_t)), 0); + (i * sizeof(u_int32_t)), 0); ifp->if_collisions += stats.sf_tx_single_colls + stats.sf_tx_multi_colls + stats.sf_tx_excess_colls; This fix is for 4.9, but the changes should also be included in the current CVS, as i looked into cvsweb and found those old bugs still being there. Fixes: statistics tables are now correctly initialized, no unaligned access, no unintialized areas which lead to strange values (the counter was collisions in netstat -ni, which looked very strange) on alpha, never use I/O space, as alpha generally works with memory mapped I/O, and this is the only thing working clean behind bridges there. Reading the comments about the StarFire chip, memory mapped I/O should also improve performance due to just needing one access cycle instead of 2 (set address and read/write value). >Release-Note: >Audit-Trail: >Unformatted: