[parisc-linux] PA8000 modutils problems

[parisc-linux] PA8000 modutils problems

[M. Grabert]

Hi, I have some problems in compiling the latest kernels;

I tried pa35 (32bit), which caused unaligned address traps during boot
(IIRC it was e2fsck).
I rebooted with pa20, which worked (but has the known IO problems,
i.e. copying a full CD to hard disk with lock up the machine).
Later I tried compiling pa39 (32bit), but depmod reported
"unhandled relocation of type 74" for each function in each module.
Compiling 64bit with the (quite old) unofficial debs worked however,
but there are some "unresolved symbols" in a few (=4) modules,
each time the symbol is "__xchg64". I'm quite sure that in former times
all modules worked. Since these modules are not important to me
(smbfs and some ipv6 netfilter modules) there is no hurry ;)

I always compiled for the "PA8000" processor type; I know there were some
issues with the PA8000 optimization and modutils, but remeber that these
were fixed. Is this a regression ?

So far I'm running a 64bit kernel (because it's the only way it works),
but I want to stick to a 32bit kernel, because they may be more stable.

However I didn't try selecting any other CPU type (was just too lazy);
though there is a good chance that this would solve the modules problem.

BTW, I'm running debian/sid, updated yesterday.

One more question: is it a good idea to compile with gcc-3.1,
e.g. make CC=gcc-3.1 HOSTCC=gcc-3.1 vmlinux ?
Does gcc-3.1 generate better code (better optimized, fewer bugs?) or
should I stick to gcc-3.0 since this is the "recommended" compiler
(or at least the one the kernel developers use and know)

thanks in advance, max
--
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.

Re: [parisc-linux] PA8000 modutils problems

[John David Anglin]

> Hi, I have some problems in compiling the latest kernels;
> 
> I tried pa35 (32bit), which caused unaligned address traps during boot
> (IIRC it was e2fsck).
> I rebooted with pa20, which worked (but has the known IO problems,
> i.e. copying a full CD to hard disk with lock up the machine).
> Later I tried compiling pa39 (32bit), but depmod reported
> "unhandled relocation of type 74" for each function in each module.
> Compiling 64bit with the (quite old) unofficial debs worked however,
> but there are some "unresolved symbols" in a few (=4) modules,
> each time the symbol is "__xchg64". I'm quite sure that in former times
> all modules worked. Since these modules are not important to me
> (smbfs and some ipv6 netfilter modules) there is no hurry ;)

Depmod does it own limited handling of relocations.  You probably
need to stick with the recommended compiler (debian 3.0.4 and binutils)
to be compatible with the relocation capability of depmod.  The
alignment issues also are likely a result of using 3.1.  BIGGEST_ALIGNMENT
was changed last Feb. to 128 bits to allow struct alignment suitable
for the ldcw semaphore insn.  I believe the deb version of gcc was
patched to do this as well.

> 
> I always compiled for the "PA8000" processor type; I know there were some
> issues with the PA8000 optimization and modutils, but remeber that these
> were fixed. Is this a regression ?

This only affects the scheduling of insns.  As far as I am aware,
there are no scheduling related bugs for any of the scheduling
models.  PA8000 will be the default for PA2.0 machines in 3.2.

Now, there is a known issue with PA2.0 code generation.  It affects
floating point loads from symbolic memory locations using the 32-bit
elf tools.  As a result, the code generation default is still PA1.1.
I'm planning to change this to PA2.0 for PA2.0 machines when the
assembler bug is fixed.

> One more question: is it a good idea to compile with gcc-3.1,
> e.g. make CC=gcc-3.1 HOSTCC=gcc-3.1 vmlinux ?
> Does gcc-3.1 generate better code (better optimized, fewer bugs?) or
> should I stick to gcc-3.0 since this is the "recommended" compiler
> (or at least the one the kernel developers use and know)

I would use the recommended compiler for the kernel.  It's difficult
to compare the debian patched versions with the vanilla FSF versions.
In general, 3.1 has fewer bugs than 3.0.  However, I doubt that it
is significantly better optimized.  For C++ apps, I would probably
go with a 3.2 snap because it has dw2 eh.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] PA8000 modutils problems

[M. Grabert]

On Fri, 21 Jun 2002, John David Anglin wrote:

> > I tried pa35 (32bit), which caused unaligned address traps during boot
> > (IIRC it was e2fsck).
> > I rebooted with pa20, which worked (but has the known IO problems,
> > i.e. copying a full CD to hard disk with lock up the machine).
> > Later I tried compiling pa39 (32bit), but depmod reported
> > "unhandled relocation of type 74" for each function in each module.
> > Compiling 64bit with the (quite old) unofficial debs worked however,
> > but there are some "unresolved symbols" in a few (=4) modules,
> > each time the symbol is "__xchg64". I'm quite sure that in former times
> > all modules worked. Since these modules are not important to me
> > (smbfs and some ipv6 netfilter modules) there is no hurry ;)

I think the unsresolve symbols are just simple programmers bugs which
will 'autmagically' be fixed in later kernels. At least this happened to
me quite a few times (on different platforms, different kernels & modules)

> Depmod does it own limited handling of relocations.  You probably
> need to stick with the recommended compiler (debian 3.0.4 and binutils)
> to be compatible with the relocation capability of depmod.  The
> alignment issues also are likely a result of using 3.1.  BIGGEST_ALIGNMENT
> was changed last Feb. to 128 bits to allow struct alignment suitable
> for the ldcw semaphore insn.  I believe the deb version of gcc was
> patched to do this as well.

I forgot to mention that I used 'gcc' (thus 3.0) to compile -pa39
(32bit, and 'hppa64-gcc' for 64bit). I'm quite sure about that.

However I'm have to agree that I used gcc-3.1 for the not
correctly working -pa35 (unaligned address). That's the reason why
I chose to use the default gcc for compiling -pa39!

Therefore the depmod issue is IMHO due to some other error ...

> Now, there is a known issue with PA2.0 code generation.  It affects
> floating point loads from symbolic memory locations using the 32-bit
> elf tools.  As a result, the code generation default is still PA1.1.
> I'm planning to change this to PA2.0 for PA2.0 machines when the
> assembler bug is fixed.

So what is the point in choosing the PA8000 anyway ? ;)
Oh, I forgot; to be able to select 64bit kernel!

Thanks alot for the quick answer!

Greeting max

-- 
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.

Re: [parisc-linux] PA8000 modutils problems

[John David Anglin]

> So what is the point in choosing the PA8000 anyway ? ;)

It affects the ordering of insns but not the insn set (PA1.0, 1.1
or 2.0).  The PA8000 ordering should work better on a PA8000
or later processor.  The ordering takes into account the number
of insn pipelines, the timing of insns, etc.  On older PA1.1
machines, the PA7100LC model should be better.

PA8000 machines all use the PA2.0 architecture but are backwards
compatible with PA1.1, etc.  There is still more work to be done
in the compiler to take full advantage of the PA2.0 architecture,
particularly in 32-bit mode.  For example, we are not taking
advantage of the fact that the general registers are actually 64
bits wide.  Thus, long long support could be better.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] PA8000 modutils problems

[Grant Grundler]

"M. Grabert" wrote:
> Later I tried compiling pa39 (32bit), but depmod reported
> "unhandled relocation of type 74" for each function in each module.

This is a known bug in the modutils package.

Richard Hirst had created an older (hacked 2.4.13) version of
modutils that can deal with relocation type 74. See
	ftp://ftp.parisc-linux.org/unofficial-debs/

and grab modutils-2.4.13-3.1rgh*


> Compiling 64bit with the (quite old) unofficial debs worked however,
> but there are some "unresolved symbols" in a few (=4) modules,
> each time the symbol is "__xchg64".

grundler <506>fgrep -n __xchg64 arch/parisc/kernel/parisc_ksyms.c
77:EXPORT_SYMBOL(__xchg64);

Something else is wrong. you are building from CVS right?
Try "make distclean" and rebuild the 64-bit vmlinux/ from scratch.


> I'm quite sure that in former times
> all modules worked. Since these modules are not important to me
> (smbfs and some ipv6 netfilter modules) there is no hurry ;)

I'm pretty sure smbfs was recently built/tested.
It's been a while since I've heard anything about ipv6 on parisc.

> So far I'm running a 64bit kernel (because it's the only way it works),
> but I want to stick to a 32bit kernel, because they may be more stable.

I would agree. But you need to use PA11 arch for now.
In general, I think the 64-bit kernel isn't too bad though.

grant

Re: [parisc-linux] PA8000 modutils problems

[Joel Soete]

Hi Dave,

John David Anglin wrote:
> 
>>One more question: is it a good idea to compile with gcc-3.1,
>>e.g. make CC=gcc-3.1 HOSTCC=gcc-3.1 vmlinux ?
>>Does gcc-3.1 generate better code (better optimized, fewer bugs?) or
>>should I stick to gcc-3.0 since this is the "recommended" compiler
>>(or at least the one the kernel developers use and know)
> 
Some weeks ago I also try to compile the kernel (32bits) with gcc-3.1 
(cvs) and eventhought it boots fine there was a problem
with network connections (as well telnet which uses inetd as well as ssh
which using its own sshd; this confirm the problem of compilation in 
network interface). Is this problem solved now?
If not I will ask to Bruno to test its last lkcd code (kdb not yet 
working) to continue to investigate this problem.

Joel

Re: [parisc-linux] PA8000 modutils problems

[John David Anglin]

> Some weeks ago I also try to compile the kernel (32bits) with gcc-3.1 
> (cvs) and eventhought it boots fine there was a problem
> with network connections (as well telnet which uses inetd as well as ssh
> which using its own sshd; this confirm the problem of compilation in 
> network interface). Is this problem solved now?

Not that I am aware of.  Maybe some of the debian folks have tried looking
into it as they were talking about moving to a newer compiler release.  
If it is a compiler problem, I would need a test case showing the
miscompilation and preferably a filed PR.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] PA8000 modutils problems

[Joel Soete]

Dave,

The problem mentionned in this mail:
http://lists.parisc-linux.org/pipermail/parisc-linux/2002-April/016119.html

about gcc-3.2 is the same with gcc-3.1.

Dono about some follow-up?

Thanks for advise,
	Joel

PS:
What means PR (how to fil it)?
And what means insn?

John David Anglin wrote:
>>Some weeks ago I also try to compile the kernel (32bits) with gcc-3.1 
>>(cvs) and eventhought it boots fine there was a problem
>>with network connections (as well telnet which uses inetd as well as ssh
>>which using its own sshd; this confirm the problem of compilation in 
>>network interface). Is this problem solved now?
> 
> 
> Not that I am aware of.  Maybe some of the debian folks have tried looking
> into it as they were talking about moving to a newer compiler release.  
> If it is a compiler problem, I would need a test case showing the
> miscompilation and preferably a filed PR.
> 
> Dave

Re: [parisc-linux] PA8000 modutils problems

[M. Grabert]

On Fri, 21 Jun 2002, Grant Grundler wrote:

> "M. Grabert" wrote:
> > Later I tried compiling pa39 (32bit), but depmod reported
> > "unhandled relocation of type 74" for each function in each module.
>
> This is a known bug in the modutils package.
>
> Richard Hirst had created an older (hacked 2.4.13) version of
> modutils that can deal with relocation type 74. See
> 	ftp://ftp.parisc-linux.org/unofficial-debs/
>
> and grab modutils-2.4.13-3.1rgh*

Thanks alot! I think I did that earlier, but after an apt-get upgrade
it might have been 'updated'. I set it to 'HOLD' (dselect) next time.

> > Compiling 64bit with the (quite old) unofficial debs worked however,
> > but there are some "unresolved symbols" in a few (=4) modules,
> > each time the symbol is "__xchg64".
>
> grundler <506>fgrep -n __xchg64 arch/parisc/kernel/parisc_ksyms.c
> 77:EXPORT_SYMBOL(__xchg64);
>
> Something else is wrong. you are building from CVS right?
> Try "make distclean" and rebuild the 64-bit vmlinux/ from scratch.

Yes, I always use the CVS trunk. I always have the CVS tree on
a different machine and do a CVS update on it (intel laptop with internet
connection, at work) and then copy the kernel to the parisc-linux machine
(no internet connection, at home). So I always have a fresh, clean CVS
kernel (with no old *.o files).

But I just did a 'make clean' when I decided to make a 64bit. I forgot
that it is actually a different architecture ... This might have caused
the problem!
Thanks for reminding!


greetings max

-- 
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.

Applied GNU GPL virus was Re: [parisc-linux] PA8000 modutils problems

[M. Grabert]

Gotcha!

Sorry, I hate to reply to my previous main, but I think it's important!

On Fri, 21 Jun 2002, M. Grabert wrote:

> Date: Fri, 21 Jun 2002 21:52:20 +0100 (IST)
> From: M. Grabert <xam@cs.ucc.ie>
> To: parisc-linux@lists.parisc-linux.org
> Subject: [parisc-linux] PA8000 modutils problems
>
> Hi, I have some problems in compiling the latest kernels;

[... problem report ...]

Now the important part (the .signature of the post):

> thanks in advance, max
> --
> I am the "ILOVEGNU" signature virus. Just copy me to your signature.
> This email was infected under the terms of the GNU General Public License.

[...]

Well, I got a lot of really helpful responses from alot of nice people,
but unfortunately we have some issue here:

Some of the people who replied to my email didn't include the original
email (source code) as required by the GNU GPL or even didn't include the
copyleft reference in their replies!
The first point is probably not valid, since the original email is
probably referenced in the mail header and usually stored in the same mail
archive and thus can be easily accessed.
But the latter is IMHO a more severe thing: you definitely violated the
GNU GPL by this! (I think all of these people are listed in the CC: field)

Be careful that you won't get caught in this trap next time :)

BTW, I should have included the GNU GPL in my first email (and not only
mention/reference it), shouldn't I ?
Moreover is an email a valid soure code as described in the GNU GPL ?

greetings max

PS: I won't sue you because of this incident (neither now nor later) :)))
PPS: This is ment to be (at least) a half-serious email. Any useful
responses (under the terms of the GNU GPL) are highly welcome, especially
from laywers! ;)

-- 
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.

Re: Applied GNU GPL virus was Re: [parisc-linux] PA8000 modutils problems

[John David Anglin]

> PPS: This is ment to be (at least) a half-serious email. Any useful
> responses (under the terms of the GNU GPL) are highly welcome, especially
> from laywers! ;)

The list is intended for for discussion of parisc-linux issues and not
the GNU GPL.  Contact RMS at the FSF if you want to discuss the GNU GPL.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Applied GNU GPL virus was Re: [parisc-linux] PA8000 modutils problems

[Grant Grundler]

"M. Grabert" wrote:
...
> Be careful that you won't get caught in this trap next time :)

Sue me. I ignore .sigs unless they amuse me.

grant