| Message ID | Pine.LNX.4.64.0904221537190.12401@pianoman.cluster.toy |
|---|---|
| State | Rejected |
| Delegated to: | David Miller |
| Headers | show |
From: Vince Weaver <vince@deater.net> Date: Wed, 22 Apr 2009 15:40:42 -0400 (EDT) > Add proper Niagara1 perfcounter accesses. > > When trying to track down the hang-on-boot NMI problem on my > T1 system, I noticed that Niagara2 performance counter accesses > were being done, even though I only have a Niagara1 system. > This means "undefined" bits were being written to in the > performance counter register. > > This patch does not fix the hang, but it's possibly the right thing > to do anyway. > > Signed-off-by: Vince Weaver <vince@deater.net> The code is correct as written. The way the counters are being accessed currently on Niagara1 is harmless, and works. I've tested it. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Miller <davem@davemloft.net> Date: Wed, 22 Apr 2009 23:11:03 -0700 (PDT) > From: Vince Weaver <vince@deater.net> > Date: Wed, 22 Apr 2009 15:40:42 -0400 (EDT) > >> Add proper Niagara1 perfcounter accesses. >> >> When trying to track down the hang-on-boot NMI problem on my >> T1 system, I noticed that Niagara2 performance counter accesses >> were being done, even though I only have a Niagara1 system. >> This means "undefined" bits were being written to in the >> performance counter register. Vince can you describe this problem? I'm trying to reproduce this on my t1000 with the current kernel sources and it works just fine. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Vince Weaver <vince@deater.net> Date: Fri, 24 Apr 2009 11:08:11 -0400 (EDT) > sorry, it was a false alarm. It turned out to be the prom console > issue. > It apparently triggered the NMI code and locked the system hard. > I made the mistake of using the .config from debian as a starting > point for my own kerne config. > > Current git of your tree with prom console disabled works fine on my > t1000 system. Thanks for the info. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Vince can you describe this problem? > > I'm trying to reproduce this on my t1000 with the current > kernel sources and it works just fine. sorry, it was a false alarm. It turned out to be the prom console issue. It apparently triggered the NMI code and locked the system hard. I made the mistake of using the .config from debian as a starting point for my own kerne config. Current git of your tree with prom console disabled works fine on my t1000 system. Thanks Vince -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/sparc/kernel/pcr.c b/arch/sparc/kernel/pcr.c index 1ae8cdd..bc6c67c 100644 --- a/arch/sparc/kernel/pcr.c +++ b/arch/sparc/kernel/pcr.c @@ -72,11 +72,25 @@ static void n2_pcr_write(u64 val) write_pcr(val); } +static void n1_pcr_write(u64 val) +{ + unsigned long ret; + + ret = sun4v_niagara_setperf(HV_N2_PERF_SPARC_CTL, val); + if (val != HV_EOK) + write_pcr(val); +} + static const struct pcr_ops n2_pcr_ops = { .read = direct_pcr_read, .write = n2_pcr_write, }; +static const struct pcr_ops n1_pcr_ops = { + .read = direct_pcr_read, + .write = n1_pcr_write, +}; + static unsigned long perf_hsvc_group; static unsigned long perf_hsvc_major; static unsigned long perf_hsvc_minor; @@ -126,11 +140,20 @@ int __init pcr_arch_init(void) switch (tlb_type) { case hypervisor: + switch (sun4v_chip_type) { + case SUN4V_CHIP_NIAGARA1: + pcr_ops = &n1_pcr_ops; + pcr_enable = PCR_SUN4U_ENABLE; + break; + + case SUN4V_CHIP_NIAGARA2: pcr_ops = &n2_pcr_ops; pcr_enable = PCR_N2_ENABLE; picl_shift = 2; break; - + } + break; + case cheetah: case cheetah_plus: pcr_ops = &direct_pcr_ops;
Add proper Niagara1 perfcounter accesses. When trying to track down the hang-on-boot NMI problem on my T1 system, I noticed that Niagara2 performance counter accesses were being done, even though I only have a Niagara1 system. This means "undefined" bits were being written to in the performance counter register. This patch does not fix the hang, but it's possibly the right thing to do anyway. Signed-off-by: Vince Weaver <vince@deater.net> -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html