Subject: digest of port-sparc messages since 96/5/30
To: None <port-sparc@NetBSD.ORG>
From: Paul Kranenburg <pk@NetBSD.ORG>
List: port-sparc
Date: 06/12/1996 17:16:13
Since most of the subscribers of `port-sparc' will not have received any
messages since the truncation of the subscription list around 10 days ago,
I'll send a digest of messages (in two parts) that likely haven't made it
to most of you.
Here's part 1:
----snip----
id m0uPDmn-0004KQC; Thu, 30 May 96 12:53 PDT
Date: Thu, 30 May 1996 12:53:26 -0700 (PDT)
From: Jake Hamby <jehamby@lightside.com>
To: Aaron Brown <abrown@eecs.harvard.edu>
cc: Jake Hamby <hamby@aris.jpl.nasa.gov>, port-sparc@NetBSD.ORG
Subject: Re: More Sun4m troubles (core dumps)..
In-Reply-To: <199605301453.KAA08392@virtual4.eecs.harvard.edu>
Message-ID: <Pine.AUX.3.91.960530125129.29740B-100000@covina.lightside.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 30 May 1996, Aaron Brown wrote:
>
> Are you using a -current ld.so? The 1.1 sparc ld.so didn't flush the
> ICache after modifying it, although this shouldn't affect the
> cache-coherent SuperSPARC caches... hmm....
>
> --Aaron
I'm using -current everything, from a "make build" a few days ago. I'll
double-check ld.so, though I'm sure it would've been installed as part of
the make install. This is a SPARCstation 20 Model 71 (75MHz
SuperSPARC-II) if it makes any difference. After looking at the core
dumps, I don't think any useful information could be obtained from them
since they occur in random places, and only occasionally. Looks like any
program has the potential to crash under sun4m.
---Jake
id m0uPDke-0004KQC; Thu, 30 May 96 12:51 PDT
Date: Thu, 30 May 1996 12:51:12 -0700 (PDT)
From: Jake Hamby <jehamby@lightside.com>
To: Aaron Brown <abrown@eecs.harvard.edu>
cc: Jake Hamby <hamby@aris.jpl.nasa.gov>, port-sparc@NetBSD.ORG
Subject: Re: Sun4m TP Ethernet problem...
In-Reply-To: <199605301451.KAA08379@virtual4.eecs.harvard.edu>
Message-ID: <Pine.AUX.3.91.960530125050.29740A-100000@covina.lightside.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 30 May 1996, Aaron Brown wrote:
>
> You need to add the "link0" flag to /etc/hostname.le0. This was hashed
> out here a while ago with no real consensus, and any auto-detect-type
> system would require changes in the MI driver. I'm going to look into
> the best way to do this this summer, but it won't make it for 1.2.
> The le(4) man page documents the link0 option.
>
> --Aaron
This makes sense. Guess I should've RTFM first. Thanks!
---Jake
(5.65c/IDA-1.4.4 for port-sparc@netbsd.org); Thu, 30 May 1996 23:31:02 +0200
From: Eric Jantzen <Eric.Jantzen@ccmitpa.univ-lyon1.fr>
Message-Id: <199605302131.AA09161@ccmitpa.univ-lyon1.fr>
Subject: Pb with SunOS binary...
To: jehamby@lightside.com (Jake Hamby)
Date: Thu, 30 May 1996 23:31:02 +0200 (MET DST)
Cc: port-sparc@NetBSD.ORG
In-Reply-To: <Pine.AUX.3.91.960528134925.12144A-100000@covina.lightside.com> from "Jake Hamby" at May 28, 96 01:50:29 pm
Content-Type: text
> >
> > > 1) how can I find a Mosaic for Sparc-NetBSD
> > >
> > > you can probably use lesstif (http://www.hungry.com/) for this. i haven't
> > > tried it personally, but, i plan to sometime soon.
> >
> > YES, I have tried this, that don't work...
> > the binary crash.
>
> I've had no trouble with the SunOS version of Netscape. It even supports
> Java, sound, and plugins! MUCH nicer than Mosaic, you may want to try it.
>
Hello,
I want use SunOS version of Netscape, but when I start it I have already this
problem:
----begin----
# ./netscape_dns
Bad system call (core dumped)
----end----
and that's all
I have the same problem with all SunOS executable dynamically linked...
WHY???
Some info on my netscape:
LICENSE: English text
Netscape.ad: English text
README: English text
XKeysymDB: English text
hot-convert.sh: Bourne Shell script text
movemail: sparc demand paged dynamically linked executable
movemail-src: directory
netscape: sparc demand paged dynamically linked executable
nls: directory
That is a version 2.01
Eric JANTZEN
Message-Id: <199605302202.SAA08846@virtual4.eecs.harvard.edu>
To: Jake Hamby <jehamby@lightside.com>
cc: port-sparc@netbsd.org
Subject: Re: More Sun4m troubles (core dumps)..
In-reply-to: Your message of "Thu, 30 May 1996 12:53:26 PDT."
<Pine.AUX.3.91.960530125129.29740B-100000@covina.lightside.com>
Date: Thu, 30 May 1996 18:02:10 -0400
From: Aaron Brown <abrown@eecs.harvard.edu>
On Thu, 30 May 1996, Jake Hamby wrote:
> I'm using -current everything, from a "make build" a few days ago. I'll
> double-check ld.so, though I'm sure it would've been installed as part of
> the make install. This is a SPARCstation 20 Model 71 (75MHz
> SuperSPARC-II) if it makes any difference. After looking at the core
> dumps, I don't think any useful information could be obtained from them
> since they occur in random places, and only occasionally. Looks like any
> program has the potential to crash under sun4m.
This is strange...I've had absolutely no trouble on the same machine. But
I haven't had a chance to build a kernel recently, and there have been
a bunch of changes to locore, in the same area where a bug early in the
porting process caused the same problems. I'll try to build a new
kernel and see if I can reproduce it (it may take a few days...I'm not
physically near my machine until Monday).
--Aaron
id AA00677; Fri, 31 May 96 00:14:57 +0200
From: Paul Kranenburg <pk@cs.few.eur.nl>
Message-Id: <9605302214.AA00677@cs.few.eur.nl>
Subject: Re: Alas...
To: thorpej@nas.nasa.gov
Date: Fri, 31 May 1996 00:14:57 +0200 (MET DST)
Cc: port-sparc@netbsd.org
In-Reply-To: <199605282319.QAA24924@lestat.nas.nasa.gov> from "Jason Thorpe" at May 28, 96 04:19:05 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> ...it looks like we treat the "TC" bit differently ... SunOS calls it:
>
> #define ESP_STAT_XZERO 0x10 /* transfer counter zero */
>
> ...where we call it:
>
> #define ESPSTAT_TC 0x10 /* Terminal Count */
>
> I would guess from the SunOS name for the bit that they treat the
> presence of that bit as "zero bytes transfered".
I don't think so. The `terminal count' bit is (reportedly) set at the moment
the transfer count goes from 1 to 0. If, by the time the device interrupts,
`TC' is not set this means that the actual transfer was less then requested.
(this is not an error, it happens all the time because of intervening
SAVEPOINTER messages or when `requesting sense'). If that's the case, the
residual io count can be found in the esp's transfer count registers.
> From looking at our
> handling of this in dma.c (line 450), I'm not entirely certain that
> setting resid to 64k is a wise idea ... it _seems_ like it should be set
> to sc->sc_dmasize (the size of the request).
>
> Note that the chunk of code in espdmaintr() looks like this:
>
> if (resid == 0 && (sc->sc_esp->sc_rev <= ESP100A) &&
> (sc->sc_esp->sc_espstat & ESPSTAT_TC) == 0)
> resid = 65536;
>
> trans = sc->sc_dmasize - resid;
> if (trans < 0) { /* transferred < 0 ? */
> printf("%s: xfer (%d) > req (%d)\n",
> sc->sc_dev.dv_xname, trans, sc->sc_dmasize);
> trans = sc->sc_dmasize;
> }
The idea behind this is that loading an all-zero bit pattern in the esp's
transfer counters actually means "a 64K transfer count". Now, this never
happens in any of the cases reported here...
Note that the transfer size _is_ actually set to the initial request size
(after printing the message), whenever this "impossible" situation is
detected.
> Now, if it is indeed an indication that nothing was actually transfered,
> then that chunk of code "feels wrong"...
>
> > sd0 at scsibus0 targ 3 lun 0: <QUANTUM, TRB850S, 0404> SCSI2 0/direct fixed
> > sd0: dma0: xfer (-65528) > req (8)
> > esp0: !TC [intr 10, stat 83, step 4] prevphase 1, resid 8
> > 810MB 3653 cyl, 4 head 113, sec, 512 bytes/sec
Obviously, something has made it to the host, as the inquiry and mode sense
commands have at least produced some reasonable output.
-pk
id AA01515; Fri, 31 May 96 00:47:28 +0200
From: Paul Kranenburg <pk@cs.few.eur.nl>
Message-Id: <9605302247.AA01515@cs.few.eur.nl>
Subject: Re: More Sun4m troubles (core dumps)..
To: jehamby@lightside.com (Jake Hamby)
Date: Fri, 31 May 1996 00:47:27 +0200 (MET DST)
Cc: port-sparc@NETBSD.ORG
In-Reply-To: <Pine.AUX.3.91.960530125129.29740B-100000@covina.lightside.com> from "Jake Hamby" at May 30, 96 12:53:26 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> I'm using -current everything, from a "make build" a few days ago. I'll
> double-check ld.so, though I'm sure it would've been installed as part of
> the make install. This is a SPARCstation 20 Model 71 (75MHz
> SuperSPARC-II) if it makes any difference. After looking at the core
> dumps, I don't think any useful information could be obtained from them
> since they occur in random places, and only occasionally. Looks like any
> program has the potential to crash under sun4m.
Those are the symptoms of a kernel bug that would make the system loose
track of the state of physical pages (referenced/modified bits) that
I've been seeing. In my case (Sparcstation Classic) this happened normally
only under heavy load. If you have a chance, try the little bugger below.
I'd be interested toknow how a SS20 behaves if you start a couple of
`./b.out &' ..
I've checked in a couple of fixes for pmap.c over the few last days.
You'll see these appearing (in sup/tar) when I've had a chance to
pull them down to the release branch (which will not happen until
after the weekend, I'm afraid).
On a Classic, I also used to see an occasional "trap 0x29" (causing a
SIGILL to be delivered to the process). This might be related to the
aforementioned bugs - i've not seen them for a couple of days now -
but a demonstrable cause escapes me so far..
-pk
---- bugger ----
> a.c cat << _EOF
main() { return 0; }
_EOF
> b.c cat << _EOF
main(){
int n;
int status;
while(1) {
n = fork();
if (n == 0) {
execl("./a.out", "a.out", 0);
err(1, "execl");
} else if (n == -1) {
err(1, "fork");
}
wait(&status);
}
return 0;
}
_EOF
cc a.c
cc -o b.out b.c
Message-Id: <199605310004.RAA18544@lestat.nas.nasa.gov>
To: Eric Jantzen <Eric.Jantzen@ccmitpa.univ-lyon1.fr>
Cc: jehamby@lightside.com (Jake Hamby), port-sparc@netbsd.org
Subject: Re: Pb with SunOS binary...
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Thu, 30 May 1996 17:04:49 -0700
On Thu, 30 May 1996 23:31:02 +0200 (MET DST)
Eric Jantzen <Eric.Jantzen@ccmitpa.univ-lyon1.fr> wrote:
> ----begin----
> # ./netscape_dns
> Bad system call (core dumped)
> ----end----
> and that's all
> I have the same problem with all SunOS executable dynamically linked...
Do you have COMPAT_SUNOS in your kernel?
----save the ancient forests - http://www.bayarea.net/~thorpej/forest/----
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939
Message-Id: <199605310213.EAA04522@wit387304.student.utwente.nl>
Subject: Re: Alas...
To: port-sparc@NetBSD.ORG
Date: Fri, 31 May 1996 04:13:51 +0200 (MET DST)
From: e.p.boven@student.utwente.nl (Paul Boven)
Reply-to: e.p.boven@student.utwente.nl
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hello everyone,
pk wrote:
> I don't think so. The `terminal count' bit is (reportedly) set at the moment
> the transfer count goes from 1 to 0. If, by the time the device interrupts,
> `TC' is not set this means that the actual transfer was less then requested.
> (this is not an error, it happens all the time because of intervening
> SAVEPOINTER messages or when `requesting sense'). If that's the case, the
> residual io count can be found in the esp's transfer count registers.
Yes, that explanation kind of makes sense, given the way SunOS and NetBSD
decide to name the register-bit. And of course this is only neccesary on
ESP-versions <100A, too. So it is indeed kind of a "carry" or "overflow"
situation.
>
> > From looking at our
> > handling of this in dma.c (line 450), I'm not entirely certain that
> > setting resid to 64k is a wise idea ... it _seems_ like it should be set
> > to sc->sc_dmasize (the size of the request).
[ chainsaw ]
> The idea behind this is that loading an all-zero bit pattern in the esp's
> transfer counters actually means "a 64K transfer count". Now, this never
> happens in any of the cases reported here...
Ok, I hope I understand this: The interrupt comes in, and resid = 0,
while TC is unset. We therefore assume that this must have been a 64k
request, of which no bytes were transferred yet, and let it go for another
round, resetting resid to 65536 which will loose it's first (high) bit
again somewhere on it's way to the esp-chip.
But I think it's fairly safe to assume that 64k transfers won't be happening
at this stage, we are after all autoconfigging the devices. And anyway, I
only requested 4 bytes. So how come I still end up with an unset TC while
resid = 0? Are we replying too quickly to the interrupt, perhaps, it needing
some more time to flip TC?
> Note that the transfer size _is_ actually set to the initial request size
> (after printing the message), whenever this "impossible" situation is
> detected.
Well, as we apparently know how big the transfer was we requested, maybe one
ought to add a check on sc->sc_dmasize to the code that sets resid to 65536?
> > > sd0 at scsibus0 targ 3 lun 0: <QUANTUM, TRB850S, 0404>
SCSI2 0/direct fixed
> > > sd0: dma0: xfer (-65528) > req (8)
> > > esp0: !TC [intr 10, stat 83, step 4] prevphase 1, resid 8
> > > 810MB 3653 cyl, 4 head 113, sec, 512 bytes/sec
>
> Obviously, something has made it to the host, as the inquiry and mode sense
> commands have at least produced some reasonable output.
Well, on my ELC, even that doesn't happen, the drive is not recognised at
all. It could be that Kirsten gets 44 bytes transfered, and I only 4, there
is likely a bit more information in what he gets :)
The rest of the error-messages we see are all !TC, I think (not 100% sure)
and it therefore seems that the problems we have are really with the TC-
bit of the ESP-status-register. Or is this just symptomatic, and is there
another reason why this doesn't work on so many ELCs?
I recompiled the kernel, with the original dma.c again, and after setting
the debugging on esp on. Would anyone be interested in a dump of this, to
help further the search? In that case, I'll hook up another computer and set
the console to ttya etc.
--
----------------------------------------------------------------------
Paul Boven, <e.p.boven@student.utwente.nl> PE1NUT QRV 145.575 JO32KF
"And she looked like she had sex, with a tyranosaurus rex"
Cannibal surf babe -- Afraid of sunlight -- Marillion
----------------------------------------------------------------------
id HAA23816; Fri, 31 May 1996 07:35:06 -0400
From: "John Franklin Acree" <jfacree@eos.ncsu.edu>
Message-Id: <9605310735.ZM23814@eos.ncsu.edu>
Date: Fri, 31 May 1996 07:35:05 -0400
To: port-sparc@NetBSD.ORG
Subject: sparc NetBSD
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
I'm trying to install NetBSD for a Sparc, onto a 424mb drive, where can I get
the miniroot, already compiled, for this?
Message-Id: <199605311331.RAA08341@stack.comstar.ru>
From: "Eugene Nesterenko" <eenest@comstar.ru>
To: <port-sparc@netbsd.org>
Subject: please help me get off this list!
Date: Fri, 31 May 1996 17:25:17 +0400
Please help me get off this group!
--
---------------------------------------
Eugene Nesterenko, QUARTA Networks
E-mail: eenest@quarta-net.ru, eenest@quarta.msk.ru
Fax: +7 095 425-0000
id HAA28951; Fri, 31 May 1996 07:53:13 -0700
Date: Fri, 31 May 1996 07:53:12 -0700 (PDT)
From: Kerry Gray <kgray@netcom.com>
To: port-sparc@NetBSD.ORG
Subject: Successful boot of sun4c
Message-ID: <Pine.SUN.3.91.960531074110.27239A-100000@netcom13>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I finally got my sparc to boot yesterday. I would like to publicly thank
all these people for helping me out (during the many reformats and
shuffling of stuff, the dev directory had gotten lost):
Chuck Cranor <chuck@dworkin.wustl.edu>
Jason Thorpe <thorpej@nas.nasa.gov>
Greg Earle <earle@isolar.Tujunga.CA.US>
"Ron G. Minnich" <rminnich@sarnoff.com>
Peter Svensson <petersv@df.lth.se>
Taras Ivanenko <ivanenko@ctpa03.mit.edu>
greywolf@defender.VAS.viewlogic.com
tuc@melb.convergent.com.au
David Brownlee <david@mono.org>
der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
To: port-sparc@NetBSD.ORG
Subject: Re: Booting sun4c via nfs
> nfs_boot finishes and I get the following:
> root on boot9:/usr/sparc
> WARNING: clock lost 9631 days -- CHECK AND RESET THE DATE!
> swap on boot9:/usr/sparc/swapfile
> At this point the sparc hangs. L1-A will get me back to the boot ROM
> 'ok' prompt.
This looks a lot like the "missing /dev/console" problem. Try
installing the patch in PR 2236 and see if the kernel complains about a
missing /dev/console. If so, make sure boot9:/usr/sparc/dev/ is
populated...if not, check it anyway; /dev/console may exist but not be
character special device (0,0).
der Mouse
mouse@collatz.mcrcim.mcgill.edu
id HAA29677; Fri, 31 May 1996 07:56:02 -0700
Date: Fri, 31 May 1996 07:56:02 -0700 (PDT)
From: Kerry Gray <kgray@netcom.com>
To: port-sparc@NetBSD.ORG
Subject: getting sparc to boot off sd
Message-ID: <Pine.SUN.3.91.960531075400.27239B-100000@netcom13>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
The install doc says I must have a copy of a boot program from SunOS to
boot from the internal disk. I don't have SunOS. Is there a way to make
it boot from disk, or am I S.O.L., doomed to net-boot for all eternity?
Message-Id: <199605311538.IAA01158@lestat.nas.nasa.gov>
To: "John Franklin Acree" <jfacree@eos.ncsu.edu>
Cc: port-sparc@NetBSD.ORG
Subject: Re: sparc NetBSD
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Fri, 31 May 1996 08:38:21 -0700
On Fri, 31 May 1996 07:35:05 -0400
"John Franklin Acree" <jfacree@eos.ncsu.edu> wrote:
> I'm trying to install NetBSD for a Sparc, onto a 424mb drive, where can I get
> the miniroot, already compiled, for this?
You can get the NetBSD/sparc 1.1 distribution from:
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.1/sparc/
Ciao.
----save the ancient forests - http://www.bayarea.net/~thorpej/forest/----
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939
id KAA01809; Fri, 31 May 1996 10:02:24 -0700 (PDT)
Date: Fri, 31 May 1996 10:02:03 -0700 (PDT)
From: "Daniel C. Konnoff" <daniel@icess.ucsb.edu>
Subject: unsubscribe
To: port-sparc@NetBSD.ORG
Message-ID: <Pine.3.85.9605311003.A1794-0100000@eos.s2k.ucsb.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Daniel Konnoff
CRM-Programmer/Analyst
Institute for Computational Earth System Science
6832 Ellison Hall
UC Santa Barbara
Santa Barbara, Ca. 93106
daniel@icess.ucsb.edu
805/962-0463
Message-Id: <199605311731.KAA02741@lestat.nas.nasa.gov>
To: Kerry Gray <kgray@netcom.com>
Cc: port-sparc@netbsd.org
Subject: Re: Successful boot of sun4c
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Fri, 31 May 1996 10:31:07 -0700
On Fri, 31 May 1996 07:53:12 -0700 (PDT)
Kerry Gray <kgray@netcom.com> wrote:
> I finally got my sparc to boot yesterday. I would like to publicly thank
> all these people for helping me out (during the many reformats and
> shuffling of stuff, the dev directory had gotten lost):
Cool!
----save the ancient forests - http://www.bayarea.net/~thorpej/forest/----
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939
From: greywolf@defender.VAS.viewlogic.com
id AA03925; Fri, 31 May 1996 16:18:07 +0500
id AA21022; Fri, 31 May 96 13:47:26 PDT
id AA26736; Fri, 31 May 96 13:47:24 PDT
Date: Fri, 31 May 96 13:47:24 PDT
Message-Id: <9605312047.AA26736@>
To: port-sparc@netbsd.org
Subject: libkvm has a problem -- and WOW!
Reply-To: greywolf@starwolf.com
First, the WOW! part. This is an AMAZING thing! I have a nice neat little
MAKE script which goes through and rebuilds everything, basically hitting
each subdirectory and doing "make && make install && make clean" (as I
have a BARELY sufficient /usr/src partition -- 180MB isn't QUITE large
enough to hold source + obj + binaries; don't know how much that needs
on a SPARC). ...
Anyway, ran it last night and WOW! Came back this morning and noticed that
except for some stuff in usr, the build worked. I did a (cd /usr/src;
make includes) followed by (cd /usr/src/gnu/usr.bin/gcc; make install; make &&
make install), and that worked as predicted, followed by (cd /usr/src;
sh MAKE), and that rebuilt an amazingly large part of the world (lib, libexec,
bin, sbin, usr.sbin...) without much of a hitch...
...but anything that referenced libkvm tried to make a call to _kvm_pa2off();
and that failed because kvm_sparc.c doesn't HAVE _kvm_pa2off() as a function
there. I dropped in the one from kvm_sun3.c and it worked like a charm --
(cd /usr/src/bin/ps; make; ./ps ax) produced the right output, so I installed.
Sources were from 5/29. Similar problems occurred building ccdconfig and
fsck_ffs (though why fsck_ffs I'm not sure).
Everything else just kind of worked! Thanks to everyone who put in the hard
work, and thanks to core for committing my changes to fsck_ffs and umount
in a (relatively) timely manner.
--*greywolf;
--
"Your chief has even inscribed his mark on the sole of my boot."
Message-Id: <199605312141.XAA00219@wit387304.student.utwente.nl>
Subject: ESP-debug output on my ELC
To: port-sparc@NetBSD.ORG
Date: Fri, 31 May 1996 23:41:11 +0200 (MET DST)
From: e.p.boven@student.utwente.nl (Paul Boven)
Reply-to: e.p.boven@student.utwente.nl
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hello everyone,
Compiled a kernel with the debugging on ESP set to maximum, and here's
what it got me, read it and weep. (And then please give some hints how
to fix this :)
*** WARNING *** this kernel has been compiled with GCC 2.4.5 from the
NetBSD-1.1 installation kit, with -Werror turned off. The printf ("%b")
for the flags, I fear, does *NOT* work properly. Some of the output
of debug might therefore be a little bit inaccurate, but I think it will
have no effect on how the code behaves apart from that. After all, the
current-snapshot kernel behaves in just the same way. I hope to try and
get the new GCC 2.7.2 installed over the weekend, but decided to send you
this anyway to look at.
--
boot netbsd.diy -s
SPARCstation ELC, Type 4 Keyboard
ROM Rev. 2.4, 12 MB memory installed, Serial #117740.
Boot device: /sbus/esp@0,800000/sd@0,0 File and args: netbsd.diy -s
>> NetBSD BOOT [$Revision: 1.4 $]
NetBSD 1.2_ALPHA (BLURB) #5: Fri May 31 11:48:11 MET DST 1996
paul@wit387304.student.utwente.nl:/usr/src/sys/arch/sparc/compile/BLURB
cpu0 at mainbus0: SUNW,Sun 4/25 (W8601/8701 or MB86903 @ 33 MHz, on-chip FPU)
cpu0: cache chip bug; trap page uncached
cpu0: 65536 byte write-through, 32 bytes/line, hw flush cache enabled
dma0 at sbus0 slot 0 offset 0x400000: rev 1+
esp0 at sbus0 slot 0 offset 0x800000 pri 3: ESP100A[ESP_INIT(1)] 20Mhz, target 7
scsibus0 at esp0
[esp_scsi_cmd] [0x0, 6]->0 [esp_poll] [espintr]regs[intr=98,stat=80,step=00] [esp_sched] [espselect(t0,l0,cmd:0)] [espintr]regs[intr=18,stat=86,step=01] MESSAGE_OUT_PHASE [esp_msgout(priq:40, prevphase:101)][espintr]regs[intr=10,stat=87,step=01] dma0: xfer (-65531) > req (5)
*** this is the familiar DMA-error, because TC wasn't set.
esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0
*** And again, resid = 0 while TC unset, now esp complains about it
MESSAGE_IN_PHASE esp_poll: timeoutprobe(esp0:0:0): esp0: timed out [ecb 0xf85730a0 (flags 0x0, dleft 0, stat 0)], <state 5, nexus 0xf85730a0, phase(c 7, p 7), resid 0, msg(q 0,o 0) >TRACE: .
*** And so the SCSI-Probe on my machine times out
esp_sched_msgout 4 esp0: timed out [ecb 0xf85730a0 (flags 0x10, dleft 0, stat 0)], <state 5, nexus 0xf85730a0, phase(c 7, p 7), resid 0, msg(q 4,o 0) >TRACE: . AGAIN
[ESP_INIT(1)] [esp_done(error:4)] err=0x04 esp_done: error=4
[esp_sched] [esp_scsi_cmd] [0x0, 6]->0 [esp_poll] [espintr]regs[intr=98,stat=80,step=00] [esp_sched] esp: message queue not empty: 4!
[espselect(t0,l0,cmd:0)] [espintr]regs[intr=18,stat=86,step=01] MESSAGE_OUT_PHASE [esp_msgout(priq:40, prevphase:101)][espintr]regs[intr=10,stat=87,step=01] dma0: xfer (-65531) > req (5)
esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0
MESSAGE_IN_PHASE esp_poll: timeoutprobe(esp0:0:0): esp0: timed out [ecb 0xf85730a0 (flags 0x0, dleft 0, stat 0)], <state 5, nexus 0xf85730a0, phase(c 7, p 7), resid 0, msg(q 0,o 0) >TRACE: .
--
And it goes on, and on, and on, and at last the kernel panicks lacking a
root-device, and reboots.
Paul.
----------------------------------------------------------------------
Paul Boven, <e.p.boven@student.utwente.nl> PE1NUT QRV 145.575 JO32KF
"And she looked like she had sex, with a tyranosaurus rex"
Cannibal surf babe -- Afraid of sunlight -- Marillion
----------------------------------------------------------------------