Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front panel NMI crash

[agya naila <agya.naila@xxxxxxxxx>]

I configure it by added nmi=ignore to my /boot/grub/grub.cfg

### BEGIN /etc/grub.d/20_linux_xen ###

submenu "Xen 4.1-amd64" {

menuentry 'Ubuntu GNU/Linux, with Xen 4.1-amd64 and Linux 3.2.0-29-generic' --class ubuntu --class gnu-linux --class gnu --c$

        insmod part_msdos

        insmod ext2

        set root='(hd0,msdos1)'

        search --no-floppy --fs-uuid --set=root 730a0f5f-4c35-4391-b760-0b6cf0cdd6a7

        echo    'Loading Xen 4.1-amd64 ...'

        multiboot       /boot/xen-4.1-amd64.gz placeholder noreboot dom0_mem=1024M nmi=ignore

        echo    'Loading Linux 3.2.0-29-generic ...'

        module  /boot/vmlinuz-3.2.0-29-generic placeholder root=UUID=730a0f5f-4c35-4391-b760-0b6cf0cdd6a7 ro rootdelay=180 q$

        echo    'Loading initial ramdisk ...'

        module  /boot/initrd.img-3.2.0-29-generic

}

And its doent work

Agya

On Wed, Feb 6, 2013 at 2:28 PM, Pasi Kärkkäinen <pasik@xxxxxx> wrote:

On Wed, Feb 06, 2013 at 12:48:50PM +0100, agya naila wrote:
>    Thank you Pasi to forward this email for me too, it seem not only me
>    facing this problem. I found this guy also found similar problem, its in
>    french but we can translate it easily using

>    google [1]http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html

>    I found parameter nmi=ignore | dom0 | fatal
>    nmi=reaction : Enables you to specify how the hypervisor reacts to a non -
>    maskable interrupt
>    (NMI) resulting from a parity or I/O error. Possible values for reaction
>    are fatal (the hypervisor
>    prints a diagnostic message and then hangs), dom0 (send a message to
>    domain0 for logging
>    purposes but continue), and ignore (ignore the error). If you do not
>    specify this option, Xen
>    uses the default value dom0 internally.
>    But its still doesn't work on my machine.
>

So you tried adding "nmi=ignore" for xen.gz in grub settings and it didn't help?
Did you try the other possible values?

-- Pasi

>    Agya

>    On Wed, Feb 6, 2013 at 12:29 PM, Pasi Kärkkäinen <[2]pasik@xxxxxx> wrote:
>
>      On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:

>      > >>> On 05.02.13 at 21:08, Pasi Kärkkäinen<[3]pasik@xxxxxx> wrote:
>      > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade
>      with
>      > > Xen 4.2.1
>      > > with Linux 3.4.28 dom0 kernel.
>      > >
>      > > Does this ring anyone's bells?
>      > >
>      > >
>      > > serial console log of the crash
>      >
>      > Which doesn't even include the message in the subject afaics, so I
>      > don't even know what you're talking about. And the other, earlier
>      > report has no useful information either.
>      >
>      > From an abstract perspective, a front panel NMI to me would mean
>      > someone pressed an NMI button on the system's front panel. You
>      > don't think Xen can do anything about this, do you? And even if
>      > the NMI has another origin, it's still a hardware generated event
>      > that Xen has no control over.
>      >
>
>      Arrfab said Xen crashes and reboots in the middle of the boot process,
>      and the blade chassis management logs the NMI error. The user is not
>      pressing (NMI) buttons.
>
>      The serial log included is everything he gets. No error visible in the
>      serial log,
>      only a crash/reboot without any errors.. No idea what could be causing
>      that..
>
>      The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.
>
>      Do you have any Xen and/or dom0 kernel options to use to do further
>      analysis?
>      -- Pasi
>

> References
>
>    Visible links
>    1. http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html
>    2. mailto:pasik@xxxxxx
>    3. mailto:pasik@xxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel