On Fri, Jun 28, 2013 at 09:11:13AM +0200, Janne Johansson wrote:
> Now the hard part is to figure out exactly where it should have been
> initialized and to what. Just setting it to 0 somewhere is not necessarily
> better.
It seems the mips64/mips64/cache_tfp.c one is a proper bug. Looking at the
caching routines for the r10k, I'd propose this (untested):
Index: cache_tfp.c
===
RCS file: /cvs/src/sys/arch/mips64/mips64/cache_tfp.c,v
retrieving revision 1.1
diff -p -u -r1.1 cache_tfp.c
--- cache_tfp.c 29 Sep 2012 21:37:03 - 1.1
+++ cache_tfp.c 28 Jun 2013 07:16:38 -
@@ -106,6 +106,7 @@ tfp_SyncCache(struct cpu_info *ci)
sr = disableintr();
va = ci->ci_l1datacachesize;
+ eva = va + ci->ci_l1instcacheset;
for (va = 0; va < eva; va += TFP_DCTW_STEP)
tfp_dctw_zero(va);
setsr(sr);
But I reckon Miod would be able to a conclusive answer here.
> 2013/6/28 Maxime Villard
>
> > Hi,
> > some other uninitialized vars found by my scanner in arch/.
> >
> > == hp300/dev/hd.c
> > At l.544, 'error' is not initialized.
> > == luna88k/luna88k/autoconf.c
> > At l.132, 'c' may be uninitialized.
> > == mips64/mips64/cache_tfp.c
> > At l.109, 'eva' is not initialized.
> > == sparc/dev/zs.c
> > At l.513, 'tmp' may be uninitialized.
> > == sparc64/dev/vdsp.c
> > At l.384, 'err' may be uninitialized. This variable should
> > be the return value of hv_ldc_tx_get_state(), see l.417.
> > == zaurus/dev/vdsp.c
> > At l.897, 'parity' is not initialized.
> >
> >
>
>
> --
> May the most significant bit of your life be positive.
--
Cheers,
Jasper
"Stay Hungry. Stay Foolish"
