linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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) {

  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).