Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Geert Uytterhoeven]

On Tue, 11 Nov 2008, Stephen N Chivers wrote:
> In the past few days I have attempted to get 2.6 kernels booting on my
> diskless MVME167 boards.
> I have tried several kernels, including:
> linux-image-2.6.26-1-mvme16x_2.6.26-9_m68k.deb.
> 
> None of them appear to continue beyond the initialisation code in:
> 
>       arch/m68k/kernel/head.S
> 
> They load normally via tftplilo and commence executing, apparently stopping
> with the only
> diagnostic available at the console being the magic:
> 
>       ABCGHIJK
> 
> In frustration, I compiled my own 2.6.24 kernel from clean source using a
> cross compilation
> system based on binutils-2.18 and gcc-4.1.2. The linking of vmlinux failed
> with the infamous:
> 
>       m68k-linux-gnu-ld: .tmp_vmlinux1: Not enough room for program
> headers, try linking with -N
> 
> I applied the patch for vmlinux-std.lds provided by Andreas Schwab:
> 
>        http://marc.info/?l=linux-m68k&m=120596505621019&w=2

That patch is not in the m68k tree. It also doesn't apply anymore, as we
already have a NOTES somewhere else now.

Do you still need it on e.g. 2.6.27?

> I traced the "freeze" of the kernel to the 'BUG_ON' test in
> 'm68k_setup_user_interrupt' in file
> arch/m68k/ints.c:
> 
>       BUG_ON(IRQ_USER + cnt >= NR_IRQS);
> 
> Now, for the VME boards, IRQ_USER is 8, cnt is 192 and NR_IRQS is 200. So
> this test will
> trigger the BUG_ON action, and so the kernel appears to stop without
> logging any diagnostics.

Oops, that looks like an off-by-one error.  It has been introduced by commit
69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari: Interrupt
updates").

I'll fix it.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Kars de Jong]

On di, 2008-11-11 at 11:01 +0100, Geert Uytterhoeven wrote:
> On Tue, 11 Nov 2008, Stephen N Chivers wrote:
> > In the past few days I have attempted to get 2.6 kernels booting on my
> > diskless MVME167 boards.
> > I have tried several kernels, including:
> > linux-image-2.6.26-1-mvme16x_2.6.26-9_m68k.deb.
> > 
> > I traced the "freeze" of the kernel to the 'BUG_ON' test in
> > 'm68k_setup_user_interrupt' in file
> > arch/m68k/ints.c:
> > 
> >       BUG_ON(IRQ_USER + cnt >= NR_IRQS);
> > 
> > Now, for the VME boards, IRQ_USER is 8, cnt is 192 and NR_IRQS is 200. So
> > this test will
> > trigger the BUG_ON action, and so the kernel appears to stop without
> > logging any diagnostics.
> 
> Oops, that looks like an off-by-one error.  It has been introduced by commit
> 69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari: Interrupt
> updates").

Hm, no fair! I already reported this bug back in 2006, asking for
feedback:

http://www.nabble.com/Re%3A-CVS-Update%3A-linux-tt6999670.html

... but I never got any ;)

By the way, I tested Linus' HEAD today (with your quilt patches, Geert)
on my MVME167, it only needed the above fixed and it booted.

I couldn't compile it with my old cross compiler (gcc version 4.1.3
20080623 (prerelease) (Debian 4.1.2-23)), it ICEed somewhere in
net/sunrpc. 

The new cross compiler I built after that (gcc version 4.3.2 (Debian
4.3.2-1)) had no problems with it.


Kind regards, Kars.

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Geert Uytterhoeven]

On Thu, 13 Nov 2008, Kars de Jong wrote:
> On di, 2008-11-11 at 11:01 +0100, Geert Uytterhoeven wrote:
> > On Tue, 11 Nov 2008, Stephen N Chivers wrote:
> > > In the past few days I have attempted to get 2.6 kernels booting on my
> > > diskless MVME167 boards.
> > > I have tried several kernels, including:
> > > linux-image-2.6.26-1-mvme16x_2.6.26-9_m68k.deb.
> > > 
> > > I traced the "freeze" of the kernel to the 'BUG_ON' test in
> > > 'm68k_setup_user_interrupt' in file
> > > arch/m68k/ints.c:
> > > 
> > >       BUG_ON(IRQ_USER + cnt >= NR_IRQS);
> > > 
> > > Now, for the VME boards, IRQ_USER is 8, cnt is 192 and NR_IRQS is 200. So
> > > this test will
> > > trigger the BUG_ON action, and so the kernel appears to stop without
> > > logging any diagnostics.
> > 
> > Oops, that looks like an off-by-one error.  It has been introduced by commit
> > 69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari: Interrupt
> > updates").
> 
> Hm, no fair! I already reported this bug back in 2006, asking for
> feedback:
> 
> http://www.nabble.com/Re%3A-CVS-Update%3A-linux-tt6999670.html
> 
> ... but I never got any ;)

Bummer...

> By the way, I tested Linus' HEAD today (with your quilt patches, Geert)
> on my MVME167, it only needed the above fixed and it booted.

OK. Can I add your Tested-by? Then I'll forward it to Linus ASAP.

> I couldn't compile it with my old cross compiler (gcc version 4.1.3
> 20080623 (prerelease) (Debian 4.1.2-23)), it ICEed somewhere in
> net/sunrpc. 

Too bad... Still at 4.1.2...

> The new cross compiler I built after that (gcc version 4.3.2 (Debian
> 4.3.2-1)) had no problems with it.

Good!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Kars de Jong]

On do, 2008-11-13 at 22:48 +0100, Geert Uytterhoeven wrote:
> On Thu, 13 Nov 2008, Kars de Jong wrote:
> > On di, 2008-11-11 at 11:01 +0100, Geert Uytterhoeven wrote:
> > > On Tue, 11 Nov 2008, Stephen N Chivers wrote:
> > > > In the past few days I have attempted to get 2.6 kernels booting on my
> > > > diskless MVME167 boards.
> > > > I have tried several kernels, including:
> > > > linux-image-2.6.26-1-mvme16x_2.6.26-9_m68k.deb.
> > > > 
> > > > I traced the "freeze" of the kernel to the 'BUG_ON' test in
> > > > 'm68k_setup_user_interrupt' in file
> > > > arch/m68k/ints.c:
> > > > 
> > > >       BUG_ON(IRQ_USER + cnt >= NR_IRQS);
> > > > 
> > > > Now, for the VME boards, IRQ_USER is 8, cnt is 192 and NR_IRQS is 200. So
> > > > this test will
> > > > trigger the BUG_ON action, and so the kernel appears to stop without
> > > > logging any diagnostics.
> > > 
> > > Oops, that looks like an off-by-one error.  It has been introduced by commit
> > > 69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari: Interrupt
> > > updates").
> > 
> > Hm, no fair! I already reported this bug back in 2006, asking for
> > feedback:
> > 
> > http://www.nabble.com/Re%3A-CVS-Update%3A-linux-tt6999670.html
> > 
> > ... but I never got any ;)
> 
> Bummer...
> 
> > By the way, I tested Linus' HEAD today (with your quilt patches, Geert)
> > on my MVME167, it only needed the above fixed and it booted.
> 
> OK. Can I add your Tested-by? Then I'll forward it to Linus ASAP.

Yes, no problem, if your patch would look something like this (I like
git already!):

diff --git a/arch/m68k/kernel/ints.c b/arch/m68k/kernel/ints.c
index 7e8a0d3..761ee04 100644
--- a/arch/m68k/kernel/ints.c
+++ b/arch/m68k/kernel/ints.c
@@ -133,7 +133,7 @@ void __init m68k_setup_user_interrupt(unsigned int vec, unsigned int cnt,
 {
        int i;
 
-       BUG_ON(IRQ_USER + cnt >= NR_IRQS);
+       BUG_ON(IRQ_USER + cnt > NR_IRQS);
        m68k_first_user_vec = vec;
        for (i = 0; i < cnt; i++)
                irq_controller[IRQ_USER + i] = &user_irq_controller;

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Geert Uytterhoeven]

On Thu, 13 Nov 2008, Kars de Jong wrote:
> On do, 2008-11-13 at 22:48 +0100, Geert Uytterhoeven wrote:
> > On Thu, 13 Nov 2008, Kars de Jong wrote:
> > > On di, 2008-11-11 at 11:01 +0100, Geert Uytterhoeven wrote:
> > > > On Tue, 11 Nov 2008, Stephen N Chivers wrote:
> > > > > In the past few days I have attempted to get 2.6 kernels booting on my
> > > > > diskless MVME167 boards.
> > > > > I have tried several kernels, including:
> > > > > linux-image-2.6.26-1-mvme16x_2.6.26-9_m68k.deb.
> > > > > 
> > > > > I traced the "freeze" of the kernel to the 'BUG_ON' test in
> > > > > 'm68k_setup_user_interrupt' in file
> > > > > arch/m68k/ints.c:
> > > > > 
> > > > >       BUG_ON(IRQ_USER + cnt >= NR_IRQS);
> > > > > 
> > > > > Now, for the VME boards, IRQ_USER is 8, cnt is 192 and NR_IRQS is 200. So
> > > > > this test will
> > > > > trigger the BUG_ON action, and so the kernel appears to stop without
> > > > > logging any diagnostics.
> > > > 
> > > > Oops, that looks like an off-by-one error.  It has been introduced by commit
> > > > 69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari: Interrupt
> > > > updates").
> > > 
> > > Hm, no fair! I already reported this bug back in 2006, asking for
> > > feedback:
> > > 
> > > http://www.nabble.com/Re%3A-CVS-Update%3A-linux-tt6999670.html
> > > 
> > > ... but I never got any ;)
> > 
> > Bummer...
> > 
> > > By the way, I tested Linus' HEAD today (with your quilt patches, Geert)
> > > on my MVME167, it only needed the above fixed and it booted.
> > 
> > OK. Can I add your Tested-by? Then I'll forward it to Linus ASAP.
> 
> Yes, no problem, if your patch would look something like this (I like

Yes it does.

> git already!):

Good!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Finn Thain]

On Thu, 13 Nov 2008, Kars de Jong wrote:

...
> 
> I couldn't compile it with my old cross compiler (gcc version 4.1.3 
> 20080623 (prerelease) (Debian 4.1.2-23)), it ICEed somewhere in 
> net/sunrpc.

I don't suppose that you still have the error message? (I think I've seen 
that compiler fail like PR 29826 which has a patch in the gcc bugzilla.)

Finn

> The new cross compiler I built after that (gcc version 4.3.2 (Debian
> 4.3.2-1)) had no problems with it.
> 
> 
> Kind regards, Kars.
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 817 bytes --]



On Fri, 14 Nov 2008, Kars de Jong wrote:

> Preprocessed source stored into /tmp/ccgSA9Qa.out file, please attach this to your bugreport.
> make[1]: *** [net/sunrpc/xdr.o] Error 1
> make: *** [_module_net/sunrpc] Error 2
> 
> I have attached the preprocessed source.

It works for me...

pismo:/tmp$ m68k-linux-gnu-gcc -c ccgSA9Qa.c 
pismo:/tmp$ m68k-linux-gnu-gcc --version
m68k-linux-gnu-gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But the version is misleading because I've added and removed patches.
I'll build another one and try and reproduce the bug.

Finn


> 
> Kind regards,
> 
> Kars.
> 
> 

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1665 bytes --]

--- gcc-4.0.3/gcc/cse.c
+++ gcc-4_1-branch/gcc/cse.c
@@ -5513,6 +5513,22 @@
 	      break;
 	    }
 
+	  /* Reject certain invalid forms of CONST that we create.  */
+	  else if (CONSTANT_P (trial)
+		   && GET_CODE (trial) == CONST
+		   /* Reject cases that will cause decode_rtx_const to
+		      die.  On the alpha when simplifying a switch, we
+		      get (const (truncate (minus (label_ref)
+		      (label_ref)))).  */
+		   && (GET_CODE (XEXP (trial, 0)) == TRUNCATE
+		       /* Likewise on IA-64, except without the
+			  truncate.  */
+		       || (GET_CODE (XEXP (trial, 0)) == MINUS
+			   && GET_CODE (XEXP (XEXP (trial, 0), 0)) == LABEL_REF
+			   && GET_CODE (XEXP (XEXP (trial, 0), 1)) == LABEL_REF)))
+	    /* Do nothing for this case.  */
+	    ;
+
 	  /* Look for a substitution that makes a valid insn.  */
 	  else if (validate_change (insn, &SET_SRC (sets[i].rtl), trial, 0))
 	    {
@@ -5548,16 +5555,6 @@
 
 	  else if (constant_pool_entries_cost
 		   && CONSTANT_P (trial)
-		   /* Reject cases that will abort in decode_rtx_const.
-		      On the alpha when simplifying a switch, we get
-		      (const (truncate (minus (label_ref) (label_ref)))).  */
-		   && ! (GET_CODE (trial) == CONST
-			 && GET_CODE (XEXP (trial, 0)) == TRUNCATE)
-		   /* Likewise on IA-64, except without the truncate.  */
-		   && ! (GET_CODE (trial) == CONST
-			 && GET_CODE (XEXP (trial, 0)) == MINUS
-			 && GET_CODE (XEXP (XEXP (trial, 0), 0)) == LABEL_REF
-			 && GET_CODE (XEXP (XEXP (trial, 0), 1)) == LABEL_REF)
 		   && (src_folded == 0
 		       || (!MEM_P (src_folded)
 			   && ! src_folded_force_flag))

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Finn Thain]

On Fri, 14 Nov 2008, I wrote:

> 
> It works for me...
> 

Oops. I didn't use any optimisation. It fails here too.

Finn

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Stephen N Chivers]

On Friday 14/11/2008, Kars de Jong wrote:

>By the way, I tested Linus' HEAD today (with your quilt patches, Geert)
>on my MVME167, it only needed the above fixed and it booted.
>
>I couldn't compile it with my old cross compiler (gcc version 4.1.3
>20080623 (prerelease) (Debian 4.1.2-23)), it ICEed somewhere in
>net/sunrpc.
That is also where my attempts to cross compile 2.6.27 failed.
>
>The new cross compiler I built after that (gcc version 4.3.2 (Debian
>4.3.2-1)) had no problems with it.

Stephen Chivers,
CSC Australia, Pty. Ltd.

Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Stephen N Chivers]

On Tue, 11 Nov 2008, Geert Uytterhoeven wrote:
   >On Tue, 11 Nov 2008, Stephen N Chivers wrote:
   >> In the past few days I have attempted to get 2.6 kernels booting on
   my
   >> diskless MVME167 boards.
   >> I have tried several kernels, including:
   >> linux-image-2.6.26-1-mvme16x_2.6.26-9_m68k.deb.
   >>
   >> None of them appear to continue beyond the initialisation code in:
   >>
   >>       arch/m68k/kernel/head.S
   >>
   >> They load normally via tftplilo and commence executing, apparently
   stopping
   >> with the only
   >> diagnostic available at the console being the magic:
   >>
   >>       ABCGHIJK
   >>
   >> In frustration, I compiled my own 2.6.24 kernel from clean source
   using a
   >> cross compilation
   >> system based on binutils-2.18 and gcc-4.1.2. The linking of vmlinux
   failed
   >> with the infamous:
   >>
   >>       m68k-linux-gnu-ld: .tmp_vmlinux1: Not enough room for program
   >> headers, try linking with -N
   >>
   >> I applied the patch for vmlinux-std.lds provided by Andreas Schwab:
   >>
   >>        http://marc.info/?l=linux-m68k&m=120596505621019&w=2
   >>
   >That patch is not in the m68k tree. It also doesn't apply anymore, as
   we
   >already have a NOTES somewhere else now.
   >
   >Do you still need it on e.g. 2.6.27?
   >
   Thanks, but no. I had found that the NOTES section was in a later
   kernel version. I use 2.6.24 here as it is my 'configuration baseline'
   for
   x86 and ppc. I have a number of MVME5110 PPC boards running 2.6 kernels
   in VME racks as well as the MVME167. I have tried compiling 2.6.27 but
   it failed with my toolchain.
   >> I traced the "freeze" of the kernel to the 'BUG_ON' test in
   >> 'm68k_setup_user_interrupt' in file
   >> arch/m68k/ints.c:
   >>
   >>       BUG_ON(IRQ_USER + cnt >= NR_IRQS);
   >>
   >> Now, for the VME boards, IRQ_USER is 8, cnt is 192 and NR_IRQS is
   200. So
   >> this test will
   >> trigger the BUG_ON action, and so the kernel appears to stop without
   >> logging any diagnostics.
   >>
   >Oops, that looks like an off-by-one error.  It has been introduced by
   commit
   >69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari:
   Interrupt
   >updates").
   >
   >I'll fix it.
   Yes, please, I would appreciate it. I am not comfortable with
   submitting patches to the kernel and feel that it is better left
   to those with more experience.
   >
   >Gr{oetje,eeting}s

   Stephen Chivers,
   CSC  Australia, Pty. Ltd.