headers
Manuel Bouyer | 1 Nov 2003 17:05

Re: I cannot install netbsd on an AlphaStation 400

On Fri, Oct 31, 2003 at 02:53:23PM -0800, Carl Lowenstein wrote:
> When I recently used the 1.6.1 CD to install NetBSD on an Alphastation
> 255, I concluded that the "/: file system full" message came from
> an attempt to write to the boot drive (the CDrom) which of course is
> full and not writeable.

No, it's sysinst trying to dump core in the ramdisk, which is too small.
I think this sysinst core dump has been fixed in current and 1.6.2_RC*

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--
Permalink | Reply | 0 comments |
headers
Greg A. Woods | 1 Nov 2003 19:51
X-Face
Favicon

Re: netbsd-1-6 ( <at> 2003/08/10) frozen solid on 2-CPU AS4000, sitting at DDB now

[ On Friday, August 29, 2003 at 17:54:46 (-0600), Michael L. Hitch wrote: ]
> Subject: Re: netbsd-1-6 ( <at> 2003/08/10) frozen solid on 2-CPU AS4000, sitting  at DDB now
>
>   The problem you have appears to be the MP alpha hang problem that a
> number of other people have experienced.  The PR for that problem hasn't
> been submitted yet.

I suppose I should turn one of these messages into a PR then....

> On Fri, 29 Aug 2003, Greg A. Woods wrote:
> > Here's the latest trace and indeed sched_lock is "1" as predicted:
> ...
> > db{0}> trace
> > cpu_Debugger() at cpu_Debugger+0x4
> > panic() at panic+0x168
> > console_restart() at console_restart+0x74
> > XentRestart() at XentRestart+0x90
> > --- console restart (from ipl 4) ---
> > _simple_lock() at _simple_lock+0x15c
> > wakeup() at wakeup+0xcc
> > schedcpu() at schedcpu+0x34c
> > softclock() at softclock+0x2b4
> > hardclock() at hardclock+0x7c0
> > interrupt() at interrupt+0x180
> > XentInt() at XentInt+0x1c
> > --- interrupt (from ipl 0) ---
> > _simple_unlock() at _simple_unlock+0x208
> > pool_put() at pool_put+0x6c
> > pmap_pv_remove() at pmap_pv_remove+0x10c
> > pmap_remove_mapping() at pmap_remove_mapping+0x404
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem Belevich | 5 Nov 2003 03:06

Re: How can I help with hung vnlock()'ed clients?

I occasionally see this problem on my NetBSD-1.6.1/i386 boxes.  In my
case NetBSD is a client and NetAPP file server & bunch of solaris
boxes as NFS servers. Everything is heavily automounted (and
unmounted, too).

The problem usually happens on the box with Intel's i82559 NIC
(if_fxp). The NIC in question occasionally gets stuck for about a
minute, prints "fxp0: device timeout" on the console and starts
working again. This may or may not have something to do with the
problem.

The box with 3com card (if_ex) gets stuck occasionally too, but way
less often ( once every few months vs. once every few weeks).

Good news is that sometimes everything recovers if you do 'ls' on the
filesystem that's mounted from the same place that locked file comes
from. Chances are 50/50. The bad news is that if you're unlucky,
you'll get another stuck process. :-(

--Artem

On Thu, Oct 30, 2003 at 08:50:56PM -0600, "Stephen M. Jones" <smj <at> cirr.com> wrote:
> Hi there!
> 
> I'm wondering what is the best way I can help with a problem I've experienced
> and seen others experience for a couple of years now.  The problem is
> where an NFS client will get 'hung' in a vnlock() and will most likely not
> recover.  Since I have the oppourtunity to run NetBSD in a high usage
> environment, I thought I might be able to help out .. but I want to know
> what is the best way to.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg A. Woods | 6 Nov 2003 00:33
X-Face
Favicon

Re: fxp bug triggering hung vnlock()'ed NFS client

[[ moving from port-alpha to tech-net (and tech-kern) because this is
   definitely not architecture specific ]]

[ On Tuesday, November 4, 2003 at 18:06:55 (-0800), Artem Belevich wrote: ]
> Subject: Re: How can I help with hung vnlock()'ed clients?
>
> The problem usually happens on the box with Intel's i82559 NIC
> (if_fxp). The NIC in question occasionally gets stuck for about a
> minute, prints "fxp0: device timeout" on the console and starts
> working again. This may or may not have something to do with the
> problem.

Hey!  I was just going to post about that.  I was wondering if anyone
else was having problems with timeouts on fxp interfaces with i82559
chips.

I've been having now repeatable problems with the on-board fxp interface
of an Intel STL/2 (PIII) motherboard.

	fxp0 at pci0 dev 3 function 0: i82559 Ethernet, rev 8
	fxp0: interrupting at irq 10
	fxp0: Ethernet address 00:d0:b7:b6:ad:4b
	inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
	inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

I usually see the following first, sometimes several times in a row:

	fxp0: WARNING: SCB timed out!

Then sporadically inter-mixed will be some lines of:
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Woyciesjes | 6 Nov 2003 18:25
Picon

PC64 parts...

	Well, I'm finally getting around to building up my PC64/275MHz box.
Only problem is I have no L2 cache SIMMs, so it won't boot up at the
moment. Plus, I still have to rewire my ATX power supply for it. Got the
mother board connectors from a dead donor Aspen Alpine box :) Tried a
regular AT power supply on the PC64, but since there is no cache, no
go...
	Anybody know where I can get some cache for cheap/trade?
--
---   Dave Woyciesjes
---   ICQ# 905818
Permalink | Reply | 1 comment |
headers
William Langford | 6 Nov 2003 21:03
Picon

Alphastation 500 400MHz with Powerstorm 4d20

'lo!

I've recently decided to dust off and start playing with an AS500 400MHz 
that also happens to have a Powerstorm 4d20.

I first installed linux (debian) with ease, but Xfree86 lacked drivers 
for the card....

Since I've seen several posts on NetBSD and the 4d20, I thought I would 
try it.  My initial attempts met with failure, however, as booting with 
the 4d20 would cause a switch to a black screen during the secondary 
boot loader.  I yanked the 4D20 out and stuck a S3 card in and 
successfully (joyfully ?) installed netbsd.  Yay. I've since then 
attempted to get the 4D20 to work a time or two, but with no success.  
I've tried changing wscon configuration to use only tga0 or vga0 
(instead of both) to no avail, etc.

I've heard of Roland Dowdeswell's work on getting the cards to work, but 
I've not seen any documentation on how to go about casting the right 
spell to make it happen :(.  Any insight would be greatly appreciated.

-Will
Permalink | Reply | 1 comment |
headers
vance | 6 Nov 2003 23:24

AlphaServer 8400


Is SMP supported on these machines?  How about on the GS140?  ES40?

Peace...  Sridhar
Permalink | Reply | 0 comments |
headers
Roland Dowdeswell | 7 Nov 2003 05:40
Favicon

Re: Alphastation 500 400MHz with Powerstorm 4d20

On 1068148994 seconds since the Beginning of the UNIX epoch
William Langford wrote:
>

>I've heard of Roland Dowdeswell's work on getting the cards to work, but 
>I've not seen any documentation on how to go about casting the right 
>spell to make it happen :(.  Any insight would be greatly appreciated.

Well, there shouldn't really be much magic involved.  There are
two variables that might affect what is going on:  one of the
jumpers on the card which is labeled `vga en' and the dial switch
which will choose what resolution to use.  I'd suggest trying some
different resolutions on the dial and seeing if that makes any
difference.

There is a chart on the NetBSD/alpha FAQ that suggests what the different
settings mean.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/
Permalink | Reply | 0 comments |
headers
Greg A. Woods | 7 Nov 2003 23:22
X-Face
Favicon

"virtual memory exausted" building netbsd-1-6 for sparc on alpha

I'm trying a cross-build of netbsd-1-6 for sparc on my alpha.  It gets this far:

/build/woods/building/NetBSD-1.6.x-alpha-sparc-tools/bin/sparc--netbsdelf-gcc -O2 -g
-DALL_STATE -DUSG_COMPAT -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wreturn-type -Wpointer-arith -Wswitch -Wshadow  -Werror  -D_LIBC -DLIBC_SCCS
-DSYSLIBC_SCCS -D_REENTRANT -I/proven/work/woods/m-NetBSD-1.6/lib/libc/include -DINET6 -DNLS
-D__DBINTERFACE_PRIVATE -I/proven/work/woods/m-NetBSD-1.6/lib/libc/../../libexec/ld.elf_so
-I/proven/work/woods/m-NetBSD-1.6/lib/libc/dlfcn -DI18NMODULE_MAJOR=4 -DWITH_RUNE
-I/proven/work/woods/m-NetBSD-1.6/lib/libc -DRESOLVDEBUG -DRESOLVSORT -I. -DPOSIX_MISTAKE
-DPORTMAP -DFLOATING_POINT -nostdinc -isystem
/build/woods/building/NetBSD-1.6.x-sparc-destdir/usr/include  -c /proven/work/woods/m-NetBSD-1.6/lib/libc/hash/sha1.c
/proven/work/woods/m-NetBSD-1.6/lib/libc/hash/sha1.c: In function `_SHA1Transform':
/proven/work/woods/m-NetBSD-1.6/lib/libc/hash/sha1.c:206: virtual memory exhausted

This machine has 1.5GB of RAM and 1GB of swap, but of course that's not
what counts.  My default soft rlimits are:

	$ ulimit -a
	time(cpu-seconds)    unlimited
	file(blocks)         unlimited
	coredump(blocks)     unlimited
	data(kbytes)         131072
	stack(kbytes)        2048
	lockedmem(kbytes)    485077
	memory(kbytes)       1455232
	nofiles(descriptors) 64
	processes            160

I increased the data and stack limits to their default hard limits:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Husemann | 8 Nov 2003 00:01
Picon

Re: "virtual memory exausted" building netbsd-1-6 for sparc on alpha

On Fri, Nov 07, 2003 at 05:22:58PM -0500, Greg A. Woods wrote:
> I'm trying a cross-build of netbsd-1-6 for sparc on my alpha.  It gets this far:
> 
> /build/woods/building/NetBSD-1.6.x-alpha-sparc-tools/bin/sparc--netbsdelf-gcc -O2 -g
-DALL_STATE -DUSG_COMPAT -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wreturn-type -Wpointer-arith -Wswitch -Wshadow  -Werror  -D_LIBC -DLIBC_SCCS
-DSYSLIBC_SCCS -D_REENTRANT -I/proven/work/woods/m-NetBSD-1.6/lib/libc/include -DINET6 -DNLS
-D__DBINTERFACE_PRIVATE -I/proven/work/woods/m-NetBSD-1.6/lib/libc/../../libexec/ld.elf_so
-I/proven/work/woods/m-NetBSD-1.6/lib/libc/dlfcn -DI18NMODULE_MAJOR=4 -DWITH_RUNE
-I/proven/work/woods/m-NetBSD-1.6/lib/libc -DRESOLVDEBUG -DRESOLVSORT -I. -DPOSIX_MISTAKE
-DPORTMAP -DFLOATING_POINT -nostdinc -isystem
/build/woods/building/NetBSD-1.6.x-sparc-destdir/usr/include  -c /proven/work/woods/m-NetBSD-1.6/lib/libc/hash/sha1.c
> /proven/work/woods/m-NetBSD-1.6/lib/libc/hash/sha1.c: In function `_SHA1Transform':
> /proven/work/woods/m-NetBSD-1.6/lib/libc/hash/sha1.c:206: virtual memory exhausted

Gcc 2.95.x had lots of problems compiling sha* code for sparc on 64bit 
machines, most sha* places in our kernel have #ifdef __sparc64__ versions
that split otherwise inlined code into smaller procedures for this reason.

Seems like host=alpha target=sparc triggers the same problem.

It is solved in gcc 3.3.x.

Martin
Permalink | Reply | 0 comments |

Gmane