similar to: [PATCH] gpllib: fix call to CPUID function 4

Background: Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co.,Ltd., aims at providing high performance x86 processor for China server market. Its first generation processor codename is Dhyana, which originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different

Hi, When testing syslinux on Hygon Dhyana processor, there are some information as follows: boot: cpuidtest.c32 Vendor = Unknown Vendor ... boot: ifcpu.c32 debug multicore multicore : 1 cores on this system After adding support for Hygon Dhyana processor, the info- rmation is correct: boot: cpuidtest.c32 Vendor = Hygon ... boot: ifcpu.c32 debug multicore multicore : 64 cores on this

The code was passing sizeof(char *) - not the length of the buffer - to strlcpy and snprintf. Change the function to take the length of the buffer as a parameter. Fixes the warning: argument to 'sizeof' in 'snprintf' call is the same expression as the destination; did you mean to provide an explicit length? Signed-off-by: Jonathan Boeing <jonathan.n.boeing at gmail.com>

The speed value is available since version 2.3 of the SMBIOS specification. Set the default speed string to "Unknown" for older versions. - Sebastian Index: syslinux-3.74-20-g3b80c26/com32/gpllib/dmi/dmi.c =================================================================== --- syslinux-3.74-20-g3b80c26.orig/com32/gpllib/dmi/dmi.c +++ syslinux-3.74-20-g3b80c26/com32/gpllib/dmi/dmi.c @@

Here is a partial patch that I'm using to illustrate a few questions that I have. Looking at the gpllib write_sectors (com32/gpllib/disk/write.c) it looks like the allocated size is wrong; size is in sectors so we should adjust the alloc/memcpy by size*SECTOR. Also, comparing core/diskio.c it looks like the registers aren't even setup right. In the patch below I put an #if 0 around the

From: Borislav Petkov <bp at suse.de> Use boot_cpu_has() instead. Signed-off-by: Borislav Petkov <bp at suse.de> Cc: virtualization at lists.linux-foundation.org Cc: sparmaintainer at unisys.com --- arch/x86/events/intel/cstate.c | 2 +- arch/x86/events/intel/uncore.c | 2 +- arch/x86/include/asm/cpufeature.h | 1 -

From: Borislav Petkov <bp at suse.de> Use boot_cpu_has() instead. Signed-off-by: Borislav Petkov <bp at suse.de> Cc: virtualization at lists.linux-foundation.org Cc: sparmaintainer at unisys.com --- arch/x86/events/intel/cstate.c | 2 +- arch/x86/events/intel/uncore.c | 2 +- arch/x86/include/asm/cpufeature.h | 1 -

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

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

From: Borislav Petkov <bp at suse.de> Using static_cpu_has() is pointless on those paths, convert them to the boot_cpu_has() variant. No functional changes. Reported-by: Nadav Amit <nadav.amit at gmail.com> Signed-off-by: Borislav Petkov <bp at suse.de> Cc: Aubrey Li <aubrey.li at intel.com> Cc: Dave Hansen <dave.hansen at intel.com> Cc: Dominik Brodowski <linux

I'm seeing some sporadic build failures with 'make -j4'. The failures are: make[4]: *** No rule to make target 'hello.c32', needed by 'all'. Stop. I've only seen the failures with com32/samples/hello.c32 and com32/rosh/rosh.c32. I'm not a make expert, but I think it's due to missing dependencies. This patch seems to fix my failures, but I'm

The following makes 'x86info -r' dump hypervisor leaf cpu ids (for kvm this is signature+features) when running in a vm. On the guest we see the signature and the features: eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 Hypervisor flag is checked to avoid output changes when

The following makes 'x86info -r' dump hypervisor leaf cpu ids (for kvm this is signature+features) when running in a vm. On the guest we see the signature and the features: eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 Hypervisor flag is checked to avoid output changes when

Add detection code for "FreeDOS (eXtended FDisk)" MBR to disklib. Signed-off-by: Gert Hulselmans <gerth at zytor.com> --- com32/gpllib/disk/mbrs.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/com32/gpllib/disk/mbrs.c b/com32/gpllib/disk/mbrs.c index 37309e1..6150fcf 100644 --- a/com32/gpllib/disk/mbrs.c +++ b/com32/gpllib/disk/mbrs.c @@ -27,7 +27,6

Add detection code for "MS-DOS 3.30 through Windows 95 (A)" MBR to disklib. Signed-off-by: Gert Hulselmans <gerth at zytor.com> --- com32/gpllib/disk/mbrs.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/com32/gpllib/disk/mbrs.c b/com32/gpllib/disk/mbrs.c index 77e4180..37309e1 100644 --- a/com32/gpllib/disk/mbrs.c +++ b/com32/gpllib/disk/mbrs.c @@

Hi, Gene Cumm wrote: > > 3) It feels like this is a moving target where gcc keeps changing and > > different results get reported. Do we have indications that different versions of gcc5 cause different behavior on the same build and boot machines ? Ady wrote: > Since the issue is only present on specific > hardware / firmware, whatever might seem to "solve" the

Hi Peter, Please pull the following changes. Paulo, I had to revert your "pxe: resolve names via DNS from protected-mode code" change because dns_resolv() is only implemented for PXELINUX and causes undefined symbol references for ISOLINUX, etc. Feel free to make the change again on top of the revert. The following changes since commit e7bd19def830e8341b1a100956345f1028740b9e:

Hello Erwan, You will find below a pull request for the bug reported by Robert Jordan in the disk library. The first patch is the one he tested (see http://syslinux.zytor.com/archives/2010-September/015341.html) and the second one is a sanity check for the number of sectors written by call ( see http://syslinux.zytor.com/archives/2010-September/015342.html). Thanks, The following changes

Hi, Matt Fleming wrote: > ld: libpng/pngrtran.o: warning: relocation against `png_do_read_filler' in readonly section `.text'. > ld: warning: creating a DT_TEXTREL in object. > > Looks like your files aren't position-independent. What does, > > file com32/gpllib/dmi/dmi.o > > say? # file com32/gpllib/dmi/dmi.o com32/gpllib/dmi/dmi.o: ELF 32-bit LSB

Based on syslinux 6.03 Memory allocation and copy length should be SECTOR * size for sectors operation. Signed-off-by: Robert <luyao-c at 360.cn> diff --git a/com32/gpllib/disk/write.c b/com32/gpllib/disk/write.c index d183ade..3c9edff 100644 --- a/com32/gpllib/disk/write.c +++ b/com32/gpllib/disk/write.c @@ -40,7 +40,7 @@ int write_sectors(const struct driveinfo *drive_info, const