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 -- Take care Rick Miller
> 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 > > -- > Take care > Rick MillerAre there relevant differences between these two systems (such as type and amount of RAM)? Are the "BIOS" settings exactly the same in both systems? Would you please post the entire syslinux.cfg? Have you attempted to use/set "complete" CHS values for this HDD image? Which CHS values are detected by memdisk when the same HDD image is booted in the "g8" system? 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.) Which exact version of Syslinux are we talking about? Package? Official pre-built binaries? Your own build? Are the binaries (e.g. the bootloader file, c32 files, memdisk, etc.) originated from the same exact build? 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. Regards, Ady. PS: I am hoping the OP is subscribed to the Syslinux Mailing List.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux
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. Are the "BIOS" settings exactly the same in both systems?> > Would you please post the entire syslinux.cfg? >iPXE is used in place of syslinux here. 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 attempted to use/set "complete" CHS values for this HDD image?>No 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. 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. 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 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. -- Take care Rick Miller
On 02/02/17 08:54, Rick Miller via Syslinux 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. >Since this is a regression in the HP firmware, could you please file a support request with HP? -hpa