NetBSD Problem Report #36628
From martin@duskware.de Wed Jul 11 07:48:20 2007
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id A447463B874
for <gnats-bugs@gnats.netbsd.org>; Wed, 11 Jul 2007 07:48:20 +0000 (UTC)
Message-Id: <20070711005136.41ECF63B874@narn.NetBSD.org>
Date: Wed, 11 Jul 2007 00:51:36 +0000 (UTC)
From: ChristophFranzen@gmx.net
Reply-To: ChristophFranzen@gmx.net
To: netbsd-bugs-owner@NetBSD.org
Subject: cdhdtape image panics with memory management trap on Jensen
X-Send-Pr-Version: www-1.0
>Number: 36628
>Category: port-alpha
>Synopsis: cdhdtape image panics with memory management trap on Jensen
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: thorpej
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Jul 11 07:50:01 +0000 2007
>Closed-Date: Sun Jul 25 21:48:18 +0000 2021
>Last-Modified: Sun Jul 25 21:48:18 +0000 2021
>Originator: Christoph Franzen
>Release: 4.0 Beta 2
>Organization:
>Environment:
Not available.
>Description:
Machine: DECpc 150 AXP / DEC200/300 ("Jensen")
The current Netbsd install images panic with trap 0x2 (memory management) immediately. At the following prompt you can just re-enter the SRM console.
In fact there is NO cdhdtape image at all which can boot on my Jensen machine, all releases panic at different stages for various reasons.
Examples:
Version 2.0: trap 0x4 (memory alignment)
Versions 1.6x: LPT Port issue (has apparently been fixed, but did not go into the official releases?)
Versions 1.5x: stops and hangs forever after recognizing the floppy drive
>How-To-Repeat:
Boot the cdhdtape image on Jensen.
>Fix:
>Release-Note:
>Audit-Trail:
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Wed, 11 Jul 2007 21:22:04 +0900
> Examples:
:
Please post whole dmesg, panic messages and "trace" output on ddb(4)
with 3.1 or 4.0_BETA2.
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: gnats-bugs@NetBSD.org
Cc: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>,
port-alpha-maintainer@netbsd.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Thu, 12 Jul 2007 02:26:07 +0200
Hello,
thank you for your quick answer.
> Please post whole dmesg, panic messages and "trace" output on ddb(4)
> with 3.1 or 4.0_BETA2. --- Izumi Tsutsui
The output captured from the serial console follows below; as you can
see, there is no "trace" output, and dmesg doesn't provide any
additional information.
====================================================
Alpha AXP System - ROM Version 1.7
Copyright (c) 1993 Digital Equipment Corporation.
Alpha AXP SRM Firmware Version - 32f
System conducting power up tests
------------------------------------------------------------
Devnam Devstat
-------- -------
CPU OK EV4 P3.0 6.6ns
MEM OK 32MB
NVR OK
SCC OK
IT OK
KBD OK
LPT OK
VGA OK
SCSI OK
------------------------------------------------------------
System power up OK.
83 BOOT SYS
INIT-S-CPU...
AUDIT_BOOT_STARTS ...
AUDIT_CHECKSUM_GOOD
AUDIT_LOAD_BEGINS
AUDIT_LOAD_DONE
NetBSD/alpha 4.0_BETA2 ustar Bootstrap, Revision 1.3
(builds@wb27, Mon Jul 9 21:26:10 PDT 2007)
VMS PAL rev: 0x100010530
OSF PAL rev: 0x20123
Switch to OSF PAL code succeeded.
Boot flags: A
9057040+177808=0x8cef20
Entering netbsd at 0xfffffc00003012e0...
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
2005, 2006
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights
reserved.
NetBSD 4.0_BETA2 (INSTALL) #0: Mon Jul 9 22:30:11 PDT 2007
builds@wb27:/home/builds/ab/netbsd-4/alpha/200707090002Z-
obj/home/builds/ab/netbsd-4/src/sys/arch/alpha/compile/INSTALL
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 21120 KB
mainbus0 (root)
CPU 0: fatal kernel trap:
CPU 0 trap entry = 0x2 (memory management fault)
CPU 0 a0 = 0x20
CPU 0 a1 = 0x1
CPU 0 a2 = 0x0
CPU 0 pc = 0xfffffc00005bb410
CPU 0 ra = 0xfffffc00005bb3d4
CPU 0 pv = 0xfffffc00005f02f0
CPU 0 curlwp = 0xfffffc0000bc32b0
CPU 0 pid = 0, comm = swapper
panic: trap
Stopped in pid 0.1 (swapper) at 0xfffffc00005d9ba0: ret
zero,(ra)
db> trace
db> dmesg
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
2005, 2006
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights
reserved.
NetBSD 4.0_BETA2 (INSTALL) #0: Mon Jul 9 22:30:11 PDT 2007
builds@wb27:/home/builds/ab/netbsd-4/alpha/200707090002Z-
obj/home/builds/ab/netbsd-4/src/sys/arch/alpha/compile/INSTALL
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 21120 KB
mainbus0 (root)
CPU 0: fatal kernel trap:
CPU 0 trap entry = 0x2 (memory management fault)
CPU 0 a0 = 0x20
CPU 0 a1 = 0x1
CPU 0 a2 = 0x0
CPU 0 pc = 0xfffffc00005bb410
CPU 0 ra = 0xfffffc00005bb3d4
CPU 0 pv = 0xfffffc00005f02f0
CPU 0 curlwp = 0xfffffc0000bc32b0
CPU 0 pid = 0, comm = swapper
panic: trap
db>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, port-alpha-maintainer@NetBSD.org,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Fri, 13 Jul 2007 00:47:16 +0900
ChristophFranzen@gmx.net wrote:
> NetBSD 4.0_BETA2 (INSTALL) #0: Mon Jul 9 22:30:11 PDT 2007
>
> builds@wb27:/home/builds/ab/netbsd-4/alpha/200707090002Z-
> obj/home/builds/ab/netbsd-4/src/sys/arch/alpha/compile/INSTALL
>
> DEC2000 model 300, 150MHz, s/n
> 8192 byte page size, 1 processor.
> total memory = 32768 KB
> (2048 KB reserved for PROM, 30720 KB used by NetBSD)
> avail memory = 21120 KB
> mainbus0 (root)
> CPU 0: fatal kernel trap:
>
> CPU 0 trap entry = 0x2 (memory management fault)
> CPU 0 a0 = 0x20
> CPU 0 a1 = 0x1
> CPU 0 a2 = 0x0
> CPU 0 pc = 0xfffffc00005bb410
> CPU 0 ra = 0xfffffc00005bb3d4
> CPU 0 pv = 0xfffffc00005f02f0
Hmm, looks NULL pointer dereference in
alpha/dec_2000_300.c:dec_2000_300_device_register().
Could you try the following image or attached patch?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070712.gz
Index: alpha/dec_2000_300.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/alpha/dec_2000_300.c,v
retrieving revision 1.13
diff -u -r1.13 dec_2000_300.c
--- alpha/dec_2000_300.c 4 Mar 2007 15:18:10 -0000 1.13
+++ alpha/dec_2000_300.c 12 Jul 2007 14:39:03 -0000
@@ -229,7 +229,7 @@
isadev = dev;
if (scsiboot && (scsidev == NULL)) {
- if (parent != eisadev)
+ if (eisadev == NULL || parent != eisadev)
return;
else {
struct eisa_attach_args *ea = aux;
@@ -286,7 +286,7 @@
/*
* XXX WHAT ABOUT ISA NETWORK CARDS?
*/
- if (parent != eisadev)
+ if (eisadev == NULL || parent != eisadev)
return;
else {
struct eisa_attach_args *ea = aux;
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org, port-alpha-maintainer@netbsd.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Thu, 12 Jul 2007 22:49:59 +0200
> Hmm, looks NULL pointer dereference in
> alpha/dec_2000_300.c:dec_2000_300_device_register().
>
> Could you try the following image or attached patch?
>
> http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070712.gz
This one is better, but now looks to me a lot like the bug around
version 1.6 (lpt port issue). I found something in the archives;
Jason Thorpe apparently had fixed something like that in/before 1.6:
http://mail-index.netbsd.org/port-alpha/2002/06/26/0003.html
I wonder why it has come back, or is this a different issue?
==============================
NetBSD/alpha 4.0_BETA2 ustar Bootstrap, Revision 1.3
(tsutsui@mirage, Fri Jul 13 00:08:27 JST 2007)
VMS PAL rev: 0x100010530
OSF PAL rev: 0x20123
Switch to OSF PAL code succeeded.
Boot flags: A
9057184+177808=0x8cefb0
Entering netbsd at 0xfffffc00003012e0...
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
2005, 2006
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights
reserved.
NetBSD 4.0_BETA2 (INSTALL) #1: Fri Jul 13 00:29:28 JST 2007
tsutsui@mirage:/r/work/src-
4.0/src/sys/arch/alpha/compile/obj.alpha/INSTALL
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 21120 KB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
pckbc0 at jensenio0 port 0x60
pms0 at pckbc0 (aux slot)
pckbc0: aux slot interrupting at vector 0x990
wsmouse0 at pms0 (mux ignored)
com0 at jensenio0 port 0x3f8: ns8250 or ns16450, no fifo
com0: console
com0: interrupting at vector 0x900
com1 at jensenio0 port 0x2f8: ns8250 or ns16450, no fifo
com1: interrupting at vector 0x920
lpt0 at jensenio0 port 0x3bc
panic: scb_set: bad vector 0x1
Stopped in pid 0.1 (swapper) at 0xfffffc00005d9cc0: ret
zero,(ra)
==============================
Again, "trace" is empty.
Regards, Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, port-alpha-maintainer@NetBSD.org,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Tue, 17 Jul 2007 00:17:51 +0900
ChristophFranzen@gmx.net wrote:
> This one is better, but now looks to me a lot like the bug around
> version 1.6 (lpt port issue). I found something in the archives;
> Jason Thorpe apparently had fixed something like that in/before 1.6:
> http://mail-index.netbsd.org/port-alpha/2002/06/26/0003.html
> I wonder why it has come back, or is this a different issue?
Looks Jason had a fix at that time but he had not committed it.
With a quick glance, lpt at jensenio uses a real eisa interrupt,
so I guess reverting lpt_jensenio.c rev 1.2 is enough.
Could you try this one?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070716.gz
Index: jensenio/lpt_jensenio.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/jensenio/lpt_jensenio.c,v
retrieving revision 1.5
diff -u -r1.5 lpt_jensenio.c
--- jensenio/lpt_jensenio.c 2 Oct 2002 04:06:38 -0000 1.5
+++ jensenio/lpt_jensenio.c 16 Jul 2007 15:11:02 -0000
@@ -71,8 +71,7 @@
struct lpt_softc sc_lpt; /* real "lpt" softc */
/* Jensen-specific goo. */
- char sc_vecstr[8];
- struct evcnt sc_ev_intr;
+ void *sc_ih; /* interrupt handler */
};
int lpt_jensenio_match(struct device *, struct cfdata *, void *);
@@ -81,8 +80,6 @@
CFATTACH_DECL(lpt_jensenio, sizeof(struct lpt_jensenio_softc),
lpt_jensenio_match, lpt_jensenio_attach, NULL, NULL);
-void lpt_jensenio_intr(void *, u_long);
-
int
lpt_jensenio_match(struct device *parent, struct cfdata *match, void *aux)
{
@@ -101,6 +98,7 @@
struct lpt_jensenio_softc *jsc = (void *)self;
struct lpt_softc *sc = &jsc->sc_lpt;
struct jensenio_attach_args *ja = aux;
+ const char *intrstr;
sc->sc_iot = ja->ja_iot;
@@ -114,20 +112,16 @@
lpt_attach_subr(sc);
- scb_set(ja->ja_irq[0], lpt_jensenio_intr, sc);
- printf("%s: interrupting at vector 0x%x\n",
- sc->sc_dev.dv_xname, ja->ja_irq[0]);
-
- sprintf(jsc->sc_vecstr, "0x%x", ja->ja_irq[0]);
- evcnt_attach_dynamic(&jsc->sc_ev_intr, EVCNT_TYPE_INTR,
- NULL, "vector", jsc->sc_vecstr);
-}
-
-void
-lpt_jensenio_intr(void *arg, u_long vec)
-{
- struct lpt_jensenio_softc *jsc = arg;
-
- jsc->sc_ev_intr.ev_count++;
- (void) lptintr(&jsc->sc_lpt);
+ intrstr = eisa_intr_string(ja->ja_ec, ja->ja_irq[0]);
+ jsc->sc_ih = eisa_intr_establish(ja->ja_ec, ja->ja_irq[0],
+ IST_EDGE, IPL_TTY, lptintr, sc);
+ if (jsc->sc_ih == NULL) {
+ printf("%s: unable to establish interrupt",
+ sc->sc_dev.dv_xname);
+ if (intrstr != NULL)
+ printf(" at %s", intrstr);
+ printf("\n");
+ return;
+ }
+ printf("%s: interrupting at %s\n", sc->sc_dev.dv_xname, intrstr);
}
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: gnats-bugs@NetBSD.org
Cc: port-alpha-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, ChristophFranzen@gmx.net
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Mon, 16 Jul 2007 21:47:25 +0200
> With a quick glance, lpt at jensenio uses a real eisa interrupt, so I
> guess reverting lpt_jensenio.c rev 1.2 is enough.
>
> Could you try this one?
> http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070716.gz
Thank you, but there is still something broken. Now it says "eisa irq
1" instead of "bad vector 0x1" while the other items all look like
"interupting at vector 0x###":
=========================
9057152+177808=0x8cef90
Entering netbsd at 0xfffffc00003012e0...
[...]
NetBSD 4.0_BETA2 (INSTALL) #2: Tue Jul 17 00:06:33 JST 2007
tsutsui@mirage:/r/work/src-
4.0/src/sys/arch/alpha/compile/obj.alpha/INSTALL
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 21120 KB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
pckbc0 at jensenio0 port 0x60
pms0 at pckbc0 (aux slot)
pckbc0: aux slot interrupting at vector 0x990
wsmouse0 at pms0 (mux ignored)
com0 at jensenio0 port 0x3f8: ns8250 or ns16450, no fifo
com0: console
com0: interrupting at vector 0x900
com1 at jensenio0 port 0x2f8: ns8250 or ns16450, no fifo
com1: interrupting at vector 0x920
lpt0 at jensenio0 port 0x3bc
lpt0: interrupting at eisa irq 1
mcclock0 at jensenio0 port 0x170: mc146818 or compatible
eisa0 at jensenio0
CPU 0: fatal kernel trap:
CPU 0 trap entry = 0x2 (memory management fault)
CPU 0 a0 = 0xfffffe0000058000
CPU 0 a1 = 0x1
CPU 0 a2 = 0x0
CPU 0 pc = 0xfffffc000058fa10
CPU 0 ra = 0xfffffc000058ffa8
CPU 0 pv = 0xfffffc00005f06c0
CPU 0 curlwp = 0xfffffc0000bc3320
CPU 0 pid = 0, comm = swapper
panic: trap
Stopped in pid 0.1 (swapper) at 0xfffffc00005d9cb8: ret
zero,(ra)
=========================
Regards, Christoph
Responsible-Changed-From-To: port-alpha-maintainer->tsutsui
Responsible-Changed-By: tsutsui@netbsd.org
Responsible-Changed-When: Tue, 17 Jul 2007 18:56:52 +0900
Responsible-Changed-Why:
I'll take this one.
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, port-alpha-maintainer@NetBSD.org,
tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Tue, 17 Jul 2007 19:10:56 +0900
ChristophFranzen@gmx.net wrote:
> > Could you try this one?
> > http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070716.gz
>
> Thank you, but there is still something broken. Now it says "eisa irq
> 1" instead of "bad vector 0x1" while the other items all look like
> "interupting at vector 0x###":
"eisa irq 1" is okay according to this (old but working) dmesg:
http://mail-index.netbsd.org/port-alpha/2000/07/12/0002.html
> com1: interrupting at vector 0x920
> lpt0 at jensenio0 port 0x3bc
> lpt0: interrupting at eisa irq 1
> mcclock0 at jensenio0 port 0x170: mc146818 or compatible
> eisa0 at jensenio0
>
> CPU 0: fatal kernel trap:
>
> CPU 0 trap entry = 0x2 (memory management fault)
> CPU 0 a0 = 0xfffffe0000058000
> CPU 0 a1 = 0x1
> CPU 0 a2 = 0x0
> CPU 0 pc = 0xfffffc000058fa10
> CPU 0 ra = 0xfffffc000058ffa8
This is another failure in alpha/eisa/eisa_machdep.c:eisa_read_config_bytes()
called from eisa_init() and there was the similar report:
http://mail-index.netbsd.org/port-alpha/2000/12/07/0009.html
I'm not sure how such NULL pointer deference could happen,
but could you try this debug kernel?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070717.gz
Index: eisa/eisa_machdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/eisa/eisa_machdep.c,v
retrieving revision 1.5
diff -u -r1.5 eisa_machdep.c
--- eisa/eisa_machdep.c 1 Jun 2002 23:50:53 -0000 1.5
+++ eisa/eisa_machdep.c 17 Jul 2007 10:02:05 -0000
@@ -162,7 +162,7 @@
int i;
for (i = 0; i < ECUF_MEM_ENTRY_CNT; i++) {
- ecum = malloc(sizeof(*ecum), M_DEVBUF, M_WAITOK);
+ ecum = malloc(sizeof(*ecum), M_DEVBUF, M_ZERO|M_WAITOK);
ecum->ecum_mem.ecm_isram = dp[0] & 0x1;
ecum->ecum_mem.ecm_unitsize = dp[1] & 0x3;
@@ -174,7 +174,7 @@
ecum->ecum_mem.ecm_size = (1 << 26);
SIMPLEQ_INSERT_TAIL(&ecuf->ecuf_mem, ecum, ecum_list);
-#if 0
+#ifdef EISA_DEBUG
printf("MEM 0x%lx 0x%lx %d %d %d\n",
ecum->ecum_mem.ecm_addr, ecum->ecum_mem.ecm_size,
ecum->ecum_mem.ecm_isram, ecum->ecum_mem.ecm_unitsize,
@@ -194,17 +194,17 @@
int i;
for (i = 0; i < ECUF_IRQ_ENTRY_CNT; i++) {
- ecui = malloc(sizeof(*ecui), M_DEVBUF, M_WAITOK);
+ ecui = malloc(sizeof(*ecui), M_DEVBUF, M_ZERO|M_WAITOK);
ecui->ecui_irq.eci_irq = dp[0] & 0xf;
ecui->ecui_irq.eci_ist = (dp[0] & 0x20) ? IST_LEVEL : IST_EDGE;
ecui->ecui_irq.eci_shared = (dp[0] & 0x40) ? 1 : 0;
SIMPLEQ_INSERT_TAIL(&ecuf->ecuf_irq, ecui, ecui_list);
-#if 0
- printf("IRQ %d %s%s\n", ecui->eci_irq.ecui_irq,
- ecui->eci_irq.ecui_ist == IST_LEVEL ? "level" : "edge",
- ecui->eci_irq.ecui_shared ? " shared" : "");
+#ifdef EISA_DEBUG
+ printf("IRQ %d %s%s\n", ecui->ecui_irq.eci_irq,
+ ecui->ecui_irq.eci_ist == IST_LEVEL ? "level" : "edge",
+ ecui->ecui_irq.eci_shared ? " shared" : "");
#endif
if ((dp[0] & 0x80) == 0)
@@ -220,7 +220,7 @@
int i;
for (i = 0; i < ECUF_DMA_ENTRY_CNT; i++) {
- ecud = malloc(sizeof(*ecud), M_DEVBUF, M_WAITOK);
+ ecud = malloc(sizeof(*ecud), M_DEVBUF, M_ZERO|M_WAITOK);
ecud->ecud_dma.ecd_drq = dp[0] & 0x7;
ecud->ecud_dma.ecd_shared = dp[0] & 0x40;
@@ -228,7 +228,7 @@
ecud->ecud_dma.ecd_timing = (dp[1] >> 4) & 0x3;
SIMPLEQ_INSERT_TAIL(&ecuf->ecuf_dma, ecud, ecud_list);
-#if 0
+#ifdef EISA_DEBUG
printf("DRQ %d%s %d %d\n", ecud->ecud_dma.ecd_drq,
ecud->ecud_dma.ecd_shared ? " shared" : "",
ecud->ecud_dma.ecd_size, ecud->ecud_dma.ecd_timing);
@@ -247,13 +247,13 @@
int i;
for (i = 0; i < ECUF_IO_ENTRY_CNT; i++) {
- ecuio = malloc(sizeof(*ecuio), M_DEVBUF, M_WAITOK);
+ ecuio = malloc(sizeof(*ecuio), M_DEVBUF, M_ZERO|M_WAITOK);
ecuio->ecuio_io.ecio_addr = dp[1] | (dp[2] << 8);
ecuio->ecuio_io.ecio_size = (dp[0] & 0x1f) + 1;
ecuio->ecuio_io.ecio_shared = (dp[0] & 0x40) ? 1 : 0;
-#if 0
+#ifdef EISA_DEBUG
printf("IO 0x%lx 0x%lx%s\n", ecuio->ecuio_io.ecio_addr,
ecuio->ecuio_io.ecio_size,
ecuio->ecuio_io.ecio_shared ? " shared" : "");
@@ -340,11 +340,15 @@
}
eisa_config_header_addr = hwrpb->rpb_condat_off;
-#if 0
+#ifdef EISA_DEBUG
printf("\nEISA config header at 0x%lx\n", eisa_config_header_addr);
#endif
if (eisa_config_stride == 0)
eisa_config_stride = 1;
+#ifdef EISA_DEBUG
+ printf("EISA config at 0x%lx\n", eisa_config_addr);
+ printf("EISA config stride: %ld\n", eisa_config_stride);
+#endif
/*
* Read the slot headers, and allocate config structures for
@@ -358,12 +362,14 @@
cfgaddr += sizeof(offset) * eisa_config_stride;
if (offset != 0) {
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d: offset 0x%08x eisaid %s\n",
i, offset, eisaid);
#endif
- ecud = malloc(sizeof(*ecud), M_DEVBUF, M_WAITOK);
- memset(ecud, 0, sizeof(*ecud));
+ ecud = malloc(sizeof(*ecud), M_DEVBUF, M_ZERO|M_WAITOK);
+ if (ecud == NULL)
+ panic("%s: can't allocate memory for ecud",
+ __func__);
SIMPLEQ_INIT(&ecud->ecud_funcs);
@@ -378,22 +384,33 @@
* Now traverse the valid slots and read the info.
*/
- cdata = malloc(512, M_TEMP, M_WAITOK);
- data = malloc(512, M_TEMP, M_WAITOK);
+ cdata = malloc(512, M_TEMP, M_ZERO|M_WAITOK);
+ if (cdata == NULL)
+ panic("%s: can't allocate memory for cdata", __func__);
+ data = malloc(512, M_TEMP, M_ZERO|M_WAITOK);
+ if (data == NULL)
+ panic("%s: can't allocate memory for data", __func__);
SIMPLEQ_FOREACH(ecud, &ecu_data_list, ecud_list) {
cfgaddr = eisa_config_addr + ecud->ecud_offset;
+#ifdef EISA_DEBUG
+ printf("Reading config bytes to cdata[0] at 0x%lx\n", cfgaddr);
+#endif
eisa_read_config_bytes(cfgaddr, &cdata[0], 1);
cfgaddr += eisa_config_stride;
for (i = 1; ; cfgaddr += eisa_config_stride, i++) {
+#ifdef EISA_DEBUG
+ printf("Reading config bytes to cdata[%d] at 0x%lx\n",
+ i, cfgaddr);
+#endif
eisa_read_config_bytes(cfgaddr, &cdata[i], 1);
if (cdata[i - 1] == 0 && cdata[i] == 0)
break;
}
i++; /* index -> length */
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d compressed data length %d:",
ecud->ecud_slot, i);
{
@@ -413,7 +430,7 @@
/* Uncompress the slot header. */
cdp += eisa_uncompress(cdp, dp, EISA_SLOT_HEADER_SIZE);
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d uncompressed header data:",
ecud->ecud_slot);
{
@@ -439,7 +456,7 @@
memcpy(&ecud->ecud_comp_id, dp, sizeof(ecud->ecud_comp_id));
dp += sizeof(ecud->ecud_comp_id);
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d: ndevfuncs %d\n", ecud->ecud_slot,
ecud->ecud_ndevfuncs);
#endif
@@ -447,7 +464,7 @@
for (func = 0; func < ecud->ecud_ndevfuncs; func++) {
dp = data;
cdp += eisa_uncompress(cdp, dp, EISA_CONFIG_BLOCK_SIZE);
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d:%d uncompressed data:",
ecud->ecud_slot, func);
{
@@ -464,7 +481,7 @@
/* Skip disabled functions. */
if (dp[EISA_FUNC_INFO_OFFSET] & ECUF_DISABLED) {
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d:%d disabled\n",
ecud->ecud_slot, func);
#endif
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Thu, 19 Jul 2007 01:14:16 +0200
> but could you try this debug kernel?
>
> http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070717.gz
Well, this one is interesting, but not yet usable:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
pckbc0 at jensenio0 port 0x60
pms0 at pckbc0 (aux slot)
pckbc0: aux slot interrupting at vector 0x990
wsmouse0 at pms0 (mux ignored)
com0 at jensenio0 port 0x3f8: ns8250 or ns16450, no fifo
com0: console
com0: interrupting at vector 0x900
com1 at jensenio0 port 0x2f8: ns8250 or ns16450, no fifo
com1: interrupting at vector 0x920
lpt0 at jensenio0 port 0x3bc
lpt0: interrupting at eisa irq 1
mcclock0 at jensenio0 port 0x170: mc146818 or compatible
eisa0 at jensenio0
EISA config header at 0x1ac061000
EISA config at 0x1a0000000
EISA config stride: 512
SLOT 0: offset 0x18386800 eisaid DEC2400
SLOT 1: offset 0x18397000 eisaid ELS8041
SLOT 2: offset 0x183b4800 eisaid ADP0002
SLOT 3: offset 0x183c6400 eisaid CPQ6101
SLOT 8: offset 0x00000008 eisaid =DD=DD=DD=DD=DD=DD=DD
SLOT 9: offset 0x00009b63 eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 10: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 11: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 12: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 13: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 14: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 15: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
Reading config bytes to cdata[0] at 0x1b8386800
Reading config bytes to cdata[1] at 0x1b8386a00
Reading config bytes to cdata[2] at 0x1b8386c00
Reading config bytes to cdata[3] at 0x1b8386e00
Reading config bytes to cdata[4] at 0x1b8387000
Reading config bytes to cdata[5] at 0x1b8387200
Reading config bytes to cdata[6] at 0x1b8387400
Reading config bytes to cdata[7] at 0x1b8387600
Reading config bytes to cdata[8] at 0x1b8387800
Reading config bytes to cdata[9] at 0x1b8387a00
Reading config bytes to cdata[10] at 0x1b8387c00
Reading config bytes to cdata[11] at 0x1b8387e00
Reading config bytes to cdata[12] at 0x1b8388000
Reading config bytes to cdata[13] at 0x1b8388200
Reading config bytes to cdata[14] at 0x1b8388400
Reading config bytes to cdata[15] at 0x1b8388600
Reading config bytes to cdata[16] at 0x1b8388800
Reading config bytes to cdata[17] at 0x1b8388a00
Reading config bytes to cdata[18] at 0x1b8388c00
Reading config bytes to cdata[19] at 0x1b8388e00
Reading config bytes to cdata[20] at 0x1b8389000
Reading config bytes to cdata[21] at 0x1b8389200
Reading config bytes to cdata[22] at 0x1b8389400
Reading config bytes to cdata[23] at 0x1b8389600
Reading config bytes to cdata[24] at 0x1b8389800
Reading config bytes to cdata[25] at 0x1b8389a00
Reading config bytes to cdata[26] at 0x1b8389c00
Reading config bytes to cdata[27] at 0x1b8389e00
Reading config bytes to cdata[28] at 0x1b838a000
Reading config bytes to cdata[29] at 0x1b838a200
Reading config bytes to cdata[30] at 0x1b838a400
Reading config bytes to cdata[31] at 0x1b838a600
Reading config bytes to cdata[32] at 0x1b838a800
Reading config bytes to cdata[33] at 0x1b838aa00
Reading config bytes to cdata[34] at 0x1b838ac00
Reading config bytes to cdata[35] at 0x1b838ae00
Reading config bytes to cdata[36] at 0x1b838b000
Reading config bytes to cdata[37] at 0x1b838b200
Reading config bytes to cdata[38] at 0x1b838b400
Reading config bytes to cdata[39] at 0x1b838b600
Reading config bytes to cdata[40] at 0x1b838b800
Reading config bytes to cdata[41] at 0x1b838ba00
Reading config bytes to cdata[42] at 0x1b838bc00
Reading config bytes to cdata[43] at 0x1b838be00
Reading config bytes to cdata[44] at 0x1b838c000
Reading config bytes to cdata[45] at 0x1b838c200
Reading config bytes to cdata[46] at 0x1b838c400
Reading config bytes to cdata[47] at 0x1b838c600
Reading config bytes to cdata[48] at 0x1b838c800
Reading config bytes to cdata[49] at 0x1b838ca00
Reading config bytes to cdata[50] at 0x1b838cc00
Reading config bytes to cdata[51] at 0x1b838ce00
Reading config bytes to cdata[52] at 0x1b838d000
Reading config bytes to cdata[53] at 0x1b838d200
Reading config bytes to cdata[54] at 0x1b838d400
Reading config bytes to cdata[55] at 0x1b838d600
Reading config bytes to cdata[56] at 0x1b838d800
Reading config bytes to cdata[57] at 0x1b838da00
Reading config bytes to cdata[58] at 0x1b838dc00
Reading config bytes to cdata[59] at 0x1b838de00
Reading config bytes to cdata[60] at 0x1b838e000
Reading config bytes to cdata[61] at 0x1b838e200
Reading config bytes to cdata[62] at 0x1b838e400
Reading config bytes to cdata[63] at 0x1b838e600
Reading config bytes to cdata[64] at 0x1b838e800
Reading config bytes to cdata[65] at 0x1b838ea00
Reading config bytes to cdata[66] at 0x1b838ec00
Reading config bytes to cdata[67] at 0x1b838ee00
Reading config bytes to cdata[68] at 0x1b838f000
Reading config bytes to cdata[69] at 0x1b838f200
Reading config bytes to cdata[70] at 0x1b838f400
Reading config bytes to cdata[71] at 0x1b838f600
Reading config bytes to cdata[72] at 0x1b838f800
Reading config bytes to cdata[73] at 0x1b838fa00
Reading config bytes to cdata[74] at 0x1b838fc00
Reading config bytes to cdata[75] at 0x1b838fe00
Reading config bytes to cdata[76] at 0x1b8390000
Reading config bytes to cdata[77] at 0x1b8390200
Reading config bytes to cdata[78] at 0x1b8390400
Reading config bytes to cdata[79] at 0x1b8390600
Reading config bytes to cdata[80] at 0x1b8390800
Reading config bytes to cdata[81] at 0x1b8390a00
Reading config bytes to cdata[82] at 0x1b8390c00
Reading config bytes to cdata[83] at 0x1b8390e00
Reading config bytes to cdata[84] at 0x1b8391000
Reading config bytes to cdata[85] at 0x1b8391200
Reading config bytes to cdata[86] at 0x1b8391400
Reading config bytes to cdata[87] at 0x1b8391600
Reading config bytes to cdata[88] at 0x1b8391800
Reading config bytes to cdata[89] at 0x1b8391a00
Reading config bytes to cdata[90] at 0x1b8391c00
Reading config bytes to cdata[91] at 0x1b8391e00
Reading config bytes to cdata[92] at 0x1b8392000
Reading config bytes to cdata[93] at 0x1b8392200
Reading config bytes to cdata[94] at 0x1b8392400
Reading config bytes to cdata[95] at 0x1b8392600
Reading config bytes to cdata[96] at 0x1b8392800
Reading config bytes to cdata[97] at 0x1b8392a00
Reading config bytes to cdata[98] at 0x1b8392c00
Reading config bytes to cdata[99] at 0x1b8392e00
Reading config bytes to cdata[100] at 0x1b8393000
Reading config bytes to cdata[101] at 0x1b8393200
Reading config bytes to cdata[102] at 0x1b8393400
Reading config bytes to cdata[103] at 0x1b8393600
Reading config bytes to cdata[104] at 0x1b8393800
Reading config bytes to cdata[105] at 0x1b8393a00
Reading config bytes to cdata[106] at 0x1b8393c00
Reading config bytes to cdata[107] at 0x1b8393e00
Reading config bytes to cdata[108] at 0x1b8394000
Reading config bytes to cdata[109] at 0x1b8394200
Reading config bytes to cdata[110] at 0x1b8394400
Reading config bytes to cdata[111] at 0x1b8394600
Reading config bytes to cdata[112] at 0x1b8394800
Reading config bytes to cdata[113] at 0x1b8394a00
Reading config bytes to cdata[114] at 0x1b8394c00
Reading config bytes to cdata[115] at 0x1b8394e00
Reading config bytes to cdata[116] at 0x1b8395000
Reading config bytes to cdata[117] at 0x1b8395200
Reading config bytes to cdata[118] at 0x1b8395400
Reading config bytes to cdata[119] at 0x1b8395600
Reading config bytes to cdata[120] at 0x1b8395800
Reading config bytes to cdata[121] at 0x1b8395a00
Reading config bytes to cdata[122] at 0x1b8395c00
Reading config bytes to cdata[123] at 0x1b8395e00
Reading config bytes to cdata[124] at 0x1b8396000
Reading config bytes to cdata[125] at 0x1b8396200
Reading config bytes to cdata[126] at 0x1b8396400
Reading config bytes to cdata[127] at 0x1b8396600
Reading config bytes to cdata[128] at 0x1b8396800
Reading config bytes to cdata[129] at 0x1b8396a00
Reading config bytes to cdata[130] at 0x1b8396c00
Reading config bytes to cdata[131] at 0x1b8396e00
SLOT 0 compressed data length 132:
0x01 0x00 0x01 0x01 0x00 0x01 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80
0x20 0xbf
0x98 0x80 0x28 0xbf 0x98 0x80 0x11 0x01 0x27 0x55 0xa1 0x04 0x1d 0x10
0xa3 0x24
0x00 0x01 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x01 0x43 0x4f 0x4d
0x31 0x00
0xff 0x00 0x1a 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x01 0x43 0x4f
0x4d 0x32
0x00 0xff 0x00 0x1a 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x05 0x4c
0x50 0x54
0x31 0x00 0x8b 0x01 0x00 0x8d 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d
0x1d 0x46
0x4c 0x4f 0x50 0x50 0x59 0x20 0x44 0x49 0x53 0x4b 0x20 0x43 0x4f 0x4e
0x54 0x52
0x4f 0x4c 0x4c 0x45 0x52 0x00 0x79 0x06 0x00 0x0d 0x02 0x00 0x07 0x07
0xf0 0x03
0x00 0x75 0x00 0x00
SLOT 0 uncompressed header data:
0x01 0x00 0x01 0x00 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80 0x20 0xbf
0x98 0x80
0x28 0xbf 0x98 0x80 0x11 0x01 0x27 0x55 0xa1 0x04 0x1d 0x10 0xa3 0x24
0x00
SLOT 0: ndevfuncs 4
SLOT 0:0 uncompressed data:
0x10 0xa3 0x24 0x00 0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x01 0x43 0x4f 0x4d 0x31 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x01 0x00 0x01 0x01 0x00 0x01 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80
0x20 0xbf
0x98 0x80 0x28 0xbf 0x98 0x80 0x11 0x01 0x27 0x55 0xa1 0x04 0x1d 0x10
0xa3 0x24
0x00 0x01 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x01 0x43 0x4f 0x4d
0x31 0x00
0xff 0x00 0x1a 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x01 0x43 0x4f
0x4d 0x32
0x00 0xff 0x00 0x1a 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x05 0x4c
0x50 0x54
0x31 0x00 0x8b 0x01 0x00 0x8d 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d
0x1d 0x46
0x4c 0x4f 0x50 0x50 0x59 0x20 0x44 0x49 0x53 0x4b 0x20 0x43 0x4f 0x4e
0x54 0x52
0x4f 0x4c 0x4c 0x45 0x52 0x00 0x79 0x06 0x00 0x0d 0x02 0x00 0x07 0x07
0xf0 0x03
0x00 0x75 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
[...]
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
CPU 0: fatal kernel trap:
CPU 0 trap entry =3D 0x2 (memory management fault)
CPU 0 a0 =3D 0xfffffe0000058000
CPU 0 a1 =3D 0x1
CPU 0 a2 =3D 0x0
CPU 0 pc =3D 0xfffffc00005903b0
CPU 0 ra =3D 0xfffffc00005903a4
CPU 0 pv =3D 0xfffffc00004974a0
CPU 0 curlwp =3D 0xfffffc0000bc3940
CPU 0 pid =3D 0, comm =3D swapper
panic: trap
Stopped in pid 0.1 (swapper) at 0xfffffc00005da0c0: ret
zero,(ra)
db>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Regards, Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Thu, 19 Jul 2007 21:33:36 +0900
ChristophFranzen@gmx.net wrote:
> > http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070717.gz
>
> Well, this one is interesting, but not yet usable:
:
> eisa0 at jensenio0
> EISA config header at 0x1ac061000
> EISA config at 0x1a0000000
> EISA config stride: 512
> SLOT 0: offset 0x18386800 eisaid DEC2400
> SLOT 1: offset 0x18397000 eisaid ELS8041
> SLOT 2: offset 0x183b4800 eisaid ADP0002
> SLOT 3: offset 0x183c6400 eisaid CPQ6101
:
> SLOT 0: ndevfuncs 4
> SLOT 0:0 uncompressed data:
> 0x10 0xa3 0x24 0x00 0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> 0x00 0x00
:
> [...]
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> 0x00 0x00
> CPU 0: fatal kernel trap:
> CPU 0 trap entry = 0x2 (memory management fault)
> CPU 0 a0 = 0xfffffe0000058000
> CPU 0 a1 = 0x1
> CPU 0 a2 = 0x0
> CPU 0 pc = 0xfffffc00005903b0
> CPU 0 ra = 0xfffffc00005903a4
Umm, it fails at different place from the previous one..
I've added more debug info printfs, could you try the next one?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070719.gz
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: PR/36628 CVS commit: src/sys/arch/alpha/alpha
Date: Thu, 19 Jul 2007 12:46:45 +0000 (UTC)
Module Name: src
Committed By: tsutsui
Date: Thu Jul 19 12:46:45 UTC 2007
Modified Files:
src/sys/arch/alpha/alpha: dec_2000_300.c
Log Message:
Avoid NULL pointer dereference in MD device_register() function.
Fixes a part of PR port-alpha/36628.
To generate a diff of this commit:
cvs rdiff -r1.13 -r1.14 src/sys/arch/alpha/alpha/dec_2000_300.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Izumi Tsutsui <tsutsui@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: PR/36628 CVS commit: src/sys/arch/alpha/jensenio
Date: Thu, 19 Jul 2007 12:58:29 +0000 (UTC)
Module Name: src
Committed By: tsutsui
Date: Thu Jul 19 12:58:29 UTC 2007
Modified Files:
src/sys/arch/alpha/jensenio: lpt_jensenio.c
Log Message:
Backout changes on lpt_jensenio.c rev 1.2.
lpt at jensenio doesn't seem to have a specific interrupt vector
but uses a normal EISA interrupt.
Fixes another part of PR port-alpha/36628 and PR port-alpha/20386.
To generate a diff of this commit:
cvs rdiff -r1.5 -r1.6 src/sys/arch/alpha/jensenio/lpt_jensenio.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: ChristophFranzen@gmx.net, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Sat, 21 Jul 2007 05:24:22 +0900
ChristophFranzen@gmx.net wrote:
> the Result is attached.
:
> > http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070719.gz
>
> I did not send this to GNATS because the attachment ist rather large,
> and I don't know which information you need so I haven't shortened
> the file.
Thanks, it shows that reading config data region of invalid slots
causes the problem:
---
:
eisa0 at jensenio0
EISA config header at 0x1ac061000
EISA config at 0x1a0000000
EISA config stride: 512
SLOT 0: offset 0x18386800 eisaid DEC2400
SLOT 1: offset 0x18397000 eisaid ELS8041
SLOT 2: offset 0x183b4800 eisaid ADP0002
SLOT 3: offset 0x183c6400 eisaid CPQ6101
SLOT 8: offset 0x00000008 eisaid <DD><DD><DD><DD><DD><DD><DD>
SLOT 9: offset 0x00009b63 eisaid <FF><FF><FF><FF><FF><FF><FF>
SLOT 10: offset 0xffffffff eisaid <FF><FF><FF><FF><FF><FF><FF>
SLOT 11: offset 0xffffffff eisaid <FF><FF><FF><FF><FF><FF><FF>
SLOT 12: offset 0xffffffff eisaid <FF><FF><FF><FF><FF><FF><FF>
SLOT 13: offset 0xffffffff eisaid <FF><FF><FF><FF><FF><FF><FF>
SLOT 14: offset 0xffffffff eisaid <FF><FF><FF><FF><FF><FF><FF>
SLOT 15: offset 0xffffffff eisaid <FF><FF><FF><FF><FF><FF><FF>
:
SLOT 8 compressed data length 48:
0x01 0x09 0x10 0x01 0x55 0x00 0xaa 0xff 0x56 0x31 0x2e 0x31 0x20 0x20 0x20 0x20
0x44 0x45 0x43 0x20 0x20 0x20 0x20 0x20 0x4a 0x45 0x4e 0x53 0x5f 0x53 0x59 0x53
0x41 0x4c 0x50 0x48 0xff 0xff 0xff 0xff 0x17 0x01 0x01 0x00 0xc0 0x03 0x00 0x00
SLOT 8 uncompressed header data:
0x01 0x09 0x10 0x01 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
SLOT 8: ndevfuncs 0
Slot 8:0 done
Reading config bytes to cdata[0] at 0x1a0009b63
Reading config bytes to cdata[1] at 0x1a0009d63
:
Reading config bytes to cdata[62463] at 0x1a1e89963
Reading config bytes to cdata[62464] at 0x1a1e89b63
CPU 0: fatal kernel trap:
CPU 0 trap entry = 0x2 (memory management fault)
CPU 0 a0 = 0xfffffe0000058000
CPU 0 a1 = 0x1
CPU 0 a2 = 0x0
CPU 0 pc = 0xfffffc000058fa10
CPU 0 ra = 0xfffffc000059008c
:
---
Maybe we shouldn't check slots more than 8 at least on Jensen
(though I'm not sure how it worked in the past).
How about this one?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070720.gz
---
Index: eisa/eisa_machdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/eisa/eisa_machdep.c,v
retrieving revision 1.5
diff -u -r1.5 eisa_machdep.c
--- eisa/eisa_machdep.c 1 Jun 2002 23:50:53 -0000 1.5
+++ eisa/eisa_machdep.c 20 Jul 2007 20:20:21 -0000
@@ -79,6 +79,7 @@
#define ECUF_DMA_ENTRY_CNT 4
#define ECUF_IO_ENTRY_CNT 20
+#define CBUFSIZE 512
/*
* EISA configuration space, as set up by the ECU, may be sparse.
*/
@@ -162,7 +163,9 @@
int i;
for (i = 0; i < ECUF_MEM_ENTRY_CNT; i++) {
- ecum = malloc(sizeof(*ecum), M_DEVBUF, M_WAITOK);
+ ecum = malloc(sizeof(*ecum), M_DEVBUF, M_ZERO|M_WAITOK);
+ if (ecum == NULL)
+ panic("%s: can't allocate memory for ecum", __func__);
ecum->ecum_mem.ecm_isram = dp[0] & 0x1;
ecum->ecum_mem.ecm_unitsize = dp[1] & 0x3;
@@ -174,7 +177,7 @@
ecum->ecum_mem.ecm_size = (1 << 26);
SIMPLEQ_INSERT_TAIL(&ecuf->ecuf_mem, ecum, ecum_list);
-#if 0
+#ifdef EISA_DEBUG
printf("MEM 0x%lx 0x%lx %d %d %d\n",
ecum->ecum_mem.ecm_addr, ecum->ecum_mem.ecm_size,
ecum->ecum_mem.ecm_isram, ecum->ecum_mem.ecm_unitsize,
@@ -194,17 +197,19 @@
int i;
for (i = 0; i < ECUF_IRQ_ENTRY_CNT; i++) {
- ecui = malloc(sizeof(*ecui), M_DEVBUF, M_WAITOK);
+ ecui = malloc(sizeof(*ecui), M_DEVBUF, M_ZERO|M_WAITOK);
+ if (ecui == NULL)
+ panic("%s: can't allocate memory for ecui", __func__);
ecui->ecui_irq.eci_irq = dp[0] & 0xf;
ecui->ecui_irq.eci_ist = (dp[0] & 0x20) ? IST_LEVEL : IST_EDGE;
ecui->ecui_irq.eci_shared = (dp[0] & 0x40) ? 1 : 0;
SIMPLEQ_INSERT_TAIL(&ecuf->ecuf_irq, ecui, ecui_list);
-#if 0
- printf("IRQ %d %s%s\n", ecui->eci_irq.ecui_irq,
- ecui->eci_irq.ecui_ist == IST_LEVEL ? "level" : "edge",
- ecui->eci_irq.ecui_shared ? " shared" : "");
+#ifdef EISA_DEBUG
+ printf("IRQ %d %s%s\n", ecui->ecui_irq.eci_irq,
+ ecui->ecui_irq.eci_ist == IST_LEVEL ? "level" : "edge",
+ ecui->ecui_irq.eci_shared ? " shared" : "");
#endif
if ((dp[0] & 0x80) == 0)
@@ -220,7 +225,9 @@
int i;
for (i = 0; i < ECUF_DMA_ENTRY_CNT; i++) {
- ecud = malloc(sizeof(*ecud), M_DEVBUF, M_WAITOK);
+ ecud = malloc(sizeof(*ecud), M_DEVBUF, M_ZERO|M_WAITOK);
+ if (ecud == NULL)
+ panic("%s: can't allocate memory for ecud", __func__);
ecud->ecud_dma.ecd_drq = dp[0] & 0x7;
ecud->ecud_dma.ecd_shared = dp[0] & 0x40;
@@ -228,7 +235,7 @@
ecud->ecud_dma.ecd_timing = (dp[1] >> 4) & 0x3;
SIMPLEQ_INSERT_TAIL(&ecuf->ecuf_dma, ecud, ecud_list);
-#if 0
+#ifdef EISA_DEBUG
printf("DRQ %d%s %d %d\n", ecud->ecud_dma.ecd_drq,
ecud->ecud_dma.ecd_shared ? " shared" : "",
ecud->ecud_dma.ecd_size, ecud->ecud_dma.ecd_timing);
@@ -247,13 +254,15 @@
int i;
for (i = 0; i < ECUF_IO_ENTRY_CNT; i++) {
- ecuio = malloc(sizeof(*ecuio), M_DEVBUF, M_WAITOK);
+ ecuio = malloc(sizeof(*ecuio), M_DEVBUF, M_ZERO|M_WAITOK);
+ if (ecuio == NULL)
+ panic("%s: can't allocate memory for ecuio", __func__);
ecuio->ecuio_io.ecio_addr = dp[1] | (dp[2] << 8);
ecuio->ecuio_io.ecio_size = (dp[0] & 0x1f) + 1;
ecuio->ecuio_io.ecio_shared = (dp[0] & 0x40) ? 1 : 0;
-#if 0
+#ifdef EISA_DEBUG
printf("IO 0x%lx 0x%lx%s\n", ecuio->ecuio_io.ecio_addr,
ecuio->ecuio_io.ecio_size,
ecuio->ecuio_io.ecio_shared ? " shared" : "");
@@ -285,7 +294,7 @@
int i;
for (i = 0; i < sizeof(val); i++) {
- val |= (u_int)(*src << (i * 8));
+ val |= (u_int)*src << (i * 8);
src += eisa_config_stride;
}
@@ -314,7 +323,7 @@
}
void
-eisa_init()
+eisa_init(eisa_chipset_tag_t ec)
{
struct ecu_data *ecud;
paddr_t cfgaddr;
@@ -340,30 +349,36 @@
}
eisa_config_header_addr = hwrpb->rpb_condat_off;
-#if 0
- printf("\nEISA config header at 0x%lx\n", eisa_config_header_addr);
-#endif
if (eisa_config_stride == 0)
eisa_config_stride = 1;
+#ifdef EISA_DEBUG
+ printf("\nEISA config header at 0x%lx\n", eisa_config_header_addr);
+ printf("EISA config at 0x%lx\n", eisa_config_addr);
+ printf("EISA config stride: %ld\n", eisa_config_stride);
+#endif
+
/*
* Read the slot headers, and allocate config structures for
* valid slots.
*/
- for (cfgaddr = eisa_config_header_addr, i = 0; i < 16 /* XXX */; i++) {
+ for (cfgaddr = eisa_config_header_addr, i = 0;
+ i < eisa_maxslots(ec); i++) {
eisa_read_config_bytes(cfgaddr, eisaid, sizeof(eisaid));
eisaid[EISA_IDSTRINGLEN - 1] = '\0'; /* sanity */
cfgaddr += sizeof(eisaid) * eisa_config_stride;
eisa_read_config_word(cfgaddr, &offset);
cfgaddr += sizeof(offset) * eisa_config_stride;
- if (offset != 0) {
-#if 0
+ if (offset != 0 || offset != 0xffffffff) {
+#ifdef EISA_DEBUG
printf("SLOT %d: offset 0x%08x eisaid %s\n",
i, offset, eisaid);
#endif
- ecud = malloc(sizeof(*ecud), M_DEVBUF, M_WAITOK);
- memset(ecud, 0, sizeof(*ecud));
+ ecud = malloc(sizeof(*ecud), M_DEVBUF, M_ZERO|M_WAITOK);
+ if (ecud == NULL)
+ panic("%s: can't allocate memory for ecud",
+ __func__);
SIMPLEQ_INIT(&ecud->ecud_funcs);
@@ -378,22 +393,42 @@
* Now traverse the valid slots and read the info.
*/
- cdata = malloc(512, M_TEMP, M_WAITOK);
- data = malloc(512, M_TEMP, M_WAITOK);
+ cdata = malloc(CBUFSIZE, M_TEMP, M_ZERO|M_WAITOK);
+ if (cdata == NULL)
+ panic("%s: can't allocate memory for cdata", __func__);
+ data = malloc(CBUFSIZE, M_TEMP, M_ZERO|M_WAITOK);
+ if (data == NULL)
+ panic("%s: can't allocate memory for data", __func__);
SIMPLEQ_FOREACH(ecud, &ecu_data_list, ecud_list) {
cfgaddr = eisa_config_addr + ecud->ecud_offset;
+#ifdef EISA_DEBUG
+ printf("Checking SLOT %d\n", ecud->ecud_slot);
+ printf("Reading config bytes at 0x%lx to cdata[0]\n", cfgaddr);
+#endif
eisa_read_config_bytes(cfgaddr, &cdata[0], 1);
cfgaddr += eisa_config_stride;
- for (i = 1; ; cfgaddr += eisa_config_stride, i++) {
+ for (i = 1; i < CBUFSIZE; cfgaddr += eisa_config_stride, i++) {
+#ifdef EISA_DEBUG
+ printf("Reading config bytes at 0x%lx to cdata[%d]\n",
+ cfgaddr, i);
+#endif
eisa_read_config_bytes(cfgaddr, &cdata[i], 1);
if (cdata[i - 1] == 0 && cdata[i] == 0)
break;
}
+ if (i == CBUFSIZE) {
+ /* assume this compressed data invalid */
+#ifdef EISA_DEBUG
+ printf("SLOT %d has invalid config\n", ecud->ecud_slot);
+#endif
+ continue;
+ }
+
i++; /* index -> length */
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d compressed data length %d:",
ecud->ecud_slot, i);
{
@@ -413,7 +448,7 @@
/* Uncompress the slot header. */
cdp += eisa_uncompress(cdp, dp, EISA_SLOT_HEADER_SIZE);
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d uncompressed header data:",
ecud->ecud_slot);
{
@@ -439,7 +474,7 @@
memcpy(&ecud->ecud_comp_id, dp, sizeof(ecud->ecud_comp_id));
dp += sizeof(ecud->ecud_comp_id);
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d: ndevfuncs %d\n", ecud->ecud_slot,
ecud->ecud_ndevfuncs);
#endif
@@ -447,7 +482,7 @@
for (func = 0; func < ecud->ecud_ndevfuncs; func++) {
dp = data;
cdp += eisa_uncompress(cdp, dp, EISA_CONFIG_BLOCK_SIZE);
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d:%d uncompressed data:",
ecud->ecud_slot, func);
{
@@ -464,7 +499,7 @@
/* Skip disabled functions. */
if (dp[EISA_FUNC_INFO_OFFSET] & ECUF_DISABLED) {
-#if 0
+#ifdef EISA_DEBUG
printf("SLOT %d:%d disabled\n",
ecud->ecud_slot, func);
#endif
@@ -472,6 +507,9 @@
}
ecuf = malloc(sizeof(*ecuf), M_DEVBUF, M_WAITOK);
+ if (ecuf == NULL)
+ panic("%s: can't allocate memory for ecuf",
+ __func__);
ecuf_init(ecuf);
ecuf->ecuf_funcno = func;
SIMPLEQ_INSERT_TAIL(&ecud->ecud_funcs, ecuf,
Index: include/eisa_machdep.h
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/include/eisa_machdep.h,v
retrieving revision 1.7
diff -u -r1.7 eisa_machdep.h
--- include/eisa_machdep.h 11 Aug 2000 00:43:20 -0000 1.7
+++ include/eisa_machdep.h 20 Jul 2007 20:20:21 -0000
@@ -78,7 +78,7 @@
* Internal functions, NOT TO BE USED BY MACHINE-INDEPENDENT CODE!
*/
-void eisa_init(void);
+void eisa_init(eisa_chipset_tag_t);
extern bus_size_t eisa_config_stride;
extern paddr_t eisa_config_addr;
Index: jensenio/jensenio.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/jensenio/jensenio.c,v
retrieving revision 1.13
diff -u -r1.13 jensenio.c
--- jensenio/jensenio.c 11 Dec 2005 12:16:17 -0000 1.13
+++ jensenio/jensenio.c 20 Jul 2007 20:20:21 -0000
@@ -244,7 +244,7 @@
*/
eisa_config_stride = 0x200;
eisa_config_addr = JENSEN_FEPROM1;
- eisa_init();
+ eisa_init(eba->eba_ec);
#endif
}
@@ -252,7 +252,7 @@
jensenio_eisa_maxslots(void *v)
{
- return (16); /* as good a number as any. only 8, maybe? */
+ return (8); /* jensen seems to have only 8 valid slots */
}
void
Index: pci/sio.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/pci/sio.c,v
retrieving revision 1.40
diff -u -r1.40 sio.c
--- pci/sio.c 11 Dec 2005 12:16:17 -0000 1.40
+++ pci/sio.c 20 Jul 2007 20:20:21 -0000
@@ -318,7 +318,7 @@
{
#if NEISA > 0
- eisa_init();
+ eisa_init(eba->eba_ec);
#endif
}
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Sat, 21 Jul 2007 01:38:41 +0200
Hello, thank you,
> Thanks, it shows that reading config data region of invalid slots
> causes the problem:
[...]
> Maybe we shouldn't check slots more than 8 at least on Jensen
> (though I'm not sure how it worked in the past).
The Jensen has got exactly 6 EISA slots and the system board, so
there should only the slots 0, 1, 2, 3, 4, 5, 6 being found.
I have installed and configured 3 EISA cards in the first three
slots, number 4 and 5 are empty and number 6 contains an ISA network
card which I left unconfigured in the ECU.
The card in slot 1, however, is found as ISA, not EISA by the SRM
while the real ISA card is not seen by the SRM console at all.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
EISA config header at 0x1ac061000
EISA config at 0x1a0000000
EISA config stride: 512
SLOT 0: offset 0x18386800 eisaid DEC2400
SLOT 1: offset 0x18397000 eisaid ELS8041
SLOT 2: offset 0x183b4800 eisaid ADP0002
SLOT 3: offset 0x183c6400 eisaid CPQ6101
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
I don't know much about this stuff, but I wonder if the problem is
really here where it "sees" the slots 8 to 15.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
SLOT 8: offset 0x00000008 eisaid =DD=DD=DD=DD=DD=DD=DD
SLOT 9: offset 0x00009b63 eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 10: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 11: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 12: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 13: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 14: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 15: offset 0xffffffff eisaid =FF=FF=FF=FF=FF=FF=FF
SLOT 0 compressed data length 132:
0x01 0x00 0x01 0x01 0x00 0x01 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80
0x20 0xbf
0x98 0x80 0x28 0xbf 0x98 0x80 0x11 0x01 0x27 0x55 0xa1 0x04 0x1d 0x10
0xa3 0x24
0x00 0x01 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x01 0x43 0x4f 0x4d
0x31 0x00
0xff 0x00 0x1a 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x01 0x43 0x4f
0x4d 0x32
0x00 0xff 0x00 0x1a 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d 0x05 0x4c
0x50 0x54
0x31 0x00 0x8b 0x01 0x00 0x8d 0x10 0xa3 0x24 0x00 0x01 0x11 0x00 0x1d
0x1d 0x46
0x4c 0x4f 0x50 0x50 0x59 0x20 0x44 0x49 0x53 0x4b 0x20 0x43 0x4f 0x4e
0x54 0x52
0x4f 0x4c 0x4c 0x45 0x52 0x00 0x79 0x06 0x00 0x0d 0x02 0x00 0x07 0x07
0xf0 0x03
0x00 0x75 0x00 0x00
SLOT 0 uncompressed header data:
0x01 0x00 0x01 0x00 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80 0x20 0xbf
0x98 0x80
0x28 0xbf 0x98 0x80 0x11 0x01 0x27 0x55 0xa1 0x04 0x1d 0x10 0xa3 0x24
0x00
SLOT 0: ndevfuncs 4
SLOT 0:0 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
SLOT 0:1 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
SLOT 0:2 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
IRQ 1 edge
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
SLOT 0:3 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
IRQ 6 edge
Setting ecuf_dma_entry
DRQ 2 0 0
Setting ecuf_io_entry
IO 0x3f0 0x8
Setting ecuf_init_entry
Slot 0:4 done
SLOT 1 compressed data length 236:
0x01 0x00 0x01 0x01 0x00 0x01 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80
0x20 0xbf
0x98 0x80 0x28 0xbf 0x98 0x80 0x41 0x01 0x27 0xc4 0x9f 0x04 0x17 0x15
0x93 0x80
0x41 0x15 0x93 0x80 0x41 0x41 0x03 0x00 0x1c 0x11 0x56 0x49 0x44 0x2c
0x56 0x47
0x41 0x2c 0x56 0x49 0x44 0x2c 0x56 0x47 0x41 0x00 0x96 0x80 0x02 0x01
0x80 0xe8
0x02 0x80 0xea 0x02 0x80 0xc0 0x03 0x80 0xc1 0x03 0x80 0xc2 0x03 0x80
0xc4 0x03
0x80 0xc5 0x03 0x80 0xc6 0x03 0x80 0xc7 0x03 0x80 0xc8 0x03 0x80 0xc9
0x03 0x80
0xcc 0x03 0x80 0xce 0x03 0x00 0x01 0xcf 0x03 0x00 0x4b 0x15 0x93 0x80
0x41 0x41
0x03 0x00 0x1c 0x13 0x56 0x49 0x44 0x2c 0x56 0x47 0x41 0x3b 0x43 0x4f
0x4c 0x4f
0x52 0x00 0x43 0x99 0x0a 0x80 0x0b 0x00 0x01 0x20 0x00 0x01 0x18 0x08
0x00 0x01
0x0c 0x00 0x01 0x20 0x00 0x48 0x80 0xd4 0x03 0x80 0xd5 0x03 0x80 0xd8
0x03 0x80
0xd9 0x03 0x80 0xda 0x03 0x80 0xdb 0x03 0x00 0x01 0xdc 0x03 0x00 0x63
0x15 0x93
0x80 0x41 0x41 0x03 0x00 0x1c 0x01 0x56 0x49 0x44 0x2c 0x56 0x47 0x41
0x2c 0x56
0x49 0x44 0x2c 0x56 0x47 0x41 0x00 0xff 0x00 0x0f 0x15 0x93 0x80 0x41
0x41 0x03
0x00 0x02 0x01 0x00 0x19 0x05 0x56 0x49 0x44 0x2c 0x56 0x47 0x41 0x2c
0x56 0x49
0x44 0x2c 0x56 0x47 0x41 0x00 0x80 0x09 0x00 0x8d 0x00 0x00
SLOT 1 uncompressed header data:
0x01 0x00 0x01 0x00 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80 0x20 0xbf
0x98 0x80
0x28 0xbf 0x98 0x80 0x41 0x01 0x27 0xc4 0x9f 0x04 0x17 0x15 0x93 0x80
0x41
SLOT 1: ndevfuncs 4
SLOT 1:0 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
IO 0x102 0x1
IO 0x2e8 0x1
IO 0x2ea 0x1
IO 0x3c0 0x1
IO 0x3c1 0x1
IO 0x3c2 0x1
IO 0x3c4 0x1
IO 0x3c5 0x1
IO 0x3c6 0x1
IO 0x3c7 0x1
IO 0x3c8 0x1
IO 0x3c9 0x1
IO 0x3cc 0x1
IO 0x3ce 0x1
IO 0x3cf 0x1
Setting ecuf_init_entry
SLOT 1:1 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
MEM 0xb8000 0x8000 1 2 2
MEM 0xc0000 0x8000 0 0 2
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
IO 0x3d4 0x1
IO 0x3d5 0x1
IO 0x3d8 0x1
IO 0x3d9 0x1
IO 0x3da 0x1
IO 0x3db 0x1
IO 0x3dc 0x1
Setting ecuf_init_entry
SLOT 1:2 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
SLOT 1:3 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
IRQ 9 edge
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
Slot 1:4 done
SLOT 2 compressed data length 142:
0x01 0x00 0x01 0x01 0x00 0x01 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80
0x20 0xbf
0x98 0x80 0x28 0xbf 0x98 0x80 0x00 0x01 0x01 0x27 0xf8 0x00 0x01 0x04
0x27 0x04
0x90 0x00 0x01 0x02 0x04 0x90 0x00 0x01 0x02 0x00 0x01 0x03 0x00 0x1c
0x25 0x41
0x48 0x41 0x31 0x37 0x34 0x30 0x00 0x88 0x2b 0x00 0x51 0x80 0xc0 0x2c
0x80 0x80
0xc1 0x2c 0xc3 0x80 0xc2 0x2c 0x12 0x80 0xc3 0x2c 0x17 0x00 0x01 0xc4
0x2c 0x01
0x00 0x28 0x04 0x90 0x00 0x01 0x02 0x00 0x01 0x03 0x00 0x1c 0x03 0x41
0x44 0x41
0x50 0x54 0x45 0x52 0x3d 0x53 0x43 0x53 0x49 0x00 0x44 0x18 0x08 0xc0
0x0c 0x00
0x01 0x10 0x00 0xc7 0x04 0x90 0x00 0x01 0x02 0x00 0x01 0x03 0x00 0xff
0x00 0x3b
0x04 0x90 0x00 0x01 0x02 0x00 0x01 0x03 0x00 0xff 0x00 0x3b 0x00 0x00
SLOT 2 uncompressed header data:
0x01 0x00 0x01 0x00 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80 0x20 0xbf
0x98 0x80
0x28 0xbf 0x98 0x80 0x00 0x01 0x27 0xf8 0x00 0x04 0x27 0x04 0x90 0x00
0x02
SLOT 2: ndevfuncs 4
SLOT 2:0 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
IRQ 11 level
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
SLOT 2:1 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
MEM 0xcc000 0x4000 0 0 2
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
SLOT 2:2 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
SLOT 2:3 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
Slot 2:4 done
SLOT 3 compressed data length 128:
0x01 0x00 0x01 0x01 0x00 0x01 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80
0x20 0xbf
0x98 0x80 0x28 0xbf 0x98 0x80 0x01 0x01 0x27 0x49 0xa0 0x02 0x25 0x0e
0x11 0x61
0x01 0x0e 0x11 0x61 0x01 0x01 0x01 0x00 0x04 0x04 0x00 0x01 0x02 0x02
0x00 0x14
0x25 0x4e 0x45 0x54 0x3b 0x45 0x54 0x48 0x3b 0x49 0x52 0x51 0x35 0x2c
0x4c 0x45
0x56 0x45 0x4c 0x3b 0x31 0x30 0x4d 0x42 0x50 0x53 0x3b 0x55 0x54 0x50
0x00 0x72
0x25 0x00 0x51 0x80 0x85 0x3c 0x28 0x81 0x1c 0x30 0x01 0x00 0x01 0x01
0x08 0x30
0x80 0x00 0x2f 0x0e 0x11 0x61 0x01 0x01 0x01 0x00 0x1c 0x41 0x4f 0x54
0x48 0x2c
0x52 0x45 0x56 0x50 0x4f 0x52 0x54 0x00 0x45 0x02 0x63 0x0c 0x00 0xca
0x00 0x00
SLOT 3 uncompressed header data:
0x01 0x00 0x01 0x00 0x10 0xbf 0x98 0x80 0x18 0xbf 0x98 0x80 0x20 0xbf
0x98 0x80
0x28 0xbf 0x98 0x80 0x01 0x01 0x27 0x49 0xa0 0x02 0x25 0x0e 0x11 0x61
0x01
SLOT 3: ndevfuncs 2
SLOT 3:0 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
IRQ 5 level
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
SLOT 3:1 uncompressed data:
Checking this function enabled
Calling ecuf_init; done
Setting ecuf_id
Setting ecuf_slot_info
Setting ecuf_cfg_ext
Setting ecuf_selections
Setting ecuf_func_info
Setting ecuf_type_string
Setting ecuf_mem_entry
Setting ecuf_irq_entry
Setting ecuf_dma_entry
Setting ecuf_io_entry
Setting ecuf_init_entry
Slot 3:2 done
SLOT 8 compressed data length 48:
0x01 0x09 0x10 0x01 0x55 0x00 0xaa 0xff 0x56 0x31 0x2e 0x31 0x20 0x20
0x20 0x20
0x44 0x45 0x43 0x20 0x20 0x20 0x20 0x20 0x4a 0x45 0x4e 0x53 0x5f 0x53
0x59 0x53
0x41 0x4c 0x50 0x48 0xff 0xff 0xff 0xff 0x17 0x01 0x01 0x00 0xc0 0x03
0x00 0x00
SLOT 8 uncompressed header data:
0x01 0x09 0x10 0x01 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00
SLOT 8: ndevfuncs 0
Slot 8:0 done
CPU 0: fatal kernel trap:
CPU 0 trap entry =3D 0x2 (memory management fault)
CPU 0 a0 =3D 0xfffffe0000058000
CPU 0 a1 =3D 0x1
CPU 0 a2 =3D 0x0
CPU 0 pc =3D 0xfffffc000058fa10
CPU 0 ra =3D 0xfffffc000059008c
CPU 0 pv =3D 0xfffffc00004974a0
CPU 0 curlwp =3D 0xfffffc0000bc3c20
CPU 0 pid =3D 0, comm =3D swapper
panic: trap
Stopped in pid 0.1 (swapper) at 0xfffffc00005da244: ret
zero,(ra)
db>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Christoph Franzen
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Sun, 22 Jul 2007 08:08:14 +0900
ChristophFranzen@gmx.net wrote:
> The Jensen has got exactly 6 EISA slots and the system board, so
> there should only the slots 0, 1, 2, 3, 4, 5, 6 being found.
Maybe EISA spec allows up to 16 slots, but I guess
it's implementation specific how many slots should
be probed on boot.
Newer 20070720 image has a fix that makes eisa_init()
check only slot 0-7. Please let me know how it works.
> The card in slot 1, however, is found as ISA, not EISA by the SRM
> while the real ISA card is not seen by the SRM console at all.
I guess this is VGA and it's handled something specially.
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Sun, 22 Jul 2007 03:19:17 +0200
Hello!
> Newer 20070720 image has a fix that makes eisa_init()
> check only slot 0-7. Please let me know how it works.
I'm sorry, I thought the last log already was from the new version,
but obviously it was not successfully written to the disk, and the
older version survived somehow. I called "dd" via SSH on another
computer, I guess this failed somehow.
> > The card in slot 1, however, is found as ISA, not EISA by the SRM
> > while the real ISA card is not seen by the SRM console at all.
>
> I guess this is VGA and it's handled something specially.
Yes, this is the VGA, an Elsa Winner 1000 (S3 chipset). This one is
special, you have to select the correct file in the ECU by Hand. The
Jensen calls the VGA BIOS to initialise the card. In fact, this is a
real EISA card; as you can see below, Netbsd seems also to "think"
that it's ISA only. I have tried to configure the CPQ6101, but it's
not recognized... But that's not a real problem for now.
Below you find the new log. This one shows apparently an error which
also occured in a previous version of Netbsd. It hangs forever after
recognising the floppy. I read old posts in the archives where
somebody said that removing the floppy would not work.
---------------------------------
NetBSD 4.0_BETA2 (INSTALL) #9: Sat Jul 21 05:26:43 JST 2007
tsutsui@mirage:/r/work/src-
4.0/src/sys/arch/alpha/compile/obj.alpha/INSTALL
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 21120 KB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
pckbc0 at jensenio0 port 0x60
pms0 at pckbc0 (aux slot)
pckbc0: aux slot interrupting at vector 0x990
wsmouse0 at pms0 (mux ignored)
com0 at jensenio0 port 0x3f8: ns8250 or ns16450, no fifo
com0: console
com0: interrupting at vector 0x900
com1 at jensenio0 port 0x2f8: ns8250 or ns16450, no fifo
com1: interrupting at vector 0x920
lpt0 at jensenio0 port 0x3bc
lpt0: interrupting at eisa irq 1
mcclock0 at jensenio0 port 0x170: mc146818 or compatible
eisa0 at jensenio0
ahb0 at eisa0 slot 2: Adaptec AHA-1742A SCSI
ahb0: interrupting at eisa irq 12
scsibus0 at ahb0: 8 targets, 8 luns per target
device CPQ6101 at eisa0 slot 3 not configured
isa0 at jensenio0
depca: address not found
we1 at isa0 port 0x300-0x31f iomem 0xcc000-0xcffff irq 10
we1: WD8013EPC Ethernet (16-bit)
we1: Ethernet address 00:00:c0:db:6c:2e
vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
wsdisplay0 at vga0 (kbdmux ignored)
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
---------------------------------
Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Sun, 22 Jul 2007 10:53:04 +0900
ChristophFranzen@gmx.net wrote:
> Below you find the new log. This one shows apparently an error which
> also occured in a previous version of Netbsd. It hangs forever after
> recognising the floppy. I read old posts in the archives where
> somebody said that removing the floppy would not work.
Could you get ddb(4) prompt by sending break via serial console
at the point?
After fdc(4), I guess mcclock at isa (which should be not matched) is
checked, interrupts are enabled, and then fd0 at fdc0 is probed.
("scsibus0: waiting 2 seconds..." message should follow)
If you can get ddb(4) prompt, I guess interrupts might be enabled
but not served properly. We could get some info by backtrace anyway.
If not, we should check where actually the hang occurs
during cpu_configure(9), by sprinkling printf or so.
---
Izumi Tsutsui
From: Izumi Tsutsui <tsutsui@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: PR/36628 CVS commit: src/sys/arch/alpha
Date: Sun, 22 Jul 2007 02:14:40 +0000 (UTC)
Module Name: src
Committed By: tsutsui
Date: Sun Jul 22 02:14:40 UTC 2007
Modified Files:
src/sys/arch/alpha/eisa: eisa_machdep.c
src/sys/arch/alpha/include: eisa_machdep.h
src/sys/arch/alpha/jensenio: jensenio.c
src/sys/arch/alpha/pci: sio.c
Log Message:
More fixes for Jensen, reported and tested by Christoph Franzen
in PR port-alpha/36628:
- make jensenio_eisa_maxslots() return 8 (instead of 16) since
EISA config for slot 8-15 on jensen could return invalid values
- pass eisa_chipset_tag_t to eisa_init() and check eisa_maxslots()
on probing EISA config space
- pass M_ZERO to malloc(9) and make sure malloc(9) doesn't fail
- fix typo in a debug printf, add more debug printfs, and
use #ifdef EISA_DEBUG to enable them
- cast uint8_t value to uint32_t before shift more than 8 bits
- check buffer region on reading compressed data from EISA config space
To generate a diff of this commit:
cvs rdiff -r1.5 -r1.6 src/sys/arch/alpha/eisa/eisa_machdep.c
cvs rdiff -r1.7 -r1.8 src/sys/arch/alpha/include/eisa_machdep.h
cvs rdiff -r1.13 -r1.14 src/sys/arch/alpha/jensenio/jensenio.c
cvs rdiff -r1.40 -r1.41 src/sys/arch/alpha/pci/sio.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Sun, 22 Jul 2007 15:44:08 +0200
Hello again,
> > This one shows apparently an error which
> > also occured in a previous version of Netbsd. It hangs forever after
> > recognising the floppy. I read old posts in the archives where
> > somebody said that removing the floppy would not work.
I investigated further and finally found some hint about the same or
a similar issue in the archive:
http://mail-index.netbsd.org/port-alpha/2001/01/09/0001.html
> Could you get ddb(4) prompt by sending break via serial console
> at the point?
Yes, the ddb unfortunately gives no further information, though (at
least nothing seeming useful to me).
> After fdc(4), I guess mcclock at isa (which should be not matched) is
> checked, interrupts are enabled, and then fd0 at fdc0 is probed.
> ("scsibus0: waiting 2 seconds..." message should follow)
>
> If you can get ddb(4) prompt, I guess interrupts might be enabled but
> not served properly. We could get some info by backtrace anyway. If
> not, we should check where actually the hang occurs during
> cpu_configure(9), by sprinkling printf or so.
I think it would be best to try some printfs.
--
Christoph Franzen
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Mon, 23 Jul 2007 00:27:42 +0900
ChristophFranzen@gmx.net wrote:
> > Could you get ddb(4) prompt by sending break via serial console
> > at the point?
>
> Yes, the ddb unfortunately gives no further information, though (at
> least nothing seeming useful to me).
Maybe INSTALL kernel in cdhdtape doesn't have symbol table
so trace command doesn't work properly.
I've put cdhdtape image which contains GENERIC with some printfs
(but not root md image):
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-GENERIC-20070722.gz
If you can get ddb(4) prompt, please try
"trace", "ps/w", "show event" and "show uvmexp" etc.
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Sun, 22 Jul 2007 20:01:54 +0200
Hello.
> > > Could you get ddb(4) prompt by sending break via serial console at
> > > the point?
> >
> > Yes, the ddb unfortunately gives no further information>
> Maybe INSTALL kernel in cdhdtape doesn't have symbol table
> so trace command doesn't work properly.
> I've put cdhdtape image which contains GENERIC with some printfs
This time "trace" works.
There seems to be something wrong however. The ECU configuration
shows the SCSI adapter at IRQ 11 while Netbsd shows EISA IRQ 12. The
host adapter is revision E.
--------
NetBSD 4.0_BETA2 (GENERIC) #3: Mon Jul 23 00:13:17 JST 2007
tsutsui@mirage:/r/work/src-4.0/src/sys/arch/alpha/compile/GENERIC
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 20200 KB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
pckbc0 at jensenio0 port 0x60
pms0 at pckbc0 (aux slot)
pckbc0: aux slot interrupting at vector 0x990
wsmouse0 at pms0 mux 0
com0 at jensenio0 port 0x3f8: ns8250 or ns16450, no fifo
com0: console
com0: interrupting at vector 0x900
com1 at jensenio0 port 0x2f8: ns8250 or ns16450, no fifo
com1: interrupting at vector 0x920
lpt0 at jensenio0 port 0x3bc
lpt0: interrupting at eisa irq 1
mcclock0 at jensenio0 port 0x170: mc146818 or compatible
eisa0 at jensenio0
ahb0 at eisa0 slot 2: Adaptec AHA-1742A SCSI
ahb0: interrupting at eisa irq 12
scsibus0 at ahb0: 8 targets, 8 luns per target
Compaq NetFlex-2 ENET-TR at eisa0 slot 3 not configured
isa0 at jensenio0
depca: address not found
attimer0 at isa0 port 0x40-0x43: AT Timer
we1 at isa0 port 0x300-0x31f iomem 0xcc000-0xcffff irq 10
we1: WD8013EPC Ethernet (16-bit)
we1: Ethernet address 00:00:c0:db:6c:2e
vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
wsdisplay0 at vga0 kbdmux 1
wsmux1: connecting to wsdisplay0
pcppi0 at isa0 port 0x61
pcppi0: children must have an explicit unit
midi0 at pcppi0: PC speaker (CPU-intensive output)
spkr0 at pcppi0
isabeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
pcppi0: attached to attimer0
enabling interrupts
Stopped in pid 0.1 (swapper) at netbsd:cpu_Debugger+0x4: ret
zero,(ra
)
db> trace
cpu_Debugger() at netbsd:cpu_Debugger+0x4
comintr() at netbsd:comintr+0x920
com_jensenio_intr() at netbsd:com_jensenio_intr+0x24
interrupt() at netbsd:interrupt+0x1f4
XentInt() at netbsd:XentInt+0x1c
--- interrupt (from ipl 0) ---
spl0() at netbsd:spl0+0x30
cpu_configure() at netbsd:cpu_configure+0x70
configure() at netbsd:configure+0x44
main() at netbsd:main+0x1bc
locorestart() at netbsd:locorestart+0x64
--- root of call graph ---
db> ps/w
PID COMMAND EMUL PRI UTIME STIME WAIT-MSG WAIT-
CHANNEL
>0 swapper netbsd 0 0.0 0.0
db> show event
evcnt type 0: uvmmap ukh_alloc = 2
evcnt type 0: uvmmap uke_free = 10
evcnt type 0: uvmmap uke_alloc = 65
evcnt type 0: uvmmap mlk_hint = 1
evcnt type 0: uvmmap mlk_call = 6
evcnt type 0: uvmmap map_call = 60
evcnt type 0: uvmmap knomerge = 12
evcnt type 0: uvmmap kbackmerge = 48
evcnt type 1: cpu0 device = 6390298
evcnt type 1: eisa irq 12 = 6390297
evcnt type 1: vector 0x900 = 1
db> show uvmexp
Current UVM status:
pagesize=8192 (0x2000), pagemask=0x1fff, pageshift=13
2547 VM pages: 0 active, 0 inactive, 0 wired, 2418 free
pages 0 anon, 0 file, 0 exec
freemin=0, free-target=0, wired-max=0
faults=0, traps=1, intrs=6390298, ctxswitch=0
softint=0, syscalls=0, swapins=0, swapouts=0
fault counts:
noram=0, noanon=0, pgwait=0, pgrele=0
ok relocks(total)=0(0), anget(retrys)=0(0), amapcopy=0
neighbor anon/obj pg=0/0, gets(lock/unlock)=0/0
cases: anon=0, anoncow=0, obj=0, prcopy=0, przero=0
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=0, swpgavail=0
swpages=0, swpginuse=0, swpgonly=0, paging=0
db> show vnode
CPU 0: fatal kernel trap:
CPU 0 trap entry = 0x4 (unaligned access fault)
CPU 0 a0 = 0xfffffc00008d571c
CPU 0 a1 = 0x29
CPU 0 a2 = 0x13
CPU 0 pc = 0xfffffc000063cb60
CPU 0 ra = 0xfffffc000070377c
CPU 0 pv = 0xfffffc000063cb30
CPU 0 curlwp = 0xfffffc0000bdd528
CPU 0 pid = 0, comm = swapper
Caught exception in ddb.
panic: longjmp botch from 0xfffffc0000412320
Stopped in pid 0.1 (swapper) at 0x20:
CPU 0: fatal kernel trap:
[...] repeatedly, so I interrupted that.
------------
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Mon, 23 Jul 2007 20:16:22 +0900
ChristophFranzen@gmx.net wrote:
> There seems to be something wrong however. The ECU configuration
> shows the SCSI adapter at IRQ 11 while Netbsd shows EISA IRQ 12. The
> host adapter is revision E.
Hmm. According to src/sys/dev/eisa/ahb.c, the irq setting
is stored in AHA-1742 INTDEF register so the ECU should
set up the card properly but somehow it doesn't.
Does the card work on other OSes (DIGITAL UNIX or Linux)?
One concern is that the EISA config file provided by DEC
doesn't have "CHOICE" section for IRQ levels while
the Adaptec one for x86 has it:
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/archive/ecu/ntecuv111a.zip
http://www.adaptec.com/en-US/speed/eprom_bios/aswc174_exe.htm
What "CHOICE" items are shown on the ECU menu for AHA-1742A?
If there is no IRQ "CHOICE", what happens if you choose
"BIOS Base Address E8000H" one?
(it seems to set the ahb INTDEF register irq 11 LEVEL)
> db> trace
> cpu_Debugger() at netbsd:cpu_Debugger+0x4
> comintr() at netbsd:comintr+0x920
> com_jensenio_intr() at netbsd:com_jensenio_intr+0x24
> interrupt() at netbsd:interrupt+0x1f4
> XentInt() at netbsd:XentInt+0x1c
> --- interrupt (from ipl 0) ---
> spl0() at netbsd:spl0+0x30
> cpu_configure() at netbsd:cpu_configure+0x70
> configure() at netbsd:configure+0x44
> main() at netbsd:main+0x1bc
> locorestart() at netbsd:locorestart+0x64
> --- root of call graph ---
:
> db> show event
> evcnt type 1: cpu0 device = 6390298
> evcnt type 1: eisa irq 12 = 6390297
> evcnt type 1: vector 0x900 = 1
This indicates that the problem is unhandled interrupt
storm from eisa irq 12.
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Mon, 23 Jul 2007 16:18:04 +0200
> > There seems to be something wrong however. The ECU configuration
> > shows the SCSI adapter at IRQ 11 while Netbsd shows EISA IRQ 12.
> Hmm. According to src/sys/dev/eisa/ahb.c, the irq setting
> is stored in AHA-1742 INTDEF register so the ECU should
> set up the card properly but somehow it doesn't.
This is weird. My logs from the July 19th and previous versions of
cdhdtape show the correct IRQ 11. The next version (the one with max.
8 instead of 16 slots), however, shows IRQ 12.
*After* that I've run the ECU (V.1.10 vor SRM) again and configured
the ISA card in the 6th slot according to its jumper settings, just
to be sure that there is no conflict. The GENERIC version which I
installed afterwards also misses the IRQ.
> Does the card work on other OSes (DIGITAL UNIX or Linux)?
I did not try THIS particular card, but I've got three almost
identical Jensen machines, and I checked the host adapter "MCODE"
revisions, they are all "E". The other two machines run well with
Windows NT up to 4.0 and Linux. Linux even did not complain when the
machine's ARC consol "thought" that the ECU should be run again due
to an empty battery, it booted nonetheless.
> One concern is that the EISA config file provided by DEC
> doesn't have "CHOICE" section for IRQ levels while
> the Adaptec one for x86 has it:
> ftp://ftp.digital.com/pub/DEC/Alpha/firmware/archive/ecu/ntecuv111a.zip
> http://www.adaptec.com/en-US/speed/eprom_bios/aswc174_exe.htm
If I recall correctly, the Adaptec Version needs an x86 specific
overlay and is therefore unusable on an Alpha.
Thank you for pointing me to the file "ntecuv111a.zip". This is
apparetly the most recent ECU version available (more recent than my
ones here). While this ECU should work, it is not intended for the
SRM console (OSF1/Digital Unix and VMS), but for ARC (Windows NT).
There seem to be differences according to the file I attached below
(which nowadays appears to be available from the Google cache only).
The VMS/Unix version is "ecuopenvmv111a.zip" in the same directory of
the FTP server. Generally, you *can* use both ECU versions from the
SRM as well as from the ARC console, NT and Linux did never complain.
> What "CHOICE" items are shown on the ECU menu for AHA-1742A?
> If there is no IRQ "CHOICE", what happens if you choose
> "BIOS Base Address E8000H" one?
> (it seems to set the ahb INTDEF register irq 11 LEVEL)
The ECU does not allow to choose the interrupt directly, but while
the appropriate item is highlighted, you can enter an "advanced"
window where you can change this setting. There it showed 11 when I
have run the ECU again, also in the window where you can watch all
used resources, 11 was displayed for this slot, 12 was shown as a
free resource.
I will reconfigure the box with the "new" ECU version 1.11a for
VMS/Unix and investigate further.
Perhaps I'll also swap the controllers of my Jensens just to be sure
that this one is not defective.
There are also rumours that the "MCODE revision E" is buggy, but
almost all x86 EISA machines as well as the NT Alpha machines sold in
Germany used this without a problem, and I never had any difficulties
using these with Linux or NT.
The following file has some information (I hope it "survives"):
<<< SSAG::DISK$ARCH2:[NOTES$LIBRARY.SSAG]ASK_SSAG.NOTE;7 >>>
-< Ask the Storage Architecture Group >-
======================================================================
==========
Note 5599.1 DEC 2000-500 PROBLEM
1 of 1
BLOFLY::SMITHP "Beware the knights who say "NT"..." 244 lines 30-MAY-
1996 03:00
-< information... >-
----------------------------------------------------------------------
----------
I have attached a v.old Jensen/Culzean support note. Looks like
you
MUST disable floppy controller and MUST NOT remove the on-board
termination resistors from the 2nd 1742A.
Hope this helps.
Cheers, P.
Here are some useful snippets of poorly documented or hard-to-find
Jensen /
DECpc AXP 150 / DEC 2000-300 and Culzean / DEC 2000-500 info:
- There are some good notes file containing general Jensen/Culzean
and OS
specific info - AYJEN1::JENSEN, EVMS::JENSEN_VMS and DECWET::NTAXP
- The VMS/OSF and NT ECU (EISA Configuration Utility) are almost,
but NOT, the
same. The main difference is in how multiple SCSI adaptors are
configured.
While VMS can auto-configure the standard devices (i.e.
motherboard resident
plus one SCSI and one Ethernet adaptor) even if the ECU hasn't
been run, the
VMS specific ECU must be used if duplicate adaptors or a graphics
card is
present.
NOTE: It is usually possible to run Windows NT perfectly well
using the
VMS/OSF ECU, although not vice versa.
- Upgrading or reloading the console firmware causes all boot setup
entries
and environment variables to be lost. The customers must write
down all
the settings before up/downgrading so they can be re-entered by
hand - if
they don't, they won't be able to reboot afterwards.
Alternatively, there are a pair of DEC supplied (sometimes!)
utilities named
SAVEENV.EXE and RESTENV.EXE that can be run from a floppy using
the console
NT menu, and which will save and restore the NT environment part
of the
NVRAM to and from the file FWENV.SAV on a floppy. These utilities
can be
found on node RIPPER:: in the SYS$KITS:[AXP_FIRMWARE.JENSEN]
directory.
NOTE: Unless you do the "Set default environment variables" and
"Set default
configuration" items in the "Set up the system..." menu
before you
run RESTENV, the environment variable for drive A: won't be
defined
and you will have to run RESTENV as
eisa(0)disk(0)fdisk(0)RESTENV.EXE
instead of A:RESTENV.EXE.
- The algorithms that VMS & the Jensen/Culzean console firmware use
to assign
"controller letters" to adaptor cards when more than one of a
particular
type is present are NOT the same. Unless care is taken when
installing
cards, VMS and the >>> console will have different names for the
same
device. See EVMS::JENSEN_VMS note 55.8 for details on how to
avoid this.
- Part number PCTAZ-AB (Adaptec 1740A SCSI adapter) is no longer
valid for
ordering as an additional SCSI adapter on the Jensen / Culzean.
It never
had the correct firmware version for these systems and is now no
longer
even available - all orders for the PCTAZ-AB are currently being
fulfilled
with a PCTAZ-CB (Adaptec 2740). The PCTAZ-CB is *not* supported
by VMS,
OSF/1 or the firmware (although it can be made to work under
Windows NT
with a lot of fiddling). To obtain an additional SCSI adapter you
should
now order a PB2HA-SA (Adaptec 1742A) and disable its floppy
controller.
NOTE: The installation instructions currently tell you to remove
the
on-board SCSI terminator packs on all additional SCSI
adapters.
This is WRONG and should never be done!
- To connect an external SCSI device to the first Adaptec 1742A SCSI
adapter
(i.e. the one controlling the internal SCSI devices) in a
Jensen/Culzean
the three on-board terminator resistor packs on the SCSI adaptor
MUST be
removed. However, this should *not* be done on any additional
1740A or
1742A SCSI adapters.
Once the terminators are removed an external device or a
terminator plug
must always be plugged into the external connector on the 1742A.
- The correct external SCSI terminator for the 174xA's is the 12-
35759-01 (as
originally used on the DECpc 433W) or the 12-37791-01 (used on the
the DECpc
425ST). The electrically identical 12-33626-01 / H8578-AA used on
the
DECstation 5000-25 will NOT physically fit.
- There have been multiple revisions of the MCODE firmware on the
Adaptec
174xA SCSI controllers that are used in the Jensen and Culzean
platforms.
The following should help you know what revision you need and how
to
identify what you have:
OSF/1 V1.3B will refuse to use any 174xA that doesn't contain rev
G.2 or
higher MCODE, and VMS V1.5-1H1 will do the same unless it sees rev
G.1 or
higher. Windows NT (both Beta and SSB) will work with any rev,
but will
work more reliably with the latest MCODE.
To identify the MCODE rev on a 174xA either do a ">>> SHOW DEVICE"
in
VMS/OSF console mode, or look at the checksum on the 174xA MCODE
EPROM.
(The EPROM will be marked "MCODE xxxx", where xxxx is the
checksum.)
MCODE rev Checksum Comment
--------- -------- -------
G.2 BCE3 Minimum rev for OSF/1 V1.3B and above
G.1 C3DD Minimum rev for OpenVMS AXP V1.5-1H1 and
above
G B646 Shipped in DECpc AXP 150 "developer
specials"
F B6CF Rare, mostly seen in prototype machines
E B7D6 "Generic" 174xA's have rev E MCODE
A pre-programmed rev G.2 EPROM can be ordered as part number 23-
681E6-00.
N.B.: Revisions F, G, G.1 and G.2 were special releases of
firmware
provided to Digital by Adaptec to fix bugs found by VMS and
OSF/1
engineering, and are only found in 174xA's sold by DEC
specifically
for the Jensen/Culzean. They aren't shipping with "generic"
Adaptec
174xA's and possibly never will. The highest MCODE revision
Adaptec
has released on generic 174xA's is rev E.
There is currently no such thing as rev H MCODE - the
message
demanding rev H that the OSF/1 install process displays when
it
encounters old MCODE is in error. The correct rev for OSF/1
is G.2
(or higher). Also, the revision (usually H) reported when
booting an
Intel-based PC with the 174xA's BIOS enabled is the BIOS
revision,
not the MCODE revision. The 174xA BIOS is not used at all
on AXP PCs.
- The 174xA's are FAST-SCSI (10MB/sec) capable and if there are any
FAST-SCSI
devices (e.g. an RZ26) the maximum total effective cable length is
3 metres.
The first 1742A already has 1 metre of internal cable, so its
external max
would be 2M. As an example, the BA350 Storageworks box is
equivalent to 0.9
metres of cable so the maximum supported connecting cable length
would be
1M unless you used DWZZA repeaters. I've seen lightly loaded
BA350's with
one or two RZ26's work fine with a 2M cable off the 1742A, but I
wouldn't
want to try it with a fully populated BA350.
- The correct SCSI cable (50-pin micro Honda -> 50 pin CHAMP-
Centronics) for
connecting the 174xA to a TK50 (or similar device with the old-
style large
SCSI connectors) is a BC09D-xx (e.g. 3 foot is BC09D-03 and 6 foot
is -06).
- To temporarily enable the alternate console port (serial port 1)
just
disconnect the keyboard cable before powering up the system, or
you can
SET CONSOLE SERIAL at the >>> prompt for a more lasting effect.
(>>> SET
CONSOLE VGA goes back to the graphic console.) The default setup
is 9600
baud, 8 bits, no parity, one stop bit. The console terminal must
be set
to send 8 bit control sequences for the arrow keys to work
properly in
console mode. The correct serial port to DECconnect adapter plug
is the
H8571-J.
NOTE: When using the serial port console there is NO WAY to
prevent
CTRL-P and BREAK from halting the system - they are always
enabled!
- The only graphics card currently supported by VMS V1.5-1H1 and
OSF/1 V1.3B
is the Compaq Qvision 1024E. Windows NT also supports the #9 GXE
card, but
there are NO plans to support this card under VMS or OSF! The
next (Jensen
and Culzean) graphics support planned for VMS/OSF is for the ATI
Mach-32
Ultra Pro and for low-end standard VGA.
- When using the Qvision graphics card under VMS the SYSGEN
parameter
VIRTUALPAGECNT must be set to at least 400,000 to allow the X
server to
map the frame buffer, otherwise it fails with a %SYSTEM-F-VASFULL
error.
- VMS accesses the console, keyboard, mouse and serial ports via
console
firmware routines and they are thus all OPAx devices - the
numbering is as
follows:
OPA0: Serial port 1 when using the alternate console
OR
Graphics head operator window when using the graphics console.
OPA1: *Serial port 2
OPA2: The PC keyboard port
OPA3: The mouse
OPA4: *Serial port 1 when using the graphics console
*Note: As of console firmware V1.2, the built-in serial ports
(OPA1: and
OPA4:) still don't work when using the graphics console.
As a
work-around you can install a PC4XD-AA serial/parallel
card; see
JENSEN_VMS note 61.10
- Other Jensen & Culzean specific VMS device names are as follows:
DVA0: The RX26 2.88MB floppy drive
(HINT: Use "$ INIT/DENS=xx DVA0: <label>" to format floppies,
where xx = ED for 2.88MB, HD for 1.44MB, or DD for 720K)
LRA0: The parallel printer port
GQA0: The Compaq Qvision 1024E card
ERA0: The DE422 Ethernet card
- The V1.2 firmware for the Jensen still has the following
shortcomings when
running VMS:
> Support for the 2 serial ports (as OPA4 & OPA1) doesn't work
yet when
the graphics card is used as the console (fixed in V1.3).
> Poor mouse performance under VMS (firmware not buffering
mouse data -
fixed in V1.3). OSF and Windows NT don't use the firmware routines
for mouse access and don't have this problem.
> No boot support for the floppy from the VMS/OSF >>> prompt,
and none
is planned as far as I know. However, V1.2 does add a >>> RUNECU
command to allow the ECU utility to be run from floppy under the
VMS/OSF console.
- The V1.5-1H1 parallel port driver for the Jensen doesn't work with
some DEC
and foreign printers, e.g. the DECwriter 95 - see JENSEN_VMS note
61.10 for
details. To be fixed in a later release of the LRDRIVER.
- The Jensen / Culzean systems are currently supplied with PC7XL-AA
or
PCXAL-AA keyboards, which have the enhanced PC-AT style 101 key
layout and
keys. The key combinations required to simulate the extra keys
present on
a DEC standard keyboard are documented on pages 1-3 & 1-4 of the
OpenVMS
AXP Version 1.5-1H1 Release Notes and Update Procedures (AV-Q1CRA-
TE).
NOTE: As of V1.2 of the firmware, the console commands to set up
for
keyboards with anything other than US or UK key layouts
(e.g.,
>>> SET KEYBOARD SUISSE) don't do anything. This will be
fixed
in V1.3 of the firmware.
- The LK450 keyboard (a PC-interface keyboard with the DEC standard
LK401 key
layout and function keys which is ideal for use with VMS or OSF/1
by people
used to DEC keyboards) is not supported by the SSB version of VMS
V1.5-1H1,
but updated drivers (SYS$IKBDRIVER.EXE and SYS$INBDRIVER.EXE) can
be copied
from BULOVA::ALPHA$KITS:[V15_SSB.UPDATE.V15_1H1] and then placed
in the
SYS$LOADABLE_IMAGES: directory.
- The Jensen/Culzean console has no provision for either low- or
high-level
formatting of system disks. The Windows NT installation utility
requires
that the hard disk already have a valid PC-style partition table,
but it
doesn't tell you how to create one and the method isn't documented
anywhere!
ARCINST.EXE is the Microsoft utility which allows you to create
the
partition table and Windows NT system partition on a Jensen disk
drive, and
it can be found in the \alpha directory on the AXP Windows NT
distribution
CDROM.
To partition a disk and/or configure an NT system partition:
1. Select 'Run a Program from the Boot Menu
2. Run the ARCINST.EXE program which is contained on the
normal
Windows NT distribution CD
Program to Run : cd:\alpha\arcinst.exe
3. Select 'Configure Partitions'
NOTE: If at any stage you make a mistake you can press the
ESC key
to abort and return to the previous menu level.
4. If you know that there are no existing partitions on the
disk you
wish to configure, go to step 5. Otherwise do the
following to
display the existing partitions and, if necessary, delete
some or
all of them. Select 'Delete Partition'. If you have more
than one
disk drive highlight the drive that you wish to configure
and press
Enter. Take great care to select the correct drive as the
naming
convention that ARCINST uses differs from that used by the
firmware
console. The list of partitions on the disk will be
displayed. If
you wish to delete a partition select it and press Enter;
otherwise
press ESC. Repeat step 4 until all unwanted partitions are
removed.
NOTE: Only FAT-format partitions of 4MBytes or more may be
used as
system partitions.
5. Select 'Create Partition'. If you have more than one
drive,
highlight the one that will contain the partition and
press Enter.
Take care to select the correct drive as the naming
convention
that ARCINST uses differs from that used by the firmware
console.
Type in the size of the partition (the system partition
must be at
least 4 MBytes) and press Enter to create it, followed by
any key
to format it.
During the Windows NT installation the loader file
OSLOADER.EXE will
be installed within the system partition. If you wish, you
can use
ARCINST.EXE to create a further partition (by carrying out
steps 4
and 5 again) which will hold all of the operating system
files (this
partition should be at least 130 MBytes in size). If you
don't create
this partition now you will be able to create one during the
Windows
NT installation process, but you will have to accept the
default size
(which is all of the remaining disk space).
6. Exit the ARCINST.EXE program back to the Boot Menu.
--
Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Tue, 24 Jul 2007 01:01:22 +0900
ChristophFranzen@gmx.net wrote:
> > Hmm. According to src/sys/dev/eisa/ahb.c, the irq setting
> > is stored in AHA-1742 INTDEF register so the ECU should
> > set up the card properly but somehow it doesn't.
>
> This is weird. My logs from the July 19th and previous versions of
> cdhdtape show the correct IRQ 11. The next version (the one with max.
> 8 instead of 16 slots), however, shows IRQ 12.
"IRQ 11 level" is a value read from the EISA configuration space
in sys/arch/alpha/eisa/eisa_machdep.c:eisa_parse_irq() called from
eisa_init().
"ahb0: interrupting at eisa irq 12" is a value read from
the INTDEF register on AHA-1742 in sys/dev/eisa/ahb.c:ahb_find()
called from ahbattach().
Then I thought the ECU didn't set ahb's register, but
maybe other OSes always prefer the ECU's value, I guess.
(though I'm not sure if it could be a problem if there is no IRQ conflict)
I've written a quick patch which makes ahb use the ECU irq value
if it's different from card setting. Could you try this one?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-GENERIC-20070723.gz
---
Index: sys/dev/eisa/ahb.c
===================================================================
RCS file: /cvsroot/src/sys/dev/eisa/ahb.c,v
retrieving revision 1.47
diff -u -r1.47 ahb.c
--- sys/dev/eisa/ahb.c 16 Nov 2006 01:32:50 -0000 1.47
+++ sys/dev/eisa/ahb.c 23 Jul 2007 15:37:03 -0000
@@ -201,6 +201,8 @@
struct ahb_probe_data apd;
struct scsipi_adapter *adapt = &sc->sc_adapter;
struct scsipi_channel *chan = &sc->sc_channel;
+ struct eisa_cfg_irq eci;
+ uint8_t intdef;
if (!strcmp(ea->ea_idstring, "ADP0000"))
model = EISA_PRODUCT_ADP0000;
@@ -254,6 +256,46 @@
return;
}
+ /*
+ * On some alpha machines (Jensen), ECU doesn't set
+ * INTDEF register properly, so check the ECU irq value
+ * if it's available and override the card setting with it.
+ */
+ if (eisa_conf_read_irq(ea->ea_ec, ea->ea_slot, 0, 0, &eci) == 0) {
+ if (apd.sc_irq != eci.eci_irq) {
+ printf("%s: INTDEF configured to use irq %d, "
+ "but ECU configured to use irq %d\n",
+ sc->sc_dev.dv_xname, apd.sc_irq, eci.eci_irq);
+ apd.sc_irq = eci.eci_irq;
+ intdef = bus_space_read_1(iot, ioh, INTDEF);
+ intdef &= ~(INTMASK | INTHIGH);
+ switch (apd.sc_irq) {
+ case 9:
+ intdef |= INT9;
+ break;
+ case 10:
+ intdef |= INT10;
+ break;
+ case 11:
+ intdef |= INT11;
+ break;
+ case 12:
+ intdef |= INT12;
+ break;
+ case 14:
+ intdef |= INT14;
+ break;
+ case 15:
+ intdef |= INT15;
+ break;
+ }
+ if (eci.eci_ist == IST_LEVEL)
+ intdef |= INTHIGH;
+
+ bus_space_write_1(iot, ioh, INTDEF, (intdef | INTEN));
+ }
+ }
+
if (eisa_intr_map(ec, apd.sc_irq, &ih)) {
printf("%s: couldn't map interrupt (%d)\n",
sc->sc_dev.dv_xname, apd.sc_irq);
Index: sys/dev/eisa/ahbreg.h
===================================================================
RCS file: /cvsroot/src/sys/dev/eisa/ahbreg.h,v
retrieving revision 1.15
diff -u -r1.15 ahbreg.h
--- sys/dev/eisa/ahbreg.h 11 Dec 2005 12:21:20 -0000 1.15
+++ sys/dev/eisa/ahbreg.h 23 Jul 2007 15:37:03 -0000
@@ -77,6 +77,7 @@
#define INT12 0x03
#define INT14 0x05
#define INT15 0x06
+#define INTMASK 0x07
#define INTHIGH 0x08 /* int high=ACTIVE (else edge) */
#define INTEN 0x10
/**** bit definitions for SCSIDEF ****/
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Tue, 24 Jul 2007 23:45:04 +0200
> Then I thought the ECU didn't set ahb's register, but
> maybe other OSes always prefer the ECU's value, I guess.
> (though I'm not sure if it could be a problem if there is no IRQ
> conflict)
I tried to resolve the conflict by setting the IRQ to 12 in the ECU.
This did not help (not with the old and new GENERIC version).
> I've written a quick patch which makes ahb use the ECU irq value
> if it's different from card setting. Could you try this one?
This doesn't work either:
-----------------------------
NetBSD 4.0_BETA2 (GENERIC) #4: Tue Jul 24 00:35:42 JST 2007
tsutsui@mirage:/r/work/src-4.0/src/sys/arch/alpha/compile/GENERIC
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 20200 KB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
pckbc0 at jensenio0 port 0x60
pms0 at pckbc0 (aux slot)
pckbc0: aux slot interrupting at vector 0x990
wsmouse0 at pms0 mux 0
com0 at jensenio0 port 0x3f8: ns8250 or ns16450, no fifo
com0: console
com0: interrupting at vector 0x900
com1 at jensenio0 port 0x2f8: ns8250 or ns16450, no fifo
com1: interrupting at vector 0x920
lpt0 at jensenio0 port 0x3bc
lpt0: interrupting at eisa irq 1
mcclock0 at jensenio0 port 0x170: mc146818 or compatible
eisa0 at jensenio0
ahb0 at eisa0 slot 2: Adaptec AHA-1742A SCSI
panic: jensenio_eisa_intr_map: bogus IRQ 9114572
Stopped in pid 0.1 (swapper) at netbsd:cpu_Debugger+0x4: ret
zero,(ra
)
db> trace
cpu_Debugger() at netbsd:cpu_Debugger+0x4
panic() at netbsd:panic+0x1e8
jensenio_eisa_intr_map() at netbsd:jensenio_eisa_intr_map+0xb4
ahbattach() at netbsd:ahbattach+0x69c
config_attach_loc() at netbsd:config_attach_loc+0x420
eisaattach() at netbsd:eisaattach+0x2a4
config_attach_loc() at netbsd:config_attach_loc+0x420
jensenio_attach() at netbsd:jensenio_attach+0x178
config_attach_loc() at netbsd:config_attach_loc+0x420
mbattach() at netbsd:mbattach+0x168
config_attach_loc() at netbsd:config_attach_loc+0x420
cpu_configure() at netbsd:cpu_configure+0x44
configure() at netbsd:configure+0x44
main() at netbsd:main+0x1bc
locorestart() at netbsd:locorestart+0x64
--- root of call graph ---
db> ps/w
PID COMMAND EMUL PRI UTIME STIME WAIT-MSG WAIT-
CHANNEL
>0 swapper netbsd 0 0.0 0.0
db> show event
evcnt type 0: uvmmap ukh_alloc = 2
evcnt type 0: uvmmap uke_free = 10
evcnt type 0: uvmmap uke_alloc = 64
evcnt type 0: uvmmap mlk_hint = 1
evcnt type 0: uvmmap mlk_call = 6
evcnt type 0: uvmmap map_call = 59
evcnt type 0: uvmmap knomerge = 12
evcnt type 0: uvmmap kbackmerge = 47
db> show uvmexp
Current UVM status:
pagesize=8192 (0x2000), pagemask=0x1fff, pageshift=13
2547 VM pages: 0 active, 0 inactive, 0 wired, 2428 free
pages 0 anon, 0 file, 0 exec
freemin=0, free-target=0, wired-max=0
faults=0, traps=1, intrs=0, ctxswitch=0
softint=0, syscalls=0, swapins=0, swapouts=0
fault counts:
noram=0, noanon=0, pgwait=0, pgrele=0
ok relocks(total)=0(0), anget(retrys)=0(0), amapcopy=0
neighbor anon/obj pg=0/0, gets(lock/unlock)=0/0
cases: anon=0, anoncow=0, obj=0, prcopy=0, przero=0
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=0, swpgavail=0
swpages=0, swpginuse=0, swpgonly=0, paging=0
db>
--
Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Thu, 26 Jul 2007 23:31:14 +0900
ChristophFranzen@gmx.net wrote:
> ahb0 at eisa0 slot 2: Adaptec AHA-1742A SCSI
> panic: jensenio_eisa_intr_map: bogus IRQ 9114572
Umm. sys/arch/alpha/jensenio/jensenio_intr.c:jensenio_eisa_intr_map()
seems to check a wrong (uninitialized) arg. (How did it work before!?)
Please try again:
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-GENERIC-20070726.gz
Index: jensenio/jensenio_intr.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/jensenio/jensenio_intr.c,v
retrieving revision 1.5
diff -u -r1.5 jensenio_intr.c
--- jensenio/jensenio_intr.c 24 Dec 2005 20:06:46 -0000 1.5
+++ jensenio/jensenio_intr.c 26 Jul 2007 14:12:38 -0000
@@ -167,12 +167,14 @@
jensenio_eisa_intr_map(void *v, u_int eirq, eisa_intr_handle_t *ihp)
{
- if (*ihp >= JENSEN_MAX_IRQ)
- panic("jensenio_eisa_intr_map: bogus IRQ %d", *ihp);
+ if (eirq >= JENSEN_MAX_IRQ) {
+ printf("%s: bogus IRQ %d\n", __func__, eirq);
+ *ihp = -1;
+ return (1);
+ }
if (jensenio_intr_deftype[eirq] == IST_UNUSABLE) {
- printf("jensenio_eisa_intr_map: unusable irq %d\n",
- eirq);
+ printf("%s: unusable irq %d\n", __func__, eirq);
*ihp = -1;
return (1);
}
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Thu, 26 Jul 2007 19:54:06 +0200
Hello,
the ahb0 interrupt seems OK (the INTDEF and ECU values are both 12),
but it still hangs at "enabling interrupts", the "evcnt" number is
still large.
-----------------------
NetBSD 4.0_BETA2 (GENERIC) #6: Thu Jul 26 23:29:20 JST 2007
tsutsui@mirage:/r/work/src-4.0/src/sys/arch/alpha/compile/GENERIC
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 20200 KB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
pckbc0 at jensenio0 port 0x60
pms0 at pckbc0 (aux slot)
pckbc0: aux slot interrupting at vector 0x990
wsmouse0 at pms0 mux 0
com0 at jensenio0 port 0x3f8: ns8250 or ns16450, no fifo
com0: console
com0: interrupting at vector 0x900
com1 at jensenio0 port 0x2f8: ns8250 or ns16450, no fifo
com1: interrupting at vector 0x920
lpt0 at jensenio0 port 0x3bc
lpt0: interrupting at eisa irq 1
mcclock0 at jensenio0 port 0x170: mc146818 or compatible
eisa0 at jensenio0
ahb0 at eisa0 slot 2: Adaptec AHA-1742A SCSI
ahb0: INTDEF configured to use irq 12, ECU configured to use irq 12
ahb0: interrupting at eisa irq 12
scsibus0 at ahb0: 8 targets, 8 luns per target
Compaq NetFlex-2 ENET-TR at eisa0 slot 3 not configured
isa0 at jensenio0
depca: address not found
attimer0 at isa0 port 0x40-0x43: AT Timer
we1 at isa0 port 0x300-0x31f iomem 0xcc000-0xcffff irq 10
we1: WD8013EPC Ethernet (16-bit)
we1: Ethernet address 00:00:c0:db:6c:2e
vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
wsdisplay0 at vga0 kbdmux 1
wsmux1: connecting to wsdisplay0
pcppi0 at isa0 port 0x61
pcppi0: children must have an explicit unit
midi0 at pcppi0: PC speaker (CPU-intensive output)
spkr0 at pcppi0
isabeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
pcppi0: attached to attimer0
enabling interrupts
Stopped in pid 0.1 (swapper) at netbsd:cpu_Debugger+0x4: ret
zero,(ra
)
db> trace
cpu_Debugger() at netbsd:cpu_Debugger+0x4
comintr() at netbsd:comintr+0x920
com_jensenio_intr() at netbsd:com_jensenio_intr+0x24
interrupt() at netbsd:interrupt+0x1f4
XentInt() at netbsd:XentInt+0x1c
--- interrupt (from ipl 0) ---
spl0() at netbsd:spl0+0x30
cpu_configure() at netbsd:cpu_configure+0x70
configure() at netbsd:configure+0x44
main() at netbsd:main+0x1bc
locorestart() at netbsd:locorestart+0x64
--- root of call graph ---
db> show event
evcnt type 0: uvmmap ukh_alloc = 2
evcnt type 0: uvmmap uke_free = 10
evcnt type 0: uvmmap uke_alloc = 65
evcnt type 0: uvmmap mlk_hint = 1
evcnt type 0: uvmmap mlk_call = 6
evcnt type 0: uvmmap map_call = 60
evcnt type 0: uvmmap knomerge = 12
evcnt type 0: uvmmap kbackmerge = 48
evcnt type 1: cpu0 device = 10602292
evcnt type 1: eisa irq 12 = 10602291
evcnt type 1: vector 0x900 = 1
db> show uvmexp
Current UVM status:
pagesize=8192 (0x2000), pagemask=0x1fff, pageshift=13
2547 VM pages: 0 active, 0 inactive, 0 wired, 2418 free
pages 0 anon, 0 file, 0 exec
freemin=0, free-target=0, wired-max=0
faults=0, traps=1, intrs=10602292, ctxswitch=0
softint=0, syscalls=0, swapins=0, swapouts=0
fault counts:
noram=0, noanon=0, pgwait=0, pgrele=0
ok relocks(total)=0(0), anget(retrys)=0(0), amapcopy=0
neighbor anon/obj pg=0/0, gets(lock/unlock)=0/0
cases: anon=0, anoncow=0, obj=0, prcopy=0, przero=0
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=0, swpgavail=0
swpages=0, swpginuse=0, swpgonly=0, paging=0
db>
-----------------------
--
Christoph
From: Izumi Tsutsui <tsutsui@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: PR/36628 CVS commit: src/sys/arch/alpha/jensenio
Date: Fri, 27 Jul 2007 13:37:07 +0000 (UTC)
Module Name: src
Committed By: tsutsui
Date: Fri Jul 27 13:37:07 UTC 2007
Modified Files:
src/sys/arch/alpha/jensenio: jensenio_intr.c
Log Message:
Check a correct value on a sanity check in jensenio_eisa_intr_map().
Fixes yet another bug on Jensen found on tracking PR port-alpha/36628.
To generate a diff of this commit:
cvs rdiff -r1.5 -r1.6 src/sys/arch/alpha/jensenio/jensenio_intr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Fri, 27 Jul 2007 23:58:07 +0900
ChristophFranzen@gmx.net wrote:
> the ahb0 interrupt seems OK (the INTDEF and ECU values are both 12),
> but it still hangs at "enabling interrupts", the "evcnt" number is
> still large.
Okay, I've checked mailing list archives and notice there is
no report that ahb(4) worked on Jensen but there is the similar hang:
http://mail-index.netbsd.org/port-alpha/2000/10/29/0000.html
Looks interrupts on Jensen PICs are not ack'ed properly.
I don't know what is the right way to handle this, but
anyway could you try this one (which includes some PIC fixes)?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-GENERIC-20070727.gz
---
Index: jensenio_intr.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/jensenio/jensenio_intr.c,v
retrieving revision 1.6
diff -u -r1.6 jensenio_intr.c
--- jensenio_intr.c 27 Jul 2007 13:37:07 -0000 1.6
+++ jensenio_intr.c 27 Jul 2007 14:27:50 -0000
@@ -56,6 +56,8 @@
#include <dev/isa/isareg.h>
#include <dev/isa/isavar.h>
+#include <dev/ic/i8259reg.h>
+
#include <alpha/jensenio/jenseniovar.h>
static bus_space_tag_t pic_iot;
@@ -71,6 +73,11 @@
int jensenio_eisa_intr_alloc(void *, int, int, int *);
#define JENSEN_MAX_IRQ 16
+#define IRQ_SLAVE 2
+
+#ifndef STRAY_MAX
+#define STRAY_MAX 10
+#endif
struct alpha_shared_intr *jensenio_eisa_intr;
@@ -103,11 +110,13 @@
jensenio_specific_eoi(int irq)
{
- if (irq > 7)
- bus_space_write_1(pic_iot, pic_ioh[1],
- 0, 0x20 | (irq & 0x07));
- bus_space_write_1(pic_iot, pic_ioh[0],
- 0, 0x20 | (irq > 7 ? 2 : irq));
+ if (irq >= 8) {
+ bus_space_write_1(pic_iot, pic_ioh[1], PIC_OCW2,
+ OCW2_SELECT | OCW2_SL | OCW2_EOI | OCW2_ILS(irq - 8));
+ irq = IRQ_SLAVE;
+ }
+ bus_space_write_1(pic_iot, pic_ioh[0], PIC_OCW2,
+ OCW2_SELECT | OCW2_SL | OCW2_EOI | OCW2_ILS(irq));
}
void
@@ -128,7 +137,7 @@
i, jensenio_intr_deftype[i]);
/* Don't bother with stray interrupts. */
alpha_shared_intr_set_maxstrays(jensenio_eisa_intr,
- i, 0);
+ i, STRAY_MAX);
cp = alpha_shared_intr_string(jensenio_eisa_intr, i);
sprintf(cp, "irq %d", i);
@@ -140,8 +149,8 @@
/*
* The cascasde interrupt must be edge triggered and always enabled.
*/
- jensenio_setlevel(2, 0);
- jensenio_enable_intr(2, 1);
+ jensenio_setlevel(IRQ_SLAVE, 0);
+ jensenio_enable_intr(IRQ_SLAVE, 1);
/*
* Initialize the EISA chipset.
@@ -289,12 +298,12 @@
pic = irq >> 3;
bit = 1 << (irq & 0x7);
- mask = bus_space_read_1(pic_iot, pic_ioh[pic], 1);
+ mask = bus_space_read_1(pic_iot, pic_ioh[pic], PIC_OCW1);
if (onoff)
mask &= ~bit;
else
mask |= bit;
- bus_space_write_1(pic_iot, pic_ioh[pic], 1, mask);
+ bus_space_write_1(pic_iot, pic_ioh[pic], PIC_OCW1, mask);
}
void
@@ -334,4 +343,58 @@
*/
if (bus_space_map(pic_iot, 0x4d0, 2, 0, &pic_elcr_ioh))
panic("jensenio_init_intr: unable to map ELCR registers");
+
+ /*
+ * Initialize master PIC.
+ */
+
+ /* reset; program device, four bytes */
+ bus_space_write_1(pic_iot, picaddr[0],
+ PIC_ICW1, ICW1_SELECT | ICW1_IC4);
+ /* starting at this vector index */
+ bus_space_write_1(pic_iot, picaddr[0],
+ PIC_ICW2, 0); /* XXX */
+ /* slave on line 2 */
+ bus_space_write_1(pic_iot, picaddr[0],
+ PIC_ICW3, ICW3_CASCADE(IRQ_SLAVE));
+ /* special fully nested mode, 8086 mode */
+ bus_space_write_1(pic_iot, picaddr[0],
+ PIC_ICW4, ICW4_SFNM | ICW4_8086);
+ /* special mask mode */
+ bus_space_write_1(pic_iot, picaddr[0],
+ PIC_OCW3, OCW3_SELECT | OCW3_SSMM | OCW3_SMM);
+ /* read IRR by default */
+ bus_space_write_1(pic_iot, picaddr[0],
+ PIC_OCW3, OCW3_SELECT | OCW3_RR);
+
+ /*
+ * Initialize slave PIC.
+ */
+
+ /* reset; program device, four bytes */
+ bus_space_write_1(pic_iot, picaddr[1],
+ PIC_ICW1, ICW1_SELECT | ICW1_IC4);
+ /* starting at this vector index */
+ bus_space_write_1(pic_iot, picaddr[1],
+ PIC_ICW2, 8); /* XXX */
+ /* slave connected to line 2 of master */
+ bus_space_write_1(pic_iot, picaddr[1],
+ PIC_ICW3, ICW3_SIC(IRQ_SLAVE));
+ /* special fully nested mode, 8086 mode */
+ bus_space_write_1(pic_iot, picaddr[1],
+ PIC_ICW4, ICW4_SFNM | ICW4_8086);
+ /* special mask mode */
+ bus_space_write_1(pic_iot, picaddr[1],
+ PIC_OCW3, OCW3_SELECT | OCW3_SSMM | OCW3_SMM);
+ /* read IRR by default */
+ bus_space_write_1(pic_iot, picaddr[1],
+ PIC_OCW3, OCW3_SELECT | OCW3_RR);
+
+ /* mask all interrupts */
+ bus_space_write_1(pic_iot, picaddr[0], PIC_OCW1, 0xff);
+ bus_space_write_1(pic_iot, picaddr[1], PIC_OCW1, 0xff);
+
+ /* default to edge-triggered */
+ bus_space_write_1(pic_iot, pic_elcr_ioh, 0, 0);
+ bus_space_write_1(pic_iot, pic_elcr_ioh, 1, 0);
}
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Fri, 27 Jul 2007 22:28:30 +0200
> Okay, I've checked mailing list archives and notice there is
> no report that ahb(4) worked on Jensen but there is the similar hang:
> http://mail-index.netbsd.org/port-alpha/2000/10/29/0000.html
This person's name sounds german, and he has got a german ISP, so I
hope that at least one of the mail addresses is still valid...
> Looks interrupts on Jensen PICs are not ack'ed properly.
> I don't know what is the right way to handle this,
So I've written him a few lines in german language, perhaps he
remembers something useful.
> but
> anyway could you try this one (which includes some PIC fixes)?
This one panics earlier than before:
-----------------------
NetBSD 4.0_BETA2 (GENERIC_MD) #0: Fri Jul 27 23:43:54 JST 2007
tsutsui@mirage:/r/work/src-
4.0/src/sys/arch/alpha/compile/GENERIC_MD
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 16608 KB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
CPU 0: fatal kernel trap:
CPU 0 trap entry = 0x2 (memory management fault)
CPU 0 a0 = 0x1000
CPU 0 a1 = 0x1
CPU 0 a2 = 0x1
CPU 0 pc = 0xfffffc000079c1fc
CPU 0 ra = 0xfffffc000079f50c
CPU 0 pv = 0xfffffc000079c1ec
CPU 0 curlwp = 0xfffffc0000f642b8
CPU 0 pid = 0, comm = swapper
panic: trap
Stopped in pid 0.1 (swapper) at netbsd:cpu_Debugger+0x4: ret
zero,(ra
)
db> trace
cpu_Debugger() at netbsd:cpu_Debugger+0x4
panic() at netbsd:panic+0x1bc
trap() at netbsd:trap+0xce0
XentMM() at netbsd:XentMM+0x20
--- memory management fault (from ipl 6) ---
jensenio_io_write_1() at netbsd:jensenio_io_write_1+0x10
jensenio_pic_init() at netbsd:jensenio_pic_init+0x11c
jensenio_intr_init() at netbsd:jensenio_intr_init+0x40
jensenio_attach() at netbsd:jensenio_attach+0x78
config_attach_loc() at netbsd:config_attach_loc+0x480
mbattach() at netbsd:mbattach+0x11c
config_attach_loc() at netbsd:config_attach_loc+0x480
cpu_configure() at netbsd:cpu_configure+0x40
configure() at netbsd:configure+0x7c
main() at netbsd:main+0x1b4
locorestart() at netbsd:locorestart+0x64
--- root of call graph ---
db> show event
evcnt type 0: uvmmap ukh_alloc = 2
evcnt type 0: uvmmap uke_free = 10
evcnt type 0: uvmmap uke_alloc = 57
evcnt type 0: uvmmap mlk_hint = 1
evcnt type 0: uvmmap mlk_call = 7
evcnt type 0: uvmmap map_call = 52
evcnt type 0: uvmmap knomerge = 12
evcnt type 0: uvmmap kbackmerge = 40
db> show uvmexp
Current UVM status:
pagesize=8192 (0x2000), pagemask=0x1fff, pageshift=13
2098 VM pages: 0 active, 0 inactive, 0 wired, 1991 free
pages 0 anon, 0 file, 0 exec
freemin=0, free-target=0, wired-max=0
faults=1, traps=2, intrs=0, ctxswitch=0
softint=0, syscalls=0, swapins=0, swapouts=0
fault counts:
noram=0, noanon=0, pgwait=0, pgrele=0
ok relocks(total)=0(0), anget(retrys)=0(0), amapcopy=0
neighbor anon/obj pg=0/0, gets(lock/unlock)=0/0
cases: anon=0, anoncow=0, obj=0, prcopy=0, przero=0
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=0, swpgavail=0
swpages=0, swpginuse=0, swpgonly=0, paging=0
db>
-----------------------
--
Christoph Franzen
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Fri, 27 Jul 2007 22:57:48 +0200
> Okay, I've checked mailing list archives and notice there is
> no report that ahb(4) worked on Jensen but there is the similar hang:
> http://mail-index.netbsd.org/port-alpha/2000/10/29/0000.html
Did you also find this one?
http://mail-index.netbsd.org/port-alpha/2002/01/10/0000.html
Regards, Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Sat, 28 Jul 2007 09:28:42 +0900
ChristophFranzen@gmx.net wrote:
> This one panics earlier than before:
:
> --- memory management fault (from ipl 6) ---
> jensenio_io_write_1() at netbsd:jensenio_io_write_1+0x10
> jensenio_pic_init() at netbsd:jensenio_pic_init+0x11c
Ah, there are bothces in the function.
(we have to use pic_ioh[] instead of picaddr[] for bus_space_write_1(9))
Please try fixed one:
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-GENERIC-20070728.gz
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Sat, 28 Jul 2007 03:23:24 +0200
Hello,
there are finally some good news: it starts several processes and can
do a "real" reboot (rather than going back to SRM).
You'll find the whole output below (without me calling for "help" and
some duplicates and typographic errors in between).
Unfortunately we still seem to be stuck at the SCSI adapter:
------------------------------
Kernelized RAIDframe activated
md0: internal 4650 KB image area
scsibus0: waiting 2 seconds for devices to settle...
probe(ahb0:0:0:0): timed out
probe(ahb0:0:0:0): timed out AGAIN
Stopped at netbsd:cpu_Debugger+0x4: ret zero,(ra)
------------------------------
There *is* a device with ID 0 installed, as you can see in the SRM
console:
------------------------------
>>> sh dev
BOOTDEV ADDR DEVTYPE RM/FX DEVNAM REV NUMBYTES
------- ---- ------- ----- ------ --- ------
FD0 PC Floppy DISK RM
SCSI Devices..
DKA0 A/0/0 DISK FX CFP2105 2D4D 2.14GB
DKA400 A/4/0 RODISK RM CD-R 1.4D ......
DKA500 A/5/0 DISK FX CP30540 B0BC 545.74MB
HOST A/7/0 PROC AHA1742A E
------------------------------
However, this is not found by NetBSD when it begins probing the bus
for device 0. The adapter's LED keeps dark, so there is no SCSI
activity at all at this point. A Reboot without powering down works,
while a halt from ddb leads to a situation, where the SRM console
would also fail to find the hostadapter:
------------------------------
db> reboot 0x8
syncing disks... done
unmounting file systems... done
halted.
?05 HLT INSTR
PC= FFFFFC00.00300118 PSL= 00000000.00000006
>>> sh dev
BOOTDEV ADDR DEVTYPE RM/FX DEVNAM REV NUMBYTES
------- ---- ------- ----- ------ --- --------
*** UNEXPECTED INTERRUPT ***
VECTOR = 000007E0
EXC_ADDR = 00030988
PS = 38000000.00001300
------------------------------
The rest of the possibly relevant logs follows:
------------------------------
NetBSD 4.0_BETA2 (GENERIC_MD) #1: Sat Jul 28 09:21:31 JST 2007
tsutsui@mirage:/r/work/src-4.0/src/sys/arch/alpha/compile/GENERIC_MD
DEC2000 model 300, 150MHz, s/n
8192 byte page size, 1 processor.
total memory = 32768 KB
(2048 KB reserved for PROM, 30720 KB used by NetBSD)
avail memory = 16608 KB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21064-0
jensenio0 at mainbus0
pckbc0 at jensenio0 port 0x60
pms0 at pckbc0 (aux slot)
pckbc0: aux slot interrupting at vector 0x990
wsmouse0 at pms0 mux 0
com0 at jensenio0 port 0x3f8: ns8250 or ns16450, no fifo
com0: console
com0: interrupting at vector 0x900
com1 at jensenio0 port 0x2f8: ns8250 or ns16450, no fifo
com1: interrupting at vector 0x920
lpt0 at jensenio0 port 0x3bc
lpt0: interrupting at eisa irq 1
mcclock0 at jensenio0 port 0x170: mc146818 or compatible
eisa0 at jensenio0
ahb0 at eisa0 slot 2: Adaptec AHA-1742A SCSI
ahb0: INTDEF configured to use irq 12, ECU configured to use irq 12
ahb0: interrupting at eisa irq 12
scsibus0 at ahb0: 8 targets, 8 luns per target
Compaq NetFlex-2 ENET-TR at eisa0 slot 3 not configured
isa0 at jensenio0
depca: address not found
attimer0 at isa0 port 0x40-0x43: AT Timer
we1 at isa0 port 0x300-0x31f iomem 0xcc000-0xcffff irq 10
we1: WD8013EPC Ethernet (16-bit)
we1: Ethernet address 00:00:c0:db:6c:2e
vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
wsdisplay0 at vga0 kbdmux 1
wsmux1: connecting to wsdisplay0
pcppi0 at isa0 port 0x61
pcppi0: children must have an explicit unit
midi0 at pcppi0: PC speaker (CPU-intensive output)
spkr0 at pcppi0
isabeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
pcppi0: attached to attimer0
enabling interrupts
WARNING: stray interrupt, vector 0x840
calling hwrpb_restart_setup()
calling initclocks()
cpu_initclocks()
starting clock
calling config_process_deferred()
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
configure() done.
Kernelized RAIDframe activated
md0: internal 4650 KB image area
scsibus0: waiting 2 seconds for devices to settle...
probe(ahb0:0:0:0): timed out
probe(ahb0:0:0:0): timed out AGAIN
Stopped at netbsd:cpu_Debugger+0x4: ret zero,(ra)
db> trace
cpu_Debugger() at netbsd:cpu_Debugger+0x4
comintr() at netbsd:comintr+0x138
com_jensenio_intr() at netbsd:com_jensenio_intr+0x24
interrupt() at netbsd:interrupt+0x230
XentInt() at netbsd:XentInt+0x1c
--- interrupt (from ipl 0) ---
idle() at netbsd:idle+0x48
mi_switch() at netbsd:mi_switch+0xe0
ltsleep() at netbsd:ltsleep+0x284
scsipi_execute_xs() at netbsd:scsipi_execute_xs+0x318
scsipi_command() at netbsd:scsipi_command+0xb8
scsipi_inquire() at netbsd:scsipi_inquire+0xa0
scsi_probe_bus() at netbsd:scsi_probe_bus+0x290
scsibus_config() at netbsd:scsibus_config+0xcc
scsipi_completion_thread() at netbsd:scsipi_completion_thread+0x30
exception_return() at netbsd:exception_return
--- root of call graph ---
db> ps /w
PID COMMAND EMUL PRI UTIME STIME WAIT-MSG WAIT-
CHANNEL
4 cryptoret netbsd 36 0.2 0.2 crypto_wait
netbsd:crp_ret_q
3 scsibus0 netbsd 16 0.0 0.4 xscmd
0xfffffc0001f13e60
2 pms0 netbsd 32 0.1 0.1 pmsreset
0xfffffe0000071e74
1 init netbsd 32 0.1 0.1 initexec
netbsd:start_init_ex
ec
0 swapper netbsd 32 0.0 0.4 cfpend
netbsd:config_pendin
g
db> show event
evcnt type 0: uvmmap ukh_alloc = 3
evcnt type 0: uvmmap uke_free = 10
evcnt type 0: uvmmap uke_alloc = 85
evcnt type 0: uvmmap mlk_hint = 8
evcnt type 0: uvmmap mlk_call = 14
evcnt type 0: uvmmap map_call = 81
evcnt type 0: uvmmap knomerge = 17
evcnt type 0: uvmmap kbackmerge = 64
evcnt type 1: soft net = 4
evcnt type 1: cpu0 clock = 138377
evcnt type 1: cpu0 device = 2
evcnt type 1: vector 0x900 = 1
db> show uvmexp
Current UVM status:
pagesize=8192 (0x2000), pagemask=0x1fff, pageshift=13
2098 VM pages: 0 active, 0 inactive, 8 wired, 1905 free
pages 8 anon, 0 file, 0 exec
freemin=0, free-target=0, wired-max=0
faults=8, traps=1, intrs=138379, ctxswitch=10
softint=4, syscalls=0, swapins=0, swapouts=0
fault counts:
noram=0, noanon=0, pgwait=0, pgrele=0
ok relocks(total)=0(0), anget(retrys)=0(0), amapcopy=0
neighbor anon/obj pg=0/0, gets(lock/unlock)=8/0
cases: anon=0, anoncow=0, obj=8, prcopy=0, przero=0
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=0, swpgavail=0
swpages=0, swpginuse=0, swpgonly=0, paging=0
db> show page
PAGE 0xfffffc00007e4ff0:
flags=0, pqflags=4801<FREE,PRIVATE4,PRIVATE7>, wire_count=63008,
pa=0x20218000
243f6801
uobject=0x6bfa800144203000, uanon=0x4821d681f4600002,
offset=0x2021c000243ffc0
1 loan_count=17921
[page ownership tracking disabled]
db> show vnode
OBJECT 0xfffffc00007e4ff0: locked=1811578881,
pgops=0x203f000d46020002, npages=5
38902529, refs=-197132283
VNODE flags fffffffff4600002<TEXT>
mp 0x4801f62046010000 numoutput 1210177153 size 0x47ff04004a01f621
data 0x406205a2243f2c00 usecount -197132283 writecount
7780672049162235904 holdc
nt 2315342790285851649 numoutput 1210177153
tag UNKNOWN(-197132278) type UNKNOWN(-195035124) mount
0x4801f62046010000 typeda
ta 0x404355a148235682
db> show object
OBJECT 0xfffffc00007e4ff0: locked=1811578881,
pgops=0x203f000d46020002, npages=5
38902529, refs=-197132283
db> reboot
syncing disks... done
unmounting file systems... done
rebooting...
83 BOOT SYS
INIT-S-CPU...
AUDIT_BOOT_STARTS ...
AUDIT_CHECKSUM_GOOD
AUDIT_LOAD_BEGINS
AUDIT_LOAD_DONE
------------------------------
[...]
------------------------------
db> x
netbsd:cpu_Debugger+0x4: 6bfa8001
db> reboot 0x8
syncing disks... done
unmounting file systems... done
halted.
?05 HLT INSTR
PC= FFFFFC00.00300118 PSL= 00000000.00000006
>>> sh dev
BOOTDEV ADDR DEVTYPE RM/FX DEVNAM REV
NUMBYTES
------- ---- ------- ----- ------ --- -----
---
*** UNEXPECTED INTERRUPT ***
VECTOR = 000007E0
EXC_ADDR = 00030988
PS = 38000000.00001300
R00 = 00000000.0000000C R01 = 00000000.01E6443F R02 =
00000000.000C34B0
R03 = 00000000.000B8300 R04 = 00000000.00000008 R05 =
00000000.0006A5C0
R06 = 00000000.000FEC28 R07 = 00000000.0006A5C0 R08 =
00000000.00000000
R09 = 00000000.00000001 R10 = FFFFFFFF.FFFFFFBF R11 =
00000000.00000001
R12 = 00000000.00000001 R13 = 00000000.00000001 R14 =
00000000.00000001
R15 = FFFFFFFF.FFFFFFBF R16 = 00000000.000001F4 R17 =
00000000.0001FA80
R18 = 00000000.00000000 R19 = 00000000.00460007 R20 =
00000000.00004600
R21 = 00000000.00000001 R22 = 00000000.CBC0C193 R23 =
00000000.CBC0C19F
R24 = 00000000.00000001 R25 = 00000000.00000001 R26 =
00000000.00066738
R27 = 00000000.000BB8F8 R28 = 00000000.000B82FC R29 =
00000000.000FE978
>>>
------------------------------
--
Christoph Franzen
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Sat, 28 Jul 2007 13:07:14 +0900
ChristophFranzen@gmx.net wrote:
> scsibus0: waiting 2 seconds for devices to settle...
> probe(ahb0:0:0:0): timed out
> probe(ahb0:0:0:0): timed out AGAIN
> Stopped at netbsd:cpu_Debugger+0x4: ret zero,(ra)
> db> show event
:
> evcnt type 1: cpu0 clock = 138377
> evcnt type 1: cpu0 device = 2
> evcnt type 1: vector 0x900 = 1
> db>
Okay, in this case there is no interrupt and maybe we shouldn't setup
PICs as x86 otherwise interrupts won't occur even on SRM console.
Could you please this (only jensenio_intr_eoi() is changed)?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-GENERIC-20070728a.gz
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Sat, 28 Jul 2007 15:46:43 +0200
Now it says: "stray eisa irq 12", the SRM console is OK afterwards:
--------------------
NetBSD 4.0_BETA2 (GENERIC_MD) #2: Sat Jul 28 12:59:01 JST 2007
tsutsui@mirage:/r/work/src-
4.0/src/sys/arch/alpha/compile/GENERIC_MD
[...]
ahb0 at eisa0 slot 2: Adaptec AHA-1742A SCSI
ahb0: INTDEF configured to use irq 12, ECU configured to use irq 12
ahb0: interrupting at eisa irq 12
scsibus0 at ahb0: 8 targets, 8 luns per target
[...]
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
pcppi0: attached to attimer0
enabling interrupts
stray eisa irq 12
stray eisa irq 12
stray eisa irq 12
stray eisa irq 12
stray eisa irq 12
stray eisa irq 12
stray eisa irq 12
stray eisa irq 12
stray eisa irq 12
stray eisa irq 12; stopped logging
Stopped in pid 0.1 (swapper) at netbsd:cpu_Debugger+0x4: ret
zero,(ra
)
db> trace
cpu_Debugger() at netbsd:cpu_Debugger+0x4
comintr() at netbsd:comintr+0x138
com_jensenio_intr() at netbsd:com_jensenio_intr+0x24
interrupt() at netbsd:interrupt+0x230
XentInt() at netbsd:XentInt+0x1c
--- interrupt (from ipl 0) ---
spl0() at netbsd:spl0+0x30
cpu_configure() at netbsd:cpu_configure+0x7c
configure() at netbsd:configure+0x7c
main() at netbsd:main+0x1b4
locorestart() at netbsd:locorestart+0x64
--- root of call graph ---
db> ps /w
PID COMMAND EMUL PRI UTIME STIME WAIT-MSG WAIT-
CHANNEL
>0 swapper netbsd 0 0.0 0.0
db> show event
evcnt type 0: uvmmap ukh_alloc = 2
evcnt type 0: uvmmap uke_free = 10
evcnt type 0: uvmmap uke_alloc = 65
evcnt type 0: uvmmap mlk_hint = 1
evcnt type 0: uvmmap mlk_call = 6
evcnt type 0: uvmmap map_call = 60
evcnt type 0: uvmmap knomerge = 12
evcnt type 0: uvmmap kbackmerge = 48
evcnt type 1: cpu0 device = 8488145
evcnt type 1: eisa irq 12 = 8488144
evcnt type 1: vector 0x900 = 1
db> show uvmexp
Current UVM status:
pagesize=8192 (0x2000), pagemask=0x1fff, pageshift=13
2098 VM pages: 0 active, 0 inactive, 0 wired, 1969 free
pages 0 anon, 0 file, 0 exec
freemin=0, free-target=0, wired-max=0
faults=0, traps=1, intrs=8488145, ctxswitch=0
softint=0, syscalls=0, swapins=0, swapouts=0
fault counts:
noram=0, noanon=0, pgwait=0, pgrele=0
ok relocks(total)=0(0), anget(retrys)=0(0), amapcopy=0
neighbor anon/obj pg=0/0, gets(lock/unlock)=0/0
cases: anon=0, anoncow=0, obj=0, prcopy=0, przero=0
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=0, swpgavail=0
swpages=0, swpginuse=0, swpgonly=0, paging=0
db> reboot 0x8
halted.
?05 HLT INSTR
PC= FFFFFC00.00300118 PSL= 00000000.00000006
>>> sh dev
BOOTDEV ADDR DEVTYPE RM/FX DEVNAM REV
NUMBYTES
------- ---- ------- ----- ------ --- -----
---
FD0 PC Floppy DISK RM
SCSI Devices..
DKA0 A/0/0 DISK FX CFP2105 2D4D
2.14GB
DKA400 A/4/0 RODISK RM CD-R 1.4D
......
DKA500 A/5/0 DISK FX CP30540 B0BC
545.74MB
HOST A/7/0 PROC AHA1742A E
>>>
--------------------
--
Christoph Franzen
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Sun, 29 Jul 2007 01:43:05 +0900
ChristophFranzen@gmx.net wrote:
> Now it says: "stray eisa irq 12", the SRM console is OK afterwards:
Hmm.
Could you check if interrupts from we1 Ethernet work
with this one (ahb at eisa disabled)?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070729.gz
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Sat, 28 Jul 2007 23:09:43 +0200
Hello.
> Could you check if interrupts from we1 Ethernet work
It reaches init, but hangs after complaining about the clock. The
Jensen's hardware clock is at 0x170 and has got an epoch value of
2000 (1900 on most other SRM machines and Ruffians, 1980 on most ARC
machines and Jensens with old Firmware).
I don't find any reference to the IRQ 10 of the we1:
md0: internal 4650 KB image area
WARNING: can't figure what device matches "SCSI 1 2 0 0 500 0 JENS-
IO"
root on md0a dumps on md0b
root file system type: ffs
WARNING: clock gained 6 days -- CHECK AND RESET THE DATE!
Stopped in pid 1.1 (init) at netbsd:cpu_Debugger+0x4: ret
zero,(ra
)
db> trace
cpu_Debugger() at netbsd:cpu_Debugger+0x4
comintr() at netbsd:comintr+0x138
com_jensenio_intr() at netbsd:com_jensenio_intr+0x24
interrupt() at netbsd:interrupt+0x230
XentInt() at netbsd:XentInt+0x1c
--- interrupt (from ipl 0) ---
--- user mode ---
db> ps /w
PID COMMAND EMUL PRI UTIME STIME WAIT-MSG WAIT-
CHANNEL
6 aiodoned netbsd 4 0.0 0.0 aiodoned
netbsd:uvm+0x2c
5 ioflush netbsd 40 0.0 0.0 syncer
netbsd:rushjob
4 pagedaemon netbsd 4 0.0 0.0 pgdaemon
netbsd:uvm+0x1c
3 cryptoret netbsd 36 0.0 0.0 crypto_wait
netbsd:crp_ret_q
2 pms0 netbsd 32 0.0 0.0 pmsreset
0xfffffe0000071e74
>1 init netbsd 71 78.6 0.0
0 swapper netbsd 4 0.0 0.0 scheduler
netbsd:proc0
db> show event
evcnt type 0: FP proc use = 1
evcnt type 0: uvmmap ukh_alloc = 3
evcnt type 0: uvmmap uke_free = 13
evcnt type 0: uvmmap uke_alloc = 90
evcnt type 0: uvmmap mlk_hint = 84
evcnt type 0: uvmmap mlk_call = 119
evcnt type 0: uvmmap map_call = 130
evcnt type 0: uvmmap knomerge = 57
evcnt type 0: uvmmap kbackmerge = 65
evcnt type 0: uvmmap unomerge = 8
evcnt type 0: vmcmd kills = 1
evcnt type 0: vmcmd calls = 6
evcnt type 1: soft net = 1
evcnt type 1: cpu0 clock = 79654
evcnt type 1: cpu0 device = 2
evcnt type 1: eisa irq 6 = 1
evcnt type 1: vector 0x900 = 1
db> show uvmexp
Current UVM status:
pagesize=8192 (0x2000), pagemask=0x1fff, pageshift=13
2099 VM pages: 43 active, 0 inactive, 12 wired, 1835 free
pages 18 anon, 0 file, 37 exec
freemin=32, free-target=42, wired-max=699
faults=59, traps=52, intrs=79656, ctxswitch=964
softint=878, syscalls=24, swapins=0, swapouts=0
fault counts:
noram=0, noanon=0, pgwait=0, pgrele=0
ok relocks(total)=35(35), anget(retrys)=1(0), amapcopy=2
neighbor anon/obj pg=0/0, gets(lock/unlock)=50/35
cases: anon=1, anoncow=0, obj=50, prcopy=0, przero=6
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=0, swpgavail=0
swpages=0, swpginuse=0, swpgonly=0, paging=0
db>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Sun, 29 Jul 2007 13:06:28 +0900
ChristophFranzen@gmx.net wrote:
> It reaches init, but hangs after complaining about the clock.
As you can see sys/arch/alpha/alpha/clock.c, inittodr(9)
compares its system clock and timestamp in root filesystem,
and then it shows a warning message if there is a certain
difference. The mdroot image was created on July 22 so
"clock gained 6 days" indicates that the system clock is
read properly.
> db> ps /w
> PID COMMAND EMUL PRI UTIME STIME WAIT-MSG WAIT-
> CHANNEL
> 6 aiodoned netbsd 4 0.0 0.0 aiodoned netbsd:uvm+0x2c
> 5 ioflush netbsd 40 0.0 0.0 syncer netbsd:rushjob
> 4 pagedaemon netbsd 4 0.0 0.0 pgdaemon netbsd:uvm+0x1c
> 3 cryptoret netbsd 36 0.0 0.0 crypto_wait netbsd:crp_ret_q
> 2 pms0 netbsd 32 0.0 0.0 pmsreset 0xfffffe0000071e74
> >1 init netbsd 71 78.6 0.0
> 0 swapper netbsd 4 0.0 0.0 scheduler netbsd:proc0
This shows that most tasks in sys/kern/init_main.c:main()
are done and looks system trying to fork /bin/sh.
On my AlphaPC 164 that image just works (system boots and
sysinst starts) so I'm afraid it's difficult to track
what's wrong on jensen specific part...
> evcnt type 1: soft net = 1
> evcnt type 1: cpu0 clock = 79654
> evcnt type 1: cpu0 device = 2
> evcnt type 1: eisa irq 6 = 1
> evcnt type 1: vector 0x900 = 1
At least one fdc(4) interrupt is handled, it seems.
Could you try "boot -flags n" on SRM console and
see what happens if you specify "we1" for root device?
You would get "cannot mount root, error = xx" error
if you don't have NFS root settings on your network,
but you could see if interrupts from we1 are handled
or not after the error on the ddb "show event" command.
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Sun, 29 Jul 2007 15:50:02 +0200
> At least one fdc(4) interrupt is handled, it seems.
This is always so.
> Could you try "boot -flags n" on SRM console and
> see what happens if you specify "we1" for root device?
Booting interactively works always.
> You would get "cannot mount root, error = xx" error
When I choose we1 as the boot device, the error above occurs and
interrupts from we1 are handled (as well as exactly one from the
floppy).
After that I can choose again...
When I choose the defaults (md0a...) I reach the install menu and
everything is fine except that it can't find a hard disk to install
to, of course.
Summary:
When I boot interactively with flag "n", this always succeeds,
regardless if I choose "we1" or the default.
When I choose the default, the install menu is reached.
When I boot with flag "a", it hangs eternally as previously
described.
Interrupts:
When I don't try "we1", there are no interrupts from "we1" handled.
When I try "we1" as a boot device, interrupts from this device are
handled.
There is always one floppy interrupt handled.
Regards, Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Wed, 1 Aug 2007 23:03:39 +0900
ChristophFranzen@gmx.net wrote:
> When I boot interactively with flag "n", this always succeeds,
:
> When I boot with flag "a", it hangs eternally as previously
> described.
Hmm, it looks there is some problem around PIC initialization.
Anyway, there is a report that ahb(4) works on AlphaServer
http://mail-index.netbsd.org/port-alpha/2007/04/11/0011.html
(no device is connected to ahb(4) though)
so this may be a Jensen specific problem.
There is no reference code about the interrupt controller on Jensen
so I have no idea of proper solutions, but could you try this one
(with both "a" and "n" flags)?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070801.gz
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Wed, 01 Aug 2007 17:59:46 +0200
Hello,
> Hmm, it looks there is some problem around PIC initialization.
I'm not sure if you already know this, and if it helps:
ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/ek-a0638-td.pdf.gz
This is a detailed description of the Machine's system board
including the interrupt controller.
When I was searching for information on my hard disk here, I didn't
find this any more, but fortunately it was still available at
netbsd.org.
> Anyway, there is a report that ahb(4) works on AlphaServer
> http://mail-index.netbsd.org/port-alpha/2007/04/11/0011.html
> (no device is connected to ahb(4) though)
> so this may be a Jensen specific problem.
According to the Mailinglist, older Netbsd versions have been
successfully run on the Jensen, and that would have been impossible
without ahb(4), because the Jensen's SRM CANNOT boot from elsewhere.
The Alphaserver hardware is quite different from the Jensen (in fact,
there is nothing like the Jensen except the Culzean, which I never
have heard of in the real world).
> There is no reference code about the interrupt controller on Jensen so
> I have no idea of proper solutions, but could you try this one (with
> both "a" and "n" flags)?
I tried "a" at first, it stopped at this line like one of the
previous versions:
stray eisa irq 12; stopped logging
Sending Break to the serial console did not help. (Perhaps I had been
waiting too long?) After pressing the halt switch, I booted with flag
"n" with the same result, except that I was able to enter ddb(4) this
time. The events showed a great number of unhandled IRQ 12.
Hans-Juergen Bergmann, who has tried to get Netbsd running on the
Jensen a few years ago, has answered to my email. Unfortunately, he
did not succeed, and had given up, but he has agreed to help testing
when his machine arrives in a month or so (he has moved to Oakland).
He has got two AHA1742A controllers, perhaps one of these has a
different MCODE revision. Later ones were reported to have less
problems. (VMS would not run on revision E, the one I have here.)
Regards, Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Mon, 6 Aug 2007 00:59:16 +0900
ChristophFranzen@gmx.net wrote:
> I'm not sure if you already know this, and if it helps:
> ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/ek-a0638-td.pdf.gz
I take a look at it, but I don't see so particular quirks
which are missed in -current code. I'll check details later.
> According to the Mailinglist, older Netbsd versions have been
> successfully run on the Jensen, and that would have been impossible
> without ahb(4), because the Jensen's SRM CANNOT boot from elsewhere.
Is there any evidence that shows Jensen working with configured
ahb(4) SCSI? I can only find Jason's post:
http://mail-index.netbsd.org/port-alpha/2000/07/12/0002.html
but in this dmesg "scsibus at ahb" was disabled (not configured)
so no interrupt from ahb(4) was handled. It was the same case
on our mdroot images without ahb(4).
Others reported that their kernel hanged up after fd was probed
(i.e. interrupt was enabled).
> The Alphaserver hardware is quite different from the Jensen (in fact,
> there is nothing like the Jensen except the Culzean, which I never
> have heard of in the real world).
Well, I meant ahb(4) driver doesn't have any MI problem
even on LP64 platforms and probably our problems are around
interrupt code for Jensen.
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Mon, 06 Aug 2007 02:38:43 +0200
> > According to the Mailinglist, older Netbsd versions have been
> > successfully run on the Jensen, and that would have been impossible
> > without ahb(4), because the Jensen's SRM CANNOT boot from elsewhere.
> >
>
> Is there any evidence that shows Jensen working with configured
> ahb(4) SCSI?
No, not really... I was trying to logically deduce this from the
postings.
> I can only find Jason's post:
> http://mail-index.netbsd.org/port-alpha/2000/07/12/0002.html
This is exactly the post I had in mind.
> but in this dmesg "scsibus at ahb" was disabled (not configured)
> so no interrupt from ahb(4) was handled. It was the same case
> on our mdroot images without ahb(4).
I obviously overlooked this line and the other one:
WARNING: can't figure what device matches "SCSI 1 4 0 0 200 0 JENS-
IO"
I thought it must be running somehow, else it would not be possible
to actually install the system.
Perhaps leaving it alone and using it only for booting form SRM would
work. After the first step one could possibly switch over to another,
supported disk controller...
Would it help to have a look at the Linux driver for the AHA174x?
> Others reported that their kernel hanged up after fd was probed
> (i.e. interrupt was enabled).
Well, this seems to be solved.
> > The Alphaserver hardware is quite different from the Jensen
>
> Well, I meant ahb(4) driver doesn't have any MI problem
> even on LP64 platforms and probably our problems are around
> interrupt code for Jensen.
This is possible. Unfortunately I don't know much about these things.
There are some weird things, however. In the Hardware Reference PDF
file I mentioned they were referring to IRQ 9 as SCSI. This IRQ is
occupied by the graphics board (can only use this one or no IRQ at
all) and the ECU doesn't complain. The board is only recognized by
NetBSD as ISA with no IRQ even in EISA mode. I think the reason is
that it doesn't support reading the EISA id (I know for sure that it
doesn't support this).
Regards, Christoph
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
trap on Jensen
Date: Mon, 6 Aug 2007 23:50:29 +0900
ChristophFranzen@gmx.net wrote:
> Would it help to have a look at the Linux driver for the AHA174x?
Well, maybe we have to look at Jensen specific code
rather than AHA174x.
> > Others reported that their kernel hanged up after fd was probed
> > (i.e. interrupt was enabled).
>
> Well, this seems to be solved.
No, I just enabled assertions which shows "stray" messages
for unhandled interrupts.
> There are some weird things, however. In the Hardware Reference PDF
> file I mentioned they were referring to IRQ 9 as SCSI. This IRQ is
> occupied by the graphics board (can only use this one or no IRQ at
> all) and the ECU doesn't complain. The board is only recognized by
> NetBSD as ISA with no IRQ even in EISA mode. I think the reason is
> that it doesn't support reading the EISA id (I know for sure that it
> doesn't support this).
There is some related description in Alpha Linux FAQ:
http://www.alphalinux.org/faq/FAQ-9.html#ss9.3
but I doubt it causes our current problem.
BTW, I also notice the folloing description in the
DEC hardware manual:
>> For level-triggered interrupt mode,
>> you must remove the interrupt request signal before issuing the
>> EOI command, or you must disable the CPU interrupt. This is
>> necessary to prevent a second interrupt from occurring.
I'm not sure how long window "we must disable the CPU interrupt"
on, but Linux seems to have the simliar kludge during processing
device interrupts on Jensen. Could you try this one?
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070806.gz
---
Index: jensenio_intr.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/jensenio/jensenio_intr.c,v
retrieving revision 1.6
diff -u -r1.6 jensenio_intr.c
--- jensenio_intr.c 27 Jul 2007 13:37:07 -0000 1.6
+++ jensenio_intr.c 6 Aug 2007 14:41:33 -0000
@@ -56,6 +56,8 @@
#include <dev/isa/isareg.h>
#include <dev/isa/isavar.h>
+#include <dev/ic/i8259reg.h>
+
#include <alpha/jensenio/jenseniovar.h>
static bus_space_tag_t pic_iot;
@@ -71,6 +73,11 @@
int jensenio_eisa_intr_alloc(void *, int, int, int *);
#define JENSEN_MAX_IRQ 16
+#define IRQ_SLAVE 2
+
+#ifndef STRAY_MAX
+#define STRAY_MAX 10
+#endif
struct alpha_shared_intr *jensenio_eisa_intr;
@@ -103,11 +110,14 @@
jensenio_specific_eoi(int irq)
{
- if (irq > 7)
- bus_space_write_1(pic_iot, pic_ioh[1],
- 0, 0x20 | (irq & 0x07));
- bus_space_write_1(pic_iot, pic_ioh[0],
- 0, 0x20 | (irq > 7 ? 2 : irq));
+ if (irq >= 8) {
+ bus_space_write_1(pic_iot, pic_ioh[1], PIC_OCW2,
+ OCW2_SELECT | OCW2_R | OCW2_SL | OCW2_EOI |
+ OCW2_ILS(irq - 8));
+ irq = IRQ_SLAVE;
+ }
+ bus_space_write_1(pic_iot, pic_ioh[0], PIC_OCW2,
+ OCW2_SELECT | OCW2_R | OCW2_SL | OCW2_EOI | OCW2_ILS(irq));
}
void
@@ -126,9 +136,8 @@
for (i = 0; i < JENSEN_MAX_IRQ; i++) {
alpha_shared_intr_set_dfltsharetype(jensenio_eisa_intr,
i, jensenio_intr_deftype[i]);
- /* Don't bother with stray interrupts. */
alpha_shared_intr_set_maxstrays(jensenio_eisa_intr,
- i, 0);
+ i, STRAY_MAX);
cp = alpha_shared_intr_string(jensenio_eisa_intr, i);
sprintf(cp, "irq %d", i);
@@ -140,8 +149,8 @@
/*
* The cascasde interrupt must be edge triggered and always enabled.
*/
- jensenio_setlevel(2, 0);
- jensenio_enable_intr(2, 1);
+ jensenio_setlevel(IRQ_SLAVE, 0);
+ jensenio_enable_intr(IRQ_SLAVE, 1);
/*
* Initialize the EISA chipset.
@@ -270,14 +279,20 @@
void
jensenio_iointr(void *framep, u_long vec)
{
- int irq;
+ int irq, s;
irq = SCB_VECTOIDX(vec - 0x800);
if (!alpha_shared_intr_dispatch(jensenio_eisa_intr, irq))
alpha_shared_intr_stray(jensenio_eisa_intr, irq, "eisa irq");
+ /*
+ * Disable CPU interrupts during EOI, per DEC docs.
+ * Note splserial() is higher than splhigh() on alpha.
+ */
+ s = splserial();
jensenio_specific_eoi(irq);
+ splx(s);
}
void
@@ -289,12 +304,12 @@
pic = irq >> 3;
bit = 1 << (irq & 0x7);
- mask = bus_space_read_1(pic_iot, pic_ioh[pic], 1);
+ mask = bus_space_read_1(pic_iot, pic_ioh[pic], PIC_OCW1);
if (onoff)
mask &= ~bit;
else
mask |= bit;
- bus_space_write_1(pic_iot, pic_ioh[pic], 1, mask);
+ bus_space_write_1(pic_iot, pic_ioh[pic], PIC_OCW1, mask);
}
void
---
Izumi Tsutsui
From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Tue, 07 Aug 2007 02:28:06 +0200
> >> For level-triggered interrupt mode,
> >> you must remove the interrupt request signal before issuing the EOI
> >> command, or you must disable the CPU interrupt. This is necessary
> >> to prevent a second interrupt from occurring.
>
> I'm not sure how long window "we must disable the CPU interrupt"
> on, but Linux seems to have the simliar kludge during processing
> device interrupts on Jensen. Could you try this one?
> http://www.ceres.dti.ne.jp/~tsutsui/netbsd/cdhdtape-20070806.gz
This causes stray IRQ 12 "as usual"; noch change in dmesg, events and
trace.
When I've time, I'll try to find some useful information we might be
missing...
Regards, Christoph
From: "Liam J. Foy" <liamjfoy@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: PR/36628 CVS commit: [netbsd-4] src/sys/arch/alpha
Date: Tue, 21 Aug 2007 20:00:29 +0000 (UTC)
Module Name: src
Committed By: liamjfoy
Date: Tue Aug 21 20:00:29 UTC 2007
Modified Files:
src/sys/arch/alpha/alpha [netbsd-4]: dec_2000_300.c
src/sys/arch/alpha/eisa [netbsd-4]: eisa_machdep.c
src/sys/arch/alpha/include [netbsd-4]: eisa_machdep.h
src/sys/arch/alpha/jensenio [netbsd-4]: jensenio.c jensenio_intr.c
lpt_jensenio.c
src/sys/arch/alpha/pci [netbsd-4]: sio.c
Log Message:
Pull up following revision(s) (requested by tsutsui in ticket #815):
sys/arch/alpha/pci/sio.c: revision 1.41
sys/arch/alpha/eisa/eisa_machdep.c: revision 1.6
sys/arch/alpha/jensenio/jensenio.c: revision 1.14
sys/arch/alpha/jensenio/jensenio_intr.c: revision 1.6
sys/arch/alpha/include/eisa_machdep.h: revision 1.8
sys/arch/alpha/alpha/dec_2000_300.c: revision 1.14
sys/arch/alpha/jensenio/lpt_jensenio.c: revision 1.6
Avoid NULL pointer dereference in MD device_register() function.
Fixes a part of PR port-alpha/36628.
Backout changes on lpt_jensenio.c rev 1.2.
lpt at jensenio doesn't seem to have a specific interrupt vector
but uses a normal EISA interrupt.
Fixes another part of PR port-alpha/36628 and PR port-alpha/20386.
More fixes for Jensen, reported and tested by Christoph Franzen
in PR port-alpha/36628:
- make jensenio_eisa_maxslots() return 8 (instead of 16) since
EISA config for slot 8-15 on jensen could return invalid values
- pass eisa_chipset_tag_t to eisa_init() and check eisa_maxslots()
on probing EISA config space
- pass M_ZERO to malloc(9) and make sure malloc(9) doesn't fail
- fix typo in a debug printf, add more debug printfs, and
use #ifdef EISA_DEBUG to enable them
- cast uint8_t value to uint32_t before shift more than 8 bits
- check buffer region on reading compressed data from EISA config space
Check a correct value on a sanity check in jensenio_eisa_intr_map().
Fixes yet another bug on Jensen found on tracking PR port-alpha/36628.
To generate a diff of this commit:
cvs rdiff -r1.11 -r1.11.18.1 src/sys/arch/alpha/alpha/dec_2000_300.c
cvs rdiff -r1.5 -r1.5.58.1 src/sys/arch/alpha/eisa/eisa_machdep.c
cvs rdiff -r1.7 -r1.7.76.1 src/sys/arch/alpha/include/eisa_machdep.h
cvs rdiff -r1.13 -r1.13.24.1 src/sys/arch/alpha/jensenio/jensenio.c
cvs rdiff -r1.5 -r1.5.24.1 src/sys/arch/alpha/jensenio/jensenio_intr.c
cvs rdiff -r1.5 -r1.5.58.1 src/sys/arch/alpha/jensenio/lpt_jensenio.c
cvs rdiff -r1.40 -r1.40.24.1 src/sys/arch/alpha/pci/sio.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Responsible-Changed-From-To: tsutsui->port-alpha-maintainer
Responsible-Changed-By: tsutsui@narn.netbsd.org
Responsible-Changed-When: Sun, 20 Jan 2008 15:24:09 +0900
Responsible-Changed-Why:
It's too hard to debug this without real hardware.I hope someone who has Jensen will take this one.
From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/36628 CVS commit: src/sys/arch/alpha/jensenio
Date: Sat, 19 Sep 2020 16:54:34 +0000
Module Name: src
Committed By: tsutsui
Date: Sat Sep 19 16:54:34 UTC 2020
Modified Files:
src/sys/arch/alpha/jensenio: com_jensenio.c
Log Message:
Possible fix for hangup on Jensen mentioned in PR/36628.
According to comments in Linux drivers/tty/serial/8250/8250.h,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/8250/8250.h?h=v5.8#n242
the driver has to set OUT1 and OUT2 lines for "some ALPHA"
otherwise "the machine locks up with endless interrupts."
Note OUT2 (MCR_IENABLE) is set in MI com_attach_subr()
so we have to set OUT1 (MCR_DSR) in the MD attachment.
The information was notified from Miod Vallat.
To generate a diff of this commit:
cvs rdiff -u -r1.15 -r1.16 src/sys/arch/alpha/jensenio/com_jensenio.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Responsible-Changed-From-To: port-alpha-maintainer->thorpej
Responsible-Changed-By: thorpej@NetBSD.org
Responsible-Changed-When: Sun, 25 Jul 2021 19:36:12 +0000
Responsible-Changed-Why:
I'm working on Jensen issues.
State-Changed-From-To: open->closed
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Sun, 25 Jul 2021 21:48:18 +0000
State-Changed-Why:
This is fixed in NetBSD 9.99.87. The root cause was indeed a problem with
the interrupt handling in the "ahb" driver.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.