From: mel@csn.ul.ie (Mel Gorman)
To: Andrew Morton <akpm@osdl.org>
Cc: linuxppc-dev@ozlabs.org, vgoyal@in.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
Date: Mon, 29 May 2006 16:49:24 +0100 [thread overview]
Message-ID: <20060529154923.GA9025@skynet.ie> (raw)
In-Reply-To: <20060526094924.10efc515.akpm@osdl.org>
On (26/05/06 09:49), Andrew Morton didst pronounce:
> mel@csn.ul.ie (Mel Gorman) wrote:
> >
> > (Resending with Andrew's email address correct this time)
> >
> > For the last few -mm releases, kernels built for an old RS6000 failed to
> > compile with the message;
> >
> > arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
> > : undefined reference to `__udivdi3'
> > arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
> > : undefined reference to `__udivdi3'
> > make: *** [.tmp_vmlinux1] Error 1
>
> A function with a name like that doesn't _deserve_ to compile.
>
heh
> But actually vrsqrtefp() doesn't call __udivdi3 - the error lies somewhere
> else in the kernel and the toolchain gets it wrong, so we don't know where.
>
It explains why I couldn't find where vrsqrtefp() was.
> The way I usually hunt this problem down is to build the .s files (make
> arch/powerpc/kernel/foo.s) and then grep around, find the offending C
> function.
>
That was a good idea, thanks. It showed that check_for_io_childs() in
arch/powerpc/kernel/pci_32.c was the real problem. A quick look showed
that is was doing divisions on resource_type_t which was 64 bits with my
.config. Selecting CONFIG_RESOURCES_32BIT made the problem go away. This
option is introduced by the kconfigurable-resources-* patches so I've cc'd
Vivek Goyal to comment on the potential fixes below.
> > 2.6.17-rc5 is not affected but I didn't search for the culprit patch in
> > -mm. The following patch adds an implementation of __udivdi3 for plain old
> > ppc32. This may not be the correct fix as Google tells me that __udivdi3
> > has been replaced by calls to do_div() in a number of cases. There was no
> > obvious way to do that for vrsqrtefp, hence this workaround. The patch should
> > be acked, rejected or replaced by a ppc expert.
>
> Yes, we've traditionally avoided adding the 64-bit divide library functions.
Understandable. The fixes are obvious in this case. Easiest is for users to
set CONFIG_RESOURCES_32BIT manually although the kernel build error is not
very obvious. A fairly easy bodge is to default CONFIG_RESOURCES_32BIT to Y
when building PPC32 but a determined user may still fail to build a kernel. A
slightly riskier option is this patch that replaces a potential 64 bit divide
with a do_div call. The patch has been successfully boot-tested on a RS6000.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc4-mm3-clean/arch/powerpc/kernel/pci_32.c linux-2.6.17-rc4-mm3-resources-32/arch/powerpc/kernel/pci_32.c
--- linux-2.6.17-rc4-mm3-clean/arch/powerpc/kernel/pci_32.c 2006-05-29 15:55:52.000000000 +0100
+++ linux-2.6.17-rc4-mm3-resources-32/arch/powerpc/kernel/pci_32.c 2006-05-29 15:53:43.000000000 +0100
@@ -1115,7 +1115,9 @@ check_for_io_childs(struct pci_bus *bus,
int rc = 0;
#define push_end(res, size) do { unsigned long __sz = (size) ; \
- res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
+ resource_size_t farEnd = (res->end + __sz); \
+ do_div(farEnd, (__sz + 1)); \
+ res->end = farEnd * (__sz + 1) + __sz; \
} while (0)
list_for_each_entry(dev, &bus->devices, bus_list) {
next prev parent reply other threads:[~2006-05-29 15:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-26 15:12 [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt) Mel Gorman
2006-05-26 16:49 ` Andrew Morton
2006-05-29 15:49 ` Mel Gorman [this message]
2006-05-29 16:22 ` Segher Boessenkool
2006-05-29 17:38 ` Mel Gorman
2006-05-29 17:56 ` Segher Boessenkool
2006-05-29 19:05 ` Mel Gorman
2006-06-09 9:36 ` Paul Mackerras
2006-06-13 16:49 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060529154923.GA9025@skynet.ie \
--to=mel@csn.ul.ie \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=vgoyal@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).