594160 - Add SSE data to .csv files

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[chris hofmann]

need to add a 26th field to the .csv files to do some analysis on crashes related to SSE architecture of the crashing PC.  expected states for this field might be  non-sse2 or sse2 or \N

see Bug 593117 for more details.

format of the file would now look like.   we should do this for both versions of the .csv file and the SSE2 doesn't need to be sanitized in the public version of the file.

1 signature
2 url
3 uuid_url
4 client_crash_date
5 date_processed
6 last_crash
7 product
8 version
9 build
10 branch
11 os_name
12 os_version
13 cpu_name
14 address
15 bug_list
16 user_comments
17 uptime_seconds
18 email
19 adu_count
20 topmost_filenames
21 addons_checked
22 flash_version
23 hangid
24 reason
25 process_type
26 sse2_state      -> non-sse or sse or \N

Comment 1

[Jean-Marc Desperrier]

I thing it would be better to have a CPUID field (containing the CPUID identifier with 3 to 6 hex numbers) instead if the SSE2 detection is based on CPUID, or both a CPUID and a SSE2 field, if SSE2 detection is based on bit 26 of the feature flags.

It could be useful to write the code to detect features based on the feature bits. For example for MMX, bug 593117 shows some Pentium CPUID results where the CPUID stepping reported is documented nowhere, but lower stepping values are documented has having no MMX. Firefox can't run on a non MMX CPU, so it does rise suspicion that this stepping may have introduced MMX for this CPU model. The feature bits would be an easier way to tell. 
cpu-world.com also reports that the 20651 CPUID is used for both iCore 3 with SSE4 and Pentium dual core without SSE4. If it's not a wrong report, it means the CPUID is not always sufficient to identify the instruction set available.

Comment 2

[(not currently active) Ted Mielczarek]

For reference, this is what the minidump file contains:http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/common/minidump_format.h#527

That's not currently exposed to Socorro though. Right now all it gets is the cpu type and vendor string.

Comment 3

[chris hofmann]

showing some representation of:

 u_int16_t        processor_level;         /* x86: 5 = 586, 6 = 686, ... */
 u_int16_t        processor_revision;      /* x86: 0xMMSS, where MM=model,
                                             *      SS=stepping */

in the .cvs files works for me.

Comment 4

[(not currently active) Ted Mielczarek]

Socorro does not have that data currently.

Comment 5

[Jean-Marc Desperrier]

What is that cpu type info sorocco gets ?
In my opinion, showing the value of 
    u_int32_t version_information;        /* cpuid 1: eax */
whould be better than processor_level and processor_revision, because this is the raw information from which processor_level and processor_revision are calculated (that's the value that's called the CPUID value at several place like here http://www.cpu-world.com/cgi-bin/CPUID.pl ). I wouldn't be surprised if cpu type were actually the same thing.

It would be useful to show this one also for direct feature availibility checking :
    u_int32_t feature_information;        /* cpuid 1: edx */

Apparently the value of the supplemental feature_information in "cpuid 1 : ecx" is missing in the minidump. That's annoying since it's required to check support for SSE3 and above (see http://www.intel.com/Assets/PDF/manual/253666.pdf p3-210 )

Comment 6

[(not currently active) Ted Mielczarek]

Socorro currently has available exactly what you see on the 'raw dump' tab of a crash report, something like:
CPU|x86|GenuineIntel family 6 model 15 stepping 6|2

(the last field is number of CPUs)

Comment 7

[Lonnen :lonnen]

This information is available from the API