Re: Status update on sparc32 genirq support

[Bob Breuer <breuerr@mc.net>]

Marcel van Nies wrote:
> Hi,
> 
> git bisect came up with this:
> 
> 4d14a459857bd151ecbd14bcd37b4628da00792b is the first bad commit
> commit 4d14a459857bd151ecbd14bcd37b4628da00792b
> Author: David S. Miller <davem@davemloft.net>
> Date:   Thu Dec 10 23:32:10 2009 -0800
> 
>     sparc: Stop trying to be so fancy and use __builtin_{memcpy,memset}()
> 
>     This mirrors commit ff60fab71bb3b4fdbf8caf57ff3739ffd0887396
>     (x86: Use __builtin_memset and __builtin_memcpy for memset/memcpy)
> 
>     Signed-off-by: David S. Miller <davem@davemloft.net>


My guess is that we're no longer using the special hyperSparc block copy
and fill from mm/hypersparc.S and are now leaving some data in the cache
that wasn't there before.

Unfortunately, my hyperSparc is failing from a completely different commit:
commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
Author: Ollie Wild <aaw@google.com>
Date:   Thu Jul 19 01:48:16 2007 -0700

    mm: variable length argument support


The result I have is that the argv array for new commands looks
completely empty leading to this strange output when booting:

Freeing unused kernel memory: 144k freed
modprobe: FATAL: Module  not found.

INIT: version 2.86 booting
: : No such file or directory
INIT: Entering runlevel: 3
: : No such file or directory


There must be a missing cache flush somewhere in there that's needed for
the argv array...

Bob