headers
Valerie Henson | 1 Aug 05:10
Picon

Re: [parisc-linux] [git patches] tulip fixes from parisc-linux

On Sun, Jul 30, 2006 at 02:54:56PM -0400, Kyle McMartin wrote:
> On Sun, Jul 30, 2006 at 11:35:32AM -0700, Andrew Morton wrote:
> > hm.  A couple of those patches have been futzing around in -mm for over a
> > year and have been nacked by Jeff and are a regular source of grumpygrams. 
> > I've been sitting on them in the pathetic hope that someone will one day
> > get down and address the bugs which they fix in an acceptable fashion,
> > whatever that is.
> > 
> 
> Jeff/Val seemed willing to merge the fixes as they stood. parisc-linux
> merged Francois' tulip workqueue patch some time ago, and have been
> running with it since without issue. This defers the tulip_select_media
> work to process context, and so should be less of an issue.

Hey Kyle,

Thanks for splitting these out.  Could you do us a favor and post the
patches themselves?  I'm not the only one who doesn't use git, and it
will be a lot less confusing if we can directly ack the patches in
email instead of referring to them third-hand.  Thanks,

-VAL
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Matthew Wilcox | 14 Aug 14:07

stack-protect in conflict with CROSS_COMPILE


Hi Sam,

We've stumbled on a problem with -fno-stack-protector and CROSS_COMPILE:

CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                   -fno-strict-aliasing -fno-common
# Force gcc to behave correct even for buggy distributions
CFLAGS          += $(call cc-option, -fno-stack-protector)

round about line 310 of Makefile will cause CC to be called before we
get a chance to set CROSS_COMPILE in arch/parisc/Makefile.  For people
who are compiling 64-bit parisc kernels, this means the wrong gcc gets
called, and sometimes the compiler versions are out of sync.

We will have similar problems with:

CFLAGS          += -fno-omit-frame-pointer $(call cc-option,-fno-optimize-sibling-calls,)

Should we include the arch Makefile earlier in the proceedings?
Permalink | Reply | 0 comments |
headers
Ralf Baechle | 14 Aug 16:14
Favicon

Re: stack-protect in conflict with CROSS_COMPILE

On Mon, Aug 14, 2006 at 06:07:29AM -0600, Matthew Wilcox wrote:

> Hi Sam,
> 
> We've stumbled on a problem with -fno-stack-protector and CROSS_COMPILE:
> 
> CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>                    -fno-strict-aliasing -fno-common
> # Force gcc to behave correct even for buggy distributions
> CFLAGS          += $(call cc-option, -fno-stack-protector)
> 
> round about line 310 of Makefile will cause CC to be called before we
> get a chance to set CROSS_COMPILE in arch/parisc/Makefile.  For people
> who are compiling 64-bit parisc kernels, this means the wrong gcc gets
> called, and sometimes the compiler versions are out of sync.
> 
> We will have similar problems with:
> 
> CFLAGS          += -fno-omit-frame-pointer $(call cc-option,-fno-optimize-sibling-calls,)
> 
> Should we include the arch Makefile earlier in the proceedings?

The -fno-stack-protector issue also affects MIPS.

  Ralf
Permalink | Reply | 0 comments |
headers
Adrian Bunk | 19 Aug 19:19
Picon
Favicon

[2.6 patch] parisc: "extern inline" -> "static inline"

"extern inline" generates a warning with -Wmissing-prototypes and I'm 
currently working on getting the kernel cleaned up for adding this to 
the CFLAGS since it will help us to avoid a nasty class of runtime 
errors.

If there are places that really need a forced inline, __always_inline 
would be the correct solution.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---

 arch/parisc/lib/memcpy.c       |    4 +--
 include/asm-parisc/io.h        |    2 -
 include/asm-parisc/pci.h       |    2 -
 include/asm-parisc/pgtable.h   |   40 ++++++++++++++++-----------------
 include/asm-parisc/prefetch.h  |    4 +--
 include/asm-parisc/semaphore.h |   10 ++++----
 include/asm-parisc/tlbflush.h  |    3 --
 7 files changed, 32 insertions(+), 33 deletions(-)

--- linux-2.6.14-rc5-mm1-full/arch/parisc/lib/memcpy.c.old	2005-10-30 01:58:43.000000000 +0200
+++ linux-2.6.14-rc5-mm1-full/arch/parisc/lib/memcpy.c	2005-10-30 01:59:11.000000000 +0200
@@ -158,12 +158,12 @@
 #define stw(_s,_t,_o,_a,_e) 	def_store_insn(stw,"r",_s,_t,_o,_a,_e)

 #ifdef  CONFIG_PREFETCH
-extern inline void prefetch_src(const void *addr)
+static inline void prefetch_src(const void *addr)
 {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian Bunk | 19 Aug 19:19
Picon
Favicon

[2.6 patch] arch/parisc/Makefile: remove GCC_VERSION

This patch removes the usage of GCC_VERSION from arch/parisc/Makefile.

There are no functional changes, it simply makes it a bit shorter (and 
removes the last instance of GCC_VERSION in the kernel).

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>
Acked-by: Kyle McMartin <kyle <at> mcmartin.ca>

---

This patch was already sent on:
- 12 Jan 2006

--- linux-2.6.15-mm3-hppa/arch/parisc/Makefile.old	2006-01-12 03:11:45.000000000 +0100
+++ linux-2.6.15-mm3-hppa/arch/parisc/Makefile	2006-01-12 03:12:35.000000000 +0100
@@ -35,12 +35,8 @@

 OBJCOPY_FLAGS =-O binary -R .note -R .comment -S

-GCC_VERSION     := $(call cc-version)
-ifneq ($(shell if [ -z $(GCC_VERSION) ] ; then echo "bad"; fi ;),)
-$(error Sorry, couldn't find ($(cc-version)).)
-endif
-ifneq ($(shell if [ $(GCC_VERSION) -lt 0303 ] ; then echo "bad"; fi ;),)
-$(error Sorry, your compiler is too old ($(GCC_VERSION)).  GCC v3.3 or above is required.)
+ifneq ($(shell if [ $(call cc-version) -lt 0303 ] ; then echo "bad"; fi ;),)
+$(error Sorry, your compiler is too old.  GCC v3.3 or above is required.)
 endif

 cflags-y	:= -pipe
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyle McMartin | 21 Aug 16:42
Picon

Re: [parisc-linux] [2.6 patch] parisc: "extern inline" -> "static inline"

On Sat, Aug 19, 2006 at 07:19:30PM +0200, Adrian Bunk wrote:
> If there are places that really need a forced inline, __always_inline 
> would be the correct solution.
> 

ACK, Ok.

> Signed-off-by: Adrian Bunk <bunk <at> stusta.de>
> 

Acked-by: Kyle McMartin <kyle <at> parisc-linux.org>
Permalink | Reply | 0 comments |
headers
Matthias Klose | 23 Aug 10:39
Picon

Bug#342545: qt-x11-free FTBFS

The qt-x11-free package builds fine with a standard Debian setup.
Building with prctl --unaligned=signal makes the "bug" reproducible.

Christopher Martin writes:
> reassign 342545 libgcc2
> stop
> 
> On Thursday 10 August 2006 00:25, Steve Langasek wrote:
> > It hasn't been, because I can't see any way that libglu1-mesa could
> > have anything to do with the failure in question.  libglu1-mesa
> > should not be a dependency of the tool that's failing with SIGBUS in
> > the build log.
> >
> > I would suggest that someone should investigate this further and get
> > a clear answer on the nature of the bug, because I really don't buy
> > that libgcc skew is to blame.
> 
> Fair enough, but before I take off for the weekend, I'm sending this 
> report back to libgcc2, since it seems to have been established long 
> ago that this isn't a Qt bug, and it really should be assigned to 
> something in the toolchain. I note that, for a time, the problem was 
> thought to be in glibc, so perhaps the glibc team would again be worth 
> consulting.
> 
> Cheers,
> Christopher Martin
Permalink | Reply | 0 comments |
headers
Kyle McMartin | 23 Aug 13:52
Picon
Favicon

Re: Bug#342545: qt-x11-free FTBFS

On Wed, Aug 23, 2006 at 10:39:04AM +0200, Matthias Klose wrote:
> The qt-x11-free package builds fine with a standard Debian setup.
> Building with prctl --unaligned=signal makes the "bug" reproducible.
> 

Right. The buildd is set up to deliver SIGBUS on unaligned accesses.
This is configurable, and not the default kernel behaviour. It is,
however, a Good Thing(tm). Unaligned accesses are quite costly, so
catching and fixing them on the buildd is ideal. However, in most cases
they are nontrivial to fix and should be rebuilt and uploaded and a 
bug filed with upstream...

When I initially added prctl for parisc, iirc there were three options
logging an unaligned access, delivering a SIGBUS, or silently catching
it and continuing on.

I have a machine that can be used to do these rebuilds, if need be.

Cheers,
	Kyle
Permalink | Reply | 0 comments |
headers
Steve Langasek | 24 Aug 02:22
Picon
Favicon

Re: Bug#342545: qt-x11-free FTBFS

reassign 342545 qt-x11-free
thanks

On Wed, Aug 23, 2006 at 07:52:48AM -0400, Kyle McMartin wrote:
> On Wed, Aug 23, 2006 at 10:39:04AM +0200, Matthias Klose wrote:
> > The qt-x11-free package builds fine with a standard Debian setup.
> > Building with prctl --unaligned=signal makes the "bug" reproducible.

> Right. The buildd is set up to deliver SIGBUS on unaligned accesses.
> This is configurable, and not the default kernel behaviour. It is,
> however, a Good Thing(tm). Unaligned accesses are quite costly, so
> catching and fixing them on the buildd is ideal. However, in most cases
> they are nontrivial to fix and should be rebuilt and uploaded and a 
> bug filed with upstream...

> When I initially added prctl for parisc, iirc there were three options
> logging an unaligned access, delivering a SIGBUS, or silently catching
> it and continuing on.

> I have a machine that can be used to do these rebuilds, if need be.

That would be wonderful if you, or another hppa porter, could track down
where the bug lies.  libgcc2 is almost certainly the wrong package, since
nothing should be *using* libgcc2 in a fresh build of qt-x11-free; it may be
a bug in libgcc4 instead, but I think that's yet to be determined.  In the
meantime, I think it's best to reassign this back to qt-x11-free.

Thanks,
--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyle McMartin | 24 Aug 02:28
Picon
Favicon

Re: Bug#342545: qt-x11-free FTBFS

On Wed, Aug 23, 2006 at 05:22:45PM -0700, Steve Langasek wrote:
> That would be wonderful if you, or another hppa porter, could track down
> where the bug lies.  libgcc2 is almost certainly the wrong package, since
> nothing should be *using* libgcc2 in a fresh build of qt-x11-free; it may be
> a bug in libgcc4 instead, but I think that's yet to be determined.  In the
> meantime, I think it's best to reassign this back to qt-x11-free.
> 

Agreed, probably the best course of action. I'll kick off a build in my
sid chroot with prctl set to dump core and we'll see what happens.

Cheers,
	Kyle
Permalink | Reply | 0 comments |

Gmane