[OmniOS-discuss] hangs on reboot

[Schweiss, Chip]

There is one situation that svccfg changes are not turning off fast
reboot.   If the system has a panic the next boot will have an automated
reboot that gets hung.

I'm assuming this is the crash dump being collected then a reboot
initiated.

Anyone know how to fix this one or how to collect better information on
where the fast reboot is coming from?

-Chip

On Fri, Dec 12, 2014 at 5:24 AM, Stephan Budach <stephan.budach at jvm.de>
wrote:
>
> 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
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20141212/cdb6824a/attachment-0001.html>