All of lore.kernel.org
 help / color / mirror / Atom feed
From: dann frazier <dannf@hp.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Peter Chubb <peterc@gelato.unsw.edu.au>,
	linux-ia64@vger.kernel.org, dmosberger@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: ip_contrack refuses to load if built UP as a module on IA64
Date: Sun, 22 Jan 2006 19:31:20 +0000	[thread overview]
Message-ID: <1137958281.31860.5.camel@localhost> (raw)
In-Reply-To: <1136928071.11049.19.camel@krebs.dannf>

On Tue, 2006-01-10 at 14:21 -0700, dann frazier wrote:
> On Mon, 2005-12-19 at 13:07 -0800, Luck, Tony wrote: 
> > On Thu, Sep 22, 2005 at 04:04:59PM -0600, dann frazier wrote:
> > > On Thu, 2005-09-01 at 14:59 +1000, Peter Chubb wrote:
> > > > 
> > > > This patch makes UP and SMP do the same thing as far as module per-cpu
> > > > data go.
> > > > 
> > > > Unfortunately it affects core code.
> > > 
> > > It causes 2.6.13/x86 to fail to link:
> > > kernel/built-in.o: In function `load_module':
> > > : undefined reference to `percpu_modcopy'
> > > make: *** [.tmp_vmlinux1] Error 1
> > > 
> > > fyi, this is a problem we're seeing in the Debian UP packages:
> > >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug25070
> > 
> > Another possible solution is to make ia64 more like other
> > architectures and make per-cpu variables just turn into
> > ordinary variables on UP.  There are some pros and cons to
> > this:
> > 
> > +) Being more like other architectures makes it less likely that
> >    we'll be burned by changes in generic code/tools that depend
> >    on implementation details
> > 
> > -) We probably get worse code to access per-cpu variables from
> >    C-compiled code, and definitely get worse code in a couple of
> >    critical paths in assembler (where an "addl" becomes a "movl")
> > 
> > Here's the patch ... lightly tested (just booted and checked that
> > I could load the ip_conntrack module).
> 
> Thanks Tony; sorry for taking so long to test this.  I required an
> additional change to discontig.c to get this to build w/ the Debian
> config.  With this additional patch, a UP kernel boots fine on my
> rx2600.

fyi, just noticed that the efivars module still doesn't load.



WARNING: multiple messages have this Message-ID (diff)
From: dann frazier <dannf@hp.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Peter Chubb <peterc@gelato.unsw.edu.au>,
	linux-ia64@vger.kernel.org, dmosberger@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: ip_contrack refuses to load if built UP as a module on IA64
Date: Sun, 22 Jan 2006 12:31:20 -0700	[thread overview]
Message-ID: <1137958281.31860.5.camel@localhost> (raw)
In-Reply-To: <1136928071.11049.19.camel@krebs.dannf>

On Tue, 2006-01-10 at 14:21 -0700, dann frazier wrote:
> On Mon, 2005-12-19 at 13:07 -0800, Luck, Tony wrote: 
> > On Thu, Sep 22, 2005 at 04:04:59PM -0600, dann frazier wrote:
> > > On Thu, 2005-09-01 at 14:59 +1000, Peter Chubb wrote:
> > > > 
> > > > This patch makes UP and SMP do the same thing as far as module per-cpu
> > > > data go.
> > > > 
> > > > Unfortunately it affects core code.
> > > 
> > > It causes 2.6.13/x86 to fail to link:
> > > kernel/built-in.o: In function `load_module':
> > > : undefined reference to `percpu_modcopy'
> > > make: *** [.tmp_vmlinux1] Error 1
> > > 
> > > fyi, this is a problem we're seeing in the Debian UP packages:
> > >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325070
> > 
> > Another possible solution is to make ia64 more like other
> > architectures and make per-cpu variables just turn into
> > ordinary variables on UP.  There are some pros and cons to
> > this:
> > 
> > +) Being more like other architectures makes it less likely that
> >    we'll be burned by changes in generic code/tools that depend
> >    on implementation details
> > 
> > -) We probably get worse code to access per-cpu variables from
> >    C-compiled code, and definitely get worse code in a couple of
> >    critical paths in assembler (where an "addl" becomes a "movl")
> > 
> > Here's the patch ... lightly tested (just booted and checked that
> > I could load the ip_conntrack module).
> 
> Thanks Tony; sorry for taking so long to test this.  I required an
> additional change to discontig.c to get this to build w/ the Debian
> config.  With this additional patch, a UP kernel boots fine on my
> rx2600.

fyi, just noticed that the efivars module still doesn't load.



  reply	other threads:[~2006-01-22 19:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-29  2:41 ip_contrack module refuses to load Peter Chubb
2005-08-29  4:09 ` Luck, Tony
2005-08-29  7:29 ` Peter Chubb
2005-08-30  1:35 ` Peter Chubb
2005-08-30 16:17 ` Luck, Tony
2005-08-30 18:38 ` david mosberger
2005-08-30 19:22 ` Luck, Tony
2005-08-30 19:29 ` david mosberger
2005-08-30 21:52 ` Peter Chubb
2005-08-30 22:01 ` david mosberger
2005-09-01  4:59   ` ip_contrack refuses to load if built UP as a module on IA64 Peter Chubb
2005-09-01  4:59     ` Peter Chubb
2005-09-22 22:04     ` dann frazier
2005-09-22 22:04       ` dann frazier
2005-12-19 21:07       ` Luck, Tony
2005-12-19 21:07         ` Luck, Tony
2006-01-10 21:21         ` dann frazier
2006-01-10 21:21           ` dann frazier
2006-01-22 19:31           ` dann frazier [this message]
2006-01-22 19:31             ` dann frazier
2005-09-02  3:37 ` ip_contrack module refuses to load Herbert Poetzl
2005-09-02  3:45 ` Luck, Tony

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=1137958281.31860.5.camel@localhost \
    --to=dannf@hp.com \
    --cc=dmosberger@gmail.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterc@gelato.unsw.edu.au \
    --cc=tony.luck@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.