On Wed, 2014-01-08 at 09:48 -0800, Olof Johansson wrote:
> > /* If it's a display, note it */
> > - memset(type, 0, sizeof(type));
> > - prom_getprop(stdout_node, "device_type", type, sizeof(type));
> > - if (strcmp(type, "display") == 0)
> > -
On Wed, Jan 08, 2014 at 03:18:26PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2014-01-08 at 15:09 +1100, Michael Ellerman wrote:
> > > Of course, main worry is that this is just hiding some latent NULL
> > deref in
> > > the kernel now... :-/
> >
> > Wow, that would have to come close to
On Wed, Jan 08, 2014 at 03:18:26PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2014-01-08 at 15:09 +1100, Michael Ellerman wrote:
Of course, main worry is that this is just hiding some latent NULL
deref in
the kernel now... :-/
Wow, that would have to come close to winning the
On Wed, 2014-01-08 at 09:48 -0800, Olof Johansson wrote:
/* If it's a display, note it */
- memset(type, 0, sizeof(type));
- prom_getprop(stdout_node, device_type, type, sizeof(type));
- if (strcmp(type, display) == 0)
- prom_setprop(stdout_node,
On Wed, 2014-01-08 at 15:09 +1100, Michael Ellerman wrote:
> > Of course, main worry is that this is just hiding some latent NULL
> deref in
> > the kernel now... :-/
>
> Wow, that would have to come close to winning the
> grossest-hack-in-arch-powerpc
> award :)
>
> Have you tried changing the
On Fri, 2014-01-03 at 00:12 -0800, Olof Johansson wrote:
> On Thu, Jan 02, 2014 at 11:56:04PM -0800, Olof Johansson wrote:
>
> > This makes things interesting though. The BE/LE trampoline code
> > assumes at least 3 consecutive instructions. What was the reasoning
> > behind entering the kernel
On Fri, 2014-01-03 at 00:12 -0800, Olof Johansson wrote:
On Thu, Jan 02, 2014 at 11:56:04PM -0800, Olof Johansson wrote:
This makes things interesting though. The BE/LE trampoline code
assumes at least 3 consecutive instructions. What was the reasoning
behind entering the kernel LE
On Wed, 2014-01-08 at 15:09 +1100, Michael Ellerman wrote:
Of course, main worry is that this is just hiding some latent NULL
deref in
the kernel now... :-/
Wow, that would have to come close to winning the
grossest-hack-in-arch-powerpc
award :)
Have you tried changing the value at 8
On Thu, Jan 02, 2014 at 11:56:04PM -0800, Olof Johansson wrote:
> This makes things interesting though. The BE/LE trampoline code
> assumes at least 3 consecutive instructions. What was the reasoning
> behind entering the kernel LE instead of keeping the old boot protocol
> and just switching to
On Thu, Jan 02, 2014 at 11:56:04PM -0800, Olof Johansson wrote:
This makes things interesting though. The BE/LE trampoline code
assumes at least 3 consecutive instructions. What was the reasoning
behind entering the kernel LE instead of keeping the old boot protocol
and just switching to LE
On Sat, Dec 28, 2013 at 1:05 PM, Olof Johansson wrote:
> Sigh, it's not this after all. I did a clean build with this applied
> and still see failures. Something else is (also?) going on here.
Ok, so after some more digging I actually think that this isn't about
the new code added as much as it
On Sat, Dec 28, 2013 at 1:05 PM, Olof Johansson o...@lixom.net wrote:
Sigh, it's not this after all. I did a clean build with this applied
and still see failures. Something else is (also?) going on here.
Ok, so after some more digging I actually think that this isn't about
the new code added
On Sat, Dec 28, 2013 at 1:01 PM, Olof Johansson wrote:
> Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') resulted in
> losing proper alignment of the spinlock variables used when booting
> secondary CPUs, causing some quite odd issues with failing to boot on
> PA Semi-based systems.
>
>
Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') resulted in
losing proper alignment of the spinlock variables used when booting
secondary CPUs, causing some quite odd issues with failing to boot on
PA Semi-based systems.
This showed itself on ppc64_defconfig, but not on pasemi_defconfig,
Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') resulted in
losing proper alignment of the spinlock variables used when booting
secondary CPUs, causing some quite odd issues with failing to boot on
PA Semi-based systems.
This showed itself on ppc64_defconfig, but not on pasemi_defconfig,
On Sat, Dec 28, 2013 at 1:01 PM, Olof Johansson o...@lixom.net wrote:
Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') resulted in
losing proper alignment of the spinlock variables used when booting
secondary CPUs, causing some quite odd issues with failing to boot on
PA Semi-based
16 matches
Mail list logo
