[hdt] [patch] ~420 seconds in cpu_detect
Jim Cromie
jim.cromie at gmail.com
Sat Apr 2 14:30:33 PDT 2011
playing with hdt on a soekris 4801,
Im getting HUGE delays in cpu_detect.
I added some timing code, heres what Im seeing
ACPI: Detecting
0 mS in detect_acpi
MEMORY: Detecting
0 mS in detect_memory
DMI: Detecting Table
DMI: ERROR ! Table not found !
DMI: Many hardware components will not be detected !
55 mS in detect_dmi
CPU: Detecting
0 mS in get_cpu_vendor
0 mS in "intel cpu level check"
0 mS in "amd cpu check"
0 mS in "core check"
0 mS in detect_cache
0 mS in generic_identify
sizeof(cpu->vendor): 48
sizeof(cpu->model): 48
0 mS in "family-vendor-model-stepping"
416445 mS in "family-vendor strings"
416445 mS in "cores-cachesizes"
416445 mS in set_generic_info
416445 mS in set_cpu_flags
416500 mS in cpu_detect
DISKS: Detecting
416500 mS in detect_disks
VPD: Detecting
416555 mS in detect_vpd
PCI: 11 devices detected
PCI: Resolving names
PCI: Resolving class names
PCI: Resolving module names
PCI: 11 Devices Found
418258 mS in detect_pci
PXE: Detecting
418258 mS in detect_pxe
VESA: Detecting
418312 mS in detect_vesa
done hardware detection, hit any key to resume
turns out the problem was missing NSC data in cpuid.c,
added in attached patch.
Also reattaching previous patch, with more commit-message
BTW, is there any interest in the timing code I used ?
its slightly crufty, esp wrt nested timings, but could be cleaned up.
OTOH, its trivial, and perhaps unlikely to be used again.
the problem manifested in the commented out statement.
its also worth noting that when offending code is restored,
I get this value out
Vendor : ����������������������������������
with replacement code:
strlcpy(cpu->model, c->x86_vendor_id, sizeof(cpu->vendor));
I get ""
void set_generic_info(struct cpuinfo_x86 *c, s_cpu * cpu)
{
clock_t et = times(NULL);
printf("sizeof(cpu->vendor): %d\n", sizeof(cpu->vendor));
printf("sizeof(cpu->model): %d\n", sizeof(cpu->model));
cpu->family = c->x86;
cpu->vendor_id = c->x86_vendor;
cpu->model_id = c->x86_model;
cpu->stepping = c->x86_mask;
print_timer(et, "family-vendor-model-stepping");
/* THIS TAKES 420 seconds
it blows up cuz c->x86_vendor is 255, > X86_VENDOR_NUM,
so code is overrunning memory - lucky result wasnt more severe.
strlcpy(cpu->vendor, cpu_devs[c->x86_vendor]->c_vendor,
sizeof(cpu->vendor));
*/
strlcpy(cpu->model, c->x86_vendor_id, sizeof(cpu->vendor));
strlcpy(cpu->model, c->x86_model_id, sizeof(cpu->model));
print_timer(et, "family-vendor strings");
cpu->num_cores = c->x86_num_cores;
cpu->l1_data_cache_size = c->x86_l1_data_cache_size;
cpu->l1_instruction_cache_size = c->x86_l1_instruction_cache_size;
cpu->l2_cache_size = c->x86_l2_cache_size;
print_timer(et, "cores-cachesizes");
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-add-cpu-id-info-for-Geode-by-NSC.patch
Type: text/x-patch
Size: 1800 bytes
Desc: not available
URL: <http://www.zytor.com/pipermail/hdt/attachments/20110402/e6dff0a4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fix-precedence-problem-in-multi-space-check.patch
Type: text/x-patch
Size: 931 bytes
Desc: not available
URL: <http://www.zytor.com/pipermail/hdt/attachments/20110402/e6dff0a4/attachment-0001.bin>
More information about the HDT
mailing list