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>
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>
Ah yes,
sitting in drafts.
Note the diff between your cache size and Memtests.
and between /proc/cpuino's model and your Model ID
I dont think the x86_64 is right either.
hth,
Jim
Memtest86+ v4.10 | Pass 3% #
Pentium-MMX 266.6MHz | Test 4% #
L1 Cache: 16K 227 MB/s | Test #3 [Moving inversions, 8 bit pattern]
L2 Cache: Unknown | Testing: 188K - 128M 128M
L3 Cache: None | Pattern: 80808080
Memory : 128M 81 MB/s |-------------------------------------------------
Chipset :
under hdt, processor info is:
Vendor : National Semiconductor
Model : Geode(TM) Integrated Processor by
L1 Cache : 0K + 0K (I+D)
L2 Cache : 0K
Family ID : 5
Model ID : 4
Stepping : 0
SMP : No
x86_64 : Yes
under linux, /proc/cpuinfo contains:
processor : 0
vendor_id : Geode by NSC
cpu family : 5
model : 9
model name : Unknown
stepping : 1
cpu MHz : 266.684
static const struct cpu_dev __cpuinitconst cyrix_cpu_dev = {
.c_vendor = "Cyrix",
.c_ident = { "CyrixInstead" },
.c_early_init = early_init_cyrix,
.c_init = init_cyrix,
.c_identify = cyrix_identify,
.c_x86_vendor = X86_VENDOR_CYRIX,
};
cpu_dev_register(cyrix_cpu_dev);
static const struct cpu_dev __cpuinitconst nsc_cpu_dev = {
.c_vendor = "NSC",
.c_ident = { "Geode by NSC" },
.c_init = init_nsc,
.c_x86_vendor = X86_VENDOR_NSC,
};
cpu_dev_register(nsc_cpu_dev);