Christos Zoulas | 1 Mar 02:35 2007

Re: COMPAT_FREEBSD for amd64?

In article <45E4B53C.6070802 <at> tastylime.net>,
Jeff Rizzo  <riz <at> tastylime.net> wrote:
>Can someone give me some pointers of what needs to be done to get
>COMPAT_FREEBSD to do something useful while running NetBSD/amd64?  I'm
>interested in running the 3ware utility tw_cli (which runs under
>NetBSD/i386 with COMPAT_FREEBSD) - there are both 32-bit and 64-bit
>FreeBSD binaries available.
>
>If it's mostly gruntwork, I'm happy to do it - I'm just not quite sure
>where to start.
>

Look at what was done for svr4 and svr4_32.... We need to create freebsd_32
and add the freebsd_*.c files in arch/x86_64/x86_64

christos

Huub | 1 Mar 07:40 2007
Picon

error building vlc

Hi,

I don't know if this is amd64 specific, but when building vlc I get this 
error:

===> Cleaning for flac-1.1.3nb1
===> Installing for flac-1.1.3nb1
cannot create 
/usr/pkgsrc/audio/flac/work/.error/install-check-installed: directory 
nonexistent
*** Error code 2

Stop.
make: stopped in /usr/pkgsrc/audio/flac
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/audio/flac
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/audio/flac
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/multimedia/vlc
bash-3.1#

Any idea what this may be?

(Continue reading)

Nicolas Joly | 6 Mar 15:37 2007
Picon
Picon

PR/35302: Wrong Intel CPUs features display


Hi,

I was asked, offline, if i can commit my changes to fix Intel CPUs
features display (PR/35302).

Here is an updated version for -current, as the one in the PR does not
apply cleanly anymore.

Any objection ?

--

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
Index: sys/arch/amd64/amd64/identcpu.c
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.10
diff -u -r1.10 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c	3 Mar 2007 10:55:34 -0000	1.10
+++ sys/arch/amd64/amd64/identcpu.c	6 Mar 2007 14:23:07 -0000
 <at>  <at>  -60,6 +60,7  <at>  <at> 
 	char buf[512];
 	u_int32_t brand[12];
 	int vendor;
+	const char *feature_str[3];
(Continue reading)

Quentin Garnier | 6 Mar 15:41 2007
Picon

Re: PR/35302: Wrong Intel CPUs features display

On Tue, Mar 06, 2007 at 03:37:06PM +0100, Nicolas Joly wrote:
[...]
> I was asked, offline, if i can commit my changes to fix Intel CPUs
> features display (PR/35302).
> 
> Here is an updated version for -current, as the one in the PR does not
> apply cleanly anymore.
> 
> Any objection ?

No.  Looks just fine to commit.

--

-- 
Quentin Garnier - cube <at> cubidou.net - cube <at> NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
Bernd Ernesti | 6 Mar 19:13 2007
Picon

Re: PR/35302: Wrong Intel CPUs features display

On Tue, Mar 06, 2007 at 03:41:29PM +0100, Quentin Garnier wrote:
> On Tue, Mar 06, 2007 at 03:37:06PM +0100, Nicolas Joly wrote:
> [...]
> > I was asked, offline, if i can commit my changes to fix Intel CPUs
> > features display (PR/35302).
> > 
> > Here is an updated version for -current, as the one in the PR does not
> > apply cleanly anymore.
> > 
> > Any objection ?
> 
> No.  Looks just fine to commit.

The only problem is that it changes amd64 and not i386 too.

IMHO we should move this function into x86.

Bernd

Manuel Bouyer | 6 Mar 23:12 2007

Re: UPDATE: various changes on INSTALL and iso generation

[ relevant port lists in Cc; please reply to one port list or
tech-install as appropriate]

On Mon, Mar 05, 2007 at 05:49:00PM +0100, Manuel Bouyer wrote:
> Hi,
> here's an updated patch for my changes on iso generation. Changes since
[...]

so I just commited this (with some minor changes thanks to Alan Barrett's
comments). The iso should be bootable on:
alpha, amd64, cats, i386, pmax, sgimips, sparc, sparc64, sun3, vax.
You can find an iso for these ports (exept cats which doesn't build at all
right now), built using build.sh iso-image with the new infrastructure.
It would be great if each of these could be tested at last once.
I tested amd64, i386, alpha and sparc64 myself.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Blair Sadewitz | 6 Mar 23:58 2007
Picon

Re: PR/35302: Wrong Intel CPUs features display

Also missing (I'm pretty sure my processor has this, anyway) is the
SSE3 flag, which quite a few processors have now.  devel/cpuflags
would work nicely with machdep.sse3, also.

--Blair

--

-- 
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>

"The frivolity and boredom which unsettle the established order, the
vague foreboding of something unknown, these are the heralds of
approaching change.  The gradual crumbling that left unaltered the
face of the whole is cut short by a sunburst which, in one flash,
illuminates the features of the new world."  --G.W.F. Hegel,
_Phenomenology of Spirit_ 5:11

Nicolas Joly | 7 Mar 00:00 2007
Picon
Picon

Re: PR/35302: Wrong Intel CPUs features display

On Tue, Mar 06, 2007 at 07:13:46PM +0100, Bernd Ernesti wrote:
> On Tue, Mar 06, 2007 at 03:41:29PM +0100, Quentin Garnier wrote:
> > On Tue, Mar 06, 2007 at 03:37:06PM +0100, Nicolas Joly wrote:
> > [...]
> > > I was asked, offline, if i can commit my changes to fix Intel CPUs
> > > features display (PR/35302).
> > > 
> > > Here is an updated version for -current, as the one in the PR does not
> > > apply cleanly anymore.
> > > 
> > > Any objection ?
> > 
> > No.  Looks just fine to commit.
> 
> The only problem is that it changes amd64 and not i386 too.

i386 does not have the problem; it support Intel CPUs for quite a long
time, and display correct CPUs features.

> IMHO we should move this function into x86.

I'm not sure for the whole function, but indeed some parts could be
shared.

--

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.

(Continue reading)

Bernd Ernesti | 7 Mar 08:40 2007
Picon

Re: PR/35302: Wrong Intel CPUs features display

On Wed, Mar 07, 2007 at 12:00:51AM +0100, Nicolas Joly wrote:
> On Tue, Mar 06, 2007 at 07:13:46PM +0100, Bernd Ernesti wrote:
[..]

> > The only problem is that it changes amd64 and not i386 too.
> 
> i386 does not have the problem; it support Intel CPUs for quite a long
> time, and display correct CPUs features.

Hmm, ok not Intel CPUs, but AMD CPUs are still displayed differently on i386:

cpu0: AMD Dual-Core Opteron or Athlon 64 X2 (686-class)

> > IMHO we should move this function into x86.
> 
> I'm not sure for the whole function, but indeed some parts could be
> shared.

I can't talk about this function because I know to few about it, but
IMHO all parts which would work on i386 and amd64 should be shared.

Bernd

Nicolas Joly | 7 Mar 12:03 2007
Picon
Picon

Re: PR/35302: Wrong Intel CPUs features display

On Wed, Mar 07, 2007 at 08:40:00AM +0100, Bernd Ernesti wrote:
> On Wed, Mar 07, 2007 at 12:00:51AM +0100, Nicolas Joly wrote:
> > On Tue, Mar 06, 2007 at 07:13:46PM +0100, Bernd Ernesti wrote:
> [..]
> 
> > > The only problem is that it changes amd64 and not i386 too.
> > 
> > i386 does not have the problem; it support Intel CPUs for quite a long
> > time, and display correct CPUs features.
> 
> Hmm, ok not Intel CPUs, but AMD CPUs are still displayed differently on i386:
> 
> cpu0: AMD Dual-Core Opteron or Athlon 64 X2 (686-class)

Ok, but that's another story. For now, i'm just fixing incorrect
display on amd64 port for some CPUs.

> > > IMHO we should move this function into x86.
> > 
> > I'm not sure for the whole function, but indeed some parts could be
> > shared.
> 
> I can't talk about this function because I know to few about it, but
> IMHO all parts which would work on i386 and amd64 should be shared.

I had a look; and in this area, cpu_info structures are currently too
different to share some code. But this can change ...

amd64:
        u_int32_t       ci_feature_flags;
(Continue reading)


Gmane