headers
Rui Paulo | 1 Jan 2006 01:29

Re: Installation on SparcStation Ultra 1

On 2005.12.31 16:15:15 -0600, Johan A.van Zanten wrote:
| 
| der Mouse <mouse <at> Rodents.Montreal.QC.CA> wrote:
| > Hmm, I note....
| > 
| > f22         0x2320			"\0\0\0\0\0\0# "
| > f24         0x556e697665727320		"Univers "
| > f26         0x20204d6443644974		"  MdCdIt"
| > f28         0xa6e616d65205543		"\nname UC"
| > f30         0x490a737061636577		"I\nspacew"
| > 
| > f40         0x2320556e69766572		"# Univer"
| > f42         0x732020204d644364		"s   MdCd"
| > f44         0x49740a6e616d6520		"It\nname "
| > f46         0x5543490a73706163		"UCI\nspac"
| > f48         0x2320556e69766572		"# Univer"
| > 
| > Darned if I know what that means, though it looks suspiciously
| > un-OS-like to me.
| 
| 
|  Google hits for "mdcdit" seem to be primarily associated with fonts.
| Could it be code from one of the font or typeface rendering libraries
| that's getting tickled by xdm starting up?

IIRC, the problem was found while installing.

		-- Rui Paulo
Permalink | Reply | 1 comment |
headers
Rick Kelly | 1 Jan 2006 02:02

Re: Installation on SparcStation Ultra 1

Rui Paulo said:

>IIRC, the problem was found while installing.

Maybe he has a bad tar archive?
--

-- 
Rick Kelly	rmk <at> rmkhome.com
		<http://www.rmkhome.com/>
		<http://rkba.rmkhome.com/> - the right to keep and bear arms
		<http://wolf.rmkhome.com/> - firearm forums
Permalink | Reply | 0 comments |
headers
John Honniball | 1 Jan 2006 15:36
Picon

Re: Installation on SparcStation Ultra 1

Rui Paulo wrote:
> It seems to me the stack is mangled. The last time I saw a problem
> like this on i386 it was due to the kernel not handling SSE
> exceptions (fixed by Christos).

Well, this made me wonder if I had either a bad CD-ROM ISO
image or some sort of hardware trouble.  I did a quick check
of some of the checksums on the CD, and all appeared to be OK.

Then, I started pulling memory modules out of the machine,
taking it down to 384Mb.  That installed and ran OK, so I'm
now trying to isolate the duff memory.  Can anyone recommend
a really good memory tester for the UltraSparc?

> I don't know the sparc arch very well to understand what's going on
> where and I can be pretty damn wrong :-)

I think you were absolutely correct!

Thanks to all, and sorry for the false alarm.

--

-- 
John Honniball
coredump <at> gifford.co.uk
Permalink | Reply | 2 comments |
headers
Michael | 1 Jan 2006 16:30
Picon
Favicon

Re: Installation on SparcStation Ultra 1

Hello,

> Then, I started pulling memory modules out of the machine,
> taking it down to 384Mb.  That installed and ran OK, so I'm
> now trying to isolate the duff memory.  Can anyone recommend
> a really good memory tester for the UltraSparc?

The firmware has plenty of built-in tests but apparently not quite as
comprehensive as older SPARCs - apparently the /memory device has no
selftest anymore. You can still 'setenv diag-level max', 'setenv
diag-switch? true' and reboot. It should print out some information and
test memory a bit more thoroughly. If something goes wrong it will tell
you which module failed. 
( note: with diag-switch? set to true the machine will use diag-file and
diag-device instead of boot-file and boot-device, usually that means it
will try to netboot after the tests )

have fun
Michael
Permalink | Reply | 1 comment |
headers
Volker A. Brandt | 1 Jan 2006 16:52
Picon

Re: Installation on SparcStation Ultra 1

> The firmware has plenty of built-in tests but apparently not quite as
> comprehensive as older SPARCs - apparently the /memory device has no
> selftest anymore. You can still 'setenv diag-level max', 'setenv
> diag-switch? true' and reboot. It should print out some information and
> test memory a bit more thoroughly. If something goes wrong it will tell
> you which module failed.

Actually, you need to power-cycle the machine in order to get
better memory diagnostics:

  setenv diag-level max
  setenv diag-switch? true
  <power off>
  <wait 10-15 sec>
  <power on>

Also, you should watch on the serial console if possible, as most
of the "low level diag" messages only appear there.

For more information, see the Sun documentation at:

http://docs.sun.com/app/docs/doc/802-3819-10/6i7minnrf?l=de&a=view

HTH -- Volker
--

-- 
------------------------------------------------------------------------
Volker A. Brandt                  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH              WWW: http://www.bb-c.de/~vab/
Meckenheim, Germany                                   Email: vab <at> bb-c.de
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thierry Lacoste | 2 Jan 2006 15:05
Picon

Re: NetBSD 3.0, named, and sparc64

On Monday 26 December 2005 20:22, Christos Zoulas wrote:
> In article <200512261919.jBQJJNg13626 <at> toad.rmkhome.com>,
>
> Rick Kelly  <rmk <at> rmkhome.com> wrote:
> >I'm replacing my main mailserver/DNS server/ntp server with a box running
> >NetBSD/sparc64 running 3.0. Is there a problem with the fact that named is
> >compiled to use threading?
> >
> >The old box is an SS5 running NetBSD 1.5.4, and it needs to be replaced
> >fairly quick as it is no longer healthy after 6 years on the job.
>
> Depends how much memory you have. I believe that there are still problems
> when threaded processes get swapped out.
>
> christos
You mean entirely swapped? No relation with paging?

I'm currently using 2.0/sparc64 on an Ultra1 production server which runs
ntpd, dhcpd and named. The machine has 128 MB memory and works nicely.
For some reasons, e.g. syslogd configuration, I wanted to upgrade to 3.0.
Do you think it is safe?

Regards,
Thierry.
Permalink | Reply | 0 comments |
headers
John Klos | 3 Jan 2006 19:00

Re: pkgsrc and the T1000

> Has anyone here tried a pkgsrc build on the 'niagra' based T1000 I am anxious 
> to get a toe-hold on this new platform, but installing only sun binaries from 
> scratch isnt my idea of a Good Time.

First, wrong list. Perhaps you're still hung over (or perhaps still 
drunk!), but no worries. BTW - thanks for fixing bunny while I was in 
Chicago.

> They have a try it for 60-days before you decided to buy it plan.

Just pay shipping and handling...

In any case, doing source builds of packages on a modern CPU is not really 
something to worry about. If it were a 50 MHz SPARC, that'd be one thing, 
but you really shouldn't worry about the amount of time it takes to 
compile BIND or Apache or whatever on an 8 core, 4 threads per core, 1 GHz 
CPU.

John
Permalink | Reply | 0 comments |
headers
doomwarrior | 3 Jan 2006 20:13
Picon

NetBSD 3.0 on E420R - esiop cmd time out locks system

hello

i got a new machine (Enterprise 420R) and try to install NetBSD on it. 
But the Systems locks while booting the installation kernel

Trace:

ok boot cdrom
Boot device: /pci <at> 1f,4000/scsi <at> 3/disk <at> 6,0:f  File and args:
NetBSD IEEE 1275 Bootblock
..>> NetBSD/sparc64 OpenFirmware Boot, Revision 1.8
 >> (builds <at> b4.netbsd.org, Mon Dec 19 03:43:43 UTC 2005)
devopen: getdisklabel returned no disk label
devopen: search_label returned no disk label
loadfile: reading header
elf64_exec: Booting 
/pci <at> 1f,4000/scsi <at> 3/disk <at> 6,0:f/netbsd+5570288 <at> 0x1800000+2818320 <at> 0x1d4fef0
symbols  <at>  0xfff42400 195- start=0x1000000
chain: calling OF_chain(800000, d728, 1000000, fff83a80, 18)
Kernel size exceeds 4MB
console is /pci <at> 1f,4000/ebus <at> 1/se <at> 14,400000:a
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
    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 3.0 (INSTALL) #0: Mon Dec 19 04:06:57 UTC 2005

builds <at> b4.netbsd.org:/home/builds/ab/netbsd-3-0-RELEASE/sparc64/200512182024Z-obj/home/builds/ab/netbsd-3-0-RELEASE/src/sys/arch/sparc64/compile/INSTALL
total memory = 256 MB
(Continue reading)

Permalink | Reply | 9 comments |
headers
Manuel Bouyer | 3 Jan 2006 21:50

Re: NetBSD 3.0 on E420R - esiop cmd time out locks system

On Tue, Jan 03, 2006 at 08:13:20PM +0100, doomwarrior wrote:
> hello
> 
> i got a new machine (Enterprise 420R) and try to install NetBSD on it. 
> But the Systems locks while booting the installation kernel
> 
> Trace:
> 
> ok boot cdrom
> [...]
> esiop0 at pci0 dev 3 function 0: Symbios Logic 53c875 (ultra-wide scsi)
> esiop0: using on-board RAM
> esiop0: interrupting at ivec 20
> scsibus0 at esiop0: 16 targets, 8 luns per target
> esiop1 at pci0 dev 3 function 1: Symbios Logic 53c875 (ultra-wide scsi)
> esiop1: using on-board RAM
> esiop1: interrupting at ivec 26
> scsibus1 at esiop1: 16 targets, 8 luns per target
> psycho1 at mainbus0 addr 0xfffc6000
> SUNW,psycho: impl 0, version 4: ign 7c0 bus range 128 to 128; PCI bus 128
> pci1 at psycho1
> pci1: i/o space, memory space enabled
> timer0 at mainbus0 addr 0xfff9fc00 irq vectors 7ec and 7ed
> pcons at mainbus0 not configured
> wskbd0 at kbd0 mux 1
> kbd0: reset failed
> Kernelized RAIDframe activated
> md0: internal 5120 KB image area
> scsibus0: waiting 2 seconds for devices to settle...
> scsibus1: waiting 2 seconds for devices to settle...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael | 3 Jan 2006 21:53
Picon
Favicon

Re: NetBSD 3.0 on E420R - esiop cmd time out locks system

Hello,

> i got a new machine (Enterprise 420R) and try to install NetBSD on
> it.
> 
> But the Systems locks while booting the installation kernel
...
> kbd0: reset failed
...
> probe(esiop0:0:0:0): command timeout, CDB: 0x12 00 00 00 24 00

On first glance this looks like an interrupt routing issue. Either
interrupts are not enabled ( unlikely I think ) or they aren't signalled
where the kernel expects them.
Did you try a -current kernel? Blade 1x0 systems have similar problems (
depending on firmware, newer revisions apparently encode interrupt
information in a different way ) - I'm not sure if anyone fixed it.

have fun
Michael
Permalink | Reply | 3 comments |

Gmane