freebsd-ia64 Digest, Vol 352, Issue 4
freebsd-ia...@freebsd.org
freebs...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
or, via email, send a message with subject or body 'help' to
freebsd-ia...@freebsd.org
You can reach the person managing the list at
freebsd-i...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-ia64 digest..."
Today's Topics:
1. Re: Request for review/comments: 32-bit compat for non-x86
architectures (Kostik Belousov)
2. port lang/gnustep-base - make configure fails on ia64
(Anton Shterenlikht)
3. Re: Request for review/comments: 32-bit compat for non-x86
architectures (John Baldwin)
4. Re: Request for review/comments: 32-bit compat for non-x86
architectures (Nathan Whitehorn)
5. Re: Request for review/comments: 32-bit compat for non-x86
architectures (Nathan Whitehorn)
6. Re: Request for review/comments: 32-bit compat for non-x86
architectures (John Baldwin)
7. Re: Request for review/comments: 32-bit compat for non-x86
architectures (Nathan Whitehorn)
8. Re: Request for review/comments: 32-bit compat for non-x86
architectures (John Baldwin)
9. Re: Request for review/comments: 32-bit compat for non-x86
architectures (Kostik Belousov)
10. Re: Request for review/comments: 32-bit compat for non-x86
architectures (Nathan Whitehorn)
11. Re: port lang/gnustep-base - make configure fails on ia64
(Anton Shterenlikht)
12. Re: port lang/gnustep-base - make configure fails on ia64
(Marcel Moolenaar)
13. Re: port lang/gnustep-base - make configure fails on ia64
(Anton Shterenlikht)
14. Re: Installation Problem - 8.0 (Mister Itanium)
15. Re: Installation Problem - 8.0 (Marcel Moolenaar)
16. [head tinderbox] failure on ia64/ia64 (FreeBSD Tinderbox)
17. Re: Installation Problem - 8.0 (Mister Itanium)
----------------------------------------------------------------------
Message: 1
Date: Wed, 10 Mar 2010 13:46:12 +0200
From: Kostik Belousov <kost...@gmail.com>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: Nathan Whitehorn <nwhit...@freebsd.org>
Cc: freebsd-...@freebsd.org, freebs...@freebsd.org,
freebs...@freebsd.org
Message-ID: <2010031011...@deviant.kiev.zoral.com.ua>
Content-Type: text/plain; charset="us-ascii"
On Tue, Mar 09, 2010 at 10:14:27PM -0600, Nathan Whitehorn wrote:
> The patch at http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
> (pre-generated freebsd32 syscalls stuff is included, which will be done
> in two steps on commit) provides groundwork for supporting 32-bit
> compatibility for 64-bit MIPS and PowerPC systems. It has been tested on
> amd64 and powerpc64, and compile-tested on ia64. There are two main
> parts to the patch:
>
> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
> COMPAT_LINUX32, etc. This requires updating kernel configurations, but
> is less painful than filling machine-independent bits of the kernel with
> #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old name.
>
> 2) Modifications to the freebsd32 compat layer to support big-endian
> architectures.
>
> I would appreciate any comments, bugs, or test results on ia64.
> -Nathan
This fragment
--- sys/kern/imgact_elf.c (revision 204681)
+++ sys/kern/imgact_elf.c (working copy)
@@ -75,7 +75,7 @@
#include <machine/elf.h>
#include <machine/md_var.h>
-#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
+#if (defined(__amd64__) || defined(__ia64__)) && __ELF_WORD_SIZE == 32
#include <machine/fpu.h>
#include <compat/ia32/ia32_reg.h>
#endif
probably should be changed ? How are struct reg32 for !ia32 case is
brought into the imgact_elf ? Can it be unified for ia32 case ?
(Similar fragment is present in sys_process.c at least).
I do not understand how +#if !defined(PAD64_REQUIRED) && defined(__powerpc__)
etc lines are generated.
You may want to change sysent->sv_flag SV_IA32 to SV_FREEBSD32, or add
SV_FREEBSD32. You might want to review SV_IA32 usage, if any.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ia64/attachments/20100310/8508c91f/attachment-0001.pgp
------------------------------
Message: 2
Date: Wed, 10 Mar 2010 12:29:23 +0000
From: Anton Shterenlikht <me...@bristol.ac.uk>
Subject: port lang/gnustep-base - make configure fails on ia64
To: din...@freebsd.org
Cc: freebs...@freebsd.org
Message-ID: <20100310122...@mech-cluster241.men.bris.ac.uk>
Content-Type: text/plain; charset=us-ascii
On FreeBSD 9.0-CURRENT #0 r203484M
port lang/gnustep-base fails "make configure".
Please see the log here:
http://seis.bris.ac.uk/~mexas/gnustep-base-ia64.log
Portsmon is empty for this port, so I've no
idea if this is a regression:
http://portsmon.freebsd.org/portoverview.py?category=lang&portname=gnustep-base
many thanks
anton
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
------------------------------
Message: 3
Date: Wed, 10 Mar 2010 08:10:10 -0500
From: John Baldwin <j...@freebsd.org>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: freebs...@freebsd.org
Cc: freebsd-...@freebsd.org, Nathan Whitehorn
<nwhit...@freebsd.org>, freebs...@freebsd.org
Message-ID: <20100310081...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-1"
On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote:
> The patch at http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
> (pre-generated freebsd32 syscalls stuff is included, which will be done
> in two steps on commit) provides groundwork for supporting 32-bit
> compatibility for 64-bit MIPS and PowerPC systems. It has been tested on
> amd64 and powerpc64, and compile-tested on ia64. There are two main
> parts to the patch:
>
> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
> COMPAT_LINUX32, etc. This requires updating kernel configurations, but
> is less painful than filling machine-independent bits of the kernel with
> #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old name.
>
> 2) Modifications to the freebsd32 compat layer to support big-endian
> architectures.
>
> I would appreciate any comments, bugs, or test results on ia64.
This doesn't look right for non-x86 32-bit ABIs:
Index: sys/kern/imgact_elf.c
===================================================================
--- sys/kern/imgact_elf.c (revision 204681)
+++ sys/kern/imgact_elf.c (working copy)
@@ -1439,7 +1439,7 @@
ehdr->e_ident[EI_ABIVERSION] = 0;
ehdr->e_ident[EI_PAD] = 0;
ehdr->e_type = ET_CORE;
-#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
+#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32
ehdr->e_machine = EM_386;
#else
ehdr->e_machine = ELF_ARCH;
It would be nice to eliminate having <compat/ia32*> includes in MI code by
instead including those headers in appropriate headers in <machine/*>. For
example, we could change <machine/reg.h> on amd64 and ia64 to include these
headers, perhaps under an #ifdef COMPAT_FREEBSD32.
Hmm, actually, I'm quite convinced now that <machine/reg.h> for ia64 and amd64
should include <compat/ia32/ia32_reg.h> in the #ifdef _KERNEL section to avoid
polluting those includes in MI code. I'm not sure what the various
<machine/fpu.h> includes are for, but fixing ia32_reg.h would be a good first
step. It would make your diffs smaller I think.
The rest of the diff looks fine to me.
--
John Baldwin
------------------------------
Message: 4
Date: Wed, 10 Mar 2010 08:35:09 -0600
From: Nathan Whitehorn <nwhit...@freebsd.org>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: Kostik Belousov <kost...@gmail.com>
Cc: freebsd-...@freebsd.org, freebs...@freebsd.org,
freebs...@freebsd.org
Message-ID: <4B97AE1D...@freebsd.org>
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
Kostik Belousov wrote:
> On Tue, Mar 09, 2010 at 10:14:27PM -0600, Nathan Whitehorn wrote:
>
>> The patch at http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
>> (pre-generated freebsd32 syscalls stuff is included, which will be done
>> in two steps on commit) provides groundwork for supporting 32-bit
>> compatibility for 64-bit MIPS and PowerPC systems. It has been tested on
>> amd64 and powerpc64, and compile-tested on ia64. There are two main
>> parts to the patch:
>>
>> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
>> COMPAT_LINUX32, etc. This requires updating kernel configurations, but
>> is less painful than filling machine-independent bits of the kernel with
>> #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
>> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old name.
>>
>> 2) Modifications to the freebsd32 compat layer to support big-endian
>> architectures.
>>
>> I would appreciate any comments, bugs, or test results on ia64.
>> -Nathan
>>
>
> This fragment
> --- sys/kern/imgact_elf.c (revision 204681)
> +++ sys/kern/imgact_elf.c (working copy)
> @@ -75,7 +75,7 @@
> #include <machine/elf.h>
> #include <machine/md_var.h>
>
> -#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
> +#if (defined(__amd64__) || defined(__ia64__)) && __ELF_WORD_SIZE == 32
> #include <machine/fpu.h>
> #include <compat/ia32/ia32_reg.h>
> #endif
> probably should be changed ? How are struct reg32 for !ia32 case is
> brought into the imgact_elf ? Can it be unified for ia32 case ?
> (Similar fragment is present in sys_process.c at least).
>
For !ia32, they are brought in machine/reg.h. You can see how that works
here:
http://svn.freebsd.org/viewvc/base/projects/ppc64/sys/powerpc/include/reg.h?revision=204915&view=markup
I would be more than happy for them to be brought in the same way for
amd64 and ia64. Since John Baldwin seems to want this too, I might roll
a new version of the diff today or tomorrow that does that.
> I do not understand how +#if !defined(PAD64_REQUIRED) && defined(__powerpc__)
> etc lines are generated.
>
These end up in syscalls.master and take advantage of the syscalls
generator propagating preprocessor statements through. 32-bit powerpc
has an ABI quirk where 64-bit arguments are transmitted in "aligned"
registers, so this adds some padding to those syscalls such that this is
preserved. The !defined bit just protects against redefinition when one
of the .c files generated from syscalls.master includes one of the
header files.
> You may want to change sysent->sv_flag SV_IA32 to SV_FREEBSD32, or add
> SV_FREEBSD32. You might want to review SV_IA32 usage, if any.
We already have SV_ILP32, which is used pretty consistently for this.
The patch includes a fix for the one erroneous use in
sys/kern/kern_jail.c that I could find with grep -R SV_IA32 /sys.
-Nathan
------------------------------
Message: 5
Date: Wed, 10 Mar 2010 08:39:15 -0600
From: Nathan Whitehorn <nwhit...@freebsd.org>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: John Baldwin <j...@freebsd.org>
Cc: freebsd-...@freebsd.org, freebs...@freebsd.org,
freebs...@freebsd.org
Message-ID: <4B97AF13...@freebsd.org>
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
John Baldwin wrote:
> On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote:
>
>> The patch at http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
>> (pre-generated freebsd32 syscalls stuff is included, which will be done
>> in two steps on commit) provides groundwork for supporting 32-bit
>> compatibility for 64-bit MIPS and PowerPC systems. It has been tested on
>> amd64 and powerpc64, and compile-tested on ia64. There are two main
>> parts to the patch:
>>
>> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
>> COMPAT_LINUX32, etc. This requires updating kernel configurations, but
>> is less painful than filling machine-independent bits of the kernel with
>> #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
>> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old name.
>>
>> 2) Modifications to the freebsd32 compat layer to support big-endian
>> architectures.
>>
>> I would appreciate any comments, bugs, or test results on ia64.
>>
>
> This doesn't look right for non-x86 32-bit ABIs:
>
> Index: sys/kern/imgact_elf.c
> ===================================================================
> --- sys/kern/imgact_elf.c (revision 204681)
> +++ sys/kern/imgact_elf.c (working copy)
> @@ -1439,7 +1439,7 @@
> ehdr->e_ident[EI_ABIVERSION] = 0;
> ehdr->e_ident[EI_PAD] = 0;
> ehdr->e_type = ET_CORE;
> -#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
> +#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32
> ehdr->e_machine = EM_386;
> #else
> ehdr->e_machine = ELF_ARCH;
>
Good catch! Such are the dangers of sed. How about defining an
ELF_ARCH32 in machine/elf.h for this case?
> It would be nice to eliminate having <compat/ia32*> includes in MI code by
> instead including those headers in appropriate headers in <machine/*>. For
> example, we could change <machine/reg.h> on amd64 and ia64 to include these
> headers, perhaps under an #ifdef COMPAT_FREEBSD32.
>
> Hmm, actually, I'm quite convinced now that <machine/reg.h> for ia64 and amd64
> should include <compat/ia32/ia32_reg.h> in the #ifdef _KERNEL section to avoid
> polluting those includes in MI code. I'm not sure what the various
> <machine/fpu.h> includes are for, but fixing ia32_reg.h would be a good first
> step. It would make your diffs smaller I think.
>
This is how it works on powerpc64. I didn't modify amd64 and ia64 in
order to avoid making too many changes, but I think you're right that
this is a good idea. I'll add that to the patch when fixing the EM_386
bit you pointed out above.
> The rest of the diff looks fine to me.
>
Thanks for the comments!
-Nathan
------------------------------
Message: 6
Date: Wed, 10 Mar 2010 10:43:23 -0500
From: John Baldwin <j...@freebsd.org>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: Nathan Whitehorn <nwhit...@freebsd.org>
Cc: freebsd-...@freebsd.org, freebs...@freebsd.org,
freebs...@freebsd.org
Message-ID: <20100310104...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-1"
On Wednesday 10 March 2010 9:39:15 am Nathan Whitehorn wrote:
> John Baldwin wrote:
> > On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote:
> >
> >> The patch at http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
> >> (pre-generated freebsd32 syscalls stuff is included, which will be done
> >> in two steps on commit) provides groundwork for supporting 32-bit
> >> compatibility for 64-bit MIPS and PowerPC systems. It has been tested on
> >> amd64 and powerpc64, and compile-tested on ia64. There are two main
> >> parts to the patch:
> >>
> >> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
> >> COMPAT_LINUX32, etc. This requires updating kernel configurations, but
> >> is less painful than filling machine-independent bits of the kernel with
> >> #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
> >> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old name.
> >>
> >> 2) Modifications to the freebsd32 compat layer to support big-endian
> >> architectures.
> >>
> >> I would appreciate any comments, bugs, or test results on ia64.
> >>
> >
> > This doesn't look right for non-x86 32-bit ABIs:
> >
> > Index: sys/kern/imgact_elf.c
> > ===================================================================
> > --- sys/kern/imgact_elf.c (revision 204681)
> > +++ sys/kern/imgact_elf.c (working copy)
> > @@ -1439,7 +1439,7 @@
> > ehdr->e_ident[EI_ABIVERSION] = 0;
> > ehdr->e_ident[EI_PAD] = 0;
> > ehdr->e_type = ET_CORE;
> > -#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
> > +#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32
> > ehdr->e_machine = EM_386;
> > #else
> > ehdr->e_machine = ELF_ARCH;
> >
> Good catch! Such are the dangers of sed. How about defining an
> ELF_ARCH32 in machine/elf.h for this case?
Yes, that sounds good.
> > It would be nice to eliminate having <compat/ia32*> includes in MI code by
> > instead including those headers in appropriate headers in <machine/*>. For
> > example, we could change <machine/reg.h> on amd64 and ia64 to include these
> > headers, perhaps under an #ifdef COMPAT_FREEBSD32.
> >
> > Hmm, actually, I'm quite convinced now that <machine/reg.h> for ia64 and amd64
> > should include <compat/ia32/ia32_reg.h> in the #ifdef _KERNEL section to avoid
> > polluting those includes in MI code. I'm not sure what the various
> > <machine/fpu.h> includes are for, but fixing ia32_reg.h would be a good first
> > step. It would make your diffs smaller I think.
> >
> This is how it works on powerpc64. I didn't modify amd64 and ia64 in
> order to avoid making too many changes, but I think you're right that
> this is a good idea. I'll add that to the patch when fixing the EM_386
> bit you pointed out above.
Ok, thanks.
--
John Baldwin
------------------------------
Message: 7
Date: Wed, 10 Mar 2010 09:55:40 -0600
From: Nathan Whitehorn <nwhit...@freebsd.org>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: John Baldwin <j...@freebsd.org>
Cc: freebsd-...@freebsd.org, freebs...@freebsd.org,
freebs...@freebsd.org
Message-ID: <4B97C0FC...@freebsd.org>
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
John Baldwin wrote:
> On Wednesday 10 March 2010 9:39:15 am Nathan Whitehorn wrote:
>
>> John Baldwin wrote:
>>
>>> On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote:
>>>
>>>
>>>> The patch at http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
>>>> (pre-generated freebsd32 syscalls stuff is included, which will be done
>>>> in two steps on commit) provides groundwork for supporting 32-bit
>>>> compatibility for 64-bit MIPS and PowerPC systems. It has been tested on
>>>> amd64 and powerpc64, and compile-tested on ia64. There are two main
>>>> parts to the patch:
>>>>
>>>> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
>>>> COMPAT_LINUX32, etc. This requires updating kernel configurations, but
>>>> is less painful than filling machine-independent bits of the kernel with
>>>> #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
>>>> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old name.
>>>>
>>>> 2) Modifications to the freebsd32 compat layer to support big-endian
>>>> architectures.
>>>>
>>>> I would appreciate any comments, bugs, or test results on ia64.
>>>>
>>>>
>>> This doesn't look right for non-x86 32-bit ABIs:
>>>
>>> Index: sys/kern/imgact_elf.c
>>> ===================================================================
>>> --- sys/kern/imgact_elf.c (revision 204681)
>>> +++ sys/kern/imgact_elf.c (working copy)
>>> @@ -1439,7 +1439,7 @@
>>> ehdr->e_ident[EI_ABIVERSION] = 0;
>>> ehdr->e_ident[EI_PAD] = 0;
>>> ehdr->e_type = ET_CORE;
>>> -#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
>>> +#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32
>>> ehdr->e_machine = EM_386;
>>> #else
>>> ehdr->e_machine = ELF_ARCH;
>>>
>>>
>> Good catch! Such are the dangers of sed. How about defining an
>> ELF_ARCH32 in machine/elf.h for this case?
>>
>
> Yes, that sounds good.
>
>
>>> It would be nice to eliminate having <compat/ia32*> includes in MI code by
>>> instead including those headers in appropriate headers in <machine/*>. For
>>> example, we could change <machine/reg.h> on amd64 and ia64 to include these
>>> headers, perhaps under an #ifdef COMPAT_FREEBSD32.
>>>
>>> Hmm, actually, I'm quite convinced now that <machine/reg.h> for ia64 and amd64
>>> should include <compat/ia32/ia32_reg.h> in the #ifdef _KERNEL section to avoid
>>> polluting those includes in MI code. I'm not sure what the various
>>> <machine/fpu.h> includes are for, but fixing ia32_reg.h would be a good first
>>> step. It would make your diffs smaller I think.
>>>
>>>
>> This is how it works on powerpc64. I didn't modify amd64 and ia64 in
>> order to avoid making too many changes, but I think you're right that
>> this is a good idea. I'll add that to the patch when fixing the EM_386
>> bit you pointed out above.
>>
>
> Ok, thanks.
>
>
I've updated the patch to incorporate these two changes, at
http://people.freebsd.org/~nwhitehorn/compat_freebsd32_2.diff. Due to
recursive inclusion issues with sys/procfs.h, it also moves prstatus32
and friends to compat/freebsd32/freebsd32.h from ia32_reg.h. They are
MI, and seems like a more appropriate place for them anyway.
-Nathan
------------------------------
Message: 8
Date: Wed, 10 Mar 2010 12:59:07 -0500
From: John Baldwin <j...@freebsd.org>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: Nathan Whitehorn <nwhit...@freebsd.org>
Cc: freebsd-...@freebsd.org, freebs...@freebsd.org,
freebs...@freebsd.org
Message-ID: <20100310125...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-1"
On Wednesday 10 March 2010 10:55:40 am Nathan Whitehorn wrote:
> John Baldwin wrote:
> > On Wednesday 10 March 2010 9:39:15 am Nathan Whitehorn wrote:
> >
> >> John Baldwin wrote:
> >>
> >>> On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote:
> >>>
> >>>
> >>>> The patch at http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
> >>>> (pre-generated freebsd32 syscalls stuff is included, which will be done
> >>>> in two steps on commit) provides groundwork for supporting 32-bit
> >>>> compatibility for 64-bit MIPS and PowerPC systems. It has been tested on
> >>>> amd64 and powerpc64, and compile-tested on ia64. There are two main
> >>>> parts to the patch:
> >>>>
> >>>> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
> >>>> COMPAT_LINUX32, etc. This requires updating kernel configurations, but
> >>>> is less painful than filling machine-independent bits of the kernel with
> >>>> #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
> >>>> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old name.
> >>>>
> >>>> 2) Modifications to the freebsd32 compat layer to support big-endian
> >>>> architectures.
> >>>>
> >>>> I would appreciate any comments, bugs, or test results on ia64.
> >>>>
> >>>>
> >>> This doesn't look right for non-x86 32-bit ABIs:
> >>>
> >>> Index: sys/kern/imgact_elf.c
> >>> ===================================================================
> >>> --- sys/kern/imgact_elf.c (revision 204681)
> >>> +++ sys/kern/imgact_elf.c (working copy)
> >>> @@ -1439,7 +1439,7 @@
> >>> ehdr->e_ident[EI_ABIVERSION] = 0;
> >>> ehdr->e_ident[EI_PAD] = 0;
> >>> ehdr->e_type = ET_CORE;
> >>> -#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
> >>> +#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32
> >>> ehdr->e_machine = EM_386;
> >>> #else
> >>> ehdr->e_machine = ELF_ARCH;
> >>>
> >>>
> >> Good catch! Such are the dangers of sed. How about defining an
> >> ELF_ARCH32 in machine/elf.h for this case?
> >>
> >
> > Yes, that sounds good.
> >
> >
> >>> It would be nice to eliminate having <compat/ia32*> includes in MI code by
> >>> instead including those headers in appropriate headers in <machine/*>. For
> >>> example, we could change <machine/reg.h> on amd64 and ia64 to include these
> >>> headers, perhaps under an #ifdef COMPAT_FREEBSD32.
> >>>
> >>> Hmm, actually, I'm quite convinced now that <machine/reg.h> for ia64 and amd64
> >>> should include <compat/ia32/ia32_reg.h> in the #ifdef _KERNEL section to avoid
> >>> polluting those includes in MI code. I'm not sure what the various
> >>> <machine/fpu.h> includes are for, but fixing ia32_reg.h would be a good first
> >>> step. It would make your diffs smaller I think.
> >>>
> >>>
> >> This is how it works on powerpc64. I didn't modify amd64 and ia64 in
> >> order to avoid making too many changes, but I think you're right that
> >> this is a good idea. I'll add that to the patch when fixing the EM_386
> >> bit you pointed out above.
> >>
> >
> > Ok, thanks.
> >
> >
> I've updated the patch to incorporate these two changes, at
> http://people.freebsd.org/~nwhitehorn/compat_freebsd32_2.diff. Due to
> recursive inclusion issues with sys/procfs.h, it also moves prstatus32
> and friends to compat/freebsd32/freebsd32.h from ia32_reg.h. They are
> MI, and seems like a more appropriate place for them anyway.
Looks good to me.
--
John Baldwin
------------------------------
Message: 9
Date: Wed, 10 Mar 2010 22:24:58 +0200
From: Kostik Belousov <kost...@gmail.com>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: Nathan Whitehorn <nwhit...@freebsd.org>
Cc: freebsd-...@freebsd.org, freebs...@freebsd.org,
freebs...@freebsd.org
Message-ID: <2010031020...@deviant.kiev.zoral.com.ua>
Content-Type: text/plain; charset="us-ascii"
On Wed, Mar 10, 2010 at 09:55:40AM -0600, Nathan Whitehorn wrote:
> John Baldwin wrote:
> >On Wednesday 10 March 2010 9:39:15 am Nathan Whitehorn wrote:
> >
> >>John Baldwin wrote:
> >>
> >>>On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote:
> >>>
> >>>
> >>>>The patch at
> >>>>http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
> >>>>(pre-generated freebsd32 syscalls stuff is included, which will be done
> >>>>in two steps on commit) provides groundwork for supporting 32-bit
> >>>>compatibility for 64-bit MIPS and PowerPC systems. It has been tested
> >>>>on amd64 and powerpc64, and compile-tested on ia64. There are two main
> >>>>parts to the patch:
> >>>>
> >>>>1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
> >>>>COMPAT_LINUX32, etc. This requires updating kernel configurations, but
> >>>>is less painful than filling machine-independent bits of the kernel
> >>>>with #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
> >>>>defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old
> >>>>name.
> >>>>
> >>>>2) Modifications to the freebsd32 compat layer to support big-endian
> >>>>architectures.
> >>>>
> >>>>I would appreciate any comments, bugs, or test results on ia64.
> >>>>
> >>>>
> >>>This doesn't look right for non-x86 32-bit ABIs:
> >>>
> >>>Index: sys/kern/imgact_elf.c
> >>>===================================================================
> >>>--- sys/kern/imgact_elf.c (revision 204681)
> >>>+++ sys/kern/imgact_elf.c (working copy)
> >>>@@ -1439,7 +1439,7 @@
> >>> ehdr->e_ident[EI_ABIVERSION] = 0;
> >>> ehdr->e_ident[EI_PAD] = 0;
> >>> ehdr->e_type = ET_CORE;
> >>>-#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
> >>>+#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32
> >>> ehdr->e_machine = EM_386;
> >>> #else
> >>> ehdr->e_machine = ELF_ARCH;
> >>>
> >>>
> >>Good catch! Such are the dangers of sed. How about defining an
> >>ELF_ARCH32 in machine/elf.h for this case?
> >>
> >
> >Yes, that sounds good.
> >
> >
> >>>It would be nice to eliminate having <compat/ia32*> includes in MI code
> >>>by instead including those headers in appropriate headers in
> >>><machine/*>. For example, we could change <machine/reg.h> on amd64 and
> >>>ia64 to include these headers, perhaps under an #ifdef COMPAT_FREEBSD32.
> >>>
> >>>Hmm, actually, I'm quite convinced now that <machine/reg.h> for ia64 and
> >>>amd64 should include <compat/ia32/ia32_reg.h> in the #ifdef _KERNEL
> >>>section to avoid polluting those includes in MI code. I'm not sure what
> >>>the various <machine/fpu.h> includes are for, but fixing ia32_reg.h
> >>>would be a good first step. It would make your diffs smaller I think.
> >>>
> >>>
> >>This is how it works on powerpc64. I didn't modify amd64 and ia64 in
> >>order to avoid making too many changes, but I think you're right that
> >>this is a good idea. I'll add that to the patch when fixing the EM_386
> >>bit you pointed out above.
> >>
> >
> >Ok, thanks.
> >
> >
> I've updated the patch to incorporate these two changes, at
> http://people.freebsd.org/~nwhitehorn/compat_freebsd32_2.diff. Due to
> recursive inclusion issues with sys/procfs.h, it also moves prstatus32
> and friends to compat/freebsd32/freebsd32.h from ia32_reg.h. They are
> MI, and seems like a more appropriate place for them anyway.
First chunk for the sys_generic.c about ibits/obits looks like a bug fix ?
If yes, it probably would make sense to commit it separately to be able
to MFC it.
The same note about chunks that remove #include <compat/ia32...>, if
possible ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ia64/attachments/20100310/0329fdd9/attachment-0001.pgp
------------------------------
Message: 10
Date: Wed, 10 Mar 2010 14:29:47 -0600
From: Nathan Whitehorn <nwhit...@freebsd.org>
Subject: Re: Request for review/comments: 32-bit compat for non-x86
architectures
To: Kostik Belousov <kost...@gmail.com>
Cc: freebsd-...@freebsd.org, freebs...@freebsd.org,
freebs...@freebsd.org
Message-ID: <4B98013B...@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kostik Belousov wrote:
> On Wed, Mar 10, 2010 at 09:55:40AM -0600, Nathan Whitehorn wrote:
>
>> John Baldwin wrote:
>>
>>> On Wednesday 10 March 2010 9:39:15 am Nathan Whitehorn wrote:
>>>
>>>
>>>> John Baldwin wrote:
>>>>
>>>>
>>>>> On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote:
>>>>>
>>>>>
>>>>>
>>>>>> The patch at
>>>>>> http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff
>>>>>> (pre-generated freebsd32 syscalls stuff is included, which will be done
>>>>>> in two steps on commit) provides groundwork for supporting 32-bit
>>>>>> compatibility for 64-bit MIPS and PowerPC systems. It has been tested
>>>>>> on amd64 and powerpc64, and compile-tested on ia64. There are two main
>>>>>> parts to the patch:
>>>>>>
>>>>>> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to
>>>>>> COMPAT_LINUX32, etc. This requires updating kernel configurations, but
>>>>>> is less painful than filling machine-independent bits of the kernel
>>>>>> with #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||
>>>>>> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old
>>>>>> name.
>>>>>>
>>>>>> 2) Modifications to the freebsd32 compat layer to support big-endian
>>>>>> architectures.
>>>>>>
>>>>>> I would appreciate any comments, bugs, or test results on ia64.
>>>>>>
>>>>>>
>>>>>>
>>>>> This doesn't look right for non-x86 32-bit ABIs:
>>>>>
>>>>> Index: sys/kern/imgact_elf.c
>>>>> ===================================================================
>>>>> --- sys/kern/imgact_elf.c (revision 204681)
>>>>> +++ sys/kern/imgact_elf.c (working copy)
>>>>> @@ -1439,7 +1439,7 @@
>>>>> ehdr->e_ident[EI_ABIVERSION] = 0;
>>>>> ehdr->e_ident[EI_PAD] = 0;
>>>>> ehdr->e_type = ET_CORE;
>>>>> -#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32
>>>>> +#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32
>>>>> ehdr->e_machine = EM_386;
>>>>> #else
>>>>> ehdr->e_machine = ELF_ARCH;
>>>>>
>>>>>
>>>>>
>>>> Good catch! Such are the dangers of sed. How about defining an
>>>> ELF_ARCH32 in machine/elf.h for this case?
>>>>
>>>>
>>> Yes, that sounds good.
>>>
>>>
>>>
>>>>> It would be nice to eliminate having <compat/ia32*> includes in MI code
>>>>> by instead including those headers in appropriate headers in
>>>>> <machine/*>. For example, we could change <machine/reg.h> on amd64 and
>>>>> ia64 to include these headers, perhaps under an #ifdef COMPAT_FREEBSD32.
>>>>>
>>>>> Hmm, actually, I'm quite convinced now that <machine/reg.h> for ia64 and
>>>>> amd64 should include <compat/ia32/ia32_reg.h> in the #ifdef _KERNEL
>>>>> section to avoid polluting those includes in MI code. I'm not sure what
>>>>> the various <machine/fpu.h> includes are for, but fixing ia32_reg.h
>>>>> would be a good first step. It would make your diffs smaller I think.
>>>>>
>>>>>
>>>>>
>>>> This is how it works on powerpc64. I didn't modify amd64 and ia64 in
>>>> order to avoid making too many changes, but I think you're right that
>>>> this is a good idea. I'll add that to the patch when fixing the EM_386
>>>> bit you pointed out above.
>>>>
>>>>
>>> Ok, thanks.
>>>
>>>
>>>
>> I've updated the patch to incorporate these two changes, at
>> http://people.freebsd.org/~nwhitehorn/compat_freebsd32_2.diff. Due to
>> recursive inclusion issues with sys/procfs.h, it also moves prstatus32
>> and friends to compat/freebsd32/freebsd32.h from ia32_reg.h. They are
>> MI, and seems like a more appropriate place for them anyway.
>>
>
> First chunk for the sys_generic.c about ibits/obits looks like a bug fix ?
> If yes, it probably would make sense to commit it separately to be able
> to MFC it.
>
> The same note about chunks that remove #include <compat/ia32...>, if
> possible ?
>
It is a bug fix, but one that only matters on big-endian systems
(swizzle_fdbits needs it defined), and so goes into the
fixes-for-big-endian bucket. Disentangling all of this would be pretty
difficult, and most of the changes are pointless without their companion
changes. Some of the big endian bits could be pulled out, I guess, but
I'm not completely sure what the point of separately MFCing them is.
------------------------------
Message: 11
Date: Wed, 10 Mar 2010 22:15:02 +0000
From: Anton Shterenlikht <me...@bristol.ac.uk>
Subject: Re: port lang/gnustep-base - make configure fails on ia64
To: Dirk Meyer <dirk....@dinoex.sub.org>
Cc: ger...@FreeBSD.org, freebs...@FreeBSD.org
Message-ID: <20100310221...@mech-cluster241.men.bris.ac.uk>
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 10, 2010 at 09:20:47PM +0100, Dirk Meyer wrote:
> Hallo Anton Shterenlikht,
>
> > On FreeBSD 9.0-CURRENT #0 r203484M
> > port lang/gnustep-base fails "make configure".
> >
> > Please see the log here:
> > http://seis.bris.ac.uk/~mexas/gnustep-base-ia64.log
>
> /usr/local/lib/gcc42/gcc/ia64-portbld-freebsd9.0/4.2.5/../../../libobjc.so: undefined reference to `__ia64_restore_stack_nonlocal@GCC_3.0'
> /usr/local/lib/gcc42/gcc/ia64-portbld-freebsd9.0/4.2.5/../../../libobjc.so: undefined reference to `__ia64_save_stack_nonlocal@GCC_3.0'
> collect2: ld returned 1 exit status
>
> Please rebuild your gcc port.
I've rebuilt gcc42:
> pkg_info -xo gcc-
Information for gcc-4.2.5.20090325_2:
> gcc42 --version
gcc42 (GCC) 4.2.5 20090325 (prerelease)
and still get the same error.
I must say that gcc42 is marked "NOT_FOR_ARCHS= ia64 powerpc",
which I've overwritten manually.
Perhaps the fact that gcc42 now builds on ia64 doesn't
mean that is works correctly..
many thanks
anton
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
------------------------------
Message: 12
Date: Wed, 10 Mar 2010 17:30:44 -0800
From: Marcel Moolenaar <xcl...@mac.com>
Subject: Re: port lang/gnustep-base - make configure fails on ia64
To: Anton Shterenlikht <me...@bristol.ac.uk>
Cc: din...@freebsd.org, freebs...@freebsd.org
Message-ID: <E3F7A3CB-247C-4DFA...@mac.com>
Content-Type: text/plain; charset=us-ascii
On Mar 10, 2010, at 4:29 AM, Anton Shterenlikht wrote:
> On FreeBSD 9.0-CURRENT #0 r203484M
> port lang/gnustep-base fails "make configure".
>
> Please see the log here:
> http://seis.bris.ac.uk/~mexas/gnustep-base-ia64.log
>
> Portsmon is empty for this port, so I've no
> idea if this is a regression:
>
> http://portsmon.freebsd.org/portoverview.py?category=lang&portname=gnustep-base
This is the problem:
/usr/local/lib/gcc42/gcc/ia64-portbld-freebsd9.0/4.2.5/../../../libobjc.so: undefined reference to `__ia64_restore_stack_nonlocal@GCC_3.0'
/usr/local/lib/gcc42/gcc/ia64-portbld-freebsd9.0/4.2.5/../../../libobjc.so: undefined reference to `__ia64_save_stack_nonlocal@GCC_3.0'
The libobjc on FreeBSD/ia64 is missing 2 functions.
--
Marcel Moolenaar
xcl...@mac.com
------------------------------
Message: 13
Date: Thu, 11 Mar 2010 01:40:37 +0000
From: Anton Shterenlikht <me...@bristol.ac.uk>
Subject: Re: port lang/gnustep-base - make configure fails on ia64
To: Marcel Moolenaar <xcl...@mac.com>
Cc: din...@freebsd.org, freebs...@freebsd.org
Message-ID: <20100311014...@mech-cluster241.men.bris.ac.uk>
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 10, 2010 at 05:30:44PM -0800, Marcel Moolenaar wrote:
>
> On Mar 10, 2010, at 4:29 AM, Anton Shterenlikht wrote:
>
> > On FreeBSD 9.0-CURRENT #0 r203484M
> > port lang/gnustep-base fails "make configure".
> >
> > Please see the log here:
> > http://seis.bris.ac.uk/~mexas/gnustep-base-ia64.log
> >
> > Portsmon is empty for this port, so I've no
> > idea if this is a regression:
> >
> > http://portsmon.freebsd.org/portoverview.py?category=lang&portname=gnustep-base
>
>
> This is the problem:
>
> /usr/local/lib/gcc42/gcc/ia64-portbld-freebsd9.0/4.2.5/../../../libobjc.so: undefined reference to `__ia64_restore_stack_nonlocal@GCC_3.0'
> /usr/local/lib/gcc42/gcc/ia64-portbld-freebsd9.0/4.2.5/../../../libobjc.so: undefined reference to `__ia64_save_stack_nonlocal@GCC_3.0'
>
> The libobjc on FreeBSD/ia64 is missing 2 functions.
I tried to check and got this:
# ar -t /usr/local/lib/gcc42/libobjc.so.2
ar: warning: Unrecognized archive format
# ldd /usr/local/lib/gcc42/libobjc.so.2
ldd: /usr/local/lib/gcc42/libobjc.so.2: not a FreeBSD ELF shared object
thanks
anton
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
------------------------------
Message: 14
Date: Wed, 10 Mar 2010 22:13:19 -0500
From: Mister Itanium <itaniu...@gmail.com>
Subject: Re: Installation Problem - 8.0
To: Marcel Moolenaar <xcl...@mac.com>
Cc: freebs...@freebsd.org
Message-ID:
<230f61611003101913r25...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Mar 8, 2010 at 3:27 PM, Marcel Moolenaar <xcl...@mac.com> wrote:
>
> On Mar 8, 2010, at 11:11 AM, Mister Itanium wrote:
>
> > Hello,
> > I'm trying to install FreeBSD 8.0 IA64 on a Supermicro Itanium2 Server.
> >
> > When I load the CD, the FreeBSD EFI Boot starts to load (FreeBSD 8.0,
> > etc...) and then 5 seconds later the screen goes blank/black and the
> server
> > reboots.
>
> Use a serial console.
>
> --
> Marcel Moolenaar
> xcl...@mac.com
>
>
>
>
Hi,
I was able to connect a null-modem cable to this machine, and this is the
output:
*ehci0: USB init failed err=18
fatal kernel trap (cpu 0):
trap vector = 0x1e (Unaligned Reference)
cr.iip = 0xe000000004634400
cr.ipsr = 0x1210080a2010 (mfl,ic,dt,dfh,rt,cpl=0,it,ri=1,bn)
cr.isr = 0xa0400000000 (code=0,vector=0,r,ei=1,ed)
cr.ifa = 0xdeadc0dedeadc106
curthread = 0xe000000004ccd3e0
pid = 0, comm = swapper
panic: trap
cpuid = 0
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,
--> or switch off the system now.
*
Please advise,
Thanks.
------------------------------
Message: 15
Date: Wed, 10 Mar 2010 21:17:12 -0800
From: Marcel Moolenaar <xcl...@mac.com>
Subject: Re: Installation Problem - 8.0
To: Mister Itanium <itaniu...@gmail.com>
Cc: freebs...@freebsd.org
Message-ID: <61D1F630-3DA2-47FB...@mac.com>
Content-Type: text/plain; charset=us-ascii
On Mar 10, 2010, at 7:13 PM, Mister Itanium wrote:
>
> ehci0: USB init failed err=18
>
> fatal kernel trap (cpu 0):
>
> trap vector = 0x1e (Unaligned Reference)
> cr.iip = 0xe000000004634400
> cr.ipsr = 0x1210080a2010 (mfl,ic,dt,dfh,rt,cpl=0,it,ri=1,bn)
> cr.isr = 0xa0400000000 (code=0,vector=0,r,ei=1,ed)
> cr.ifa = 0xdeadc0dedeadc106
> curthread = 0xe000000004ccd3e0
> pid = 0, comm = swapper
>
> panic: trap
> cpuid = 0
> Uptime: 1s
> Automatic reboot in 15 seconds - press a key on the console to abort
> --> Press a key on the console to reboot,
> --> or switch off the system now.
It seems there's a problem with the USB 2.0 host controller.
The EHCI problem is causing the kernel panic due to an
uninitialized pointer dereference.
Can you tell me what FreeBSD version and can you also boot
verbose -- i.e. interrupt the boot in the loader and at the
loader prompt type:
boot -v
Also: do you get a "reset timeout" error immediately prior
to the "USB init failed" error?
--
Marcel Moolenaar
xcl...@mac.com
------------------------------
Message: 16
Date: Thu, 11 Mar 2010 06:20:17 GMT
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [head tinderbox] failure on ia64/ia64
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<ia...@freebsd.org>
Message-ID: <201003110620....@freebsd-current.sentex.ca>
TB --- 2010-03-11 04:38:57 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-11 04:38:57 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-03-11 04:38:57 - cleaning the object tree
TB --- 2010-03-11 04:39:14 - cvsupping the source tree
TB --- 2010-03-11 04:39:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2010-03-11 04:39:45 - building world
TB --- 2010-03-11 04:39:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-03-11 04:39:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-03-11 04:39:45 - TARGET=ia64
TB --- 2010-03-11 04:39:45 - TARGET_ARCH=ia64
TB --- 2010-03-11 04:39:45 - TZ=UTC
TB --- 2010-03-11 04:39:45 - __MAKE_CONF=/dev/null
TB --- 2010-03-11 04:39:45 - cd /src
TB --- 2010-03-11 04:39:45 - /usr/bin/make -B buildworld
>>> World build started on Thu Mar 11 04:39:45 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Mar 11 05:55:40 UTC 2010
TB --- 2010-03-11 05:55:40 - generating LINT kernel config
TB --- 2010-03-11 05:55:40 - cd /src/sys/ia64/conf
TB --- 2010-03-11 05:55:40 - /usr/bin/make -B LINT
TB --- 2010-03-11 05:55:40 - building LINT kernel
TB --- 2010-03-11 05:55:40 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-03-11 05:55:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-03-11 05:55:40 - TARGET=ia64
TB --- 2010-03-11 05:55:40 - TARGET_ARCH=ia64
TB --- 2010-03-11 05:55:40 - TZ=UTC
TB --- 2010-03-11 05:55:40 - __MAKE_CONF=/dev/null
TB --- 2010-03-11 05:55:40 - cd /src
TB --- 2010-03-11 05:55:40 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Mar 11 05:55:40 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
===> siba_bwn (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/ia64/src/sys/LINT -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c
cc1: warnings being treated as errors
/src/sys/modules/siba_bwn/../../dev/siba/siba_core.c: In function 'siba_dma_translation':
/src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:2035: warning: dereferencing 'void *' pointer
/src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:2035: error: request for member 'sd_bus' in something not a structure or union
/src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:2035: warning: dereferencing 'void *' pointer
/src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:2035: error: request for member 'sd_bus' in something not a structure or union
*** Error code 1
Stop in /src/sys/modules/siba_bwn.
*** Error code 1
Stop in /src/sys/modules.
*** Error code 1
Stop in /obj/ia64/src/sys/LINT.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-03-11 06:20:17 - WARNING: /usr/bin/make returned exit code 1
TB --- 2010-03-11 06:20:17 - ERROR: failed to build lint kernel
TB --- 2010-03-11 06:20:17 - 4954.32 user 660.40 system 6079.48 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full
------------------------------
Message: 17
Date: Thu, 11 Mar 2010 06:19:54 -0500
From: Mister Itanium <itaniu...@gmail.com>
Subject: Re: Installation Problem - 8.0
To: Marcel Moolenaar <xcl...@mac.com>
Cc: freebs...@freebsd.org
Message-ID:
<230f61611003110319r685...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Mar 11, 2010 at 12:17 AM, Marcel Moolenaar <xcl...@mac.com> wrote:
>
> On Mar 10, 2010, at 7:13 PM, Mister Itanium wrote:
>
> >
> > ehci0: USB init failed err=18
> >
> > fatal kernel trap (cpu 0):
> >
> > trap vector = 0x1e (Unaligned Reference)
> > cr.iip = 0xe000000004634400
> > cr.ipsr = 0x1210080a2010 (mfl,ic,dt,dfh,rt,cpl=0,it,ri=1,bn)
> > cr.isr = 0xa0400000000 (code=0,vector=0,r,ei=1,ed)
> > cr.ifa = 0xdeadc0dedeadc106
> > curthread = 0xe000000004ccd3e0
> > pid = 0, comm = swapper
> >
> > panic: trap
> > cpuid = 0
> > Uptime: 1s
> > Automatic reboot in 15 seconds - press a key on the console to abort
> > --> Press a key on the console to reboot,
> > --> or switch off the system now.
>
> It seems there's a problem with the USB 2.0 host controller.
> The EHCI problem is causing the kernel panic due to an
> uninitialized pointer dereference.
>
> Can you tell me what FreeBSD version and can you also boot
> verbose -- i.e. interrupt the boot in the loader and at the
> loader prompt type:
> boot -v
>
>
> Also: do you get a "reset timeout" error immediately prior
> to the "USB init failed" error?
>
> --
> Marcel Moolenaar
> xcl...@mac.com
>
>
>
This is the entire boot -v (verbose)
-^H\^HEntering /boot/kernel/kernel at 0xe000000004080000...
PAL Proc at 0xe00000007ff08010
SAL Proc at 0xe00000007ff48020, GP at 0xe0000000801712c0
SAL: AP wake-up vector: 0xf0
Platform clock frequency 199475857 Hz
Processor ratio 14/2, Bus ratio 1/1, ITC ratio 14/2
ptc.e base=0x0, count1=1, count2=1, stride1=0x0, stride2=0x0
Processor supports 24 Region ID bits
Trying VHPT size 0x1000000
Putting VHPT at 0x6000000
Splitting [0x560c000-0x7fb40000]
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-RELEASE #0: Sun Nov 22 01:11:28 UTC 2009
ro...@pluto1.freebsd.org:/usr/obj/usr/src/sys/GENERIC
UNWIND: table added: base=e000000004000000, start=e000000004bbb060,
end=e000000004bfc250
Preloaded elf kernel "/boot/kernel/kernel" at 0xe000000005608580.
Preloaded mfs_root "/boot/mfsroot" at 0xe000000005608660.
CPU: Madison (1396.33-Mhz Itanium 2)
Origin = "GenuineIntel" Revision = 5
Features = 0x1<LB>
real memory = 4282048512 (4083 MB)
Physical memory chunk(s):
0x01900000 - 0x03ffffff, 40894464 bytes (4992 pages)
0x0560c000 - 0x05ffffff, 10436608 bytes (1274 pages)
0x0a000000 - 0x7fb3ffff, 1974730752 bytes (241056 pages)
0x180000000 - 0x1fb455fff, 2068144128 bytes (252459 pages)
0x1feffe000 - 0x1ff453fff, 4546560 bytes (555 pages)
0x1ff802000 - 0x1ff8fdfff, 1032192 bytes (126 pages)
0x1ff9fe000 - 0x1ffd63fff, 3563520 bytes (435 pages)
0x1ffdfe000 - 0x1ffe0ffff, 73728 bytes (9 pages)
0x1ffe7e000 - 0x1fffb7fff, 1286144 bytes (157 pages)
avail memory = 4083957760 (3894 MB)
FPSWA Revision = 0x10012, Entry = 0xe0000001ffe60050
Table 'FACP' at 0xe00000007ff99138
Table 'APIC' at 0xe00000007ff99230
Local APIC address=0xfee00000
Local SAPIC entry
ProcessorId=0x0, Id=0xc0, Eid=0x18
Local SAPIC entry
ProcessorId=0x1, Id=0xc6, Eid=0x18
I/O SAPIC entry
Id=0x0, InterruptBase=0x0, Address=0xfec00000
I/O SAPIC entry
Id=0x2, InterruptBase=0x18, Address=0xfaffe000
I/O SAPIC entry
Id=0x1, InterruptBase=0x30, Address=0xfafff000
Interrupt source override entry
Bus=0, Source=9, Irq=0x9
Platform interrupt entry
Polarity=3, TriggerMode=3, Id=0xc6, Eid=0x18, Vector=0x1e,
Irq=22
Table 'IPPT' at 0xe00000007ff99308
Table 'SPCR' at 0xe00000007ff99340
MCA: allocated 16384 bytes for state info.
SMP: waking up cpu1
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0: ACPI Id=1, SAPIC Id=c6, SAPIC Eid=18 (BSP)
cpu1: ACPI Id=0, SAPIC Id=c0, SAPIC Eid=18
ULE: setup cpu 0
ULE: setup cpu 1
mem: <memory>
null: <null device, zero device>
nfslock: pseudo-device
random: <entropy source, Software, Yarrow>
ACPI: RSDP 0x7ff99000 00024 (v2 AMI )
ACPI: XSDT 0x7ff99090 00044 (v1 AMI TIGER_2W 01072002 MSFT 00010013)
ACPI: FACP 0x7ff99138 000F4 (v3 AMI TIGER_2W 01072002 MSFT 00010013)
ACPI: DSDT 0x7ff9b000 0220E (v1 AMI TIGER2W 00000000 MSFT 0100000D)
ACPI: FACS 0x7ff992c0 00040
ACPI: APIC 0x7ff99230 0008E (v1 AMI TIGER_2W 01072002 MSFT 00010013)
ACPI: IPPT 0x7ff99308 00034 (v1 AMI TIGER_2W 01072002 MSFT 00010013)
ACPI: SPCR 0x7ff99340 00050 (v1 AMI TIGER_2W 01072002 MSFT 00010013)
nexus0: registered as a time-of-day clock (resolution 1000us)
acpi0: <AMI TIGER_2W> on motherboard
acpi0: [MPSAFE]
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
AcpiOsDerivePciId: \_SB_.CSFF.IOH5.IOHC -> bus 255 dev 28 func 5
AcpiOsDerivePciId: \_SB_.CSFF.IOH1.IO01 -> bus 255 dev 28 func 1
AcpiOsDerivePciId: \_SB_.CSFF.IOH2.IO02 -> bus 255 dev 28 func 2
ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xc08-0xc0b on acpi0
pcib0: <ACPI Host-PCI bridge> on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: domain=0, physical bus=0
found-> vendor=0x8086, dev=0x24c2, revid=0x02
domain=0, bus=0, slot=29, func=0
class=0c-03-00, hdrtype=0x00, mfdev=1
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=5
map[20]: type I/O Port, range 32, base 0xef20, size 5, enabled
pcib0: matched entry for 0.29.INTA
pcib0: slot 29 INTA hardwired to IRQ 16
found-> vendor=0x8086, dev=0x24c4, revid=0x02
domain=0, bus=0, slot=29, func=1
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=10
map[20]: type I/O Port, range 32, base 0xef40, size 5, enabled
pcib0: matched entry for 0.29.INTB
pcib0: slot 29 INTB hardwired to IRQ 19
found-> vendor=0x8086, dev=0x24c7, revid=0x02
domain=0, bus=0, slot=29, func=2
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=c, irq=11
map[20]: type I/O Port, range 32, base 0xef80, size 5, enabled
pcib0: matched entry for 0.29.INTC
pcib0: slot 29 INTC hardwired to IRQ 18
found-> vendor=0x8086, dev=0x24cd, revid=0x02
domain=0, bus=0, slot=29, func=7 class=0c-03-20,
hdrtype=0x00, mfdev=0
cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=d, irq=0
powerspec 2 supports D0 D3 current D0
map[10]: type Memory, range 32, base 0, size 10, memory disabled
pcib0: matched entry for 0.29.INTD
pcib0: slot 29 INTD hardwired to IRQ 23
found-> vendor=0x8086, dev=0x244e, revid=0x82
domain=0, bus=0, slot=30, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
cmdreg=0x0147, statreg=0x0080, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x24c0, revid=0x02
domain=0, bus=0, slot=31, func=0
class=06-01-00, hdrtype=0x00, mfdev=1
cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x24cb, revid=0x02
domain=0, bus=0, slot=31, func=1
class=01-01-8a, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=0
map[20]: type I/O Port, range 32, base 0x1000, size 4, enabled
map[24]: type Memory, range 32, base 0, size 10, memory disabled
pcib0: no PRT entry for 0.31.INTA
found-> vendor=0x8086, dev=0x24c3, revid=0x02
domain=0, bus=0, slot=31, func=3
class=0c-05-00, hdrtype=0x00, mfdev=0
cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=0
map[20]: type I/O Port, range 32, base 0xcc0, size 5, enabled
pcib0: no PRT entry for 0.31.INTB
uhci0: <Intel 82801DB (ICH4) USB controller USB-A> port 0xef20-0xef3f irq 16
at device 29.0 on pci0
uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xef20
uhci0: [MPSAFE]
uhci0: [ITHREAD]
uhci0: LegSup = 0x0f00
usbus0: <Intel 82801DB (ICH4) USB controller USB-A> on uhci0
uhci1: <Intel 82801DB (ICH4) USB controller USB-B> port 0xef40-0xef5f irq 19
at device 29.1 on pci0
uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xef40
uhci1: [MPSAFE]
uhci1: [ITHREAD]
uhci1: LegSup = 0x0f00
usbus1: <Intel 82801DB (ICH4) USB controller USB-B> on uhci1
uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xef80-0xef9f irq 18
at device 29.2 on pci0
uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xef80
uhci2: [MPSAFE]
uhci2: [ITHREAD]
uhci2: LegSup = 0x0f00
usbus2: <Intel 82801DB (ICH4) USB controller USB-C> on uhci2
ehci0: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> irq 23 at device 29.7
on pci0
ehci0: Lazy allocation of 0x400 bytes rid 0x10 type 3 at 0x80000000
ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0x80000000
ehci0: [MPSAFE]
ehci0: [ITHREAD]
usbus3: EHCI version 0.0
usbus3: stop timeout
usbus3: reset timeout
usbus3: reset timeout
ehci0: USB init failed err=18
fatal kernel trap (cpu 0):
trap vector = 0x1e (Unaligned Reference)
cr.iip = 0xe000000004634400
cr.ipsr = 0x1210080a2010 (mfl,ic,dt,dfh,rt,cpl=0,it,ri=1,bn)
cr.isr = 0xa0400000000 (code=0,vector=0,r,ei=1,ed)
cr.ifa = 0xdeadc0dedeadc106
curthread = 0xe000000004ccd3e0
pid = 0, comm = swapper
panic: trap
cpuid = 0
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,
--> or switch off the system now.
Rebooting...
------------------------------
End of freebsd-ia64 Digest, Vol 352, Issue 4
********************************************