NetBSD Problem Report #35531
From root@garbled.net Wed Jan 31 18:44:34 2007
Return-Path: <root@garbled.net>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id C1EFC63B938
for <gnats-bugs@gnats.NetBSD.org>; Wed, 31 Jan 2007 18:44:33 +0000 (UTC)
Message-Id: <20070131184443.1487B2AC99@polaris.garbled.net>
Date: Wed, 31 Jan 2007 11:44:43 -0700 (MST)
From: root@garbled.net
Reply-To: root@garbled.net
To: gnats-bugs@NetBSD.org
Subject: iee0 does not work on 735/99
X-Send-Pr-Version: 3.95
>Number: 35531
>Category: port-hp700
>Synopsis: iee0 does not work on 735/99
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: tsutsui
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Jan 31 18:45:00 +0000 2007
>Closed-Date: Mon May 03 03:24:23 +0000 2010
>Last-Modified: Mon May 03 03:24:23 +0000 2010
>Originator: Tim Rightnour
>Release: NetBSD 4.0_BETA2
>Organization:
>Environment:
System: NetBSD polaris.garbled.net 3.0 NetBSD 3.0 (GENERIC) #0: Mon Dec 19 01:04:02 UTC 2005 builds@works.netbsd.org:/home/builds/ab/netbsd-3-0-RELEASE/i386/200512182024Z-obj/home/builds/ab/netbsd-3-0-RELEASE/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
The iee0 driver hangs hard when attempting to bring up the interface. I have
tried both manual and autoselect media modes.
HP9000/735/99 (Hardball)
real mem = 240 MB (73728 reserved for PROM, 216 MB used by NetBSD)
avail mem = 212 MB
gsc0 at asp0: wordleds
asp0 at mainbus0 hpa 0xf0000000 path 2 irq 28: Hardball rev 20, lan 1 scsi 7
iee0 at gsc0 hpa 0xf0826000 path 2/0/2 irq 8 ipl 2: Intel 82596DX/SX address 08:00:09:48:88:79
>How-To-Repeat:
# ifconfig -a
iee0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
address: 08:00:09:48:88:79
media: Ethernet autoselect
lo0: flags=8048<LOOPBACK,RUNNING,MULTICAST> mtu 33192
# ifconfig -m iee0
iee0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
address: 08:00:09:48:88:79
media: Ethernet autoselect
supported Ethernet media:
media manual
media autoselect
# ifconfig iee0 media manual
# ifconfig -a
iee0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
address: 08:00:09:48:88:79
media: Ethernet manual
lo0: flags=8048<LOOPBACK,RUNNING,MULTICAST> mtu 33192
# ifconfig iee0 inet 192.168.10.26
*HANG*
>Fix:
supposedly disabling iee0 in the kernel config.
>Release-Note:
>Audit-Trail:
From: Nick Hudson <skrll@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: PR/35531 CVS commit: src/sys/arch/hp700
Date: Thu, 1 Feb 2007 21:09:42 +0000 (UTC)
Module Name: src
Committed By: skrll
Date: Thu Feb 1 21:09:42 UTC 2007
Modified Files:
src/sys/arch/hp700/conf: GENERIC
src/sys/arch/hp700/gsc: if_iee_gsc.c
Log Message:
Workaround PR/35531 by preventing iee(4) from matching the 82596DX/SX
chip variant and adding ie(4) to the kernel to match it - ie(4) works.
To generate a diff of this commit:
cvs rdiff -r1.72 -r1.73 src/sys/arch/hp700/conf/GENERIC
cvs rdiff -r1.2 -r1.3 src/sys/arch/hp700/gsc/if_iee_gsc.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: PR/35531 CVS commit: [netbsd-4] src/sys/arch/hp700
Date: Fri, 9 Feb 2007 22:23:51 +0000 (UTC)
Module Name: src
Committed By: tron
Date: Fri Feb 9 22:23:51 UTC 2007
Modified Files:
src/sys/arch/hp700/conf [netbsd-4]: GENERIC
src/sys/arch/hp700/gsc [netbsd-4]: if_iee_gsc.c
Log Message:
Pull up following revision(s) (requested by skrll in ticket #404):
sys/arch/hp700/conf/GENERIC: revision 1.73
sys/arch/hp700/gsc/if_iee_gsc.c: revision 1.3
Workaround PR/35531 by preventing iee(4) from matching the 82596DX/SX
chip variant and adding ie(4) to the kernel to match it - ie(4) works.
To generate a diff of this commit:
cvs rdiff -r1.72 -r1.72.2.1 src/sys/arch/hp700/conf/GENERIC
cvs rdiff -r1.2 -r1.2.24.1 src/sys/arch/hp700/gsc/if_iee_gsc.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Nick Hudson <nick.hudson@dsl.pipex.com>
To: gnats-bugs@netbsd.org
Cc: port-hp700-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Thu, 16 Aug 2007 09:07:18 +0100
On Wednesday 31 January 2007 18:45, root@garbled.net wrote:
> >Synopsis: iee0 does not work on 735/99
Can you get the markings on the chip? iee(4) is written with the assumption
it's dealing with a C step chip. I suspect earlier machines have earlier chip
revisions.
For example, my 715/50 has a chip with
KU82596DX-33
SZ522
L2528254
Intel (m)(c)'89
which doesn't work with iee(4) as I believe it's a B step chip.
Thanks,
Nick
State-Changed-From-To: open->feedback
State-Changed-By: skrll@netbsd.org
State-Changed-When: Sat, 01 Sep 2007 08:25:48 +0000
State-Changed-Why:
A request for information has been sent.
From: Tim Rightnour <root@garbled.net>
To: gnats-bugs@NetBSD.org
Cc: netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
port-hp700-maintainer@netbsd.org
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Thu, 13 Sep 2007 11:02:41 -0700 (MST)
On 16-Aug-2007 Nick Hudson wrote:
> Can you get the markings on the chip? iee(4) is written with the assumption
> it's dealing with a C step chip. I suspect earlier machines have earlier
> chip
> revisions.
KU82596DX-33
SZ522
L3023941
INTEL '89
---
Tim Rightnour <root@garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/
State-Changed-From-To: feedback->analyzed
State-Changed-By: skrll@netbsd.org
State-Changed-When: Tue, 20 Nov 2007 07:51:17 +0000
State-Changed-Why:
I believe this is because the driver programs the chip as a
rev C device where the chips in earlier models where rev.B
(or earlier)
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: skrll@NetBSD.org, port-hp700-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Sun, 3 May 2009 19:33:36 +0900
>> I believe this is because the driver programs the chip as a
>> rev C device where the chips in earlier models where rev.B
>> (or earlier)
The major difference between Step-A and B/C is 32 bit big endian mode
enabled by IEE_SYSBUS_BE bit. On rev A chip, we have to treats
all 32 bit pointers in DMA descriptors as two 16-bit big endian entities
as well as the SCP pointer.
My 735/125 seems to have Rev C chip as the following:
KU82596DX-33
L4502047
SZ715 C
INTEL(M)(C)1989
but now it also works in Rev A compatible mode (i.e. without IEE_SYSBUS_BE)
with the attached patch, so it should also work on Rev A chips.
As noted in comments, it might be better to detect chip revision
and switch flags at runtime, but I can't find how we ca do it
in the Intel manual.
---
Index: dev/ic/i82596.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/i82596.c,v
retrieving revision 1.19
diff -u -r1.19 i82596.c
--- dev/ic/i82596.c 4 Apr 2008 17:03:42 -0000 1.19
+++ dev/ic/i82596.c 3 May 2009 07:48:53 -0000
@@ -256,7 +256,7 @@
sc->sc_rx_mbuf[sc->sc_rx_done] = new_mbuf;
rbd->rbd_count = 0;
rbd->rbd_size = IEE_RBD_EL | rx_map->dm_segs[0].ds_len;
- rbd->rbd_rb_addr = rx_map->dm_segs[0].ds_addr;
+ rbd->rbd_rb_addr = IEE_SWAPA32(rx_map->dm_segs[0].ds_addr);
sc->sc_rx_done = (sc->sc_rx_done + 1) % IEE_NRFD;
rfd = SC_RFD(sc->sc_rx_done);
}
@@ -266,16 +266,19 @@
/* Receive Overrun, reinit receive ring buffer. */
for (n = 0 ; n < IEE_NRFD ; n++) {
SC_RFD(n)->rfd_cmd = IEE_RFD_SF;
- SC_RFD(n)->rfd_link_addr = IEE_PHYS_SHMEM(IEE_RFD_OFF
- + IEE_RFD_SZ * ((n + 1) % IEE_NRFD));
- SC_RBD(n)->rbd_next_rbd = IEE_PHYS_SHMEM(IEE_RBD_OFF
- + IEE_RBD_SZ * ((n + 1) % IEE_NRFD));
+ SC_RFD(n)->rfd_link_addr =
+ IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_RFD_OFF
+ + IEE_RFD_SZ * ((n + 1) % IEE_NRFD)));
+ SC_RBD(n)->rbd_next_rbd =
+ IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_RBD_OFF
+ + IEE_RBD_SZ * ((n + 1) % IEE_NRFD)));
SC_RBD(n)->rbd_size = IEE_RBD_EL |
sc->sc_rx_map[n]->dm_segs[0].ds_len;
SC_RBD(n)->rbd_rb_addr =
- sc->sc_rx_map[n]->dm_segs[0].ds_addr;
+ IEE_SWAPA32(sc->sc_rx_map[n]->dm_segs[0].ds_addr);
}
- SC_RFD(0)->rfd_rbd_addr = IEE_PHYS_SHMEM(IEE_RBD_OFF);
+ SC_RFD(0)->rfd_rbd_addr =
+ IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_RBD_OFF));
sc->sc_rx_done = 0;
bus_dmamap_sync(sc->sc_dmat, sc->sc_shmem_map, IEE_RFD_OFF,
IEE_RFD_LIST_SZ + IEE_RBD_LIST_SZ, BUS_DMASYNC_PREWRITE);
@@ -330,33 +333,33 @@
/* Try to get deferred packets going. */
iee_start(ifp);
}
- if (IEE_SWAP(SC_SCB->scb_crc_err) != sc->sc_crc_err) {
- sc->sc_crc_err = IEE_SWAP(SC_SCB->scb_crc_err);
+ if (IEE_SWAP32(SC_SCB->scb_crc_err) != sc->sc_crc_err) {
+ sc->sc_crc_err = IEE_SWAP32(SC_SCB->scb_crc_err);
printf("%s: iee_intr: crc_err=%d\n", device_xname(sc->sc_dev),
sc->sc_crc_err);
}
- if (IEE_SWAP(SC_SCB->scb_align_err) != sc->sc_align_err) {
- sc->sc_align_err = IEE_SWAP(SC_SCB->scb_align_err);
+ if (IEE_SWAP32(SC_SCB->scb_align_err) != sc->sc_align_err) {
+ sc->sc_align_err = IEE_SWAP32(SC_SCB->scb_align_err);
printf("%s: iee_intr: align_err=%d\n", device_xname(sc->sc_dev),
sc->sc_align_err);
}
- if (IEE_SWAP(SC_SCB->scb_resource_err) != sc->sc_resource_err) {
- sc->sc_resource_err = IEE_SWAP(SC_SCB->scb_resource_err);
+ if (IEE_SWAP32(SC_SCB->scb_resource_err) != sc->sc_resource_err) {
+ sc->sc_resource_err = IEE_SWAP32(SC_SCB->scb_resource_err);
printf("%s: iee_intr: resource_err=%d\n",
device_xname(sc->sc_dev), sc->sc_resource_err);
}
- if (IEE_SWAP(SC_SCB->scb_overrun_err) != sc->sc_overrun_err) {
- sc->sc_overrun_err = IEE_SWAP(SC_SCB->scb_overrun_err);
+ if (IEE_SWAP32(SC_SCB->scb_overrun_err) != sc->sc_overrun_err) {
+ sc->sc_overrun_err = IEE_SWAP32(SC_SCB->scb_overrun_err);
printf("%s: iee_intr: overrun_err=%d\n",
device_xname(sc->sc_dev), sc->sc_overrun_err);
}
- if (IEE_SWAP(SC_SCB->scb_rcvcdt_err) != sc->sc_rcvcdt_err) {
- sc->sc_rcvcdt_err = IEE_SWAP(SC_SCB->scb_rcvcdt_err);
+ if (IEE_SWAP32(SC_SCB->scb_rcvcdt_err) != sc->sc_rcvcdt_err) {
+ sc->sc_rcvcdt_err = IEE_SWAP32(SC_SCB->scb_rcvcdt_err);
printf("%s: iee_intr: rcvcdt_err=%d\n",
device_xname(sc->sc_dev), sc->sc_rcvcdt_err);
}
- if (IEE_SWAP(SC_SCB->scb_short_fr_err) != sc->sc_short_fr_err) {
- sc->sc_short_fr_err = IEE_SWAP(SC_SCB->scb_short_fr_err);
+ if (IEE_SWAP32(SC_SCB->scb_short_fr_err) != sc->sc_short_fr_err) {
+ sc->sc_short_fr_err = IEE_SWAP32(SC_SCB->scb_short_fr_err);
printf("%s: iee_intr: short_fr_err=%d\n",
device_xname(sc->sc_dev), sc->sc_short_fr_err);
}
@@ -476,8 +479,9 @@
iee_cb_setup(sc, IEE_CB_CMD_CONF);
break;
case IEE_CB_CMD_TR: /* Transmit */
- cb->cb_transmit.tx_tbd_addr = IEE_PHYS_SHMEM(IEE_TBD_OFF
- + IEE_TBD_SZ * sc->sc_next_tbd);
+ cb->cb_transmit.tx_tbd_addr =
+ IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_TBD_OFF
+ + IEE_TBD_SZ * sc->sc_next_tbd));
cb->cb_cmd |= IEE_CB_SF; /* Always use Flexible Mode. */
break;
case IEE_CB_CMD_TDR: /* Time Domain Reflectometry */
@@ -490,8 +494,8 @@
/* can't happen */
break;
}
- cb->cb_link_addr = IEE_PHYS_SHMEM(IEE_CB_OFF + IEE_CB_SZ *
- (sc->sc_next_cb + 1));
+ cb->cb_link_addr = IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_CB_OFF + IEE_CB_SZ *
+ (sc->sc_next_cb + 1)));
bus_dmamap_sync(sc->sc_dmat, sc->sc_shmem_map, IEE_CB_OFF
+ IEE_CB_SZ * sc->sc_next_cb, IEE_CB_SZ, BUS_DMASYNC_PREWRITE);
sc->sc_next_cb++;
@@ -510,14 +514,14 @@
/* Set pointer to Intermediate System Configuration Pointer. */
/* Phys. addr. in big endian order. (Big endian as defined by Intel.) */
- SC_SCP->scp_iscp_addr = IEE_SWAP(IEE_PHYS_SHMEM(IEE_ISCP_OFF));
+ SC_SCP->scp_iscp_addr = IEE_SWAP32(IEE_PHYS_SHMEM(IEE_ISCP_OFF));
/* Set pointer to System Control Block. */
/* Phys. addr. in big endian order. (Big endian as defined by Intel.) */
- SC_ISCP->iscp_scb_addr = IEE_SWAP(IEE_PHYS_SHMEM(IEE_SCB_OFF));
+ SC_ISCP->iscp_scb_addr = IEE_SWAP32(IEE_PHYS_SHMEM(IEE_SCB_OFF));
/* Set pointer to Receive Frame Area. (physical address) */
- SC_SCB->scb_rfa_addr = IEE_PHYS_SHMEM(IEE_RFD_OFF);
+ SC_SCB->scb_rfa_addr = IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_RFD_OFF));
/* Set pointer to Command Block. (physical address) */
- SC_SCB->scb_cmd_blk_addr = IEE_PHYS_SHMEM(IEE_CB_OFF);
+ SC_SCB->scb_cmd_blk_addr = IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_CB_OFF));
ifmedia_init(&sc->sc_ifmedia, 0, iee_mediachange, iee_mediastatus);
if (media != NULL) {
@@ -656,12 +660,12 @@
}
for (n = 0 ; n < sc->sc_tx_map[t]->dm_nsegs ; n++) {
SC_TBD(sc->sc_next_tbd + n)->tbd_tb_addr =
- sc->sc_tx_map[t]->dm_segs[n].ds_addr;
+ IEE_SWAPA32(sc->sc_tx_map[t]->dm_segs[n].ds_addr);
SC_TBD(sc->sc_next_tbd + n)->tbd_size =
sc->sc_tx_map[t]->dm_segs[n].ds_len;
SC_TBD(sc->sc_next_tbd + n)->tbd_link_addr =
- IEE_PHYS_SHMEM(IEE_TBD_OFF + IEE_TBD_SZ
- * (sc->sc_next_tbd + n + 1));
+ IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_TBD_OFF + IEE_TBD_SZ
+ * (sc->sc_next_tbd + n + 1)));
}
SC_TBD(sc->sc_next_tbd + n - 1)->tbd_size |= IEE_CB_EL;
bus_dmamap_sync(sc->sc_dmat, sc->sc_tx_map[t], 0,
@@ -778,11 +782,13 @@
memset(SC_RBD(0), 0, IEE_RBD_LIST_SZ);
for (r = 0 ; r < IEE_NRFD ; r++) {
SC_RFD(r)->rfd_cmd = IEE_RFD_SF;
- SC_RFD(r)->rfd_link_addr = IEE_PHYS_SHMEM(IEE_RFD_OFF
- + IEE_RFD_SZ * ((r + 1) % IEE_NRFD));
-
- SC_RBD(r)->rbd_next_rbd = IEE_PHYS_SHMEM(IEE_RBD_OFF
- + IEE_RBD_SZ * ((r + 1) % IEE_NRFD));
+ SC_RFD(r)->rfd_link_addr =
+ IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_RFD_OFF
+ + IEE_RFD_SZ * ((r + 1) % IEE_NRFD)));
+
+ SC_RBD(r)->rbd_next_rbd =
+ IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_RBD_OFF
+ + IEE_RBD_SZ * ((r + 1) % IEE_NRFD)));
if (sc->sc_rx_mbuf[r] == NULL) {
MGETHDR(sc->sc_rx_mbuf[r], M_DONTWAIT, MT_DATA);
if (sc->sc_rx_mbuf[r] == NULL) {
@@ -824,9 +830,10 @@
bus_dmamap_sync(sc->sc_dmat, sc->sc_rx_map[r], 0,
sc->sc_rx_mbuf[r]->m_ext.ext_size, BUS_DMASYNC_PREREAD);
SC_RBD(r)->rbd_size = sc->sc_rx_map[r]->dm_segs[0].ds_len;
- SC_RBD(r)->rbd_rb_addr= sc->sc_rx_map[r]->dm_segs[0].ds_addr;
+ SC_RBD(r)->rbd_rb_addr =
+ IEE_SWAPA32(sc->sc_rx_map[r]->dm_segs[0].ds_addr);
}
- SC_RFD(0)->rfd_rbd_addr = IEE_PHYS_SHMEM(IEE_RBD_OFF);
+ SC_RFD(0)->rfd_rbd_addr = IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_RBD_OFF));
if (err != 0) {
for (n = 0 ; n < r; n++) {
m_freem(sc->sc_rx_mbuf[n]);
@@ -860,7 +867,7 @@
sc->sc_cf[12] = IEE_CF_12_DEF;
sc->sc_cf[13] = IEE_CF_13_DEF;
iee_cb_setup(sc, IEE_CB_CMD_CONF | IEE_CB_S | IEE_CB_EL);
- SC_SCB->scb_rfa_addr = IEE_PHYS_SHMEM(IEE_RFD_OFF);
+ SC_SCB->scb_rfa_addr = IEE_SWAPA32(IEE_PHYS_SHMEM(IEE_RFD_OFF));
bus_dmamap_sync(sc->sc_dmat, sc->sc_shmem_map, 0, IEE_SHMEM_MAX,
BUS_DMASYNC_PREWRITE);
(sc->sc_iee_cmd)(sc, IEE_SCB_CUC_EXE | IEE_SCB_RUC_ST);
Index: dev/ic/i82596var.h
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/i82596var.h,v
retrieving revision 1.10
diff -u -r1.10 i82596var.h
--- dev/ic/i82596var.h 4 Apr 2008 17:03:42 -0000 1.10
+++ dev/ic/i82596var.h 3 May 2009 07:48:53 -0000
@@ -189,10 +189,23 @@
/* Flags */
#define IEE_NEED_SWAP 0x01
-#define IEE_WANT_MCAST 0x02
+#define IEE_WANT_MCAST 0x02
+#define IEE_REV_A 0x04
-#define IEE_SWAP(x) ((sc->sc_flags & IEE_NEED_SWAP) == 0 ? x : \
- (((x) << 16) | ((x) >> 16)))
+/*
+ * Rev A1 chip doesn't have 32-bit BE mode and all 32 bit pointers are
+ * treated as two 16-bit big endian entities.
+ */
+#define IEE_SWAPA32(x) ((sc->sc_flags & (IEE_NEED_SWAP|IEE_REV_A)) == \
+ (IEE_NEED_SWAP|IEE_REV_A) ? \
+ (((x) << 16) | ((x) >> 16)) : (x))
+/*
+ * The SCB absolute address and statistical counters are
+ * always treated as two 16-bit big endian entities
+ * even in 32-bit BE mode supported by Rev B and C chips.
+ */
+#define IEE_SWAP32(x) ((sc->sc_flags & IEE_NEED_SWAP) != 0 ? \
+ (((x) << 16) | ((x) >> 16)) : (x))
#define IEE_PHYS_SHMEM(x) ((uint32_t) (sc->sc_shmem_map->dm_segs[0].ds_addr \
+ (x)))
Index: arch/hp700/gsc/if_iee_gsc.c
===================================================================
RCS file: /cvsroot/src/sys/arch/hp700/gsc/if_iee_gsc.c,v
retrieving revision 1.7
diff -u -r1.7 if_iee_gsc.c
--- arch/hp700/gsc/if_iee_gsc.c 4 Apr 2008 17:03:42 -0000 1.7
+++ arch/hp700/gsc/if_iee_gsc.c 3 May 2009 07:48:53 -0000
@@ -194,7 +194,8 @@
struct gsc_attach_args *ga = aux;
if (ga->ga_type.iodc_type == HPPA_TYPE_FIO
- && ga->ga_type.iodc_sv_model == HPPA_FIO_GLAN)
+ && (ga->ga_type.iodc_sv_model == HPPA_FIO_LAN
+ || ga->ga_type.iodc_sv_model == HPPA_FIO_GLAN))
/* beat old ie(4) i82586 driver */
return 10;
return 0;
@@ -216,7 +217,6 @@
sc->sc_type = I82596_DX; /* ASP(2) based */
else
sc->sc_type = I82596_CA; /* LASI based */
- sc->sc_flags = IEE_NEED_SWAP;
/*
* Pre PA7100LC CPUs don't support uncacheable mappings. So make
* descriptors align to cache lines. Needed to avoid race conditions
@@ -266,8 +266,24 @@
memset(sc->sc_shmem_addr, 0, IEE_SHMEM_MAX);
/* Setup SYSBUS byte. */
- SC_SCP->scp_sysbus = IEE_SYSBUS_BE | IEE_SYSBUS_INT |
- IEE_SYSBUS_TRG | IEE_SYSBUS_LIEAR | IEE_SYSBUS_STD;
+ if (ga->ga_type.iodc_sv_model == HPPA_FIO_LAN) {
+ /*
+ * Some earlier machines have 82596DX Rev A1 chip
+ * which doesn't have IEE_SYSBUS_BE for 32-bit BE pointers.
+ *
+ * XXX: How can we detect chip revision at runtime?
+ * Should we check cpu_models instead?
+ * 715/50, 735/99: Rev A1? (per PR port-hp700/35531)
+ * 735/125: Rev C
+ */
+ SC_SCP->scp_sysbus = IEE_SYSBUS_INT |
+ IEE_SYSBUS_TRG | IEE_SYSBUS_LIEAR | IEE_SYSBUS_STD;
+ sc->sc_flags = IEE_NEED_SWAP | IEE_REV_A;
+ } else {
+ SC_SCP->scp_sysbus = IEE_SYSBUS_BE | IEE_SYSBUS_INT |
+ IEE_SYSBUS_TRG | IEE_SYSBUS_LIEAR | IEE_SYSBUS_STD;
+ sc->sc_flags = IEE_NEED_SWAP;
+ }
sc_gsc->sc_ih = hp700_intr_establish(self, IPL_NET,
iee_intr, sc, ga->ga_int_reg, ga->ga_irq);
---
Izumi Tsutsui
Responsible-Changed-From-To: port-hp700-maintainer->tsutsui
Responsible-Changed-By: tsutsui@NetBSD.org
Responsible-Changed-When: Mon, 04 May 2009 00:41:14 +0900
Responsible-Changed-Why:
I'll take a look.
State-Changed-From-To: analyzed->feedback
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Mon, 04 May 2009 00:41:14 +0900
State-Changed-Why:
patch provided.
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@netbsd.org
Cc: port-hp700-maintainer@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
root@garbled.net
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Mon, 4 May 2009 17:52:40 +0100
On Sunday 03 May 2009 11:35:03 Izumi Tsutsui wrote:
> The major difference between Step-A and B/C is 32 bit big endian mode
> enabled by IEE_SYSBUS_BE bit. On rev A chip, we have to treats
> all 32 bit pointers in DMA descriptors as two 16-bit big endian entities
> as well as the SCP pointer.
>
> My 735/125 seems to have Rev C chip as the following:
>
> KU82596DX-33
> L4502047
> SZ715 C
> INTEL(M)(C)1989
>
> but now it also works in Rev A compatible mode (i.e. without
> IEE_SYSBUS_BE) with the attached patch, so it should also work on Rev A
> chips.
This is cool! Thanks for working on this.
I've tested this on my 715/50 against netbsd-5 as I've got too many changes in
my -current source trees :)
> As noted in comments, it might be better to detect chip revision
> and switch flags at runtime, but I can't find how we ca do it
> in the Intel manual.
Is it worth running IEE_SYSBUS_BE at all? Is there a big performance impact on
the machines with rev C chips? If there isn't a big hit I'd say we just use
iee(4) without IEE_SYSBUS_BE on hppa.
> ---
> Izumi Tsutsui
Thanks,
Nick
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: nick.hudson@gmx.co.uk
Cc: gnats-bugs@NetBSD.org, port-hp700-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, root@garbled.net,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Tue, 5 May 2009 02:37:09 +0900
nick.hudson@gmx.co.uk wrote:
> I've tested this on my 715/50 against netbsd-5 as I've got too many changes in
> my -current source trees :)
The same patch can be applied to -current too ;-)
> > As noted in comments, it might be better to detect chip revision
> > and switch flags at runtime, but I can't find how we ca do it
> > in the Intel manual.
>
> Is it worth running IEE_SYSBUS_BE at all? Is there a big performance impact on
> the machines with rev C chips? If there isn't a big hit I'd say we just use
> iee(4) without IEE_SYSBUS_BE on hppa.
The manual says "no software byteswap code is required on
the enhanched BE mode" so the only difference is
"(((x) << 16) | ((x) >> 16))" ops around 32 bit pointers,
but I don't think they are so expensive.
I'll commit the patch after some more tests.
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: nick.hudson@gmx.co.uk
Cc: gnats-bugs@NetBSD.org, port-hp700-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, root@garbled.net,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Tue, 5 May 2009 21:26:42 +0900
I wrote:
> nick.hudson@gmx.co.uk wrote:
> > I've tested this on my 715/50 against netbsd-5 as I've got too many changes in
> > my -current source trees :)
>
> The same patch can be applied to -current too ;-)
Umm, on -current iee(4) even without my patch gets
timeouts and errors on heavy load:
---
iee0: iee_watchdog: transmit timeout 22
:
iee0: iee_intr: receive error 1, rfd_status=0x0000, rfd_count=0x0000
:
---
Could newer pmap require more strict bus_dmamap_sync(9) calls
in MI drivers? IIRC hppa doesn't have BUS_DMA_COHERENT support.
(I don't know if it will work on other newer machines like 712)
I'll commit MI i82596 changes anyway, but should we still disable
iee(4) on its hp700 attachment, and enable it only in netbsd-5 branch?
(though ie(4) also gets timeouts even on netbsd-5...)
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/35531 CVS commit: src/sys/dev/ic
Date: Tue, 5 May 2009 15:47:35 +0000
Module Name: src
Committed By: tsutsui
Date: Tue May 5 15:47:35 UTC 2009
Modified Files:
src/sys/dev/ic: i82596.c i82596var.h
Log Message:
Add support for i82596 Rev A chip which doesn't have the enhanced 32 bit
big endian mode:
- add IEE_REV_A flag to indicate if chip support the 32 bit BE mode or not
- add IEE_SWAPA32() macro and use it on necessary 32 bit DMA pointers
- rename IEE_SWAP() macro for the SCP address pointer and statistics
counters which require word swap even on Rev B/C chips to IEE_SWAP32()
for clarification
- add comments about these BE mode quirks
Tested on HP9000 735/125 by me and also tested on 715/50 by skrll@
with netbsd-5 branch, and fixes MI part of PR port-hp700/35531.
To generate a diff of this commit:
cvs rdiff -u -r1.19 -r1.20 src/sys/dev/ic/i82596.c
cvs rdiff -u -r1.10 -r1.11 src/sys/dev/ic/i82596var.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@netbsd.org,
port-hp700-maintainer@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
root@garbled.net
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Tue, 5 May 2009 19:15:01 +0100
On Tuesday 05 May 2009 13:26:42 Izumi Tsutsui wrote:
> I wrote:
> > nick.hudson@gmx.co.uk wrote:
> > > I've tested this on my 715/50 against netbsd-5 as I've got too many
> > > changes in my -current source trees :)
> >
> > The same patch can be applied to -current too ;-)
yep :)
> Umm, on -current iee(4) even without my patch gets
> timeouts and errors on heavy load:
> ---
> iee0: iee_watchdog: transmit timeout 22
>
> iee0: iee_intr: receive error 1, rfd_status=0x0000, rfd_count=0x0000
>
> ---
>
I've briefly tested by scp'ing a kernel to a hp715/50
notsonoisy# dmesg | grep iee
iee0 at gsc0 hpa 0xf0826000 path 2/0/2 irq 8 ipl 2: Intel 82596DX/SX address
08:00:09:49:03:40
and a hp715/64
hp715-64# dmesg | grep iee
iee0 at gsc0 hpa 0xf0107000 path 2/0/2 irq 8 ipl 2: Intel 82596CA address
08:00:09:5f:d2:58
and neither prints the watchdog message.
> Could newer pmap require more strict bus_dmamap_sync(9) calls
> in MI drivers? IIRC hppa doesn't have BUS_DMA_COHERENT support.
> (I don't know if it will work on other newer machines like 712)
All bus_dmamem_alloc memory is mapped uncacheable regardless of pmap, so I
don't think this is the problem.
> I'll commit MI i82596 changes anyway, but should we still disable
> iee(4) on its hp700 attachment, and enable it only in netbsd-5 branch?
> (though ie(4) also gets timeouts even on netbsd-5...)
I still think we go with iee(4) everywhere and kill ie(4).
> ---
> Izumi Tsutsui
Thanks,
Nick
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: nick.hudson@gmx.co.uk
Cc: gnats-bugs@NetBSD.org, port-hp700-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, root@garbled.net,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Wed, 6 May 2009 03:15:19 +0900
I wrote:
> I wrote:
> > nick.hudson@gmx.co.uk wrote:
> > > I've tested this on my 715/50 against netbsd-5 as I've got too many changes in
> > > my -current source trees :)
> >
> > The same patch can be applied to -current too ;-)
>
> Umm, on -current iee(4) even without my patch gets
> timeouts and errors on heavy load:
Okay, this is DMA-cache coherency problem. bus_dma(9) on hp700
doesn't support BUS_DMA_COHERENT even on any CPU, so we have to
always set proper cache line size to sc_cl_align for MI iee(4).
(probably it might be worth to have <machine/cache.h> like mips)
---
Index: if_iee_gsc.c
===================================================================
RCS file: /cvsroot/src/sys/arch/hp700/gsc/if_iee_gsc.c,v
retrieving revision 1.8
diff -u -r1.8 if_iee_gsc.c
--- if_iee_gsc.c 30 Apr 2009 07:01:26 -0000 1.8
+++ if_iee_gsc.c 5 May 2009 18:10:11 -0000
@@ -206,9 +206,9 @@
struct iee_gsc_softc *sc_gsc = device_private(self);
struct iee_softc *sc = &sc_gsc->iee_sc;
struct gsc_attach_args *ga = aux;
- enum hppa_cpu_type cpu_type;
int media[2];
int rsegs;
+ extern int dcache_stride; /* XXX: in hp700/machdep.c */
sc->sc_dev = self;
@@ -221,12 +221,11 @@
* Pre PA7100LC CPUs don't support uncacheable mappings. So make
* descriptors align to cache lines. Needed to avoid race conditions
* caused by flushing cache lines that overlap multiple descriptors.
+ *
+ * XXX: MD bus_dma(9) on hp700 doesn't support BUS_DMA_COHERENT at all,
+ * so use dcache_stride on all CPUs for now.
*/
- cpu_type = hppa_cpu_info->hci_type;
- if (cpu_type == hpcx || cpu_type == hpcxs || cpu_type == hpcxt)
- sc->sc_cl_align = 32;
- else
- sc->sc_cl_align = 1;
+ sc->sc_cl_align = dcache_stride;
sc_gsc->sc_iot = ga->ga_iot;
if (bus_space_map(sc_gsc->sc_iot, ga->ga_hpa, IEE_GSC_IO_SZ, 0,
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: nick.hudson@gmx.co.uk
Cc: gnats-bugs@NetBSD.org, port-hp700-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, root@garbled.net,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Wed, 6 May 2009 03:29:56 +0900
> All bus_dmamem_alloc memory is mapped uncacheable regardless of pmap, so I
> don't think this is the problem.
Hmm, newer HPPA CPUs actually support uncacheable mappings?
BTW, my 735/125 have the following CPU:
---
cpu0 at mainbus0 hpa 0xfffbe000 path 8 irq 31 ipl 0: PA7150 (T-Bird) rev 2
cpu0: PCX-T, PA-RISC 1.1b, lev 1, cat A, 125 MHz clk
cpu0: shadows, 256K/256K D/I caches, 120 shared TLB, 16 shared BTLB
cpu0: PCX-T (Rolex - CMOS-26B) floating point, rev 1
---
but cpu_type returns 3 (hpcxl), not hpcxt. What's wrong?
---
Izumi Tsutsui
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@netbsd.org,
port-hp700-maintainer@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
root@garbled.net
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Tue, 5 May 2009 20:40:37 +0100
On Tuesday 05 May 2009 19:29:56 Izumi Tsutsui wrote:
> > All bus_dmamem_alloc memory is mapped uncacheable regardless of pmap, so
> > I don't think this is the problem.
>
> Hmm, newer HPPA CPUs actually support uncacheable mappings?
yeah, everything after PA-RISC 1.1b, iirc.
>
> BTW, my 735/125 have the following CPU:
> ---
> cpu0 at mainbus0 hpa 0xfffbe000 path 8 irq 31 ipl 0: PA7150 (T-Bird) rev 2
> cpu0: PCX-T, PA-RISC 1.1b, lev 1, cat A, 125 MHz clk
> cpu0: shadows, 256K/256K D/I caches, 120 shared TLB, 16 shared BTLB
> cpu0: PCX-T (Rolex - CMOS-26B) floating point, rev 1
> ---
> but cpu_type returns 3 (hpcxl), not hpcxt. What's wrong?
Something in sys/arch/hp700/hp700/machdep.c and/or sys/arch/hp700/dev/cpudevs?
>
> ---
> Izumi Tsutsui
Nick
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: nick.hudson@gmx.co.uk
Cc: gnats-bugs@NetBSD.org, port-hp700-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, root@garbled.net,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Wed, 6 May 2009 09:04:05 +0900
> > BTW, my 735/125 have the following CPU:
> > ---
> > cpu0 at mainbus0 hpa 0xfffbe000 path 8 irq 31 ipl 0: PA7150 (T-Bird) rev 2
> > cpu0: PCX-T, PA-RISC 1.1b, lev 1, cat A, 125 MHz clk
> > cpu0: shadows, 256K/256K D/I caches, 120 shared TLB, 16 shared BTLB
> > cpu0: PCX-T (Rolex - CMOS-26B) floating point, rev 1
> > ---
> > but cpu_type returns 3 (hpcxl), not hpcxt. What's wrong?
>
> Something in sys/arch/hp700/hp700/machdep.c and/or sys/arch/hp700/dev/cpudevs?
Ah, 5.0 says as above, but now -current says:
---
cpu0 at mainbus0 hpa 0xfffbe000 path 8 irq 31 ipl 0: PA7100LC (Hummingbird) rev 0
cpu0: PCXL, PA-RISC 1.1c, lev 1, cat A, 125 MHz clk
cpu0: shadows, 256K/256K D/I caches, 120 shared TLB, 16 shared BTLB
cpu0: PCXT (Rolex - CMOS-26B) floating point, rev 1
---
Which type is correct?
PCXL doesn't support uncached mapping, or wrong cpu_type?
---
Izumi Tsutsui
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@netbsd.org,
port-hp700-maintainer@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
root@garbled.net
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Wed, 6 May 2009 08:47:32 +0100
On Wednesday 06 May 2009 01:04:05 Izumi Tsutsui wrote:
> > > BTW, my 735/125 have the following CPU:
> > > ---
> > > cpu0 at mainbus0 hpa 0xfffbe000 path 8 irq 31 ipl 0: PA7150 (T-Bird)
> > > rev 2 cpu0: PCX-T, PA-RISC 1.1b, lev 1, cat A, 125 MHz clk
> > > cpu0: shadows, 256K/256K D/I caches, 120 shared TLB, 16 shared BTLB
> > > cpu0: PCX-T (Rolex - CMOS-26B) floating point, rev 1
> > > ---
> > > but cpu_type returns 3 (hpcxl), not hpcxt. What's wrong?
> >
> > Something in sys/arch/hp700/hp700/machdep.c and/or
> > sys/arch/hp700/dev/cpudevs?
>
> Ah, 5.0 says as above, but now -current says:
> ---
> cpu0 at mainbus0 hpa 0xfffbe000 path 8 irq 31 ipl 0: PA7100LC (Hummingbird)
> rev 0 cpu0: PCXL, PA-RISC 1.1c, lev 1, cat A, 125 MHz clk
> cpu0: shadows, 256K/256K D/I caches, 120 shared TLB, 16 shared BTLB
> cpu0: PCXT (Rolex - CMOS-26B) floating point, rev 1
> ---
> Which type is correct?
The 735 is a PCXT, PA-RISC 1.1b. Can you post DEBUG output of cpuid.version,
please?
> PCXL doesn't support uncached mapping, or wrong cpu_type?
Wrong cpu_type / cpu_version.
> ---
> Izumi Tsutsui
Thanks,
Nick
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
root@garbled.net, tsutsui@ceres.dti.ne.jp
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Wed, 6 May 2009 17:14:33 +0900
> The 735 is a PCXT, PA-RISC 1.1b. Can you post DEBUG output of cpuid.version,
> please?
Here it is (#define DEBUG in machdep.c):
---
7284172+110592+487424 [277280+265479]=0x916d0c
Start @ 0x200000 [1=0xa92000-0xb16d0c]...
PDC_CACHE_SETCS: 0, 0, 0, 0 (-2)
SPID bits: 0x0, error = -2
pdc_model.hvers 8288
cpuid: model 735/130 (Snake Cheetah)
WARNING: PDC_MODEL_CPUID error -2
pdc_coproc: 0xc0, 0xc0; model 9 rev 1
cpuid: bootstrap fpu
btlb info: minsz=128, maxsz=16384
btlb fixed: i=0, d=0, c=16
btlb varbl: i=0, d=0, c=0
hppa_btlb_size_min 0x80
hppa_btlb_size_max 0x4000
cpuid: pmap_hptsize 0x10000
hppa_init: PDC_CHASSIS
hppa_init: intr bootstrap
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
:
---
So we have to handle older machines (which don't return CPUIDs)
separately as 5.0 did with HPPA_TYPE_BOARD and pdc_model.hvers?
Or can we assume CPUID from fpu_model as PCXW kludge?
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: nick.hudson@gmx.co.uk
Cc: gnats-bugs@NetBSD.org, port-hp700-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, root@garbled.net,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-hp700/35531: iee0 does not work on 735/99
Date: Thu, 7 May 2009 21:40:31 +0900
> > PCXL doesn't support uncached mapping, or wrong cpu_type?
> Wrong cpu_type / cpu_version.
This is not iee(4) issue so I've filed a new PR for it.
(PR port-hp700/41379)
I'll commit MD part of my iee(4) fixes soon.
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/35531 CVS commit: src/sys/arch/hp700/gsc
Date: Thu, 7 May 2009 14:13:02 +0000
Module Name: src
Committed By: tsutsui
Date: Thu May 7 14:13:01 UTC 2009
Modified Files:
src/sys/arch/hp700/gsc: if_iee_gsc.c
Log Message:
Some earlier machines like 715/50 and 735/99 have the i82596DX Rev A chip
which doesn't support 32-bit big endian mode enabled by IEE_SYSBUS_BE bit,
so don't rely on the IEE_SYSBUS_BE mode on old HPPA_FIO_LAN models and
use IEE_REV_A quirk flag recently added into MI i82596.c.
Tested on HP9000 735/125 by me and also tested on 715/50 by skrll@
with netbsd-5 branch. Closes MD part of PR port-hp700/35531.
To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/sys/arch/hp700/gsc/if_iee_gsc.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 03 May 2010 03:24:23 +0000
State-Changed-Why:
From reading the PR contents it appears this is fixed. If it's not, please
reopen it.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home