headers
Andy Ruhl | 2 Mar 2009 06:53
Picon

Re: Qube2 with release-5 hangs, wapbl problem?

On Mon, Dec 1, 2008 at 7:11 AM, Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp> wrote:
> - try the latest 5.0_BETA kernel from ftp.NetBSD.org://pub/NetBSD-daily/
> - try to send BREAK via serial console at freeze (to get ddb(4) console)
> - try a custom kernel with options DIAGNOSTIC or DEBUG
> etc?

I never did this, but I noticed recent fixes in the release-5 tree so
I synched my source tree and built a new kernel.

I have not had a hang since I did this, and the machine has been
running far longer than it used to before when I had logging enabled.

This is very good news for me. I think I will try it on my i386
machine that has large filesystems now.

Andy
Permalink | Reply | 0 comments |
headers
Havard Eidnes | 9 Mar 2009 08:37
Picon

Package binaries for NetBSD/sgimips 4.0 / pkgsrc-2008Q4

Hi,

I've uploaded the results of a bulk build for NetBSD/sgimips 4.0 to

   ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/mipseb/4.0_2008Q4/

A total of 5.0GB of packages were uploaded, for a total of 4221
packages.

The source tree this was built from was updated Jan 15, 2009.

For the packages which are not machine-specific (should be the vast
majority), these packages should also be usable on other mips big-
endian ports.

I'll update to the pkgsrc-2008Q4 branch proper and continue building
that for now.

Regards,

- Håvard
Permalink | Reply | 2 comments |
headers
Toru Nishimura | 13 Mar 2009 10:39

standard runtime for (possible/hopeful) 64bit kernels

Hi,

Hypothetic NetBSD/powerpc64 and NetBSD/mips64
will be bi-architecture OSes like sparc64 and amd64
where 32bit binaries work just as 64bit natives
out-of-box.  I wonder NetBSD would follow L* way for
them;

- standard userlands will be 32bit while kernel run
in 64bit mode, with provision of 64bit application
runtime and development.  It's like 64it Solaris / IRX.
Is my understanding correct?

Toru Nishimura / ALKYL Technology
Permalink | Reply | 42 comments |
headers
Martin Husemann | 13 Mar 2009 11:04
Picon

Re: standard runtime for (possible/hopeful) 64bit kernels

On Fri, Mar 13, 2009 at 06:39:19PM +0900, Toru Nishimura wrote:
> Hypothetic NetBSD/powerpc64 and NetBSD/mips64
> will be bi-architecture OSes like sparc64 and amd64
> where 32bit binaries work just as 64bit natives
> out-of-box.  I wonder NetBSD would follow L* way for
> them;

Both sparc64 and amd64 default to 64bit userland but provide -m32 support
to create 32bit binaries. For sparc the difference is marginal (i.e. it
very much depends on your application if 32bit or 64bit is better), but for
amd64 the difference is probably noticable due to the very different ABI.

Of course this does not mean that ppc64 or mips64 would have to choose the
same default.

Martin
Permalink | Reply | 40 comments |
headers
Toru Nishimura | 13 Mar 2009 11:28

Re: standard runtime for (possible/hopeful) 64bit kernels

Martin Husemann said;

> Both sparc64 and amd64 default to 64bit userland but provide -m32 support
> to create 32bit binaries. 
> ...
> Of course this does not mean that ppc64 or mips64 would have to choose the
> same default.

As a pipe dreaming, I'm inclined to 32bit userlands with 64bit kernel for them
since Linux/ppc64 and IRIX6 did so, however, some naive free software get
confused by uname -a result to determine which userland API to go.  I've
openSUSE11 for dualcore PPC970 PCIe PowerMac G5 at hard, and
occationally get tangled by poor configure script to choose 64/32bit env.

Toru Nishimura / ALKYL Technology
Permalink | Reply | 0 comments |
headers
David Holland | 15 Mar 2009 22:12
Picon

Re: standard runtime for (possible/hopeful) 64bit kernels

On Fri, Mar 13, 2009 at 11:04:56AM +0100, Martin Husemann wrote:
 > On Fri, Mar 13, 2009 at 06:39:19PM +0900, Toru Nishimura wrote:
 > > Hypothetic NetBSD/powerpc64 and NetBSD/mips64
 > > will be bi-architecture OSes like sparc64 and amd64
 > > where 32bit binaries work just as 64bit natives
 > > out-of-box.  I wonder NetBSD would follow L* way for
 > > them;
 > 
 > Both sparc64 and amd64 default to 64bit userland but provide -m32 support
 > to create 32bit binaries. For sparc the difference is marginal (i.e. it
 > very much depends on your application if 32bit or 64bit is better), but for
 > amd64 the difference is probably noticable due to the very different ABI.

amd64 should grow something like the mips N32 ABI, where you use the
64-bit instruction set but a 32-bit address space. However, that's a
discussion for elsewhere.

On mips there is no reason to build most of userland as 64-bit; 64-bit
pointers just waste memory unless you need the large address space.
However, there is a question of N32 (which is 32-on-64 only) vs. O32,
and also on most older 64-bit machines without a big heap of RAM it
makes more sense to build the kernel as N32 rather than N64... or
possibly N32 with 64-bit paddr_t. And while running 64-bit userland on
an N32 kernel is theoretically possible, in practice it is not going
to work.

The net result is that there are at least three userlands (O32, N32,
N32+N64) and there are other considerations as well, like LE vs. BE,
and the mips-IV and up FPU. (I'm not currently clear on to what extent
N32/N64 is coupled to the 64-bit FPU; if it is, we might end up
(Continue reading)

Permalink | Reply | 36 comments |
headers
Toru Nishimura | 16 Mar 2009 04:05

Re: standard runtime for (possible/hopeful) 64bit kernels

(David Holland made an extensive summary about MIPS ABI...)

> I don't think it's a particularly good idea to build out new ports for
> all of these,

My belief is there is no need to have arch/mips64 and arch/mips/ would
be able to acomodate 64bit variation as sub-dir.  That's the way L* camp
has changed ppc64 implementation.

Since NetBSD/mips is going to become new to 64bit in the 2nd dicade of
the 21st Century, the efforts should be focused on N32, w/ N64 variation,
and O32 compat, I think.  Oh, MIPS processor has such an abilities to run
'reverse-endian' program per-process basis, which is a particular feature
recent modern MIPS implementations have started omitting.

Toru Nishimura / ALKYL Technology
Permalink | Reply | 0 comments |
headers
Simon Burge | 16 Mar 2009 05:10
Picon

Re: standard runtime for (possible/hopeful) 64bit kernels

[ I don't have time to digest the rest of this thread now, I'll
  reply again soon ]

David Holland wrote:

> (I'm not currently clear on to what extent
> N32/N64 is coupled to the 64-bit FPU; if it is, we might end up
> wanting the O64 ABI...)

I'm not exactly sure what you mean by "64-bit FPU" - do you mean using
all 32 FP regs in 64-bit mode, instead of the 32 FP regs in 32-bit
"paired" mode?  If so, n32 and n64 both use 32 FP regs in 64-bit mode
so both ABIs have the "full" FPU available.

Cheers,
Simon.
Permalink | Reply | 31 comments |
headers
Toru Nishimura | 16 Mar 2009 06:31

Re: standard runtime for (possible/hopeful) 64bit kernels

> n32 and n64 both use 32 FP regs in 64-bit mode
> so both ABIs have the "full" FPU available.

MIPS32 = R4000 - upper half of 64bit registers (um, ~= e500/440)

I abandoned tracking recent MIPS processor market development,
and not sure my understanding is valid or not, however, the original
MIPS32 has no FP math inside, but, some modern variants look to
have FP circuit again.  In such designs 16 paired 32bit FP or 32x
full size 64bit FP registers revive again.  What an ABI nightmare.

Toru Nishimura / ALKYL Technology
Permalink | Reply | 0 comments |
headers
David Holland | 16 Mar 2009 07:49
Picon

Re: standard runtime for (possible/hopeful) 64bit kernels

On Mon, Mar 16, 2009 at 03:10:11PM +1100, Simon Burge wrote:
 > > (I'm not currently clear on to what extent
 > > N32/N64 is coupled to the 64-bit FPU; if it is, we might end up
 > > wanting the O64 ABI...)
 > 
 > I'm not exactly sure what you mean by "64-bit FPU" - do you mean using
 > all 32 FP regs in 64-bit mode, instead of the 32 FP regs in 32-bit
 > "paired" mode?

Yes.

 > If so, n32 and n64 both use 32 FP regs in 64-bit mode
 > so both ABIs have the "full" FPU available.

Right; the (implicit) question is whether you can have N32 without
that FPU, as e.g. on a mips-II, or whether such machines have to build
userland, or at least anything using the FPU, as O32 or O64.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 27 comments |

Gmane