[OmniOS-discuss] hangs on reboot

[Stephan Budach]

Am 12.12.14 um 08:58 schrieb Jim Klimov:
> 12 декабря 2014 г. 8:35:18 CET, Jim Klimov <jimklimov at cos.ru> пишет:
>> 11 декабря 2014 г. 23:41:35 CET, Rune Tipsmark <rt at steait.net> пишет:
>>> NIC's are not shared with IPMI.
>>>
>>>
>>>
>>> I will try the target-mode first, however on the 3rd box I actually
>>> have Infiniband and it also caused the same issue without touching the
>>> target-mode for FC.
>>>
>>>
>>>
>>> I have a 4th system on an old HP server and it reboots perfect every
>>> time, no target-mode and has Infiniband as well... I am leaning
>> towards
>>> something with the SuperMicro hardware but can't really pinpoint it.
>>>
>>> br,
>>>
>>> Rune
>>>
>>> ________________________________
>>> From: Dan McDonald <danmcd at omniti.com>
>>> Sent: Thursday, December 11, 2014 11:39 PM
>>> To: Rune Tipsmark
>>> Cc: omnios-discuss at lists.omniti.com
>>> Subject: Re: [OmniOS-discuss] hangs on reboot
>>>
>>> Nothing printed out on the console?
>>>
>>> And try eliminating the target mode first - just in case.
>>>
>>> Also, is one of your NICs a dual IPMI/host NIC?  If so, disable the
>>> IPMI portion, we don't cope with shared NIC ports like that.
>>>
>>> Dan
>>>
>>> Sent from my iPhone (typos, autocorrect, and all)
>>>
>>> On Dec 11, 2014, at 5:25 PM, Rune Tipsmark
>>> <rt at steait.net<mailto:rt at steait.net>> wrote:
>>>
>>>
>>> hi all,
>>>
>>>
>>>
>>> I got a bunch (3) installations of omnios on SuperMicro hardware and
>>> all 3 have issues rebooting. They simply hang and never ever reboot.
>>>
>>>
>>>
>>> The install is latest version and I only added the storage-server
>>> package and installed napp-it and changed the fibre channel setting in
>>> /kernel/drv/emlxs.conf target-mode=1
>>>
>>>
>>>
>>> two nics igb0 and igb1 configured as aggregation (aggr0)
>>>
>>>
>>>
>>> besides this its 100% default install, not 10 minutes old...
>>>
>>>
>>>
>>> Any ideas?
>>>
>>> br,
>>>
>>> Rune
>>>
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com<mailto:OmniOS-discuss at lists.omniti.com>
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>> I've installed latest bloody on an HP Z400 workstation last week with
>> an lsi 9212 addon hba, and it too needed to disable fastboot.
>>
>> IIRC this is somehow tied to ability of all drivers to quiesce like for
>> standby - if some one refuses to, suspend or fastboot fail.
>> IMHO the fastboot handler should have a reasonable/configurable timeout
>> after 'stand by for reboot' to do slowboot if that expires.
>>
>> Alternately on servers you can set up bmc-watchdog and have the mobo
>> reboot itself. But then use long timeouts (10-15 min) and/or take care
>> that the watchdog driver is among the first pieces of software that
>> runs in your bootup or especially 'live' repair-boots.
>>
>> HTH,
>> Jim
>> --
>> Typos courtesy of K-9 Mail on my Samsung Android
> Forgot to add my 2c: if the driver quiesce is at fault, maybe it is also a signal for devs to improve at least nominal hw support for new usb3, video chips, maybe some sata HBAs?
> Even if they don't perform optimally (i.e. let usb3 be as slow as usb2 or usb1, or let radeon be a vesa-video, but let it work without errors) -- they should not impede system work either.
>
> Jim
> --
I have recently bought a new SuperMicro which showed exactly the same 
behaviour regarding fast reboots. Rebooting through the prom however, 
worked each time I can remember trying it. That system had been 
originally installed using the release 006 of OmniOS. After upgrading to 
012 stable, these issues seem to have gone. The only thing that is 
different on the new host is, that it's equipped with a SSD DOM instead 
of a "traditional" HD,. This DOM is stuffed in SATA0 and somewhat cabled 
to the MB, so it's not just a dumb one. This cable seems to be a bit 
picky about its connection of the plug that goes into the DOM.

As for 012… I just performed 4 fast reboots in a row without issues on 
my new SuperMicro box…

Cheers,
budy