[syslinux] memdisk load failure on HP DL360g9

[Ady Ady]

> 
> 
> 
> On Thu, Feb 2, 2017 at 1:26 PM, Ady Ady via Syslinux 
> <syslinux at zytor.com > wrote:
>     
>     > Hi all,
>     >
>     > I have observed a problem where, under legacy BIOS booting mode on the
>     > DL360g9, memdisk fails to execute.  The same mechanism works fine on 
>     the
>     > DL360g8.  The system displays the below on the console and ceases to
>     > respond and must be power cycled.  Updating the firmware didn't help.
>     > There didn't appear to be any similar issues on the mailing list 
>     unless I
>     > missed them.
>     >
>     > Wondering if this has been observed before and whether or not there 
>     is an
>     > existing resolution or workaround?
>     >
>     > e820: 00000000000e0000 0000000000020000 2
>     > e820: 0000000000100000 000000005a6a1000 1
>     > e820: 000000005a7a1000 0000000000e40000 2
>     > e820: 000000005b5e1000 000000001db1e000 1
>     > e820: 00000000790ff000 0000000000100000 2
>     > e820: 00000000791ff000 0000000002400000 4
>     > e820: 000000007b5ff000 0000000000200000 3
>     > e820: 000000007b7ff000 0000000000001000 1
>     > e820: 000000007b800000 0000000000800000 2
>     > e820: 000000007c000000 0000000003c00000 2
>     > e820: 000000007fc00000 0000000000400000 2
>     > e820: 0000000080000000 0000000010000000 2
>     > e820: 00000000ff800000 0000000000800000 2
>     > e820: 0000000100000000 0000001f80000000 1
>     > Ramdisk at 0x57ba1000, length 0x02c00000
>     > command line: raw harddisk
>     > MEMDISK: Image seems to have fractional end cylinder
>     > Disk is hd0, 45056 K, C/H/S = 5/255/63 (MBR/MBR), EDD on, rw
>     > Using raw access to high memory
>     > Code 1744, meminfo 228, cmdline 13, stack 512
>     > Total size needed = 2497 bytes, allocating 3K
>     > Old dos memory at 0x90c00 (map says 0x94000), loading at 0x90000
>     > 1588: 0xffff 15E801: 0x3c00 0x56ba
>     > INT 13 08: Success, count = 3, BPT = 0000:0000
>     
>     
> 
>     Are there relevant differences between these two systems (such as type
>     and amount of RAM)?
> 
> Both systems consist of 128GB RDIMM RAM; g8 = DDR3 and g9 = DDR4.
> 
 
 
Have you considered the possibility that memtest86+ v5.01 doesn't 
support your type/amount of RAM in this chipset/mainboard?

Have you tested the "other" memtest (the one from Passmark), also in 
CSM/BIOS mode?
 
 
> 
>     Are the "BIOS" settings exactly the same in both systems?
 
 
No answer, moving on.
 
 
>     
>     Would you please post the entire syslinux.cfg?
> 
> iPXE is used in place of syslinux here.
 
 
Perhaps using Syslinux would be worth a try, at least to eliminate the 
possibility of some interaction issue between iPXE and MEMDISK. Such 
potential problematic interactions are in evidence, for instance when I 
described (in my prior email) the different behavior seen when using 
Syslinux 4.xx vs. Syslinux 6.xx in certain systems. In other words, the 
specific bootloader that is being used before MEMDISK might be relevant 
too.
 
 
> 
> Machines booting under these circumstances boot via the following iPXE 
> commands:
> 
> kernel http://192.168.1.2/path/to/memdisk
> imgargs memdisk raw harddisk
> initrd http://192.168.1.2/path/to/boot.img
> boot
> 
> "harddisk" changes to "floppy" when attempting to boot a DOS or memtest 
> floppy image.
 
 
Have you tested with no RAW, or with the other set of options? (I don't 
recall whether memtest86+ needs RAW.)
 
 
> 
> 
>     Have you attempted to use/set "complete" CHS values for this HDD image?
> 
> No
 
 
Considering that the error message from MEMDISK includes a "partial" 
CHS image, I would tend to think this could be worth a test.
 
 
> 
> 
>     Which CHS values are detected by memdisk when the same HDD image is
>     booted in the "g8" system?
> 
> 6/256/63; these same values were detected by memdisk when attempting to 
> load memtestp.bin from the memtest floppy.
 
 
This is confusing. I don't really understand how MEMDISK could parse a 
simple 1440K floppy image as having a CHS geometry of 6/256/63; not 
only because a 1440K floppy should be 80/2/18, but also because of the 
"256".
 
 
> 
> 
>     Is the problem happening with every-and-all (HDD) images? Have you
>     tried with a simple 1440K floppy image too? (It doesn't matter what
>     happens next within the floppy, but rather whether you get the same
>     type of error message from memdisk.)
> 
> Booting to memtest86+-5.01.bin exhibits the same behavior while booting 
> memtestp.bin (from the floppy image) is executing something (constant 
> scrolling of 0X:0200-like messages on stdout).  A separate bootable 
> floppy (allbootdisks.com) was also successfully booted to a DOS prompt.
> 
 
 
It makes me doubt whether you are actually using adequate parameters 
for MEMDISK with memtest86+.
 
 
> 
>     Which exact version of Syslinux are we talking about? Package? Official
>     pre-built binaries? Your own build?
> 
> As previously mentioned, iPXE is used in place of syslinux.
> 
> 
>     Are the binaries (e.g. the bootloader file, c32 files, memdisk, etc.)
>     originated from the same exact build?
> 
> Only the memdisk binary in varying versions has been tested, all of 
> which exhibited identical behavior.
> 
> MEMDISK 4.05 0x4ee25341
> MEMDISK 6.03 0x5873ba2a
> MEMDISK 6.04 pre1-20-gbb41e93
> 
 
 
So, potential "Building" interactions too.
 
 
> 
>     I would like to ask you to try the same Syslinux binaries to boot
>     memtest86+ (please use the one from www.memtest.org ).
>     
>     The reason for this memetst86+ request is not to actually test your RAM
>     (which might be useful anyway), but rather to test whether the
>     memtest86+ kernel is correctly booting (using Syslinux) in these
>     machines. There have been reports in which the memtest86+ 5.01 kernel
>     fails to boot in certain hardware (e.g. Dell XPS 13 9350, BIOS version
>     1.4.10, November 22, 2016) when it is being launched from Syslinux
>     6.03+ but it runs correctly in the same hardware when Syslinux 4.xx is
>     used instead. Such reports would suggest the possibility of a
>     regression bug / problem in Syslinux 6.xx in comparison to 4.xx.
> 
> Booting to memtest86+-5.01.bin exhibits the same behavior.
 
 
This is confusing. Directly booting the "linux-like" kernel (using 
"LINUX" instead of "KERNEL" in Syslinux) shows the _same_ error as when 
using MEMDISK? I could understand a different error message, but the 
same? I must be misunderstanding.

So:
_ memtest86+ v5.01 fails in several ways.

_ MEMDISK built by yourself from different versions / commits fails. No 
official binaries were tested.

_ MEMDISK is being launched from iPXE, not from the bootloaders of the 
Syslinux family.

_ a "complete" image aligned to "proper" CHS values has not been 
tested.

_ a floppy image reports incoherent CHS values.


Am I misunderstanding?
 
 
> 
> 
> --
> Take care
> Rick Miller


Regards,
Ady.