headers
Frank van der Linden | 1 Sep 2003 02:33
Picon

new snapshot

It's been a while, but I'm preparing a new binary snapshot (ISO image).
I would have done it this weekend, but.. I discovered I was out of
CD-Rs, and it was too late to get new ones.

So, I'll probably upload one tomorrow, and will announce it.

This should be the last snapshot with an external toolchain.tgz, I
hope that the next one will have the in-tree gcc3 and gdb53, so
that a full rebuild can be done natively. This can be done now
(it's how I build snapshots), but it requires a few Makefile
modifications that shouldn't be in the main tree.

- Frank

--

-- 
Frank van der Linden                                            fvdl <at> netbsd.org
===============================================================================
NetBSD. Free, Unix-like OS. > 45 different platforms.    http://www.netbsd.org/
Permalink | Reply | 0 comments |
headers
Frank van der Linden | 1 Sep 2003 19:37
Picon

New snapshot available

A new snapshot of NetBSD-current for amd64 is available at

	ftp://ftp.netbsd.org/pub/NetBSD/arch/amd64/iso/amd64-2003-09-01.iso

It's a bootable ISO image, which will boot into the installer.
If you have any problems, or just want to report success, send me
or this list a message.

- Frank

--

-- 
Frank van der Linden                                            fvdl <at> netbsd.org
===============================================================================
NetBSD. Free, Unix-like OS. > 45 different platforms.    http://www.netbsd.org/
Permalink | Reply | 0 comments |
headers
Matthias Scheler | 1 Sep 2003 20:22
Picon
Favicon

32Bit or 64Bit userland?

	Hello,

I guess that NetBSD-amd64 will use a 64Bit userland like NetBSD-alpha does.
This sounds like an overkill considering that AMD's CPU can execute 32Bit
programs at full speed. Many programs with low memory consumption (e.g.
"ifconfig") would only waste memory by running in 64Bit mode.

It would be nice if NetBSD-amd64 would be delivered with a mixed userland
like e.g. Solaris 7 and newer with 32Bit and 64Bit libraries and 32Bit
and 64Bit applications.

	Kind regards

--

-- 
Matthias Scheler                                  http://scheler.de/~matthias/
Permalink | Reply | 2 comments |
headers
Frank van der Linden | 1 Sep 2003 21:00
Picon

Re: 32Bit or 64Bit userland?

On Mon, Sep 01, 2003 at 06:22:24PM +0000, Matthias Scheler wrote:
> I guess that NetBSD-amd64 will use a 64Bit userland like NetBSD-alpha does.
> This sounds like an overkill considering that AMD's CPU can execute 32Bit
> programs at full speed. Many programs with low memory consumption (e.g.
> "ifconfig") would only waste memory by running in 64Bit mode.

I won't be doing this. It's not worth it having two sets of libraries
to link both types of binaries against, and all the build goo associated
with it. Also remember that I don't know of any amd64 machine with less
than 512M of memory (though I suppose you could buy a board and put in
less.. but why?). Memory use is not an issue. Lastly, 64bit apps are
a lot faster, because there are 8 more registers available, and
function parameters are passed in registers.

32bit apps (i386 binaries) will run, if you have the right ld.elf_so
and shared libs in /emul/netbsd32/. The exception is libpthread, since
the 32bit compat code for the SA code hasn't been written.

- Frank

--

-- 
Frank van der Linden                                            fvdl <at> netbsd.org
===============================================================================
NetBSD. Free, Unix-like OS. > 45 different platforms.    http://www.netbsd.org/
Permalink | Reply | 0 comments |
headers
Johan Danielsson | 2 Sep 2003 17:34
Picon
Picon
Favicon

Re: 32Bit or 64Bit userland?


I must agree with Frank. Having the option of 32 or 64 bit userland,
just make you double (or triple -- hey SGI!) the number of libraries.

And you can bet your sweet behind that the one library you need just
now is only available in the wrong flavour.

/Johan
Permalink | Reply | 0 comments |
headers
Nicolas Joly | 8 Sep 2003 13:27
Picon
Picon
Favicon

Broadcom BCM5704C NIC speed problem on amd64


I recently installed a bi-opteron with NetBSD amd64 port, everything
works fine except for the network.

The Tyan Thunder K8S has two Broadcom BCM5704C Gigabit Ethernet. A few
issues were solved (new ASIC rev 3, NIC LEDs wrongly set), but now i'm
stuck with media speed problems.

When the machine is off, and the NIC LEDs are yellow (=100Mb). During
boot process, the cards are probed (bge(4) driver) and the LEDs do not
change. But with the PHY installation process, LEDs turn green
(=10Mb), and at that time, the media speed is stuck at 10Mb.

If i unplug the cable, wait for at least 5 sec, and plug it back;
most of the time, i can have the expected 100Mb link. Setting manually
the media to 100baseTX and then turning back to auto, produce the same
behaviour.

I had a look in brgphy(4) source code, and noticed the comment about
the 5705 PHY hardware bug (reset problem). I tried to remove all
`mii_phy_reset()' call for 5704 PHY, and the problem disappeared. It
seems that ASIC BCM5704 A3 chip has a bug triggered by the reset ...

Any thought ?

[...]
bge0 at pci2 dev 9 function 0: Broadcom BCM5704C Dual Gigabit Ethernet
bge0: interrupting at ioapic1 pin 0 (irq 15)
bge0: ASIC BCM5704 A3, Ethernet address 00:e0:81:51:dd:69
brgphy0 at bge0 phy 1: BCM5704 1000BASE-T media interface, rev. 0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Joly | 19 Sep 2003 11:17
Picon
Picon
Favicon

amd64 LONG_BIT definition


Hi,

While trying to compile (and debug) the NCBI tools on NetBSD amd64, i
noticed that LONG_BIT definition is currently set to 32 :

njoly <at> calimero> grep LONG_BIT /usr/include/machine/limits.h
#define LONG_BIT        32

As this is a 64bit platform, shouldn't it be defined to 64 instead ?

--

-- 
Nicolas Joly

Biological Software and Databanks.
Pasteur Institute, Paris.
Permalink | Reply | 2 comments |
headers
Johan Danielsson | 19 Sep 2003 13:56
Picon
Picon
Favicon

Re: amd64 LONG_BIT definition

Nicolas Joly <njoly <at> pasteur.fr> writes:

> As this is a 64bit platform, shouldn't it be defined to 64 instead ?

#include <stdio.h>

main()
{
        if(sizeof(long) == 8)
                printf("Yeah, you're right.\n");
        else
                printf("Nah.\n");
}

/Johan
Permalink | Reply | 0 comments |
headers
Frank van der Linden | 19 Sep 2003 14:02
Picon

Re: amd64 LONG_BIT definition

On Fri, Sep 19, 2003 at 11:17:06AM +0200, Nicolas Joly wrote:
> njoly <at> calimero> grep LONG_BIT /usr/include/machine/limits.h
> #define LONG_BIT        32
> 
> As this is a 64bit platform, shouldn't it be defined to 64 instead ?

Yes, you're right. I changed it. Blame me for starting out with the
i386 limits.h..

- Frank

--

-- 
Frank van der Linden                                            fvdl <at> netbsd.org
===============================================================================
NetBSD. Free, Unix-like OS. > 45 different platforms.    http://www.netbsd.org/
Permalink | Reply | 0 comments |
headers
Nicolas Joly | 23 Sep 2003 11:08
Picon
Picon
Favicon

threads broken on amd64 ?


Hi,

While testing some of our programs, i discovered that threads seems to
be badly damaged on NetBSD amd64. Every program linked with pthread
library crash ... The same programs, if non threaded, work fine.

Even the NetBSD threads regression tests crash with apparently the
same problem :

njoly <at> calimero [lib/libpthread]> uname -a
NetBSD calimero.bis.pasteur.fr 1.6ZC NetBSD 1.6ZC (GENERIC.MP) #3: Tue Sep 23 10:00:52 CEST 2003 
njoly <at> calimero.bis.pasteur.fr:/local/src/NetBSD/objs/local/src/NetBSD/src/sys/arch/amd64/compile/GENERIC.MP amd64
njoly <at> calimero [lib/libpthread]> pwd
/local/src/NetBSD/src/regress/lib/libpthread
njoly <at> calimero [lib/libpthread]> make regress
regress ===> atexit
./atexit > output
if cmp /local/src/NetBSD/src/regress/lib/libpthread/atexit/../../libc/atexit/expected output;
then  echo PASSED;  else  echo FAILED; exit 1;  fi
PASSED
regress ===> barrier1
./barrier1
thread 0 entering barrier
*** Signal 10
[...]
njoly <at> calimero [lib/libpthread]> cd barrier1
njoly <at> calimero [libpthread/barrier1]> ls -l
total 11766
drwxr-xr-x  2 njoly  users      512 Jul 23 21:03 CVS
(Continue reading)

Permalink | Reply | 4 comments |

Gmane