Date: Tue, 16 Mar 1999 20:25:26 -0800 (PST) From: aron@cs.rice.edu To: freebsd-gnats-submit@freebsd.org Subject: i386/10632: bug in driver that implements performance monitoring code Message-ID: <19990317042526.A5EE614C1A@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 10632 >Category: i386 >Synopsis: bug in driver that implements performance monitoring code >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 16 20:30:01 PST 1999 >Closed-Date: >Last-Modified: >Originator: Mohit Aron >Release: 3.1 >Organization: Rice University >Environment: FreeBSD fxp1.cs.rice.edu 3.1-STABLE FreeBSD 3.1-STABLE #1: Tue Mar 9 17:51:16 CST 1999 alc@nonpc.cs.rice.edu:/usr/src/sys/compile/NONPC.fxp.elf i386 >Description: The file /sys/i386/i386/perfmon.c contains a bug that causes incorrect operation while using the /dev/perfmon device. The problem is that the Intel Pentium Pro's performance counters are 40 bits wide. The Intel manuals specifically say that reading the counters using the rdmsr instruction returns a 64 bit value of which the higher 24 bits are undefined. The code that reads the counters should then clear the high 24 bits itself. The code in /sys/i386/i386/perfmon.c doesn't do this and so the application programs using the /dev/perfmon device can get incorrect values of the counters. >How-To-Repeat: Here's a sample output of the program /usr/share/examples/perfmon (this particular example uses the Pentium Pro's performance counters to measure the floating point operations per second): % perfmon -u -e -l 1 -s 1 193 1: 89060441849857 total: 89060441849857.000000 mean: 89060441849857.000000 clocks (at 166-MHz): 167087839 Notice the large resulting values despite the fact that there were no floating point operations being executed on the machine. >Fix: The fix is pretty simple. There are two places in /sys/i386/i386/perfmon.c where the rdmsr instruction is used. At both these places, the high order 24 bits should be cleared before making any further use of the value. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990317042526.A5EE614C1A>