[hdt] [syslinux] [patch] ~420 seconds in cpu_detect

[Erwan Velu]

Hey  Jim,

Thx for your patches and tests.

Both of them got applied in my HDT repository and will be merged once HDT
0.5.0 will be ready.

Any idea why we have patch 1 & 3 of 3 ? Looks like 2/3 is missing.

Cheers,
Erwan

2011/4/2 Jim Cromie <jim.cromie at gmail.com>

> 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");
> }
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.zytor.com/pipermail/hdt/attachments/20110413/57af7fc2/attachment.html>