Syslinux - Nov 2013 - IPMI serial over lan disconnects seem to trigger extlinux reboots

Hi,

Thanks for your help.

On Mon, Nov 11, 2013 at 08:00:47PM -0800, H. Peter Anvin
wrote:
> There is no reason by Syslinux would reboot the system on a serial
> disconnect.  There could be a bug, of course; now, Syslinux 4.05 is
> pretty old so unless you can reproduce this on a current version that
> would be useful.
I am using 4.05 because that's what's packaged in the latest Fedora
release (Fedora 19 in my case).  I wonder why they are using such an
old version.  I will take a look at how difficult it would be to build
the latest version on Fedora.
> The other option is that there is something in the IPMI BC that causes
> the reboots which happens on Syslinux and not Grub for some reason.
That could well be the case.  I am just speculating about the cause.  I really
do not know what is going wrong.  There is some kind of bad interaction
occurring during the load of the initramfs.  If I disable the IPMI serial
console session, the system boots fine.  So it must be some strange interaction
between the IPMI BMC and Syslinux.  
> You may want to turn serial interrupts on (serial 0 57600 0x00b) and see
> if that makes any difference.
I tried that, but it did not help.  The system still tends to reboot while
loading the initramfs.

Thanks,
Andy

On 11/12/2013 01:22 PM, Andrew J. Schorr wrote:
> Hi,
> 
> Thanks for your help.
> 
> On Mon, Nov 11, 2013 at 08:00:47PM -0800, H. Peter Anvin wrote:
>> There is no reason by Syslinux would reboot the system on a serial
>> disconnect.  There could be a bug, of course; now, Syslinux 4.05 is
>> pretty old so unless you can reproduce this on a current version that
>> would be useful.
> 
> I am using 4.05 because that's what's packaged in the latest Fedora
> release (Fedora 19 in my case).  I wonder why they are using such an
> old version.  I will take a look at how difficult it would be to build
> the latest version on Fedora.
> 
>> The other option is that there is something in the IPMI BC that causes
>> the reboots which happens on Syslinux and not Grub for some reason.
> 
> That could well be the case.  I am just speculating about the cause.  I
really
> do not know what is going wrong.  There is some kind of bad interaction
> occurring during the load of the initramfs.  If I disable the IPMI serial
> console session, the system boots fine.  So it must be some strange
interaction
> between the IPMI BMC and Syslinux.  
> 
>> You may want to turn serial interrupts on (serial 0 57600 0x00b) and
see
>> if that makes any difference.
> 
> I tried that, but it did not help.  The system still tends to reboot while
> loading the initramfs.
> 
One possibility is that either the PXE stack or the BMC uses memory that
it shouldn't.  Try setting a mem= option with less memory than you
actually have and see if that changes things.

	-hpa

Hi,

On Tue, Nov 12, 2013 at 01:41:29PM -0800, H. Peter Anvin
wrote:
> On 11/12/2013 01:22 PM, Andrew J. Schorr wrote:
> > I am using 4.05 because that's what's packaged in the latest
Fedora
> > release (Fedora 19 in my case).  I wonder why they are using such an
> > old version.  I will take a look at how difficult it would be to build
> > the latest version on Fedora.
FYI, it is not so easy to package for Fedora.  I see there is an open
bug to get this upgraded:

   https://bugzilla.redhat.com/show_bug.cgi?id=869540
> One possibility is that either the PXE stack or the BMC uses memory that
> it shouldn't.  Try setting a mem= option with less memory than you
> actually have and see if that changes things.
That's an interesting idea.  I may give that a try.  Just to be clear,
are you talking here about the kernel "mem=" boot parameter, as
documented
in kernel-parameters.txt?

        mem=nn[KMG]     [KNL,BOOT] Force usage of a specific amount of memory
                        Amount of memory to be used when the kernel is not able
                        to see the whole system memory or for test.
                        [X86] Work as limiting max address. Use together
                        with memmap= to avoid physical address space collisions.
                        Without memmap= PCI devices could be placed at addresses
                        belonging to unused RAM.

I wonder if that has negative implications for subsequent system performance...

I also think I had the same troubles booting into memtest, so it may be
a more general problem.

Probably the best solution would be to replace these machines with newer
ones, but that will be painful since they are in the field.

Thanks,
Andy