Date: Sat, 3 Jul 2004 09:14:17 GMT From: Michael Kukat <michael@unixiron.org> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/68623: sf(4) (Adaptec StarFire) multiple problems on alpha and maybe other platforms Message-ID: <200407030914.i639EHFj089791@www.freebsd.org> Resent-Message-ID: <200407030920.i639KOH9022404@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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 <pci/pcireg.h>
#include <pci/pcivar.h>
+/* 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 <pci/if_sfreg.h>
@@ -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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407030914.i639EHFj089791>