Closed
Bug 594160
Opened 14 years ago
Closed 7 years ago
Add SSE data to .csv files
Categories
(Socorro :: General, task)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: chofmann, Unassigned)
Details
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•14 years ago
|
||
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•14 years ago
|
||
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.
Reporter | ||
Comment 3•14 years ago
|
||
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•14 years ago
|
||
Socorro does not have that data currently.
Comment 5•14 years ago
|
||
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•14 years ago
|
||
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)
Assignee | ||
Updated•13 years ago
|
Component: Socorro → General
Product: Webtools → Socorro
Comment 7•7 years ago
|
||
This information is available from the API
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•