United Nations Trust Funds | 1 Apr 2012 22:31

$650,500.00

Reply to claim.

Greg Troxel | 18 Apr 2012 18:29
Picon

macppc vs evbppc binary packages


We are trying to build packages on some evbppc systems (under
-6/current) and finding them a bit crashy under load.  So I am wondering
to what extent packages built on a macppc (that's from 2001 or so,
dual-core 500 Mhz G3) will run on an evbppc.   I would expect all the
instructions in the G3 to be present in the new chips (although I
understand the memory management architecture is different).   But, I
wonder if the ABI is somehow different.  I'd appreciate advice voting
for:

  yes, it ought to work

  maybe - worth trying

  you're doomed, don't bother
Matt Thomas | 18 Apr 2012 18:58

Re: macppc vs evbppc binary packages


On Apr 18, 2012, at 9:29 AM, Greg Troxel wrote:

> 
> We are trying to build packages on some evbppc systems (under
> -6/current) and finding them a bit crashy under load.  So I am wondering
> to what extent packages built on a macppc (that's from 2001 or so,
> dual-core 500 Mhz G3) will run on an evbppc.   I would expect all the
> instructions in the G3 to be present in the new chips (although I
> understand the memory management architecture is different).   But, I
> wonder if the ABI is somehow different.  I'd appreciate advice voting
> for:

The problem is your evbppc systems don't emulate the OEA FP instructions.
So when it encounters one, it will get a SIGILL.

We could put the fpemul code in the kernel but that code isn't that modular and need some help to work on non-IBM4xx.
Havard Eidnes | 18 Apr 2012 19:18
Picon

Re: macppc vs evbppc binary packages

> We are trying to build packages on some evbppc systems (under
> -6/current) and finding them a bit crashy under load.

Oh, you do?  I wonder if I'm seeing the same problem...  I
upgraded one of my macppc systems to 6.0_BETA in order to build
packages for that, and started a single-threaded build.  It is
now most likely sitting in DDB on the (vga) console back in my
office while I'm on the road this week...  Previously I've not
experienced such crashes with 4.0, 5.0 or 5.1.

Regards,

- Håvard

Greg Troxel | 18 Apr 2012 19:21
Picon

Re: macppc vs evbppc binary packages


  Oh, you do?  I wonder if I'm seeing the same problem...  I
  upgraded one of my macppc systems to 6.0_BETA in order to build
  packages for that, and started a single-threaded build.  It is
  now most likely sitting in DDB on the (vga) console back in my
  office while I'm on the road this week...  Previously I've not
  experienced such crashes with 4.0, 5.0 or 5.1.

That's interesting - there may be one or two problems, having to do with
disk io, or perhaps NFS/network traffic, and both a pq3 development
system and a p2020 development system are affected.

Greg Troxel | 18 Apr 2012 19:23
Picon

Re: macppc vs evbppc binary packages


Matt Thomas <matt <at> 3am-software.com> writes:

> On Apr 18, 2012, at 9:29 AM, Greg Troxel wrote:
>
>> 
>> We are trying to build packages on some evbppc systems (under
>> -6/current) and finding them a bit crashy under load.  So I am wondering
>> to what extent packages built on a macppc (that's from 2001 or so,
>> dual-core 500 Mhz G3) will run on an evbppc.   I would expect all the
>> instructions in the G3 to be present in the new chips (although I
>> understand the memory management architecture is different).   But, I
>> wonder if the ABI is somehow different.  I'd appreciate advice voting
>> for:
>
> The problem is your evbppc systems don't emulate the OEA FP instructions.
> So when it encounters one, it will get a SIGILL.
>
> We could put the fpemul code in the kernel but that code isn't that
> modular and need some help to work on non-IBM4xx.

So if I modified the compiler on the macppc to have soft-float as
default, it might work?
Havard Eidnes | 18 Apr 2012 19:25
Picon

Re: macppc vs evbppc binary packages

>   Oh, you do?  I wonder if I'm seeing the same problem...  I
>   upgraded one of my macppc systems to 6.0_BETA in order to build
>   packages for that, and started a single-threaded build.  It is
>   now most likely sitting in DDB on the (vga) console back in my
>   office while I'm on the road this week...  Previously I've not
>   experienced such crashes with 4.0, 5.0 or 5.1.
>
> That's interesting - there may be one or two problems, having to do with
> disk io, or perhaps NFS/network traffic, and both a pq3 development
> system and a p2020 development system are affected.

Disk io could be it, these boxes don't do NFS, at least.  I'll
try to collect more info this coming Monday when I'm back in the
office.

Regards,

- Håvard

Eduardo Horvath | 18 Apr 2012 19:29
Picon

Re: macppc vs evbppc binary packages

On Wed, 18 Apr 2012, Greg Troxel wrote:

> We are trying to build packages on some evbppc systems (under
> -6/current) and finding them a bit crashy under load.  So I am wondering
> to what extent packages built on a macppc (that's from 2001 or so,
> dual-core 500 Mhz G3) will run on an evbppc.   I would expect all the
> instructions in the G3 to be present in the new chips (although I
> understand the memory management architecture is different).   But, I
> wonder if the ABI is somehow different.  I'd appreciate advice voting
> for:
> 
>   yes, it ought to work
> 
>   maybe - worth trying
> 
>   you're doomed, don't bother

PowerPC exposes the cache layout to userland to userland for things like 
memcpy.  Originally the cache layout was hardcoded in libc.  When working 
on the IBM 4xx port we added code to libc to read the cache layout 
information.  That was arount 2000-2001.  So if you're running an old 
macppc userland on a chip that has a slightly different cache layout you 
may have some issues.

Then there's also the FPU emulation code that I did for the 4xx port which 
is needed to run things like newfs and fsck.

Eduardo

(Continue reading)

Greg Troxel | 18 Apr 2012 19:33
Picon

Re: macppc vs evbppc binary packages


Eduardo Horvath <eeh <at> NetBSD.org> writes:

> On Wed, 18 Apr 2012, Greg Troxel wrote:
>
>> We are trying to build packages on some evbppc systems (under
>> -6/current) and finding them a bit crashy under load.  So I am wondering
>> to what extent packages built on a macppc (that's from 2001 or so,
>> dual-core 500 Mhz G3) will run on an evbppc.   I would expect all the
>> instructions in the G3 to be present in the new chips (although I
>> understand the memory management architecture is different).   But, I
>> wonder if the ABI is somehow different.  I'd appreciate advice voting
>> for:
>> 
>>   yes, it ought to work
>> 
>>   maybe - worth trying
>> 
>>   you're doomed, don't bother
>
> PowerPC exposes the cache layout to userland to userland for things like 
> memcpy.  Originally the cache layout was hardcoded in libc.  When working 
> on the IBM 4xx port we added code to libc to read the cache layout 
> information.  That was arount 2000-2001.  So if you're running an old 
> macppc userland on a chip that has a slightly different cache layout you 
> may have some issues.
>
> Then there's also the FPU emulation code that I did for the 4xx port which 
> is needed to run things like newfs and fsck.

(Continue reading)

Matt Thomas | 18 Apr 2012 20:00

Re: macppc vs evbppc binary packages


On Apr 18, 2012, at 10:33 AM, Greg Troxel wrote:

> 
> Eduardo Horvath <eeh <at> NetBSD.org> writes:
> 
>> On Wed, 18 Apr 2012, Greg Troxel wrote:
>> 
>>> We are trying to build packages on some evbppc systems (under
>>> -6/current) and finding them a bit crashy under load.  So I am wondering
>>> to what extent packages built on a macppc (that's from 2001 or so,
>>> dual-core 500 Mhz G3) will run on an evbppc.   I would expect all the
>>> instructions in the G3 to be present in the new chips (although I
>>> understand the memory management architecture is different).   But, I
>>> wonder if the ABI is somehow different.  I'd appreciate advice voting
>>> for:
>>> 
>>>  yes, it ought to work
>>> 
>>>  maybe - worth trying
>>> 
>>>  you're doomed, don't bother
>> 
>> PowerPC exposes the cache layout to userland to userland for things like 
>> memcpy.  Originally the cache layout was hardcoded in libc.  When working 
>> on the IBM 4xx port we added code to libc to read the cache layout 
>> information.  That was arount 2000-2001.  So if you're running an old 
>> macppc userland on a chip that has a slightly different cache layout you 
>> may have some issues.
>> 
(Continue reading)


Gmane