v3.5-rc1 ARM PXA possible regression

v3.5-rc1 ARM PXA possible regression

[Andrew Lunn]

Hi Paul

I've got the same problem on my kirkwood based QNAP NAS box.

I bisected it, and the problem patch for me is:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7ff9554bb578ba02166071d2d487b7fc7d860d62

printk: convert byte-buffer to variable-length record buffer

I've not looked further, so i've no idea why this is causing problems.

     Andrew

v3.5-rc1 ARM PXA possible regression

[Arnaud Patard (Rtp)]

Andrew Lunn <andrew@lunn.ch> writes:

> Hi Paul

Hi,

>
> I've got the same problem on my kirkwood based QNAP NAS box.
>
> I bisected it, and the problem patch for me is:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7ff9554bb578ba02166071d2d487b7fc7d860d62
>
> printk: convert byte-buffer to variable-length record buffer
>
> I've not looked further, so i've no idea why this is causing problems.

There has been discussions here about that iirc. I don't know when a
proper fix will be merged but one *very* *ugly* workaround is:

--- linux.orig/kernel/printk.c  2012-06-03 15:26:20.000000000 +0200
+++ linux/kernel/printk.c       2012-06-03 16:41:24.000000000 +0200
@@ -228,7 +228,7 @@ static u32 clear_idx;
 
 /* record buffer */
 #if !defined(CONFIG_64BIT) || defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
-#define LOG_ALIGN 4
+#define LOG_ALIGN 8
 #else
 #define LOG_ALIGN 8
 #endif


At least it seems to work here.

Arnaud

v3.5-rc1 ARM PXA possible regression

[Paul Parsons]

Hello Andrew and Arnaud,

Yes, that fixed it! I now see kernel messages on the screen.

Thank you for your help.

Regards,
Paul

--- On Mon, 4/6/12, Arnaud Patard <arnaud.patard@rtp-net.org> wrote:
> Andrew Lunn <andrew@lunn.ch>
> writes:
> 
> > Hi Paul
> 
> Hi,
> 
> >
> > I've got the same problem on my kirkwood based QNAP NAS
> box.
> >
> > I bisected it, and the problem patch for me is:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7ff9554bb578ba02166071d2d487b7fc7d860d62
> >
> > printk: convert byte-buffer to variable-length record
> buffer
> >
> > I've not looked further, so i've no idea why this is
> causing problems.
> 
> There has been discussions here about that iirc. I don't
> know when a
> proper fix will be merged but one *very* *ugly* workaround
> is:
> 
> --- linux.orig/kernel/printk.c? 2012-06-03
> 15:26:20.000000000 +0200
> +++ linux/kernel/printk.c? ?
> ???2012-06-03 16:41:24.000000000 +0200
> @@ -228,7 +228,7 @@ static u32 clear_idx;
>  
>  /* record buffer */
>  #if !defined(CONFIG_64BIT) ||
> defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> -#define LOG_ALIGN 4
> +#define LOG_ALIGN 8
>  #else
>  #define LOG_ALIGN 8
>  #endif
> 
> 
> At least it seems to work here.
> 
> Arnaud

v3.5-rc1 ARM PXA possible regression

[Simon Baatz]

Hi Arnaud,

Am 04.06.2012 16:15, schrieb Arnaud Patard (Rtp):
> There has been discussions here about that iirc. I don't know when a
> proper fix will be merged but one *very* *ugly* workaround is:
>
> --- linux.orig/kernel/printk.c  2012-06-03 15:26:20.000000000 +0200
> +++ linux/kernel/printk.c       2012-06-03 16:41:24.000000000 +0200
> @@ -228,7 +228,7 @@ static u32 clear_idx;
>  
>  /* record buffer */
>  #if !defined(CONFIG_64BIT) || defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> -#define LOG_ALIGN 4
> +#define LOG_ALIGN 8
>  #else
>  #define LOG_ALIGN 8
>  #endif
>
>
> At least it seems to work here.

Yes, a thread discussing this is at
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101783.html
, which did not really come to a conclusion, but proposed the following
fix (the original proposal used "struct log_buf", but it should be
"struct log" I suppose):

/#define LOG_ALIGN (__alignof__(struct log))

/which works for me on kirkwood (but apparently may waste a couple of bytes on other architectures)


- Simon

v3.5-rc1 ARM PXA possible regression

[Paul Parsons]

Linux 3.5.0-rc1 hangs on boot on my hx4700.

Unfortunately it hangs before the kernel initializes the
screen; since I possess no serial cable I cannot see the
kernel messages.

Linux 3.4.0 boots OK.

Before I start bisecting is there an obvious change
between v3.4 and v3.5-rc1 that I could be investigating?
Since the screen is not initialized I suspect - but
cannot prove - that the kernel hangs before the hx4700
platform code is reached.

v3.5-rc1 ARM PXA possible regression

[Eric Miao]

Hi Paul,

There seems to be one other thread talking exactly about this,
possibly due to the change to printk(), and I believe it's not affecting
PXA only, but several other architectures as well.

On Mon, Jun 4, 2012 at 8:35 PM, Paul Parsons <lost.distance@yahoo.com> wrote:
> Linux 3.5.0-rc1 hangs on boot on my hx4700.
>
> Unfortunately it hangs before the kernel initializes the
> screen; since I possess no serial cable I cannot see the
> kernel messages.
>
> Linux 3.4.0 boots OK.
>
> Before I start bisecting is there an obvious change
> between v3.4 and v3.5-rc1 that I could be investigating?
> Since the screen is not initialized I suspect - but
> cannot prove - that the kernel hangs before the hx4700
> platform code is reached.
>